From nobody Tue May 1 00:34:56 2018 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 CBE7C127909 for ; Tue, 1 May 2018 00:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNkP_HpH23Yi for ; Tue, 1 May 2018 00:34:52 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE809120047 for ; Tue, 1 May 2018 00:34:51 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 473C26B1; Tue, 1 May 2018 09:34:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id ke1aU7SVzEEB; Tue, 1 May 2018 09:34:47 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 1 May 2018 09:34:49 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id ECA4F20035; Tue, 1 May 2018 09:34:48 +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 1t3k_uLxY35U; Tue, 1 May 2018 09:34:48 +0200 (CEST) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8CC7820031; Tue, 1 May 2018 09:34:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4F65F42C87B5; Tue, 1 May 2018 09:34:48 +0200 (CEST) Date: Tue, 1 May 2018 09:34:48 +0200 From: Juergen Schoenwaelder To: Kent Watsen Cc: NetMod WG Message-ID: <20180501073448.vs642cc2mpuzrvv3@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , NetMod WG References: <20180427.120325.419501937185262392.mbj@tail-f.com> <11da9315-40d9-60cd-d32f-b0ac4a5640c4@cisco.com> <45f5a97d205a9251b382687f54865c62250787cb.camel@nic.cz> <99aac5c0-aa2f-1a35-8a5c-ad97635e5a40@cisco.com> <20180427144708.6ekknrajexvz5yvf@elstar.local> <4305e62a9d301da22f89a0dd9a34c9c4882735af.camel@nic.cz> <87d0yglra0.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 07:34:55 -0000 On Mon, Apr 30, 2018 at 05:57:34PM +0000, Kent Watsen wrote: > > I don't understand talk about abandoning this draft. There is no question > that it is needed (e.g., anima vouch, zerotouch, tail-f's "structure"), > and RFC 8040 is unsatisfactory because 1) it doesn't allow a top-level > 'choice' between two containers and 2) it requires drafts to reference > RFC 8040, even though the drafts may have nothing to do with RESTCONF. > Re 1: RFC 8040 says: "It MUST contain data definition statements that result in exactly one container data node definition." So a choice may actually work as long as the result is exactly one container data node. OK, the wording in the RFC 8040 statement is not clear since 'result' and 'definition' do not line up (does 'result' mean the toplevel data node instances that are possible? In this case, 'definition' would be misleading). Re 2: It does not really matter whether you import the extension from RFC 8040 or some other module. Why is depending on A better than depending on B? The definition in RFC 8040 is already know by tools. I view the yang-data definition of RFC 8040 as a temporary solution, a proper solution should in my view be part of YANG 1.x. Since NMDA essentially binds all data tree definitions to datastores, the yang-data construct allows us to define data structures that are specifically not bound to any datastore, i.e., data structures that by design can't be operated on directly with NMDA NETCONF/RESTCONF. /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 1 13:03:56 2018 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 3A8971242F7 for ; Tue, 1 May 2018 13:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bu0NipYZi5dX for ; Tue, 1 May 2018 13:03:51 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 BE7E5120721 for ; Tue, 1 May 2018 13:03:51 -0700 (PDT) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w41Jx0PU019742; Tue, 1 May 2018 13:03:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=0wmFMbIGze1PPueCa5hNLZR0tLfTMUTAtT4/Wcn2xdc=; b=CZBlsQKqDIA23TjS+76mM4UseBBCW1cGUBlVWZPv4gkmKdQz2gyk7JyqIxp0LBs8hIgj AlwaNFwN7kl1mIO/w0EJGfljefzAS00B7eo7qoWol6Afmxavrat+3u1laK/YwvC/fVQn KT72Suv5amn9gXZGocku6bxSXwyxmEPT6ipYOHPJu9hhHAURMwdM4fG/5sE0pBYSwmbb Y6NPgU9TRJanfnSt9nJZkdRLCNu4ZGWvWybwf53qyAkGE27GsMwAPV4mVPQU/gPDoVmb T6KdJngRUxVplOr5M66zgNL/iiIYXtPuuwW7RRzeugzEfD9iv08wKmf/AOGLHGQrF2XL 6w== Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0115.outbound.protection.outlook.com [207.46.163.115]) by mx0b-00273201.pphosted.com with ESMTP id 2hpxg101h2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 01 May 2018 13:03:48 -0700 Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4151.namprd05.prod.outlook.com (52.135.199.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.12; Tue, 1 May 2018 20:03:47 +0000 Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::44ac:d4a9:49d0:101e]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::44ac:d4a9:49d0:101e%13]) with mapi id 15.20.0735.006; Tue, 1 May 2018 20:03:47 +0000 From: Kent Watsen To: "mjethanandani@gmail.com" , "lyihuang16@gmail.com" , "sagarwal12@gmail.com" , "dblair@cisco.com" CC: "netmod@ietf.org" Thread-Topic: [netmod] IPR call on draft-ietf-netmod-acl-model-18 Thread-Index: AQHT4YeDC6Spas57z02IfO7BNMTXtg== Date: Tue, 1 May 2018 20:03:47 +0000 Message-ID: <60E03C57-6239-4C07-8ECE-4FD788B9002A@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB4151; 7:uMHHPbbbjSXioSJ1aDmG18wfIVy6lcu0s/bMrn5GxX0p5MR0vql0zPzwMAcRpRJZDW8PGnY5k41L2gIi3jiMkwD+DRv0R10zOO7yyxywH7taoaOSFLKNRkhh7hJq8oyRp9hKZ+anEAYnt+24/JqSKB1m0cXRm1+SadvsoqXwBA2usM5U5ZFi/ojncBeiYy3FW4eE6VwjJ+DB70tp7O4Io/nEM0DdGikYMJWE8g7MGCVa7Y+1YIpvuXWPFCYoKmdW x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4151; x-ms-traffictypediagnostic: BYAPR05MB4151: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041310)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:BYAPR05MB4151; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4151; x-forefront-prvs: 06592CCE58 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(346002)(366004)(376002)(396003)(39860400002)(189003)(199004)(81166006)(81156014)(36756003)(8936002)(6436002)(4326008)(97736004)(966005)(14454004)(5250100002)(25786009)(2501003)(486006)(476003)(305945005)(6486002)(316002)(2616005)(8676002)(2906002)(110136005)(68736007)(33656002)(39060400002)(58126008)(7736002)(83716003)(106356001)(26005)(102836004)(3280700002)(3846002)(6306002)(82746002)(6512007)(6506007)(6246003)(186003)(66066001)(6116002)(478600001)(99286004)(53936002)(2900100001)(229853002)(2201001)(86362001)(575784001)(5660300001)(105586002)(3660700001)(48284002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4151; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: NNUAhzwSYG7Mdo+Yu7iCjU4aR/l9oWxPb6rckXRMZpkW8XUke3uLyMQFGCa9/wxxx8YIh/n/MsrJPJJ6QXuw7fvXcLlCjANwNf/VVcXVTaG5Qhq3ooNm/DHafSQ0enFuFHTgV1fjWd0x6oT+AHwGn98xRrj1mFtT26xufa7+IMN9X6bBzt+4+ohCizlTspGk spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 2494648c-4bfe-4a19-1b42-08d5af9ea658 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 2494648c-4bfe-4a19-1b42-08d5af9ea658 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 May 2018 20:03:47.2653 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4151 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-01_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805010193 Archived-At: Subject: Re: [netmod] IPR call on draft-ietf-netmod-acl-model-18 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 20:03:55 -0000 VGhhbmsgeW91LCBNYWhlc2ggYW5kIFNvbmFsLiAgDQoNCkknbSBzdGlsbCB3YWl0aW5nIHRvIGhl YXIgZnJvbSBMaXNhIGFuZCBEYW5hLiAgTmVpdGhlciBoYXZlIGJlZW4gaGVhcmQgZnJvbSBzaW5j ZSB0aGUgcGVuIG1vdmVkIGEgY291cGxlIHllYXJzIGFnby4gIElzIGFueW9uZSBhd2FyZSBvZiBM aXNhIG9yIERhbmEncyBjdXJyZW50IGVtYWlsPw0KDQpMZXQncyBnaXZlIGl0IGEgZmV3IGRheXMg YnV0LCBpZiB3ZSBkb24ndCBoZWFyIGJhY2sgZnJvbSB0aGVtIHNob3J0bHksIEkgcmVjb21tZW5k IG1vdmluZyB0aGVpciBuYW1lcyBmcm9tIGF1dGhvcnMgdG8gY29udHJpYnV0b3JzIHNvIHdlIGNh biB1bmJsb2NrIHRoZSBwdWJsaXNoaW5nIHByb2Nlc3MuDQoNClRoYW5rcywNCktlbnQgLy8gc2hl cGhlcmQNCg0KDQo9PT09PSBvcmlnaW5hbCBtZXNzYWdlID09PT09DQoNCkF1dGhvcnMsIENvbnRy aWJ1dG9ycywgV0csDQoNCkFzIHBhcnQgb2YgU2hlcGhlcmQgd3JpdGUtdXAgZm9yIHRoZSBhY2wt bW9kZWwgZHJhZnQsIHdlIG5lZWQgdG8gZW5zdXJlIHRoYXQgYWxsIElQUiBoYXMgYmVlbiBkZWNs YXJlZC4gIFRoZXJlIHdhcyBhbiBJUFItY2FsbCBiZWZvcmUsIHdoZW4gdGhlcmUgd2FzIGEgZGlm ZmVyZW50IHNldCBvZiBhdXRob3JzIGludm9sdmVkLCBidXQgbm90IHNpbmNlLCBzbyBpdCBzZWVt cyBwcnVkZW50IHRvIGRvIGFub3RoZXIgY2FsbCBub3cuIA0KDQpBcmUgeW91IGF3YXJlIG9mIGFu eSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0IGlkZW50aWZpZWQgYWJvdmU/DQoNCg0KUGxlYXNl IHN0YXRlIGVpdGhlcjoNCiAgICAiTm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFw cGxpZXMgdG8gdGhpcyBkcmFmdCINCiAgb3INCiAgICAiWWVzLCBJJ20gYXdhcmUgb2YgSVBSIHRo YXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KDQoNCklmIHllcywgaGFzIHRoaXMgSVBSIGJlZW4g ZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcw0KKHNlZSBSRkNzIDM5 NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscyk/IFBsZWFzZSBzdGF0ZQ0K ZWl0aGVyOg0KICAgICJZZXMsIHRoZSBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFu Y2Ugd2l0aCBJRVRGIElQUiBydWxlcyINCiAgb3INCiAgICAiTm8sIHRoZSBJUFIgaGFzIG5vdCBi ZWVuIGRpc2Nsb3NlZCINCg0KSWYgbm8sIHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlvbmFsIGRl dGFpbHMgeW91IHRoaW5rIGFwcHJvcHJpYXRlLg0KDQoNCklmIHlvdSBhcmUgbGlzdGVkIGFzIGEg ZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCBwbGVhc2UgYW5zd2VyIHRoZQ0KYWJvdmUg YnkgcmVzcG9uZGluZyB0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3Qg eW91IGFyZQ0KYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gVGhpcyBkb2N1bWVudCB3aWxsIG5v dCBhZHZhbmNlIHRvIHRoZSBuZXh0DQpzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJl Y2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGxpc3RlZA0KY29udHJpYnV0b3IuIE5PVEU6IFRI SVMgQVBQTElFUyBUTyBBTEwgT0YgWU9VIExJU1RFRCBJTiBUSElTIE1FU1NBR0UnUw0KVE8gTElO RVMuDQoNCg0KSWYgeW91IGFyZSBvbiB0aGUgV0cgZW1haWwgbGlzdCBvciBhdHRlbmQgV0cgbWVl dGluZ3MgYnV0IGFyZSBub3QgbGlzdGVkDQphcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHdl IHJlbWluZCB5b3Ugb2YgeW91ciBvYmxpZ2F0aW9ucyB1bmRlciB0aGUNCklFVEYgSVBSIHJ1bGVz IHdoaWNoIGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJlIGF3YXJl DQpvZiBJUFIgb2Ygb3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9uLCBvciB0byByZWZyYWlu IGZyb20gcGFydGljaXBhdGluZw0KaW4gYW55IGNvbnRyaWJ1dGlvbiBvciBkaXNjdXNzaW9uIHJl bGF0ZWQgdG8geW91ciB1bmRpc2Nsb3NlZCBJUFIuIEZvcg0KbW9yZSBpbmZvcm1hdGlvbiwgcGxl YXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJvdmUgYW5kDQpodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fdHJhYy50b29scy5pZXRmLm9yZ19ncm91cF9p ZXNnX3RyYWNfd2lraV9JbnRlbGxlY3R1YWxQcm9wZXJ0eSZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1 aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1lo cW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09eWowaFE5U194cmFlS2JpU3Y3TWNaWTFkaUJWVlI0RVU3 OGhua2xySTI0SSZzPXhYLWloLU1wWjFxa1hoWWxzMVVRREFLN1d1VEpuT2MyOW43WnA0bmtfR2Mm ZT0uDQoNClRoYW5rIHlvdSwNCg0KS2VudCAvLyBkb2N1bWVudCBzaGVwaGVyZCBhbmQgY28tY2hh aXINCg0KDQpQUzogUGxlYXNlIGluY2x1ZGUgYWxsIGxpc3RlZCBpbiB0aGUgaGVhZGVycyBvZiB0 aGlzIG1lc3NhZ2UgaW4geW91ciByZXNwb25zZS4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGll dGYub3JnDQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUNBZyZjPUhBa1l1 aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQ b09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09eWowaFE5U194cmFlS2JpU3Y3TWNaWTFkaUJW VlI0RVU3OGhua2xySTI0SSZzPW0tcGJJbVRsTUlWTzA3SUxDMFNwaEEtYjNELTN1ck1TT1BSM1lT V3dRWGsmZT0NCg0KDQo= From nobody Tue May 1 13:34:05 2018 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 1206712E8EC for ; Tue, 1 May 2018 13:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khDj8HJbbTB7 for ; Tue, 1 May 2018 13:34:01 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 7520A12420B for ; Tue, 1 May 2018 13:34:01 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w41KK0It001568; Tue, 1 May 2018 13:34:00 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=4KzvvdYJ8hGWxjW7B10zHQizgmoK47JVaJmDdHjG3ro=; b=LfO5VrOfth2m+3GFNCp0Wh5XDqh6E9f7/wUO18r4w40NDfc0krq4u2bn6U2mChxCGGzS Psre+cKDOPpGxtR/illb8q4gSGJcstqWL+/3kFg8xjtBcGriako+xYjcBXlw/sQuG4Wd K6Xo+ZzsvkZ+hU8EcIu+Le3VwDAH/nWn+CFc08jElm8Q6K+iflw/eC5EJVzsD5BfYShd Y6h5HFC6EH4ArOP6NsXYc1J3o256weSW4x5+yQteykTceOmFfUZWVywJKqW/CLZUyywV +4InZSiGBGtx/ii1B8DPjsC8aFLSBw8BHZzNvUtKNl2lVjLMr/TxM/re1F+61iXgWzH+ WA== Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0111.outbound.protection.outlook.com [207.46.163.111]) by mx0b-00273201.pphosted.com with ESMTP id 2hpxcwg3m9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 01 May 2018 13:34:00 -0700 Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4182.namprd05.prod.outlook.com (52.135.200.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.6; Tue, 1 May 2018 20:33:58 +0000 Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::44ac:d4a9:49d0:101e]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::44ac:d4a9:49d0:101e%13]) with mapi id 15.20.0735.006; Tue, 1 May 2018 20:33:58 +0000 From: Kent Watsen To: Juergen Schoenwaelder CC: NetMod WG Thread-Topic: [netmod] yang-data-ext issues Thread-Index: AQHT1YJYRSnZmZlnhU6JIK4LoPfNTqQEcM6AgAYAzwCAAlYhgIAB08UAgAAyUgCAATikgIAAAaSAgAGHGgCAAAK9AIAAEH6AgAACpYCAAPWtAIABPh0AgACT0YCAAAY/gIAABasAgAALQACAAARkgIAANngAgAADfgCAAAdSAIAADKEAgASYmID///yYAIABJ2YAgACWo4A= Date: Tue, 1 May 2018 20:33:58 +0000 Message-ID: <508FA1DE-87BF-425E-BC52-2C4626ACAB12@juniper.net> References: <20180427.120325.419501937185262392.mbj@tail-f.com> <11da9315-40d9-60cd-d32f-b0ac4a5640c4@cisco.com> <45f5a97d205a9251b382687f54865c62250787cb.camel@nic.cz> <99aac5c0-aa2f-1a35-8a5c-ad97635e5a40@cisco.com> <20180427144708.6ekknrajexvz5yvf@elstar.local> <4305e62a9d301da22f89a0dd9a34c9c4882735af.camel@nic.cz> <87d0yglra0.fsf@nic.cz> <20180501073448.vs642cc2mpuzrvv3@elstar.local> In-Reply-To: <20180501073448.vs642cc2mpuzrvv3@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB4182; 7:xBulur+zsB6K1wqAmP9YntmAIUrmwvOrgEz9n6xkQtHc2le28PqJohjsUEPR2dO6LJRFZ2khWIWt0o50zKdDKrego7o2aKQ+7IApfpullDOqDp32iV0ZGc3sZLKYUjYmWL+O70C8RLF0ecIZaHPCctmAW5kL5H/KqPnD7FsnsXDt9xPKYFVhoQFHVygbTV2RtB7pCFHFaGiTqf/Vn1r89pjegCYmZgoIzswYi9mzCAZZVp4Nsl5hMyiIqcenN+8l x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4182; x-ms-traffictypediagnostic: BYAPR05MB4182: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231254)(944501410)(52105095)(10201501046)(93006095)(93001095)(6055026)(6041310)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BYAPR05MB4182; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4182; x-forefront-prvs: 06592CCE58 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(376002)(396003)(366004)(346002)(189003)(199004)(86362001)(3660700001)(102836004)(26005)(3280700002)(305945005)(6486002)(68736007)(5660300001)(6916009)(6246003)(6512007)(36756003)(53936002)(4326008)(93886005)(229853002)(76176011)(6506007)(25786009)(97736004)(186003)(59450400001)(33656002)(99286004)(486006)(476003)(2900100001)(2616005)(446003)(81166006)(81156014)(5250100002)(8676002)(8936002)(6116002)(66066001)(105586002)(11346002)(6436002)(83716003)(14454004)(2906002)(3846002)(58126008)(316002)(106356001)(478600001)(82746002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4182; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: DClmh03UynLm+D9OLJ/1rHLEdVbB5/e2yfy7uWQAQ8vTM3Xz/PMsG+XMjQjvVwOTOduNlAL5+HKnn5TdItMPZ+Pbtj+5K8AqGo+o+v12d/qOXlRLnFKFbWQeql+RGNIQiXZE9rEPNcBMbB1tiaGz/0FSoWFl77aVXy4b5ySPAcqeq/RzYHRboLQ2fFJTXNs0 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 04e6c323-7c6f-4861-a9bf-08d5afa2de09 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 04e6c323-7c6f-4861-a9bf-08d5afa2de09 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 May 2018 20:33:58.6906 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4182 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-01_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805010196 Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 20:34:04 -0000 DQpKdWVyZ2VuIHdyaXRlczoNCj4gS2VudCB3cml0ZXM6DQo+PiBJIGRvbid0IHVuZGVyc3RhbmQg dGFsayBhYm91dCBhYmFuZG9uaW5nIHRoaXMgZHJhZnQuICBUaGVyZSBpcyBubyBxdWVzdGlvbg0K Pj4gdGhhdCBpdCBpcyBuZWVkZWQgKGUuZy4sIGFuaW1hIHZvdWNoLCB6ZXJvdG91Y2gsIHRhaWwt ZidzICJzdHJ1Y3R1cmUiKSwNCj4+IGFuZCBSRkMgODA0MCBpcyB1bnNhdGlzZmFjdG9yeSBiZWNh dXNlIDEpIGl0IGRvZXNuJ3QgYWxsb3cgYSB0b3AtbGV2ZWwNCj4+ICdjaG9pY2UnIGJldHdlZW4g dHdvIGNvbnRhaW5lcnMgYW5kIDIpIGl0IHJlcXVpcmVzIGRyYWZ0cyB0byByZWZlcmVuY2UgDQo+ PiBSRkMgODA0MCwgZXZlbiB0aG91Z2ggdGhlIGRyYWZ0cyBtYXkgaGF2ZSBub3RoaW5nIHRvIGRv IHdpdGggUkVTVENPTkYuDQo+Pg0KPg0KPiBSZSAxOiBSRkMgODA0MCBzYXlzOiAiSXQgTVVTVCBj b250YWluIGRhdGEgZGVmaW5pdGlvbiBzdGF0ZW1lbnRzIHRoYXQNCj4gcmVzdWx0IGluIGV4YWN0 bHkgb25lIGNvbnRhaW5lciBkYXRhIG5vZGUgZGVmaW5pdGlvbi4iIFNvIGEgY2hvaWNlIG1heQ0K PiBhY3R1YWxseSB3b3JrIGFzIGxvbmcgYXMgdGhlIHJlc3VsdCBpcyBleGFjdGx5IG9uZSBjb250 YWluZXIgZGF0YQ0KPiBub2RlLiBPSywgdGhlIHdvcmRpbmcgaW4gdGhlIFJGQyA4MDQwIHN0YXRl bWVudCBpcyBub3QgY2xlYXIgc2luY2UNCj4gJ3Jlc3VsdCcgYW5kICdkZWZpbml0aW9uJyBkbyBu b3QgbGluZSB1cCAoZG9lcyAncmVzdWx0JyBtZWFuIHRoZQ0KPiB0b3BsZXZlbCBkYXRhIG5vZGUg aW5zdGFuY2VzIHRoYXQgYXJlIHBvc3NpYmxlPyBJbiB0aGlzIGNhc2UsDQo+ICdkZWZpbml0aW9u JyB3b3VsZCBiZSBtaXNsZWFkaW5nKS4NCg0KSSBhZ3JlZSwgYnV0IE1hcnRpbiBkaWQgbm90IGFu ZCBoZSBldmVuIG1vZGlmaWVkIGBweWFuZ2AgdG8gdGhyb3cgYW4gDQplcnJvciBvbiB0aGUgemVy b3RvdWNoIGRyYWZ0LCB0aHVzIGZvcmNpbmcgdGhlIGN1cnJlbnQgc2l0dWF0aW9uLiAgSWYNCmEg bmV3IHVuZGVyc3RhbmRpbmcgcmVnYXJkaW5nIHJjOnlhbmctZGF0YSBjYW4gYmUgcmVhY2hlZCwg dGhlIHplcm90b3VjaA0KZHJhZnQgY2FuIGdvIGJhY2sgdG8gdXNpbmcgaXQuDQoNCg0KPiBSZSAy OiBJdCBkb2VzIG5vdCByZWFsbHkgbWF0dGVyIHdoZXRoZXIgeW91IGltcG9ydCB0aGUgZXh0ZW5z aW9uIGZyb20NCj4gUkZDIDgwNDAgb3Igc29tZSBvdGhlciBtb2R1bGUuIFdoeSBpcyBkZXBlbmRp bmcgb24gQSBiZXR0ZXIgdGhhbg0KPiBkZXBlbmRpbmcgb24gQj8gVGhlIGRlZmluaXRpb24gaW4g UkZDIDgwNDAgaXMgYWxyZWFkeSBrbm93IGJ5IHRvb2xzLg0KPg0KPiBJIHZpZXcgdGhlIHlhbmct ZGF0YSBkZWZpbml0aW9uIG9mIFJGQyA4MDQwIGFzIGEgdGVtcG9yYXJ5IHNvbHV0aW9uLCBhDQo+ IHByb3BlciBzb2x1dGlvbiBzaG91bGQgaW4gbXkgdmlldyBiZSBwYXJ0IG9mIFlBTkcgMS54Lg0K DQpXaGF0IGlzIHRoZSAicHJvcGVyIHNvbHV0aW9uIiwgYW5kIHdoeSBkb2VzIGl0IG5lZWQgdG8g d2FpdCBmb3IgWUFORyAxLng/DQpJbiB0aGUgZGlzY3Vzc2lvbiByZWdhcmRpbmcgbW92aW5nIGZh c3RlciwgaXQncyBiZWVuIHN1Z2dlc3RlZCB0aGF0IFlBTkcgDQoxLnggY291bGQgYmUgYSBjaGVy cnktcGlja2luZyBvZiBzb21lIG51bWJlciBvZiBleHRlbnNpb24gc3RhdGVtZW50cyANCnByb2R1 Y2VkIGluIG90aGVyIEktRHMuICBJIHdhcyBob3BpbmcgdGhhdCB0aGlzIHdhcyB0aGUgY2FzZSBo ZXJlLiAgVHJ1ZSwNCnNvbWUgdG9vbHMga25vdyBhYm91dCBBLCBidXQgaWYgQiBpcyB0aGUgTFRT LCB0aGVuIEknZCBob3BlIHRvIG1vdmUgdG8gQg0KQVNBUC4NCg0KPiBTaW5jZSBOTURBIGVzc2Vu dGlhbGx5IGJpbmRzIGFsbCBkYXRhIHRyZWUgZGVmaW5pdGlvbnMgdG8gZGF0YXN0b3JlcywNCj4g dGhlIHlhbmctZGF0YSBjb25zdHJ1Y3QgYWxsb3dzIHVzIHRvIGRlZmluZSBkYXRhIHN0cnVjdHVy ZXMgdGhhdCBhcmUNCj4gc3BlY2lmaWNhbGx5IG5vdCBib3VuZCB0byBhbnkgZGF0YXN0b3JlLCBp LmUuLCBkYXRhIHN0cnVjdHVyZXMgdGhhdCBieQ0KPiBkZXNpZ24gY2FuJ3QgYmUgb3BlcmF0ZWQg b24gZGlyZWN0bHkgd2l0aCBOTURBIE5FVENPTkYvUkVTVENPTkYuDQoNClllcy4NCg0KDQpLZW50 IC8vIGNvbnRyaWJ1dG9yDQoNCg0KDQoNCg== From nobody Tue May 1 13:43:36 2018 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 98FE9126D0C for ; Tue, 1 May 2018 13:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOuaUDEsWlck for ; Tue, 1 May 2018 13:43:31 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31B2312420B for ; Tue, 1 May 2018 13:43:30 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id AF68CD0E; Tue, 1 May 2018 22:43:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id RDuwxECmcOhP; Tue, 1 May 2018 22:43:28 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 1 May 2018 22:43:28 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5EA4020036; Tue, 1 May 2018 22:43:28 +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 tAAZ9ZB86QYU; Tue, 1 May 2018 22:43:27 +0200 (CEST) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D974C20031; Tue, 1 May 2018 22:43:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CD05242C9335; Tue, 1 May 2018 22:43:27 +0200 (CEST) Date: Tue, 1 May 2018 22:43:27 +0200 From: Juergen Schoenwaelder To: Kent Watsen Cc: NetMod WG Message-ID: <20180501204327.yfwgax2cm5kspaet@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , NetMod WG References: <45f5a97d205a9251b382687f54865c62250787cb.camel@nic.cz> <99aac5c0-aa2f-1a35-8a5c-ad97635e5a40@cisco.com> <20180427144708.6ekknrajexvz5yvf@elstar.local> <4305e62a9d301da22f89a0dd9a34c9c4882735af.camel@nic.cz> <87d0yglra0.fsf@nic.cz> <20180501073448.vs642cc2mpuzrvv3@elstar.local> <508FA1DE-87BF-425E-BC52-2C4626ACAB12@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <508FA1DE-87BF-425E-BC52-2C4626ACAB12@juniper.net> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 20:43:35 -0000 On Tue, May 01, 2018 at 08:33:58PM +0000, Kent Watsen wrote: > > Juergen writes: > > Kent writes: > >> I don't understand talk about abandoning this draft. There is no question > >> that it is needed (e.g., anima vouch, zerotouch, tail-f's "structure"), > >> and RFC 8040 is unsatisfactory because 1) it doesn't allow a top-level > >> 'choice' between two containers and 2) it requires drafts to reference > >> RFC 8040, even though the drafts may have nothing to do with RESTCONF. > >> > > > > Re 1: RFC 8040 says: "It MUST contain data definition statements that > > result in exactly one container data node definition." So a choice may > > actually work as long as the result is exactly one container data > > node. OK, the wording in the RFC 8040 statement is not clear since > > 'result' and 'definition' do not line up (does 'result' mean the > > toplevel data node instances that are possible? In this case, > > 'definition' would be misleading). > > I agree, but Martin did not and he even modified `pyang` to throw an > error on the zerotouch draft, thus forcing the current situation. If > a new understanding regarding rc:yang-data can be reached, the zerotouch > draft can go back to using it. Well, the statement in RFC 8040 is not clear (to me). > > Re 2: It does not really matter whether you import the extension from > > RFC 8040 or some other module. Why is depending on A better than > > depending on B? The definition in RFC 8040 is already know by tools. > > > > I view the yang-data definition of RFC 8040 as a temporary solution, a > > proper solution should in my view be part of YANG 1.x. > > What is the "proper solution", and why does it need to wait for YANG 1.x? > In the discussion regarding moving faster, it's been suggested that YANG > 1.x could be a cherry-picking of some number of extension statements > produced in other I-Ds. I was hoping that this was the case here. True, > some tools know about A, but if B is the LTS, then I'd hope to move to B > ASAP. You will end up with yang-data defined in ietf-restconf, yang-data defined in ietf-yang-data-ext, and something long-term stable in YANG 1.x. Do people really believe that creating three variants will be simpler and more effective? The experiment is yang-data in ietf-restconf - why do we need another experiment? /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 1 23:54:20 2018 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 1D81F12D870 for ; Tue, 1 May 2018 23:54:18 -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 5MOToLjnl7Yl for ; Tue, 1 May 2018 23:54:15 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3587E12D872 for ; Tue, 1 May 2018 23:54:15 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 6391F182015D; Wed, 2 May 2018 08:59:08 +0200 (CEST) Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 4B8541820051; Wed, 2 May 2018 08:59:05 +0200 (CEST) From: Ladislav Lhotka To: Kent Watsen , Andy Bierman Cc: NetMod WG In-Reply-To: References: <87muxq1pk9.fsf@nic.cz> <065a363753a67ee12f8bde6224009207b5fe7ee7.camel@nic.cz> <20180427.120325.419501937185262392.mbj@tail-f.com> <11da9315-40d9-60cd-d32f-b0ac4a5640c4@cisco.com> <45f5a97d205a9251b382687f54865c62250787cb.camel@nic.cz> <99aac5c0-aa2f-1a35-8a5c-ad97635e5a40@cisco.com> <20180427144708.6ekknrajexvz5yvf@elstar.local> <4305e62a9d301da22f89a0dd9a34c9c4882735af.camel@nic.cz> <87d0yglra0.fsf@nic.cz> Mail-Followup-To: Kent Watsen , Andy Bierman , NetMod WG Date: Wed, 02 May 2018 08:54:18 +0200 Message-ID: <87sh7a8s4l.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 06:54:18 -0000 Kent Watsen writes: > Lada writes: >> Andy writes: >>>IMO, the yang-data defined in RFC 8040 has a clear purpose, and it >>>is sufficient for that purpose, which is a YANG representation of >>>an instance document (such as a protocol message or file). >> >> The same is basically true even without the extension. For example, I >> fail to see any benefit from using yang-data in a module like >> ietf-zerotouch-information. > > I don't understand this, how else would you propose to define the > JSON-or-XML encoded payload of the CMS structure? Do the same, just remove the extension. I don't see any terrible things happening, and *all* tools shoud be able to process it easily. > > >>> I am in favor if keeping the yang-data in RFC 8040 and not >>> creating a new version of it that is unconstrained. >>> There does not seem to be consensus on how to do this, >>> or even consensus that it is a good idea. >> >> If the extension is deemed necessary, I would also prefer this >> approach to making the extension a Proposed Standard. > > I don't understand talk about abandoning this draft. There is no question > that it is needed (e.g., anima vouch, zerotouch, tail-f's > "structure"), So let me pose this question - why is it actually needed in these cases? I can see some need whenever such data has to be mixed with normal configuration and state data in the same module, but it is (I guess) not the case in the above applications. > and RFC 8040 is unsatisfactory because 1) it doesn't allow a top-level > 'choice' between two containers and 2) it requires drafts to reference > RFC 8040, even though the drafts may have nothing to do with RESTCONF. > > Sure, maybe we have convinced ourselves that yang-data is not needed > to model error-info, but that doesn't negate the other use case. > > We need a way to indicate that some data-model represents a stand-alone > data structure. It is not configuration, operational state, an RPC, or > a notification. It can only appear as a descendent of the 'module' That's fine, but YANG wasn't designed to be a general schema language, and I am against making such fundamental changes via extensions. Lada > statement. All 'action', 'notification', 'config', and 'if-feature' > descendent statements are ignored. For the purpose of 'must' and ' > when' statements, the yang-data structure is its own context root. It > has a namespace and a unique local name (unique only to other yang-data > defined within the same module; it's okay if an RPC, notification, or > top-level data node has the same name). Anything else? > > > Kent // contributor > > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed May 2 00:17:00 2018 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 5C20512D877 for ; Wed, 2 May 2018 00:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jL5Jecu1aQkg for ; Wed, 2 May 2018 00:16: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 506A6126E64 for ; Wed, 2 May 2018 00:16:55 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id AB0DA1AE012C; Wed, 2 May 2018 09:16:53 +0200 (CEST) Date: Wed, 02 May 2018 09:16:53 +0200 (CEST) Message-Id: <20180502.091653.2180362536464006870.mbj@tail-f.com> To: lhotka@nic.cz Cc: rwilton@cisco.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <45f5a97d205a9251b382687f54865c62250787cb.camel@nic.cz> <99aac5c0-aa2f-1a35-8a5c-ad97635e5a40@cisco.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 07:16:59 -0000 Ladislav Lhotka wrote: > On Fri, 2018-04-27 at 12:19 +0100, Robert Wilton wrote: > > > > On 27/04/2018 12:03, Ladislav Lhotka wrote: > > > On Fri, 2018-04-27 at 11:23 +0100, Robert Wilton wrote: > > > > On 27/04/2018 11:03, Martin Bjorklund wrote: > > > > > Hi, > > > > > > > > > > Ladislav Lhotka wrote: > > > > > > On Thu, 2018-04-26 at 17:52 -0700, Andy Bierman wrote: > > > > > > > On Wed, Apr 25, 2018 at 10:53 PM, Ladislav Lhotka > > > > > > > wrote: > > > > > > > > Ladislav Lhotka writes: > > > > > > > > > > > > > > > > > On Wed, 2018-04-25 at 08:04 -0700, Andy Bierman wrote: > > > > > > > > > > On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka > > > > > > > > > z> > > > > > > > > > > wrote: > > > > > > > > > > > On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder > > > > > > > > > > > wrote: > > > > > > > > > > > > On Tue, Apr 24, 2018 at 04:36:01PM +0200, Martin Bjorklund > > > > > > > > > > > > wrote: > > > > > > > > > > > > > Ladislav Lhotka wrote: > > > > > > > > > > > > > > Martin Bjorklund writes: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am not sure what this statement tells us re. the > > > > > > > > > > > > > > > issue > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > this > > > > > > > > > > > email > > > > > > > > > > > > > > > thread. > > > > > > > > > > > > > > > > > > > > > > > > > > > > It tells us that, in my view, the approach taken in > > > > > > > > > > > > > > this > > > > > > > > > > > > > > document > > > > > > > > > > > > > > > > is a > > > > > > > > > > > > > > bad idea. > > > > > > > > > > > > > > > > > > > > > > > > > > Do you mean that the WG shoud drop this document? And > > > > > > > > > > > > > people that > > > > > > > > > > > > > need yang-data should continue to use the version in > > > > > > > > > > > > > 8040? Or that > > > > > > > > > > > > > people that need yang-data do not have a valid use case > > > > > > > > > > > > > and > > > > > > > > > > > > > they > > > > > > > > > > > > > should do something else? > > > > > > > > > > > > > > > > > > > > > > > > One option is that people use yang-data as defined in RFC > > > > > > > > > > > > 8040 > > > > > > > > > > > > until > > > > > > > > > > > > > > > > > > > > > > IMO, people should use plain YANG. With the new YANG library > > > > > > > > > > > it > > > > > > > > > > > will be > > > > > > > > > > > possible > > > > > > > > > > > to confine such non-NM schemas in a special datastore so > > > > > > > > > > > that > > > > > > > > > > > the > > > > > > > > > > > > > > > > intention > > > > > > > > > > > should be clear and multi-module schemas with all the > > > > > > > > > > > additional > > > > > > > > > > > data > > > > > > > > > > > (versions, > > > > > > > > > > > features, deviations) can be used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't see how yang-data interferes with "plain YANG" at all. > > > > > > > > > > It is for data that is not in scope for plain YANG. > > > > > > > > > > > > > > > > > > My question is why this extension is needed in the first place. > > > > > > > > > > > > > > > > For example, RFC 8040 could have used two modules instead of > > > > > > > > "ietf-restconf", one with the contents of grouping "errors" and > > > > > > > > the > > > > > > > > other with the contents of grouping "restconf". No extension. > > > > > > > > > > > > > > > > > > > > > > This is true. We used to do this before yang-data was available. > > > > > > > > > > > > If I remember correctly, the stuff was inside groupings that were not > > > > > > used > > > > > > anywhere. > > > > > > > > > > Which doesn't quite work, since no namespace is attached to the nodes. > > > > > > Note that this is not what I was proposing. For RESTCONF errors, the module > > > I > > > had in mind could be like this: > > > > > > module ietf-restconf-errors { > > > > > > container errors { // same content as in RFC 8040 > > > ... > > > } > > > > > > ... > > > > > > } > > > > > > Please explain why this cannot serve the given purpose, apart from the fact > > > that > > > it looks like configuration which it isn't - but this can be explained in > > > the > > > module description. > > > > It is the "because it looks like configuration" that I don't like. > > IMO this won't change even if the same data is inside the "yang-data" extension > because RFC 7950 says in sec. 7.21.1: > > If the top node does not specify a "config" statement, the default is "true". > > So even though the description of "yang-data" says that the "config" statement > is ignored if present, it doesn't mean that schema nodes lose the config > property. No, this is not correct. 7.21.1 says: If "config" is not specified, the default is the same as the parent schema node's "config" value. Note how it says *schema node*. Nodes in a grouping that don't have a config statement don't have a config property. Also, the same text about ignoring config is present for input/output/notfication. Nodes in a yang-data extension statement thus also do not have a config value, since yang-data is not a data definition statement. This is an argument *for* an extension statement. If you just define special nodes as normal nodes with a special description statement, you really break the rules for YANG. /martin > This may look like nitpicking but it illustrates the general problem: YANG was > designed for a very specific context and using it elsewhere requires creative > interpretation of its spec, with "yang-data" extension or without. > > > > > If the server supports and advertises this module then it is reasonable > > to expect that a client should be able to configure the errors > > container, since it is configuration ... > > There is no point for the server to advertise it as a part of the standard > datastores such as "intended". And in order to advertise it as a schema for > error messages, it is IMO possible to use the trick that I suggested: define a > special datastore for it, such as "error-messages". So it will be the datastore > that enforces the desired semantics, and clients that support it can use it in > the intended way. > > > > > At least marking it as config false would be slightly better. > > > > > > > > With this module, one could validate error messages using generic YANG tools > > > etc. > > > > > > (I am not proposing to update RFC 8040, just using it as an example.) > > > > > > > OK. So, using plain groupings doesn't work. > > > > > > > > In cases where groupings are being used within a YANG defined RPC, then > > > > presumably they do work OK? > > > > > > > > Is the specific problem scenario where the data is external to YANG > > > > defined RPCs, but yet it is still desirable to use a YANG schema and one > > > > of the associated YANG encodings to describe/encode the data? > > > > > > > > > > > > > > > > What would be wrong with this solution? Instead, the reader is > > > > > > > > overwhelmed with the complexity of the "yang-data" definition, and > > > > > > > > most > > > > > > > > tools cannot process the module. > > > > > > > > > > > > > > There are tools that can use yang-data. > > > > > > > Not all use-cases involve a server to query for a yang-library. > > > > > > > > > > > > Sure, but it is not necessary, I meant it just as an option. Such YANG > > > > > > modules > > > > > > can be passed straight to tools. > > > > > > > > > > > > > Offline tools need to know about the special data somehow. > > > > > > > > > > > > Why? Let's say I want the ascii tree, and pyang will be able to > > > > > > generate > > > > > > it. All > > > > > > right, there will be "rw" labels that don't apply but it is not a big > > > > > > deal. > > > > > > > > > > > > > The yang-data extension prevents data-def-stmts from being treated > > > > > > > as if they were configuration or operational data. > > > > > > > > > > > > This would be a problem if this yang-data is mixed with standard data > > > > > > in > > > > > > the > > > > > > same module. IMO this can be avoided, and then for it is essentially > > > > > > irrelevant > > > > > > for tools whether it is normal data or not. > > > > > > > > > > > > > I agree with you that unconstrained use of yang-data is questionable > > > > > > > for a standard extension. The bar should be that all tools which > > > > > > > choose > > > > > > > to implement the extension should provide the user with the same > > > > > > > behavior. > > > > > > > Declaring that behavior out-of-scope does not help interoperability > > > > > > > at > > > > > > > all. > > > > > > > > > > > > Yes, and so my proposal here is to silently misuse YANG somewhat where > > > > > > necessary > > > > > > rather than spend cycles on a Standard Track document that gives a > > > > > > false > > > > > > impression of a general solution. > > > > > > > > > > I am strongly opposed to this. IMO it is much better to put such > > > > > structures in an extension, which tools that don't understand it will > > > > > ignore, than relying on description statements in normal data nodes, > > > > > which no tool can understand without hard coding special cases. > > > > > > > > I'm also opposed to this. > > > > > > > > Stuff that looks like configuration should be configuration, and stuff > > > > that looks like state should be state. If this data is going to be > > > > described in YANG then I think that there must be a programmatic way to > > > > indicate that the resultant schema is not configuration or operational > > > > state, but something else instead. An extension seems to achieve this. > > > > > > YANG spec deals exclusively with configuration and state data, and using its > > > statements inside an extension doesn't make this basic fact go away. > > > Specifying > > > all necessary changes properly inside a description of an extension is > > > simply > > > impossible. > > > > If an implementation needs to support generating the error messages then > > they can support the yang-data extension if they want (or just hard code > > what they expect to receive). > > Or support the "error-messages" datastore, see above. > > Lada > > > > > Otherwise, devices can also ignore the yang-data extension and it > > doesn't seem to do any harm since its doesn't change the behaviour in > > any way. > > > > Thanks, > > Rob > > > > > > > > > > Lada > > > > > > > Thanks, > > > > Rob > > > > > > > > > > > > > > > > > > > It would be great to remove NETCONF specifics from YANG and I'd be > > > > > > willing > > > > > > to > > > > > > contribute to this work. > > > > > > > > > > This is a different topic though. > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > A plain client can ignore yang-data and not affect and RPC, > > > > > > > > > > notification, > > > > > > > > > > > > > > > > or > > > > > > > > > > data > > > > > > > > > > definitions in plain YANG. > > > > > > > > > > > > > > > > > > A plain (NC/RC) client should never see such data even if it is > > > > > > > > > not > > > > > > > > > > > > > > > > protected by > > > > > > > > > yang-data in YANG. On the other hand, tools will be able to > > > > > > > > > process > > > > > > > > > such > > > > > > > > > > > > > > > > schemas > > > > > > > > > (generate the ascii tree, convert it to something else, generate > > > > > > > > > sample > > > > > > > > > instances etc.) without explicitly supporting yang-data. > > > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > there is a version of YANG that has a proper and complete > > > > > > > > > > > > integrated > > > > > > > > > > > > solution. (If for example yang-data is used to declare > > > > > > > > > > > > error > > > > > > > > > > > > content > > > > > > > > > > > > for RPCs, then more extensions are needed or a proper > > > > > > > > > > > > integration > > > > > > > > > > > > > > > > into > > > > > > > > > > > > YANG. Is it really good to introduce augment-yang-data > > > > > > > > > > > > (instead of > > > > > > > > > > > > making augment work with say 'data' in YANG 1.2)? And then > > > > > > > > > > > > we > > > > > > > > > > > > do > > > > > > > > > > > > uses-yang-data etc. > > > > > > > > > > > > > > > > > > > > > > > > /js > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > Ladislav Lhotka > > > > > > > > > > > Head, CZ.NIC Labs > > > > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > netmod mailing list > > > > > > > > > > > netmod@ietf.org > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Ladislav Lhotka > > > > > > > > > Head, CZ.NIC Labs > > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > 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 > > > > > > Head, CZ.NIC Labs > > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > From nobody Wed May 2 00:25:32 2018 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 B5FA812D947 for ; Wed, 2 May 2018 00:25:30 -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 fWTlsuhsEf1u for ; Wed, 2 May 2018 00:25: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 B2F5C126CB6 for ; Wed, 2 May 2018 00:25:28 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 2B5FC1AE012C; Wed, 2 May 2018 09:25:27 +0200 (CEST) Date: Wed, 02 May 2018 09:25:27 +0200 (CEST) Message-Id: <20180502.092527.2305319833268262996.mbj@tail-f.com> To: andy@yumaworks.com Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <87d0yglra0.fsf@nic.cz> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 07:25:31 -0000 Andy Bierman wrote: > On Mon, Apr 30, 2018 at 7:09 AM, Ladislav Lhotka wrote: > > > Andy Bierman writes: > > > > > On Fri, Apr 27, 2018 at 8:13 AM, Ladislav Lhotka wrote: > > > > > >> On Fri, 2018-04-27 at 16:47 +0200, Juergen Schoenwaelder wrote: > > >> > On Fri, Apr 27, 2018 at 04:34:38PM +0200, Ladislav Lhotka wrote: > > >> > > > >> > > [...] define a special datastore for it, such as "error-messages". > > >> > > > >> > This seems worse than using, well, RFC 8040 yang-data. The proper > > >> > > >> Why it seems worse? > > >> > > >> > > > Because this is not part of the NMDA. > > > > NMDA is extensible. > > > > > If your only tool is a hammer, then all your problems look like nails. > I fail to see how an "error-messages" datastore fits in with NMDA > > > > > > > > IMO, the yang-data defined in RFC 8040 has a clear purpose, and it > > > is sufficient for that purpose, which is a YANG representation of > > > an instance document (such as a protocol message or file). > > > > The same is basically true even without the extension. For example, I > > fail to see any benefit from using yang-data in a module like > > ietf-zerotouch-information. > > > > > I don't see the benefit of pretending all data-def-stmts represent > configuration or operational data. > > Wrapping the data-def-stmts in an extension says "this is not configuration > or operational data". This is useful for tools that can process YANG in > other contexts. I fully agree > > > YANG is useful for defining data structures that can be represented in > > > different formats, yet it is independent of any 1 format. > > > > Of course I see this potential. Unfortunately, YANG spec was explicitly > > written for a very specific context. Using an extension for removing > > this specificity is IMO an ugly hack that undermines the architecture. > > > > > > I don't see the architecture as fragile or damaged if yang-data is used. > > People are going to continue to push the boundaries of YANG capabilities. > This will happen with or without the IETF. Yes, and it already happens. /martin > Maybe this work should remain > proprietary or get moved to an opensource project. > > > > > > > > > > I am in favor if keeping the yang-data in RFC 8040 and not > > > creating a new version of it that is unconstrained. > > > There does not seem to be consensus on how to do this, > > > or even consensus that it is a good idea. > > > > > > > If the extension is deemed necessary, I would also prefer this approach > > to making the extension a Proposed Standard. > > > > Lada > > > > > Andy > > > > > > > > > > > > >> > clear solution for RPCs and actions would be to enable the definition > > >> > of error details right in the rpc/action definition (input, output, > > >> > error). > > >> > > >> Agreed. > > >> > > >> > > > >> > But something like yang-data seems to have uses in other contexts. > > >> > > >> So other datastores may be defined. I assume that YANG library data can > > be > > >> used > > >> independently, not just on a NC/RC server, pretty much along the lines > > of > > >> draft- > > >> lengyel-netmod-yang-instance-data. > > >> > > >> Lada > > >> > > >> > > > >> > > > > > > Andy > > > > > > > > > > > >> > /js > > >> > > > >> -- > > >> Ladislav Lhotka > > >> Head, CZ.NIC Labs > > >> PGP Key ID: 0xB8F92B08A9F76C67 > > >> > > >> _______________________________________________ > > >> netmod mailing list > > >> netmod@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netmod > > >> > > > > -- > > Ladislav Lhotka > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > From nobody Wed May 2 00:27:55 2018 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 C5228126CD6 for ; Wed, 2 May 2018 00:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 G6W9B1SgVsHa for ; Wed, 2 May 2018 00:27:52 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBD5126C2F for ; Wed, 2 May 2018 00:27:52 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 75C321AE012C; Wed, 2 May 2018 09:27:51 +0200 (CEST) Date: Wed, 02 May 2018 09:27:51 +0200 (CEST) Message-Id: <20180502.092751.513408171275580216.mbj@tail-f.com> To: kwatsen@juniper.net Cc: lhotka@nic.cz, andy@yumaworks.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <87d0yglra0.fsf@nic.cz> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 07:27:54 -0000 Kent Watsen wrote: > > Lada writes: > > Andy writes: > >>IMO, the yang-data defined in RFC 8040 has a clear purpose, and it > >>is sufficient for that purpose, which is a YANG representation of > >>an instance document (such as a protocol message or file). > > > > The same is basically true even without the extension. For example, I > > fail to see any benefit from using yang-data in a module like > > ietf-zerotouch-information. > > I don't understand this, how else would you propose to define the > JSON-or-XML encoded payload of the CMS structure? > > > >> I am in favor if keeping the yang-data in RFC 8040 and not > >> creating a new version of it that is unconstrained. > >> There does not seem to be consensus on how to do this, > >> or even consensus that it is a good idea. > > > > If the extension is deemed necessary, I would also prefer this > > approach to making the extension a Proposed Standard. > > I don't understand talk about abandoning this draft. There is no question > that it is needed (e.g., anima vouch, zerotouch, tail-f's "structure"), > and RFC 8040 is unsatisfactory because 1) it doesn't allow a top-level > 'choice' between two containers and 2) it requires drafts to reference > RFC 8040, even though the drafts may have nothing to do with RESTCONF. and 3) it is not possible to augement 8040's yang-data. > Sure, maybe we have convinced ourselves that yang-data is not needed > to model error-info I don't think there have been any other proposal for how to model error-info that have any sort of concensus behind it. > , but that doesn't negate the other use case. > > We need a way to indicate that some data-model represents a stand-alone > data structure. It is not configuration, operational state, an RPC, or > a notification. It can only appear as a descendent of the 'module' > statement. All 'action', 'notification', 'config', and 'if-feature' > descendent statements are ignored. For the purpose of 'must' and ' > when' statements, the yang-data structure is its own context root. It > has a namespace and a unique local name (unique only to other yang-data > defined within the same module; it's okay if an RPC, notification, or > top-level data node has the same name). Anything else? /martin From nobody Wed May 2 00:30:21 2018 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 34AA8126E64 for ; Wed, 2 May 2018 00:30: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, 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 AUFY4jUxzgqc for ; Wed, 2 May 2018 00:30:17 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3CC126C2F for ; Wed, 2 May 2018 00:30:17 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id AE26A1AE012C; Wed, 2 May 2018 09:30:16 +0200 (CEST) Date: Wed, 02 May 2018 09:30:16 +0200 (CEST) Message-Id: <20180502.093016.2140999496080783112.mbj@tail-f.com> To: kwatsen@juniper.net Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <508FA1DE-87BF-425E-BC52-2C4626ACAB12@juniper.net> References: <20180501073448.vs642cc2mpuzrvv3@elstar.local> <508FA1DE-87BF-425E-BC52-2C4626ACAB12@juniper.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 07:30:19 -0000 Kent Watsen wrote: > > Juergen writes: > > Kent writes: > >> I don't understand talk about abandoning this draft. There is no question > >> that it is needed (e.g., anima vouch, zerotouch, tail-f's "structure"), > >> and RFC 8040 is unsatisfactory because 1) it doesn't allow a top-level > >> 'choice' between two containers and 2) it requires drafts to reference > >> RFC 8040, even though the drafts may have nothing to do with RESTCONF. > >> > > > > Re 1: RFC 8040 says: "It MUST contain data definition statements that > > result in exactly one container data node definition." So a choice may > > actually work as long as the result is exactly one container data > > node. OK, the wording in the RFC 8040 statement is not clear since > > 'result' and 'definition' do not line up (does 'result' mean the > > toplevel data node instances that are possible? In this case, > > 'definition' would be misleading). > > I agree, but Martin did not and he even modified `pyang` to throw an > error on the zerotouch draft Originally pyang did not check this, but I was convinced by Andy and the discussion on the ML that pyang was not correct. The intention of the text in RFC 8040 was to allow for "uses" within a yang-data statement. It was not to allow for "choice". >, thus forcing the current situation. If > a new understanding regarding rc:yang-data can be reached, the zerotouch > draft can go back to using it. > > > > Re 2: It does not really matter whether you import the extension from > > RFC 8040 or some other module. Why is depending on A better than > > depending on B? The definition in RFC 8040 is already know by tools. > > > > I view the yang-data definition of RFC 8040 as a temporary solution, a > > proper solution should in my view be part of YANG 1.x. > > What is the "proper solution", and why does it need to wait for YANG 1.x? > In the discussion regarding moving faster, it's been suggested that YANG > 1.x could be a cherry-picking of some number of extension statements > produced in other I-Ds. I was hoping that this was the case here. +1 /martin > True, > some tools know about A, but if B is the LTS, then I'd hope to move to B > ASAP. > > > Since NMDA essentially binds all data tree definitions to datastores, > > the yang-data construct allows us to define data structures that are > > specifically not bound to any datastore, i.e., data structures that by > > design can't be operated on directly with NMDA NETCONF/RESTCONF. > > Yes. > > > Kent // contributor > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Wed May 2 00:52:23 2018 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 F123F1252BA for ; Wed, 2 May 2018 00:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] 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 qU_RE-ExACx2 for ; Wed, 2 May 2018 00:52:19 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA7CC126C2F for ; Wed, 2 May 2018 00:52:18 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:8032:75ff:fe3c:7e68]) by mail.nic.cz (Postfix) with ESMTPSA id B5C77604E8; Wed, 2 May 2018 09:52:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1525247536; bh=XJ7QVnTQW3z2vimv7l5yxZNUbBH8ePe9aRuRIZcr0lA=; h=From:To:Date; b=hyo7XcIczDzAshM6A7JlhQeqy8EZKF6XQX5sL3m7F6ZQVSwmkrvAPwu+jmxkZOkvZ cpM3+Nlh3OlzrnvNbciOThXm2tXC8zKwYKegmsLYHRjpTXr7jXaNzxBaGaMnzdYBWw FAFSsYwGU/SDyWnSh5J6h1crWnnLe21O05/hoktk= Message-ID: <1b0be1f979c8fc285461309a8d81702d16d66316.camel@nic.cz> From: Ladislav Lhotka To: Martin Bjorklund Cc: rwilton@cisco.com, netmod@ietf.org Date: Wed, 02 May 2018 09:52:25 +0200 In-Reply-To: <20180502.091653.2180362536464006870.mbj@tail-f.com> References: <45f5a97d205a9251b382687f54865c62250787cb.camel@nic.cz> <99aac5c0-aa2f-1a35-8a5c-ad97635e5a40@cisco.com> <20180502.091653.2180362536464006870.mbj@tail-f.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 07:52:23 -0000 On Wed, 2018-05-02 at 09:16 +0200, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > On Fri, 2018-04-27 at 12:19 +0100, Robert Wilton wrote: > > > > > > On 27/04/2018 12:03, Ladislav Lhotka wrote: > > > > On Fri, 2018-04-27 at 11:23 +0100, Robert Wilton wrote: > > > > > On 27/04/2018 11:03, Martin Bjorklund wrote: > > > > > > Hi, > > > > > > > > > > > > Ladislav Lhotka wrote: > > > > > > > On Thu, 2018-04-26 at 17:52 -0700, Andy Bierman wrote: > > > > > > > > On Wed, Apr 25, 2018 at 10:53 PM, Ladislav Lhotka > > > > > > > > > wrote: > > > > > > > > > Ladislav Lhotka writes: > > > > > > > > > > > > > > > > > > > On Wed, 2018-04-25 at 08:04 -0700, Andy Bierman wrote: > > > > > > > > > > > On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka ic.c > > > > > > > > > > > z> > > > > > > > > > > > wrote: > > > > > > > > > > > > On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder > > > > > > > > > > > > wrote: > > > > > > > > > > > > > On Tue, Apr 24, 2018 at 04:36:01PM +0200, Martin > Bjorklund > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > Ladislav Lhotka wrote: > > > > > > > > > > > > > > > Martin Bjorklund writes: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am not sure what this statement tells us re. > the > > > > > > > > > > > > > > > > issue > > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > > > this > > > > > > > > > > > > email > > > > > > > > > > > > > > > > thread. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It tells us that, in my view, the approach taken > in > > > > > > > > > > > > > > > this > > > > > > > > > > > > > > > document > > > > > > > > > > > > > > > > > > is a > > > > > > > > > > > > > > > bad idea. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do you mean that the WG shoud drop this document? > And > > > > > > > > > > > > > > people that > > > > > > > > > > > > > > need yang-data should continue to use the version in > > > > > > > > > > > > > > 8040? Or that > > > > > > > > > > > > > > people that need yang-data do not have a valid use > case > > > > > > > > > > > > > > and > > > > > > > > > > > > > > they > > > > > > > > > > > > > > should do something else? > > > > > > > > > > > > > > > > > > > > > > > > > > One option is that people use yang-data as defined in > RFC > > > > > > > > > > > > > 8040 > > > > > > > > > > > > > until > > > > > > > > > > > > > > > > > > > > > > > > IMO, people should use plain YANG. With the new YANG > library > > > > > > > > > > > > it > > > > > > > > > > > > will be > > > > > > > > > > > > possible > > > > > > > > > > > > to confine such non-NM schemas in a special datastore so > > > > > > > > > > > > that > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > intention > > > > > > > > > > > > should be clear and multi-module schemas with all the > > > > > > > > > > > > additional > > > > > > > > > > > > data > > > > > > > > > > > > (versions, > > > > > > > > > > > > features, deviations) can be used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't see how yang-data interferes with "plain YANG" at > all. > > > > > > > > > > > It is for data that is not in scope for plain YANG. > > > > > > > > > > > > > > > > > > > > My question is why this extension is needed in the first > place. > > > > > > > > > > > > > > > > > > For example, RFC 8040 could have used two modules instead of > > > > > > > > > "ietf-restconf", one with the contents of grouping "errors" > and > > > > > > > > > the > > > > > > > > > other with the contents of grouping "restconf". No extension. > > > > > > > > > > > > > > > > > > > > > > > > > This is true. We used to do this before yang-data was available. > > > > > > > > > > > > > > If I remember correctly, the stuff was inside groupings that were > not > > > > > > > used > > > > > > > anywhere. > > > > > > > > > > > > Which doesn't quite work, since no namespace is attached to the > nodes. > > > > > > > > Note that this is not what I was proposing. For RESTCONF errors, the > module > > > > I > > > > had in mind could be like this: > > > > > > > > module ietf-restconf-errors { > > > > > > > > container errors { // same content as in RFC 8040 > > > > ... > > > > } > > > > > > > > ... > > > > > > > > } > > > > > > > > Please explain why this cannot serve the given purpose, apart from the > fact > > > > that > > > > it looks like configuration which it isn't - but this can be explained > in > > > > the > > > > module description. > > > > > > It is the "because it looks like configuration" that I don't like. > > > > IMO this won't change even if the same data is inside the "yang-data" > extension > > because RFC 7950 says in sec. 7.21.1: > > > > If the top node does not specify a "config" statement, the default is > "true". > > > > So even though the description of "yang-data" says that the "config" > statement > > is ignored if present, it doesn't mean that schema nodes lose the config > > property. > > No, this is not correct. 7.21.1 says: > > If "config" is not specified, the default is the same as the parent > schema node's "config" value. And also: If the top node does not specify a "config" statement, the default is "true". > > Note how it says *schema node*. Nodes in a grouping that don't have a > config statement don't have a config property. Also, the same text > about ignoring config is present for input/output/notfication. > > Nodes in a yang-data extension statement thus also do not have a > config value, since yang-data is not a data definition statement. Are you saying that a container inside yang-data doesn't define a schema node? > > This is an argument *for* an extension statement. If you just define > special nodes as normal nodes with a special description statement, > you really break the rules for YANG. I wouldn't *define* the schema nodes as special, just the resulting schema may be used differently. This shouldn't matter as long as this data has nothing to do with NETCONF or RESTCONF. My main objections against yang-data are: - additional complexity - bad example (Need - or don't like - something in YANG? Just introduce an extension.) Lada > > > /martin > > > > > This may look like nitpicking but it illustrates the general problem: YANG > was > > designed for a very specific context and using it elsewhere requires > creative > > interpretation of its spec, with "yang-data" extension or without. > > > > > > > > If the server supports and advertises this module then it is reasonable > > > to expect that a client should be able to configure the errors > > > container, since it is configuration ... > > > > There is no point for the server to advertise it as a part of the standard > > datastores such as "intended". And in order to advertise it as a schema for > > error messages, it is IMO possible to use the trick that I suggested: define > a > > special datastore for it, such as "error-messages". So it will be the > datastore > > that enforces the desired semantics, and clients that support it can use it > in > > the intended way. > > > > > > > > At least marking it as config false would be slightly better. > > > > > > > > > > > With this module, one could validate error messages using generic YANG > tools > > > > etc. > > > > > > > > (I am not proposing to update RFC 8040, just using it as an example.) > > > > > > > > > OK. So, using plain groupings doesn't work. > > > > > > > > > > In cases where groupings are being used within a YANG defined RPC, > then > > > > > presumably they do work OK? > > > > > > > > > > Is the specific problem scenario where the data is external to YANG > > > > > defined RPCs, but yet it is still desirable to use a YANG schema and > one > > > > > of the associated YANG encodings to describe/encode the data? > > > > > > > > > > > > > > > > > > > What would be wrong with this solution? Instead, the reader is > > > > > > > > > overwhelmed with the complexity of the "yang-data" definition, > and > > > > > > > > > most > > > > > > > > > tools cannot process the module. > > > > > > > > > > > > > > > > There are tools that can use yang-data. > > > > > > > > Not all use-cases involve a server to query for a yang-library. > > > > > > > > > > > > > > Sure, but it is not necessary, I meant it just as an option. Such > YANG > > > > > > > modules > > > > > > > can be passed straight to tools. > > > > > > > > > > > > > > > Offline tools need to know about the special data somehow. > > > > > > > > > > > > > > Why? Let's say I want the ascii tree, and pyang will be able to > > > > > > > generate > > > > > > > it. All > > > > > > > right, there will be "rw" labels that don't apply but it is not a > big > > > > > > > deal. > > > > > > > > > > > > > > > The yang-data extension prevents data-def-stmts from being > treated > > > > > > > > as if they were configuration or operational data. > > > > > > > > > > > > > > This would be a problem if this yang-data is mixed with standard > data > > > > > > > in > > > > > > > the > > > > > > > same module. IMO this can be avoided, and then for it is > essentially > > > > > > > irrelevant > > > > > > > for tools whether it is normal data or not. > > > > > > > > > > > > > > > I agree with you that unconstrained use of yang-data is > questionable > > > > > > > > for a standard extension. The bar should be that all tools which > > > > > > > > choose > > > > > > > > to implement the extension should provide the user with the same > > > > > > > > behavior. > > > > > > > > Declaring that behavior out-of-scope does not help > interoperability > > > > > > > > at > > > > > > > > all. > > > > > > > > > > > > > > Yes, and so my proposal here is to silently misuse YANG somewhat > where > > > > > > > necessary > > > > > > > rather than spend cycles on a Standard Track document that gives a > > > > > > > false > > > > > > > impression of a general solution. > > > > > > > > > > > > I am strongly opposed to this. IMO it is much better to put such > > > > > > structures in an extension, which tools that don't understand it > will > > > > > > ignore, than relying on description statements in normal data nodes, > > > > > > which no tool can understand without hard coding special cases. > > > > > > > > > > I'm also opposed to this. > > > > > > > > > > Stuff that looks like configuration should be configuration, and stuff > > > > > that looks like state should be state. If this data is going to be > > > > > described in YANG then I think that there must be a programmatic way > to > > > > > indicate that the resultant schema is not configuration or operational > > > > > state, but something else instead. An extension seems to achieve > this. > > > > > > > > YANG spec deals exclusively with configuration and state data, and using > its > > > > statements inside an extension doesn't make this basic fact go away. > > > > Specifying > > > > all necessary changes properly inside a description of an extension is > > > > simply > > > > impossible. > > > > > > If an implementation needs to support generating the error messages then > > > they can support the yang-data extension if they want (or just hard code > > > what they expect to receive). > > > > Or support the "error-messages" datastore, see above. > > > > Lada > > > > > > > > Otherwise, devices can also ignore the yang-data extension and it > > > doesn't seem to do any harm since its doesn't change the behaviour in > > > any way. > > > > > > Thanks, > > > Rob > > > > > > > > > > > > > > Lada > > > > > > > > > Thanks, > > > > > Rob > > > > > > > > > > > > > > > > > > > > > > > It would be great to remove NETCONF specifics from YANG and I'd be > > > > > > > willing > > > > > > > to > > > > > > > contribute to this work. > > > > > > > > > > > > This is a different topic though. > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > A plain client can ignore yang-data and not affect and > RPC, > > > > > > > > > > > notification, > > > > > > > > > > > > > > > > > > or > > > > > > > > > > > data > > > > > > > > > > > definitions in plain YANG. > > > > > > > > > > > > > > > > > > > > A plain (NC/RC) client should never see such data even if it > is > > > > > > > > > > not > > > > > > > > > > > > > > > > > > protected by > > > > > > > > > > yang-data in YANG. On the other hand, tools will be able to > > > > > > > > > > process > > > > > > > > > > such > > > > > > > > > > > > > > > > > > schemas > > > > > > > > > > (generate the ascii tree, convert it to something else, > generate > > > > > > > > > > sample > > > > > > > > > > instances etc.) without explicitly supporting yang-data. > > > > > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > there is a version of YANG that has a proper and > complete > > > > > > > > > > > > > integrated > > > > > > > > > > > > > solution. (If for example yang-data is used to declare > > > > > > > > > > > > > error > > > > > > > > > > > > > content > > > > > > > > > > > > > for RPCs, then more extensions are needed or a proper > > > > > > > > > > > > > integration > > > > > > > > > > > > > > > > > > into > > > > > > > > > > > > > YANG. Is it really good to introduce augment-yang-data > > > > > > > > > > > > > (instead of > > > > > > > > > > > > > making augment work with say 'data' in YANG 1.2)? And > then > > > > > > > > > > > > > we > > > > > > > > > > > > > do > > > > > > > > > > > > > uses-yang-data etc. > > > > > > > > > > > > > > > > > > > > > > > > > > /js > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Ladislav Lhotka > > > > > > > > > > > > Head, CZ.NIC Labs > > > > > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > netmod mailing list > > > > > > > > > > > > netmod@ietf.org > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Ladislav Lhotka > > > > > > > > > > Head, CZ.NIC Labs > > > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > 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 > > > > > > > Head, CZ.NIC Labs > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed May 2 01:00:51 2018 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 78A5F124319 for ; Wed, 2 May 2018 01:00:33 -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 JFHc_2syt54t for ; Wed, 2 May 2018 01:00:12 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B7576126C2F for ; Wed, 2 May 2018 01:00:11 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 2FE581AE012C; Wed, 2 May 2018 10:00:10 +0200 (CEST) Date: Wed, 02 May 2018 10:00:10 +0200 (CEST) Message-Id: <20180502.100010.1694962477240377857.mbj@tail-f.com> To: lhotka@nic.cz Cc: rwilton@cisco.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <1b0be1f979c8fc285461309a8d81702d16d66316.camel@nic.cz> References: <20180502.091653.2180362536464006870.mbj@tail-f.com> <1b0be1f979c8fc285461309a8d81702d16d66316.camel@nic.cz> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 08:00:33 -0000 Ladislav Lhotka wrote: > On Wed, 2018-05-02 at 09:16 +0200, Martin Bjorklund wrote: > > Ladislav Lhotka wrote: > > > On Fri, 2018-04-27 at 12:19 +0100, Robert Wilton wrote: > > > > > > > > On 27/04/2018 12:03, Ladislav Lhotka wrote: > > > > > On Fri, 2018-04-27 at 11:23 +0100, Robert Wilton wrote: > > > > > > On 27/04/2018 11:03, Martin Bjorklund wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Ladislav Lhotka wrote: > > > > > > > > On Thu, 2018-04-26 at 17:52 -0700, Andy Bierman wrote: > > > > > > > > > On Wed, Apr 25, 2018 at 10:53 PM, Ladislav Lhotka > > > > > > > > > > > wrote: > > > > > > > > > > Ladislav Lhotka writes: > > > > > > > > > > > > > > > > > > > > > On Wed, 2018-04-25 at 08:04 -0700, Andy Bierman wrote: > > > > > > > > > > > > On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka > ic.c > > > > > > > > > > > > z> > > > > > > > > > > > > wrote: > > > > > > > > > > > > > On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > On Tue, Apr 24, 2018 at 04:36:01PM +0200, Martin > > Bjorklund > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Ladislav Lhotka wrote: > > > > > > > > > > > > > > > > Martin Bjorklund writes: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am not sure what this statement tells us re. > > the > > > > > > > > > > > > > > > > > issue > > > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > > > > > this > > > > > > > > > > > > > email > > > > > > > > > > > > > > > > > thread. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It tells us that, in my view, the approach taken > > in > > > > > > > > > > > > > > > > this > > > > > > > > > > > > > > > > document > > > > > > > > > > > > > > > > > > > > is a > > > > > > > > > > > > > > > > bad idea. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do you mean that the WG shoud drop this document? > > And > > > > > > > > > > > > > > > people that > > > > > > > > > > > > > > > need yang-data should continue to use the version in > > > > > > > > > > > > > > > 8040? Or that > > > > > > > > > > > > > > > people that need yang-data do not have a valid use > > case > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > they > > > > > > > > > > > > > > > should do something else? > > > > > > > > > > > > > > > > > > > > > > > > > > > > One option is that people use yang-data as defined in > > RFC > > > > > > > > > > > > > > 8040 > > > > > > > > > > > > > > until > > > > > > > > > > > > > > > > > > > > > > > > > > IMO, people should use plain YANG. With the new YANG > > library > > > > > > > > > > > > > it > > > > > > > > > > > > > will be > > > > > > > > > > > > > possible > > > > > > > > > > > > > to confine such non-NM schemas in a special datastore so > > > > > > > > > > > > > that > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > intention > > > > > > > > > > > > > should be clear and multi-module schemas with all the > > > > > > > > > > > > > additional > > > > > > > > > > > > > data > > > > > > > > > > > > > (versions, > > > > > > > > > > > > > features, deviations) can be used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't see how yang-data interferes with "plain YANG" at > > all. > > > > > > > > > > > > It is for data that is not in scope for plain YANG. > > > > > > > > > > > > > > > > > > > > > > My question is why this extension is needed in the first > > place. > > > > > > > > > > > > > > > > > > > > For example, RFC 8040 could have used two modules instead of > > > > > > > > > > "ietf-restconf", one with the contents of grouping "errors" > > and > > > > > > > > > > the > > > > > > > > > > other with the contents of grouping "restconf". No extension. > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is true. We used to do this before yang-data was available. > > > > > > > > > > > > > > > > If I remember correctly, the stuff was inside groupings that were > > not > > > > > > > > used > > > > > > > > anywhere. > > > > > > > > > > > > > > Which doesn't quite work, since no namespace is attached to the > > nodes. > > > > > > > > > > Note that this is not what I was proposing. For RESTCONF errors, the > > module > > > > > I > > > > > had in mind could be like this: > > > > > > > > > > module ietf-restconf-errors { > > > > > > > > > > container errors { // same content as in RFC 8040 > > > > > ... > > > > > } > > > > > > > > > > ... > > > > > > > > > > } > > > > > > > > > > Please explain why this cannot serve the given purpose, apart from the > > fact > > > > > that > > > > > it looks like configuration which it isn't - but this can be explained > > in > > > > > the > > > > > module description. > > > > > > > > It is the "because it looks like configuration" that I don't like. > > > > > > IMO this won't change even if the same data is inside the "yang-data" > > extension > > > because RFC 7950 says in sec. 7.21.1: > > > > > > If the top node does not specify a "config" statement, the default is > > "true". > > > > > > So even though the description of "yang-data" says that the "config" > > statement > > > is ignored if present, it doesn't mean that schema nodes lose the config > > > property. > > > > No, this is not correct. 7.21.1 says: > > > > If "config" is not specified, the default is the same as the parent > > schema node's "config" value. > > And also: > > If the top node does not specify a "config" statement, the default is > "true". > > > > > Note how it says *schema node*. Nodes in a grouping that don't have a > > config statement don't have a config property. Also, the same text > > about ignoring config is present for input/output/notfication. > > > > Nodes in a yang-data extension statement thus also do not have a > > config value, since yang-data is not a data definition statement. > > Are you saying that a container inside yang-data doesn't define a schema node? I mean that just like in groupings, nodes in yang-data don't have a config property. > > This is an argument *for* an extension statement. If you just define > > special nodes as normal nodes with a special description statement, > > you really break the rules for YANG. > > I wouldn't *define* the schema nodes as special, just the resulting schema may > be used differently. This shouldn't matter as long as this data has nothing to > do with NETCONF or RESTCONF. > > My main objections against yang-data are: > > - additional complexity > > - bad example (Need - or don't like - something in YANG? Just introduce an > extension.) extensions are *much* better than the alternative you propose (Need - or don't like - something in YANG? Just document how you break the rules in the description statement). extensions have turned out to be really useful. I agree that you need to be careful with what you do though. /martin > > Lada > > > > > > > /martin > > > > > > > > > This may look like nitpicking but it illustrates the general problem: YANG > > was > > > designed for a very specific context and using it elsewhere requires > > creative > > > interpretation of its spec, with "yang-data" extension or without. > > > > > > > > > > > If the server supports and advertises this module then it is reasonable > > > > to expect that a client should be able to configure the errors > > > > container, since it is configuration ... > > > > > > There is no point for the server to advertise it as a part of the standard > > > datastores such as "intended". And in order to advertise it as a schema for > > > error messages, it is IMO possible to use the trick that I suggested: define > > a > > > special datastore for it, such as "error-messages". So it will be the > > datastore > > > that enforces the desired semantics, and clients that support it can use it > > in > > > the intended way. > > > > > > > > > > > At least marking it as config false would be slightly better. > > > > > > > > > > > > > > With this module, one could validate error messages using generic YANG > > tools > > > > > etc. > > > > > > > > > > (I am not proposing to update RFC 8040, just using it as an example.) > > > > > > > > > > > OK. So, using plain groupings doesn't work. > > > > > > > > > > > > In cases where groupings are being used within a YANG defined RPC, > > then > > > > > > presumably they do work OK? > > > > > > > > > > > > Is the specific problem scenario where the data is external to YANG > > > > > > defined RPCs, but yet it is still desirable to use a YANG schema and > > one > > > > > > of the associated YANG encodings to describe/encode the data? > > > > > > > > > > > > > > > > > > > > > > What would be wrong with this solution? Instead, the reader is > > > > > > > > > > overwhelmed with the complexity of the "yang-data" definition, > > and > > > > > > > > > > most > > > > > > > > > > tools cannot process the module. > > > > > > > > > > > > > > > > > > There are tools that can use yang-data. > > > > > > > > > Not all use-cases involve a server to query for a yang-library. > > > > > > > > > > > > > > > > Sure, but it is not necessary, I meant it just as an option. Such > > YANG > > > > > > > > modules > > > > > > > > can be passed straight to tools. > > > > > > > > > > > > > > > > > Offline tools need to know about the special data somehow. > > > > > > > > > > > > > > > > Why? Let's say I want the ascii tree, and pyang will be able to > > > > > > > > generate > > > > > > > > it. All > > > > > > > > right, there will be "rw" labels that don't apply but it is not a > > big > > > > > > > > deal. > > > > > > > > > > > > > > > > > The yang-data extension prevents data-def-stmts from being > > treated > > > > > > > > > as if they were configuration or operational data. > > > > > > > > > > > > > > > > This would be a problem if this yang-data is mixed with standard > > data > > > > > > > > in > > > > > > > > the > > > > > > > > same module. IMO this can be avoided, and then for it is > > essentially > > > > > > > > irrelevant > > > > > > > > for tools whether it is normal data or not. > > > > > > > > > > > > > > > > > I agree with you that unconstrained use of yang-data is > > questionable > > > > > > > > > for a standard extension. The bar should be that all tools which > > > > > > > > > choose > > > > > > > > > to implement the extension should provide the user with the same > > > > > > > > > behavior. > > > > > > > > > Declaring that behavior out-of-scope does not help > > interoperability > > > > > > > > > at > > > > > > > > > all. > > > > > > > > > > > > > > > > Yes, and so my proposal here is to silently misuse YANG somewhat > > where > > > > > > > > necessary > > > > > > > > rather than spend cycles on a Standard Track document that gives a > > > > > > > > false > > > > > > > > impression of a general solution. > > > > > > > > > > > > > > I am strongly opposed to this. IMO it is much better to put such > > > > > > > structures in an extension, which tools that don't understand it > > will > > > > > > > ignore, than relying on description statements in normal data nodes, > > > > > > > which no tool can understand without hard coding special cases. > > > > > > > > > > > > I'm also opposed to this. > > > > > > > > > > > > Stuff that looks like configuration should be configuration, and stuff > > > > > > that looks like state should be state. If this data is going to be > > > > > > described in YANG then I think that there must be a programmatic way > > to > > > > > > indicate that the resultant schema is not configuration or operational > > > > > > state, but something else instead. An extension seems to achieve > > this. > > > > > > > > > > YANG spec deals exclusively with configuration and state data, and using > > its > > > > > statements inside an extension doesn't make this basic fact go away. > > > > > Specifying > > > > > all necessary changes properly inside a description of an extension is > > > > > simply > > > > > impossible. > > > > > > > > If an implementation needs to support generating the error messages then > > > > they can support the yang-data extension if they want (or just hard code > > > > what they expect to receive). > > > > > > Or support the "error-messages" datastore, see above. > > > > > > Lada > > > > > > > > > > > Otherwise, devices can also ignore the yang-data extension and it > > > > doesn't seem to do any harm since its doesn't change the behaviour in > > > > any way. > > > > > > > > Thanks, > > > > Rob > > > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > Thanks, > > > > > > Rob > > > > > > > > > > > > > > > > > > > > > > > > > > > It would be great to remove NETCONF specifics from YANG and I'd be > > > > > > > > willing > > > > > > > > to > > > > > > > > contribute to this work. > > > > > > > > > > > > > > This is a different topic though. > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > A plain client can ignore yang-data and not affect and > > RPC, > > > > > > > > > > > > notification, > > > > > > > > > > > > > > > > > > > > or > > > > > > > > > > > > data > > > > > > > > > > > > definitions in plain YANG. > > > > > > > > > > > > > > > > > > > > > > A plain (NC/RC) client should never see such data even if it > > is > > > > > > > > > > > not > > > > > > > > > > > > > > > > > > > > protected by > > > > > > > > > > > yang-data in YANG. On the other hand, tools will be able to > > > > > > > > > > > process > > > > > > > > > > > such > > > > > > > > > > > > > > > > > > > > schemas > > > > > > > > > > > (generate the ascii tree, convert it to something else, > > generate > > > > > > > > > > > sample > > > > > > > > > > > instances etc.) without explicitly supporting yang-data. > > > > > > > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > there is a version of YANG that has a proper and > > complete > > > > > > > > > > > > > > integrated > > > > > > > > > > > > > > solution. (If for example yang-data is used to declare > > > > > > > > > > > > > > error > > > > > > > > > > > > > > content > > > > > > > > > > > > > > for RPCs, then more extensions are needed or a proper > > > > > > > > > > > > > > integration > > > > > > > > > > > > > > > > > > > > into > > > > > > > > > > > > > > YANG. Is it really good to introduce augment-yang-data > > > > > > > > > > > > > > (instead of > > > > > > > > > > > > > > making augment work with say 'data' in YANG 1.2)? And > > then > > > > > > > > > > > > > > we > > > > > > > > > > > > > > do > > > > > > > > > > > > > > uses-yang-data etc. > > > > > > > > > > > > > > > > > > > > > > > > > > > > /js > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > Ladislav Lhotka > > > > > > > > > > > > > Head, CZ.NIC Labs > > > > > > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > netmod mailing list > > > > > > > > > > > > > netmod@ietf.org > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > Ladislav Lhotka > > > > > > > > > > > Head, CZ.NIC Labs > > > > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > 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 > > > > > > > > Head, CZ.NIC Labs > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > 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 > > > Head, CZ.NIC Labs > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > From nobody Wed May 2 02:02:50 2018 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 55A1112D877 for ; Wed, 2 May 2018 02:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3OuGnUNijsp for ; Wed, 2 May 2018 02:02:46 -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 8D8AD12D872 for ; Wed, 2 May 2018 02:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14044; q=dns/txt; s=iport; t=1525251765; x=1526461365; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=2hP6e5Sls/MMfn1/OEKI9x9H6Q5vxDnjdO/pd/qKOM8=; b=nCUVQRjci/ZwyRqb330zULJ8KIdLdjXYTXeUHEpYSCiagzYoJHq9cCv8 CRZV5Hb2ZAeQQdZ4SI6pz4VLw/rAn2BoB3oACsmlZAGEpZQFV+bTr2ORc jT9Oxhqo8Rp2O5pN0NmtzjumC4AL8ifOlZXuHM2L8F3zTO/otO5Dw9N1P o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQA9fela/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJNgVcXYyiDbYhgjhGBD44nhHCBeAsYAQqEA0YCgx41FwE?= =?us-ascii?q?CAQEBAQEBAmwcDIUpAQEBAwEBIUsLEAsOBAYqAgInIg4GAQwGAgEBF4R0D6g?= =?us-ascii?q?kghwfhDmDa4I9BYltP4EPI4JogxEBAYFKgxaCVAKQd4cdCI5FBodOhQmLGoU?= =?us-ascii?q?jgSUeAjSBUjMaCBsVO4JDixCFPz4wkC8BAQ?= X-IronPort-AV: E=Sophos;i="5.49,354,1520899200"; d="scan'208,217";a="3510764" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2018 09:02:43 +0000 Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w4292gF5010436; Wed, 2 May 2018 09:02:43 GMT To: Martin Bjorklund , andy@yumaworks.com, Ladislav Lhotka Cc: netmod@ietf.org References: <87d0yglra0.fsf@nic.cz> <20180502.092527.2305319833268262996.mbj@tail-f.com> From: Robert Wilton Message-ID: <9fca04b0-fb29-36b3-67aa-2f2c4fb98748@cisco.com> Date: Wed, 2 May 2018 10:02:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180502.092527.2305319833268262996.mbj@tail-f.com> Content-Type: multipart/alternative; boundary="------------0DAA4355C3A45A51E574481A" Content-Language: en-US Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 09:02:49 -0000 This is a multi-part message in MIME format. --------------0DAA4355C3A45A51E574481A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 02/05/2018 08:25, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Mon, Apr 30, 2018 at 7:09 AM, Ladislav Lhotka wrote: >> >>> Andy Bierman writes: >>> >>>> On Fri, Apr 27, 2018 at 8:13 AM, Ladislav Lhotka wrote: >>>> >>>>> On Fri, 2018-04-27 at 16:47 +0200, Juergen Schoenwaelder wrote: >>>>>> On Fri, Apr 27, 2018 at 04:34:38PM +0200, Ladislav Lhotka wrote: >>>>>> >>>>>>> [...] define a special datastore for it, such as "error-messages". >>>>>> This seems worse than using, well, RFC 8040 yang-data. The proper >>>>> Why it seems worse? >>>>> >>>>> >>>> Because this is not part of the NMDA. >>> NMDA is extensible. >>> >> >> If your only tool is a hammer, then all your problems look like nails. >> I fail to see how an "error-messages" datastore fits in with NMDA >> >> >> >>>> IMO, the yang-data defined in RFC 8040 has a clear purpose, and it >>>> is sufficient for that purpose, which is a YANG representation of >>>> an instance document (such as a protocol message or file). >>> The same is basically true even without the extension. For example, I >>> fail to see any benefit from using yang-data in a module like >>> ietf-zerotouch-information. >>> >> >> I don't see the benefit of pretending all data-def-stmts represent >> configuration or operational data. >> >> Wrapping the data-def-stmts in an extension says "this is not configuration >> or operational data". This is useful for tools that can process YANG in >> other contexts. > I fully agree YANG already models RPCs, and 7950 makes it clear that the input/output parameters of those RPC statements are not configuration or state and are not modeled in datastores.  I.e.: Since the input tree is not part of any datastore, all "config" statements for nodes in the input tree are ignored. Since the output tree is not part of any datastore, all "config" statements for nodes in the output tree are ignored. Isn't the YANG data extension just modelling fragments of YANG to be used in generic RPC messages? This doesn't seem to be a fundamental change in YANG's scope, or architecture. Thanks, Rob > >>>> YANG is useful for defining data structures that can be represented in >>>> different formats, yet it is independent of any 1 format. >>> Of course I see this potential. Unfortunately, YANG spec was explicitly >>> written for a very specific context. Using an extension for removing >>> this specificity is IMO an ugly hack that undermines the architecture. >>> >>> >> I don't see the architecture as fragile or damaged if yang-data is used. >> >> People are going to continue to push the boundaries of YANG capabilities. >> This will happen with or without the IETF. > Yes, and it already happens. > > > /martin > > > >> Maybe this work should remain >> proprietary or get moved to an opensource project. >> >> >> >> >>>> I am in favor if keeping the yang-data in RFC 8040 and not >>>> creating a new version of it that is unconstrained. >>>> There does not seem to be consensus on how to do this, >>>> or even consensus that it is a good idea. >>>> >>> If the extension is deemed necessary, I would also prefer this approach >>> to making the extension a Proposed Standard. >>> >>> Lada >>> >> >> Andy >> >> >>>> >>>>>> clear solution for RPCs and actions would be to enable the definition >>>>>> of error details right in the rpc/action definition (input, output, >>>>>> error). >>>>> Agreed. >>>>> >>>>>> But something like yang-data seems to have uses in other contexts. >>>>> So other datastores may be defined. I assume that YANG library data can >>> be >>>>> used >>>>> independently, not just on a NC/RC server, pretty much along the lines >>> of >>>>> draft- >>>>> lengyel-netmod-yang-instance-data. >>>>> >>>>> Lada >>>>> >>>> Andy >>>> >>>> >>>> >>>>>> /js >>>>>> >>>>> -- >>>>> Ladislav Lhotka >>>>> Head, CZ.NIC Labs >>>>> PGP Key ID: 0xB8F92B08A9F76C67 >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> >>> -- >>> Ladislav Lhotka >>> Head, CZ.NIC Labs >>> PGP Key ID: 0xB8F92B08A9F76C67 >>> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > --------------0DAA4355C3A45A51E574481A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 02/05/2018 08:25, Martin Bjorklund wrote:
Andy Bierman <andy@yumaworks.com> wrote:

On Mon, Apr 30, 2018 at 7:09 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:


Andy Bierman <andy@yumaworks.com> writes:


On Fri, Apr 27, 2018 at 8:13 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:


On Fri, 2018-04-27 at 16:47 +0200, Juergen Schoenwaelder wrote:

On Fri, Apr 27, 2018 at 04:34:38PM +0200, Ladislav Lhotka wrote:


[...] define a special datastore for it, such as "error-messages".

This seems worse than using, well, RFC 8040 yang-data. The proper

Why it seems worse?



Because this is not part of the NMDA.

NMDA is extensible.



If your only tool is a hammer, then all your problems look like nails.
I fail to see how an "error-messages" datastore fits in with NMDA





          

            
IMO, the yang-data defined in RFC 8040 has a clear purpose, and it
is sufficient for that purpose, which is a YANG representation of
an instance document (such as a protocol message or file).


          

          
The same is basically true even without the extension. For example, I
fail to see any benefit from using yang-data in a module like
ietf-zerotouch-information.



        

        

I don't see the benefit of pretending all data-def-stmts represent
configuration or operational data.

Wrapping the data-def-stmts in an extension says "this is not configuration
or operational data".  This is useful for tools that can process YANG in
other contexts.


      

      
I fully agree

    

    

    YANG already models RPCs, and 7950 makes it clear that the
    input/output parameters of those RPC statements are not
    configuration or state and are not modeled in datastores.  I.e.:

    

    
   Since the input tree is not part of any datastore, all "config"
   statements for nodes in the input tree are ignored.

    

    
   Since the output tree is not part of any datastore, all "config"
   statements for nodes in the output tree are ignored.




    Isn't the YANG data extension just modelling fragments of YANG to be
    used in generic RPC messages?

    

    This doesn't seem to be a fundamental change in YANG's scope, or
    architecture.

    

    Thanks,

    Rob

    

    

    

      



      

        

          

            
YANG is useful for defining data structures that can be represented in
different formats, yet it is independent of any 1 format.


          

          
Of course I see this potential. Unfortunately, YANG spec was explicitly
written for a very specific context. Using an extension for removing
this specificity is IMO an ugly hack that undermines the architecture.




        

        
I don't see the architecture as fragile or damaged if yang-data is used.

People are going to continue to push the boundaries of YANG capabilities.
This will happen with or without the IETF.


      

      
Yes, and it already happens.


/martin





      

        
Maybe this work should remain
proprietary or get moved to an opensource project.






        

          

            
I am in favor if keeping the yang-data in RFC 8040 and not
creating a new version of it that is unconstrained.
There does not seem to be consensus on how to do this,
or even consensus that it is a good idea.



          

          
If the extension is deemed necessary, I would also prefer this approach
to making the extension a Proposed Standard.

Lada



        

        

Andy




        

          

          

            



            

              

                
clear solution for RPCs and actions would be to enable the definition
of error details right in the rpc/action definition (input, output,
error).


              

              
Agreed.



              

                
But something like yang-data seems to have uses in other contexts.


              

              
So other datastores may be defined. I assume that YANG library data can


            

          

          
be


          

            

              
used
independently, not just on a NC/RC server, pretty much along the lines


            

          

          
of


          

            

              
draft-
lengyel-netmod-yang-instance-data.

Lada



              

                

              

              

            

            
Andy





            

              

                
/js



              

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

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



            

          

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



        

      

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



    

    

  


--------------0DAA4355C3A45A51E574481A--


From nobody Wed May  2 02:25:30 2018
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 B799A12D965 for ; Wed,  2 May 2018 02:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YDfuGmlz3_7O for ; Wed,  2 May 2018 02:25: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 E7DFC12D95F for ; Wed,  2 May 2018 02:25:07 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id BF3531AE012C; Wed,  2 May 2018 11:25:06 +0200 (CEST)
Date: Wed, 02 May 2018 11:25:06 +0200 (CEST)
Message-Id: <20180502.112506.845305331945500257.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: andy@yumaworks.com, lhotka@nic.cz, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <9fca04b0-fb29-36b3-67aa-2f2c4fb98748@cisco.com>
References:  <20180502.092527.2305319833268262996.mbj@tail-f.com> <9fca04b0-fb29-36b3-67aa-2f2c4fb98748@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] yang-data-ext issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 02 May 2018 09:25:29 -0000

Robert Wilton  wrote:
> =

> =

> On 02/05/2018 08:25, Martin Bjorklund wrote:
> > Andy Bierman  wrote:
> >> On Mon, Apr 30, 2018 at 7:09 AM, Ladislav Lhotka 
> >> wrote:
> >>
> >>> Andy Bierman  writes:
> >>>
> >>>> On Fri, Apr 27, 2018 at 8:13 AM, Ladislav Lhotka =

> >>>> wrote:
> >>>>
> >>>>> On Fri, 2018-04-27 at 16:47 +0200, Juergen Schoenwaelder wrote:=

> >>>>>> On Fri, Apr 27, 2018 at 04:34:38PM +0200, Ladislav Lhotka wrot=
e:
> >>>>>>
> >>>>>>> [...] define a special datastore for it, such as "error-messa=
ges".
> >>>>>> This seems worse than using, well, RFC 8040 yang-data. The pro=
per
> >>>>> Why it seems worse?
> >>>>>
> >>>>>
> >>>> Because this is not part of the NMDA.
> >>> NMDA is extensible.
> >>>
> >>
> >> If your only tool is a hammer, then all your problems look like na=
ils.
> >> I fail to see how an "error-messages" datastore fits in with NMDA
> >>
> >>
> >>
> >>>> IMO, the yang-data defined in RFC 8040 has a clear purpose, and =
it
> >>>> is sufficient for that purpose, which is a YANG representation o=
f
> >>>> an instance document (such as a protocol message or file).
> >>> The same is basically true even without the extension. For exampl=
e, I
> >>> fail to see any benefit from using yang-data in a module like
> >>> ietf-zerotouch-information.
> >>>
> >>
> >> I don't see the benefit of pretending all data-def-stmts represent=

> >> configuration or operational data.
> >>
> >> Wrapping the data-def-stmts in an extension says "this is not
> >> configuration
> >> or operational data".  This is useful for tools that can process Y=
ANG
> >> in
> >> other contexts.
> > I fully agree
> =

> YANG already models RPCs, and 7950 makes it clear that the
> input/output parameters of those RPC statements are not configuration=

> or state and are not modeled in datastores.=A0 I.e.:
> =

>    Since the input tree is not part of any datastore, all "config"
>    statements for nodes in the input tree are ignored.
> =

> =

>    Since the output tree is not part of any datastore, all "config"
>    statements for nodes in the output tree are ignored.
> =

> =

> Isn't the YANG data extension just modelling fragments of YANG to be
> used in generic RPC messages?

The primary use case is not "generic RPC messages", but standalone
instance documents, error-info structures, etc.

> This doesn't seem to be a fundamental change in YANG's scope, or
> architecture.

I agree.


/martin


> =

> Thanks,
> Rob
> =

> =

> >
> >>>> YANG is useful for defining data structures that can be represen=
ted in
> >>>> different formats, yet it is independent of any 1 format.
> >>> Of course I see this potential. Unfortunately, YANG spec was
> >>> explicitly
> >>> written for a very specific context. Using an extension for remov=
ing
> >>> this specificity is IMO an ugly hack that undermines the architec=
ture.
> >>>
> >>>
> >> I don't see the architecture as fragile or damaged if yang-data is=

> >> used.
> >>
> >> People are going to continue to push the boundaries of YANG
> >> capabilities.
> >> This will happen with or without the IETF.
> > Yes, and it already happens.
> >
> >
> > /martin
> >
> >
> >
> >> Maybe this work should remain
> >> proprietary or get moved to an opensource project.
> >>
> >>
> >>
> >>
> >>>> I am in favor if keeping the yang-data in RFC 8040 and not
> >>>> creating a new version of it that is unconstrained.
> >>>> There does not seem to be consensus on how to do this,
> >>>> or even consensus that it is a good idea.
> >>>>
> >>> If the extension is deemed necessary, I would also prefer this
> >>> approach
> >>> to making the extension a Proposed Standard.
> >>>
> >>> Lada
> >>>
> >>
> >> Andy
> >>
> >>
> >>>>
> >>>>>> clear solution for RPCs and actions would be to enable the def=
inition
> >>>>>> of error details right in the rpc/action definition (input, ou=
tput,
> >>>>>> error).
> >>>>> Agreed.
> >>>>>
> >>>>>> But something like yang-data seems to have uses in other conte=
xts.
> >>>>> So other datastores may be defined. I assume that YANG library =
data
> >>>>> can
> >>> be
> >>>>> used
> >>>>> independently, not just on a NC/RC server, pretty much along th=
e lines
> >>> of
> >>>>> draft-
> >>>>> lengyel-netmod-yang-instance-data.
> >>>>>
> >>>>> Lada
> >>>>>
> >>>> Andy
> >>>>
> >>>>
> >>>>
> >>>>>> /js
> >>>>>>
> >>>>> --
> >>>>> Ladislav Lhotka
> >>>>> Head, CZ.NIC Labs
> >>>>> PGP Key ID: 0xB8F92B08A9F76C67
> >>>>>
> >>>>> _______________________________________________
> >>>>> netmod mailing list
> >>>>> netmod@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/netmod
> >>>>>
> >>> --
> >>> Ladislav Lhotka
> >>> Head, CZ.NIC Labs
> >>> PGP Key ID: 0xB8F92B08A9F76C67
> >>>
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > .
> >
> =


From nobody Wed May  2 02:36:33 2018
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 E7FDE12DA41 for ; Wed,  2 May 2018 02:36:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 X2aevYwWZ5da for ; Wed,  2 May 2018 02:36:28 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DDB612D969 for ; Wed,  2 May 2018 02:36:28 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 603C8D25; Wed,  2 May 2018 11:36:27 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id DhvhnN3d3qnE; Wed,  2 May 2018 11:36:27 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed,  2 May 2018 11:36:27 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3B9E920035; Wed,  2 May 2018 11:36:27 +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 cZe5tnUCFcxK; Wed,  2 May 2018 11:36:26 +0200 (CEST)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B96C920031; Wed,  2 May 2018 11:36:26 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 7EFFA42C9E47; Wed,  2 May 2018 11:36:26 +0200 (CEST)
Date: Wed, 2 May 2018 11:36:26 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Cc: netmod@ietf.org
Message-ID: <20180502093626.ugsg6nq24a6vjtdn@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Martin Bjorklund , netmod@ietf.org
References:  <20180502.092527.2305319833268262996.mbj@tail-f.com> <9fca04b0-fb29-36b3-67aa-2f2c4fb98748@cisco.com> <20180502.112506.845305331945500257.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180502.112506.845305331945500257.mbj@tail-f.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] yang-data-ext issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 02 May 2018 09:36:31 -0000

On Wed, May 02, 2018 at 11:25:06AM +0200, Martin Bjorklund wrote:
> 
> The primary use case is not "generic RPC messages", but standalone
> instance documents, error-info structures, etc.
> 
> > This doesn't seem to be a fundamental change in YANG's scope, or
> > architecture.

The proper solution for rpcs and actions is to define error
information as part of the rpc/action. YANG 1.1 does not support
this but this is where it should be fixed.

Standalone instance documents (not tied to datastores) may have their
use cases as well but it feels odd to create support for standalone
instance documents as extensions and then to create even more
extensions to support augmentation of these instance documents and
whoever knows what comes next. For short-term needs, there is
yang-data defined in RFC 8040. The longer-term solution should IMHO be
a proper part of YANG and not an extension.

And if the current short-term solution requires an additional
container, then bam go for the additional container. If there is
serious pressure to use yang-data, then the additional container
should not stop people that need to use yang-data today.

/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  2 03:35:14 2018
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 4BD4312D875 for ; Wed,  2 May 2018 03:35:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] 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 iwEFGbPM6VD1 for ; Wed,  2 May 2018 03:35:08 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26110124BFA for ; Wed,  2 May 2018 03:35:07 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id E71E060440 for ; Wed,  2 May 2018 12:35:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1525257305; bh=DgoWnjfU3AkHK1ESxwdG58iep+80A5fIvkcwpmiheZE=; h=From:To:Date; b=IE463SL9afmySHaVrWQd1r4gOa04MWQgDVorju7mxyNLKkz1qX1DOWMmeIJ09fnVR wCOncY7KGYS8lJEHkQUPkn1EJrDWZ2CnIvaTUVow/hbVU2+gRxHFC0WK2GWNh2n14I rLfOg/N7ON0h65SghD2zhXnxW5esGItrsE8epP6U=
Message-ID: <5f3081d2731263f93486e8242310733e9f4060a4.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Wed, 02 May 2018 12:35:12 +0200
In-Reply-To: <20180502093626.ugsg6nq24a6vjtdn@elstar.local>
References:  <20180502.092527.2305319833268262996.mbj@tail-f.com> <9fca04b0-fb29-36b3-67aa-2f2c4fb98748@cisco.com> <20180502.112506.845305331945500257.mbj@tail-f.com> <20180502093626.ugsg6nq24a6vjtdn@elstar.local>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.1 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] yang-data-ext issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 02 May 2018 10:35:13 -0000

On Wed, 2018-05-02 at 11:36 +0200, Juergen Schoenwaelder wrote:
> On Wed, May 02, 2018 at 11:25:06AM +0200, Martin Bjorklund wrote:
> > 
> > The primary use case is not "generic RPC messages", but standalone
> > instance documents, error-info structures, etc.
> > 
> > > This doesn't seem to be a fundamental change in YANG's scope, or
> > > architecture.
> 
> The proper solution for rpcs and actions is to define error
> information as part of the rpc/action. YANG 1.1 does not support
> this but this is where it should be fixed.
> 
> Standalone instance documents (not tied to datastores) may have their
> use cases as well but it feels odd to create support for standalone
> instance documents as extensions and then to create even more
> extensions to support augmentation of these instance documents and
> whoever knows what comes next. For short-term needs, there is
> yang-data defined in RFC 8040. The longer-term solution should IMHO be
> a proper part of YANG and not an extension.
> 
> And if the current short-term solution requires an additional
> container, then bam go for the additional container. If there is
> serious pressure to use yang-data, then the additional container
> should not stop people that need to use yang-data today.

I agree with all of the above.

Lada

> 
> /js
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed May  2 04:29:09 2018
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 EFB64126CE8; Wed,  2 May 2018 04:29:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yb2OEaAf8dHJ; Wed,  2 May 2018 04:29:00 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F4A126B72; Wed,  2 May 2018 04:29:00 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 13367140E68D1; Wed,  2 May 2018 12:28:56 +0100 (IST)
Received: from DGGEMA421-HUB.china.huawei.com (10.1.198.154) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 2 May 2018 12:28:53 +0100
Received: from DGGEMA502-MBS.china.huawei.com ([169.254.3.74]) by dggema421-hub.china.huawei.com ([10.1.198.154]) with mapi id 14.03.0361.001; Wed, 2 May 2018 19:28:42 +0800
From: Rohit R Ranade 
To: Juergen Schoenwaelder 
CC: "netconf@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [Netconf] [netconf] Comments on draft-ietf-netconf-nmda-netconf-05
Thread-Index: AQHT3IIfwgC8BOYcKUCUv6tR3C0KuqQcVJCg
Date: Wed, 2 May 2018 11:28:42 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6B1F5AD1@DGGEMA502-MBS.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6B1E92F6@DGGEMA502-MBX.china.huawei.com> <20180425104222.2asz5wiuierdumr4@elstar.local>
In-Reply-To: <20180425104222.2asz5wiuierdumr4@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] [Netconf] [netconf] Comments on draft-ietf-netconf-nmda-netconf-05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 02 May 2018 11:29:03 -0000

Hi Juergen,

Some thoughts in-lined.

With Regards,
Rohit R Ranade

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20
Sent: 25 April 2018 16:12
To: Rohit R Ranade 
Cc: netconf@ietf.org; netmod@ietf.org
Subject: Re: [Netconf] [netconf] Comments on draft-ietf-netconf-nmda-netcon=
f-05

On Wed, Apr 25, 2018 at 04:22:24AM +0000, Rohit R Ranade wrote:
> Hi All,
>=20
> I plan to implement this draft and hence had some implementation related =
clarifications.
>=20
>=20
> 1.       I feel that there should be more text added about "origin" filte=
ring mechanism. I am not clear about some aspects of origin filtering.
>=20
> RFC 8342 : NMDA RFC provides the below example
>=20
>                   or:origin=3D"or:intended">
>        
>          lo0
>          loopback
>          127.0.0.1
>          ::1
>        
>      
> If user provides  as "system" ONLY, then he will NOT get t=
his record in output. Because the keys have originated from "intended" . Ri=
ght ?
> So, If user wants to get the system originated data, he MUST give all the=
 origins in the  where the keys of the system data have orig=
inated from. Can you please confirm whether this is OK.

I would expect that or:system would select t=
he ip-address tagged with or:origin=3D"or:system" and that the system would=
 return any necessary container or list elements and the necessary key elem=
ents (since otherwise the value returned is just useless). So the result wo=
uld be:

      
        
          lo0
          127.0.0.1
        
      

[Rohit R Ranade] While this looks OK for the origin filter, for the negated=
-origin-filter, for the same example given above, if  or:intended is given, then it will give the "syste=
m" related nodes even if it encountered the "intended" node first, which th=
e user definitely dint want included in the output ? Can you please confirm=
 whether this is OK.
   Can you please clarify whether the negated filter has higher priority th=
an the selected filter ?

> Another example given in RFC 8342 is as below:
>                        or:origin=3D"or:intended">
>        
>          lo0
>          127.0.0.1
>          ::1
>        
>      
>=20
> ?  Here keys are originated from "system", but it is under container of "=
intended". So if user gives "system" for "origin-filter", the output will s=
till NOT have this instance output ?

We allow origin values on containers or lists in order to inherit them, i.e=
., to achieve a more compact encoding. Anyway, if a leaf node matches, then=
 I think any encompassing containers and list should be included in the res=
ult so that the matching leaf can be reported. So you would return

      
        
          lo0
          127.0.0.1
          ::1
        
      

instead of not returning anything at all.

> ?  Also the container is not defined as "presence" in C.3.  Interface Exa=
mple, but still it has origin whether that is Ok ?

Why not?
[Rohit R Ranade] RFC 8342 Section 5.3.4
" The origin applies to all configuration nodes except non-presence contain=
ers.  "



/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 Wed May  2 05:55:07 2018
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 A72CF126FDC; Wed,  2 May 2018 05:55:00 -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 XIPrKcBl3nlu; Wed,  2 May 2018 05:54:57 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727EA126D05; Wed,  2 May 2018 05:54:57 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 44C4D3B; Wed,  2 May 2018 14:54:56 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Z3rgu1lOYsfx; Wed,  2 May 2018 14:54:55 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed,  2 May 2018 14:54:56 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E961C20035; Wed,  2 May 2018 14:54:55 +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 fQ3EChRhp1SH; Wed,  2 May 2018 14:54:55 +0200 (CEST)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 38FE420031; Wed,  2 May 2018 14:54:55 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 53C3D42CA199; Wed,  2 May 2018 14:54:54 +0200 (CEST)
Date: Wed, 2 May 2018 14:54:53 +0200
From: Juergen Schoenwaelder 
To: Rohit R Ranade 
Cc: "netconf@ietf.org" , "netmod@ietf.org" 
Message-ID: <20180502125453.3fi63v2dw5tffcnd@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Rohit R Ranade , "netconf@ietf.org" , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6B1E92F6@DGGEMA502-MBX.china.huawei.com> <20180425104222.2asz5wiuierdumr4@elstar.local> <991B70D8B4112A4699D5C00DDBBF878A6B1F5AD1@DGGEMA502-MBS.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6B1F5AD1@DGGEMA502-MBS.china.huawei.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] [Netconf] [netconf] Comments on draft-ietf-netconf-nmda-netconf-05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 02 May 2018 12:55:01 -0000

On Wed, May 02, 2018 at 11:28:42AM +0000, Rohit R Ranade wrote:
> Hi Juergen,
> 
> Some thoughts in-lined.
> 
> With Regards,
> Rohit R Ranade
> 
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] 
> Sent: 25 April 2018 16:12
> To: Rohit R Ranade 
> Cc: netconf@ietf.org; netmod@ietf.org
> Subject: Re: [Netconf] [netconf] Comments on draft-ietf-netconf-nmda-netconf-05
> 
> On Wed, Apr 25, 2018 at 04:22:24AM +0000, Rohit R Ranade wrote:
> > Hi All,
> > 
> > I plan to implement this draft and hence had some implementation related clarifications.
> > 
> > 
> > 1.       I feel that there should be more text added about "origin" filtering mechanism. I am not clear about some aspects of origin filtering.
> > 
> > RFC 8342 : NMDA RFC provides the below example
> > 
> >  >                  or:origin="or:intended">
> >        
> >          lo0
> >          loopback
> >          127.0.0.1
> >          ::1
> >        
> >      
> > If user provides  as "system" ONLY, then he will NOT get this record in output. Because the keys have originated from "intended" . Right ?
> > So, If user wants to get the system originated data, he MUST give all the origins in the  where the keys of the system data have originated from. Can you please confirm whether this is OK.
> 
> I would expect that or:system would select the ip-address tagged with or:origin="or:system" and that the system would return any necessary container or list elements and the necessary key elements (since otherwise the value returned is just useless). So the result would be:
> 
>                          or:origin="or:intended">
>         
>           lo0
>           127.0.0.1
>         
>       
> 
> [Rohit R Ranade] While this looks OK for the origin filter, for the negated-origin-filter, for the same example given above, if  or:intended is given, then it will give the "system" related nodes even if it encountered the "intended" node first, which the user definitely dint want included in the output ? Can you please confirm whether this is OK.

I think the leafs matter. Origin values on container and list nodes
are used for compactness. I think I wrote this already.

>    Can you please clarify whether the negated filter has higher priority than the selected filter ?

There are no priorities.

> > Another example given in RFC 8342 is as below:
> >       >                  or:origin="or:intended">
> >        
> >          lo0
> >          127.0.0.1
> >          ::1
> >        
> >      
> > 
> > ?  Here keys are originated from "system", but it is under container of "intended". So if user gives "system" for "origin-filter", the output will still NOT have this instance output ?
> 
> We allow origin values on containers or lists in order to inherit them, i.e., to achieve a more compact encoding. Anyway, if a leaf node matches, then I think any encompassing containers and list should be included in the result so that the matching leaf can be reported. So you would return
> 
>                          or:origin="or:intended">
>         
>           lo0
>           127.0.0.1
>           ::1
>         
>       
> 
> instead of not returning anything at all.
> 
> > ?  Also the container is not defined as "presence" in C.3.  Interface Example, but still it has origin whether that is Ok ?
> 
> Why not?
> [Rohit R Ranade] RFC 8342 Section 5.3.4
> " The origin applies to all configuration nodes except non-presence containers.  "
>

There are origin attributes that apply to the data node where the
attribute is present and there are origin attributes that exist in
order to inherit them to other data nodes. A node that is not carrying
a configuration value and is not a presence container may have an
origin attribute for inheritance purposes.

/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  2 08:21:12 2018
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 86383126579 for ; Wed,  2 May 2018 08:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwCTDZx3rvQC for ; Wed,  2 May 2018 08:21:05 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50120.outbound.protection.outlook.com [40.107.5.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3C8B124235 for ; Wed,  2 May 2018 08:21:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=63RwAU68bAJU9uadw1UYiztQ3PYnkD48g9k4e1QV91o=; b=iKFgOic1OT4py53c7XQ1uiF93fZIPjeAzhtnhSQ9qLspqLaCPpuIfkC1as8H11lwxMxzyK7lrMCUEX4gjU17xmsNWMMmsmGokkSJkMIj+vVwadT8ZQvlD6B3lqAVAyWq5GsbiiUl7traWRS35BF463QtrL0ysboEC+EjwEWo+gE=
Received: from AM0PR07MB3844.eurprd07.prod.outlook.com (52.134.82.20) by AM0PR07MB4241.eurprd07.prod.outlook.com (52.133.60.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.6; Wed, 2 May 2018 15:21:02 +0000
Received: from AM0PR07MB3844.eurprd07.prod.outlook.com ([fe80::c65:ce3c:f99e:3132]) by AM0PR07MB3844.eurprd07.prod.outlook.com ([fe80::c65:ce3c:f99e:3132%3]) with mapi id 15.20.0735.006; Wed, 2 May 2018 15:21:02 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" 
To: "netmod@ietf.org" 
Thread-Topic: NETCONF server handling of 'when' statements
Thread-Index: AdPhmt4MyR2TAhLzQmOJdvRLqrMCsA==
Date: Wed, 2 May 2018 15:21:02 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jason.sterne@nokia.com; 
x-originating-ip: [135.245.20.21]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB4241; 7:9qNs0oXlcAx9BGfnh/w38o4xzNzqf1MuuohGPdfIw/ursDDvF2q+3Py5ljn4kWORDdUA2vRK7m8ebR+HZl/BqiWYdozY2doB9KTSrAIfyf9RsMOCUcnp9eid2z7Iyu9c0nmpCdkCwFJESJdbzYE2iBItcro6razDiIyms4m4g7Jnt+2KuH8+XmB7HQlS/NnGtZHHMh1RNtAKrFKtL+AtnGHAkbjTBsngHcLGtu0Q3pW0TPQlIVD1+ftuigf9umtY
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7193020); SRVR:AM0PR07MB4241; 
x-ms-traffictypediagnostic: AM0PR07MB4241:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(21748063052155)(183022231695245); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231254)(11241501184)(806099)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041310)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:AM0PR07MB4241; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB4241; 
x-forefront-prvs: 06607E485E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(396003)(376002)(346002)(366004)(39860400002)(53754006)(199004)(189003)(25786009)(53386004)(55016002)(7736002)(33656002)(5630700001)(81156014)(3280700002)(5660300001)(68736007)(606006)(5640700003)(2900100001)(8676002)(106356001)(74316002)(6916009)(3660700001)(105586002)(2906002)(81166006)(86362001)(14454004)(66066001)(476003)(2351001)(26005)(102836004)(6506007)(1730700003)(316002)(2501003)(8936002)(5250100002)(59450400001)(486006)(99286004)(6116002)(3846002)(9686003)(53936002)(236005)(186003)(7696005)(97736004)(790700001)(478600001)(6306002)(6436002)(54896002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4241; H:AM0PR07MB3844.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: UhcC12C+BkmDUH2RvubNF0S6VSlZwlFbTgmLtT5j2LOEW8nPrATZZRAiMQRuSEJK11UEhsU9PP+8qZwzkrBJ1h1ngaaKdl2EAr39bQqmjeRYvC4pAsaNllC+mOkJGrikCoB7Jm7emiCi5cfVzb6riUBUWxZfpCva+04u0cvZfVc6D45Kp3l7oCC7U4KQK6amO5vPBtD2EOeRSHF7FfAUJXRLIiX6bFYEjc/+qQouuSQ0pWlplbshBqSAB/MT3Aeh
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM0PR07MB38442E8CF930E0D216C218459B800AM0PR07MB3844eurp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: ebc5e8e3-9eb7-45ef-e076-08d5b04050ce
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ebc5e8e3-9eb7-45ef-e076-08d5b04050ce
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2018 15:21:02.2683 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4241
Archived-At: 
Subject: [netmod] NETCONF server handling of 'when' statements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 02 May 2018 15:21:10 -0000

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

Hi all,

I've seen some older threads about 'when' handling and they ended up creati=
ng a lot of debate about behavior & intentions (and about how well the text=
 is written in the specs).

I'm hoping that the community out there is in agreement on yes vs no for th=
e questions below.

Given the following module:

module test {
   namespace "http://test.com";
   prefix "test";

   container foo {
     leaf foo-type {
       type enumeration {
         enum "green";
         enum "red";
       }
     }
     leaf green-value {
       when "../foo-type =3D 'green'";
       type uint32;
     }
     leaf red-value {
       when "../foo-type =3D 'red'";
       type uint32;
     }
   }
}


(A) Assume the candidate is empty initially.  Does the following edit-confi=
g to the candidate return "OK" ?  (only showing the content of the =
 section):


  23
  red


Does the candidate contain the following after the edit-config ?
     foo-type =3D red
     red-value =3D 23

Is the result the same if the red-value and foo-type leafs were reversed in=
 the XML above ?

(B) Assume the candidate is empty initially.  Does the following edit-confi=
g to the candidate return an error ?


  23
  green


Does it also return an error if the red-value and foo-type leafs were rever=
sed in the XML above ?

(C) Does the presence of 'when' in a YANG model ever create the need for a =
NETCONF client to specifically order nodes within a single edit-config to a=
chieve some desired behavior ?

Or do 'when' statements purely put the onus on the server to build a depend=
ency tree with the scope of a single edit-config (to ensure that the input =
leafs to a 'when' statement are processed before the when statement itself =
is evaluated, i.e. evaluate the when statements at the end) ?

Rgds,
Jason









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











=
Hi all,


=
 


=
I've seen some older threads about 'when' handling and they ended up creati=
ng a lot of debate about behavior & intentions (and about how well the =
text is written in the specs).


=
 


=
I'm hoping that the community out there is in agreement on yes vs no for th=
e questions below.


=
 


=
Given the following module:


=
 


=
module test {


=
   namespace "http://test.com";


=
   prefix "test";


=
 


=
   container foo {


=
     leaf foo-type {


=
       type enumeration {

=
         enum "green";


=
         enum "red";



=
       }


=
     }


=
     leaf green-value {


=
       when "../foo-type =3D 'green'&quo=
t;;


=
       type uint32;


=
     }


=
     leaf red-value {


=
       when "../foo-type =3D 'red'"=
;


=
       type uint32;


=
     }


=
   }


=
}


=
 


=
 


=
(A) Assume the candidate is empty initially.  Does the following edit-=
config to the candidate return "OK" ?  (only showing the con=
tent of the <config></config> section):


=
 


=
<root xmlns=3Dhttp://dummy.com>=



=
  <red-value>23</red-value>


=
  <foo-type>red</foo-type>


=
</root>


=
 


=
Does the candidate contain the following after the edit-config ?=



=
     foo-type =3D red


=
     red-value =3D 23


=
 


=
Is the result the same if the red-value and foo-type leafs were reversed in=
 the XML above ?


=
 


=
(B) Assume the candidate is empty initially.  Does the following edit-=
config to the candidate return an error ? 



=
 


=
<root xmlns=3Dhttp://dummy.com>=



=
  <red-value>23</red-value>


=
  <foo-type>green</foo-type>


=
</root>


=
 


=
Does it also return an error if the red-value and foo-type leafs were rever=
sed in the XML above ?


=
 


=
(C) Does the presence of 'when' in a YANG model ever create the need for a =
NETCONF client to specifically order nodes within a single edit-config to a=
chieve some desired behavior ?


=
 


=
Or do 'when' statements purely put the onus on the server to build a depend=
ency tree with the scope of a single edit-config (to ensure that the input =
leafs to a 'when' statement are processed before
 the when statement itself is evaluated, i.e. evaluate the when statements =
at the end) ?


=
 


=
Rgds,


=
Jason


=
 


=
 


=
     


=
  


=
 


=
 


=
 


=
 






--_000_AM0PR07MB38442E8CF930E0D216C218459B800AM0PR07MB3844eurp_--


From nobody Wed May  2 09:19:52 2018
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 EFD21128D2E for ; Wed,  2 May 2018 09:19:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 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, T_DKIMWL_WL_MED=-0.01] 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 OxAcLgxsDVAN for ; Wed,  2 May 2018 09:19:49 -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 3E08E12895E for ; Wed,  2 May 2018 09:19:49 -0700 (PDT)
Received: by mail-lf0-x229.google.com with SMTP id b23-v6so21719631lfg.4 for ; Wed, 02 May 2018 09:19:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Ll0oXCe+5P9UFiv2FIUCEu95l2jfW59i3fBYrHyN1m8=; b=yx9j5NHBOmzQBhmUxvuZ+tfF877RcCZyLZTVWZGYandMiKEv/LasUFxrEWpXlSV0WX zCP2wvw1l7Jp/+kc/p68mYcbHHPqmqA+Qt5nKJ+kDjOA61Eyzyyb+9nuQiz4q7XKFX2r aTUKdfnKUVZYalVV7MZwQH60b0MiC2clP0d3c3mQLW8yrTX2mvdcVo7OQR2X6PftMhgo bp+A1flS3kic339dylv/6t/MjVG7m6LZ9BT2IBxi0/yF4hHXZuOlB2OF4HGi1i9QkK3d sQEI/kiI4eBvUpIM8f50vibg2rJDkL1piGUB6g30wi6fAVvchnjz+djB2GSkJvP6TbIJ SMzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Ll0oXCe+5P9UFiv2FIUCEu95l2jfW59i3fBYrHyN1m8=; b=lZ9SZ8dW6rzHZWqMJA6+5ek24eSEHH78b7+y5twiNBXOg3Wt+zh3WITHg0dI5Mx5FK KF1TqrNiC8rcpT2KBnB/Q0Ka/j5iqArLxPd+JVFqNeVpEeZ++mvi7BgnQxzjylQC7MlL P/S9sYZgkHv0VKgordaZpED1wZl2kMPbwf/KyzTceRl3zCESG/USOdsuJRm9HAsHRMoF UYPJ5K+42evsKvzC1+E/doeIPFoFyZ3oq0YlAX/BQIpd/OZFgQ0XfluD/OKde1Be6ZXh X6apLwXtbeMCpejqnlo/s1iXDmwRiWwgcyljz5yv1Mz+r/oI4PUhtgUqQOWyEHGhPPif 509g==
X-Gm-Message-State: ALQs6tCF84JCSenVKcGmG/uosCn4E37WFmHyOfDx4gplgcaLJIkq57Jt YWBIp2voyg+9d9UGsPFyKXdXtq8CnLh1eJEBMfmfuQ==
X-Google-Smtp-Source: AB8JxZpiKQIJpIUJWng5rZD/HiggHy8qUeuBLBtEMxOPtcETiLORhw5C/v6yNNNGo9aZEMOmhYiaCGRngGfkd/QVBe4=
X-Received: by 2002:a19:5491:: with SMTP id b17-v6mr13002832lfl.33.1525277986974;  Wed, 02 May 2018 09:19:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Wed, 2 May 2018 09:19:45 -0700 (PDT)
From: Andy Bierman 
Date: Wed, 2 May 2018 09:19:45 -0700
Message-ID: 
To: NetMod WG 
Content-Type: multipart/alternative; boundary="000000000000990448056b3b748f"
Archived-At: 
Subject: [netmod] Abusing YANG extensions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 02 May 2018 16:19:51 -0000

--000000000000990448056b3b748f
Content-Type: text/plain; charset="UTF-8"

Hi,

The discussion about yang-data is stuck because the NETMOD WG does not
understand or does not agree on what it means to abuse a YANG extension
and use it improperly.

If a tool implementing a standard cannot do so without implementing
certain extensions, then those extensions are not optional,
but rather they are mandatory, and therefore violating YANG 1.1.

The NACM extensions are OK because they can be safely ignored
unless the implementation supports NACM, These extensions
are only implemented by the server, so the client is not impacted.

The  element is a use-case where YANG fails completely.
According to YANG, the  element should only contain child nodes
if they are defined directly or defined with the augment-stmt.
YANG says absolutely nothing about nested data nodes that contain
top-level data nodes.

The "mount-point" extension in YANG Schema Mount also violates
YANG 1.1 in this way. A plain client that does not support schema-mount
will find container and list elements that contain undefined child nodes.
If the server chooses to support schema-mount, the client
is forced to support it, and this is a violation of YANG 1.1.

However, the yang-data extension cannot possibly interfere with standard
YANG 1.1 statements because it is used to specify data structures
that are outside the plain data nodes, instead of over-riding the
definitions of the plain data nodes.


Andy

--000000000000990448056b3b748f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

The discussion about yang-data is s=
tuck because the NETMOD WG does not
understand or does not agree =
on what it means to abuse a YANG extension
and use it improperly.=


If a tool implementing a standard cannot do so wi=
thout implementing
certain extensions, then those extensions are =
not optional,
but rather they are mandatory, and therefore violat=
ing YANG 1.1.

The NACM extensions are OK because t=
hey can be safely ignored
unless the implementation supports NACM=
, These extensions
are only implemented by the server, so the cli=
ent is not impacted.

The <config> element is=
 a use-case where YANG fails completely.
According to YANG, the &=
lt;config> element should only contain child nodes
if they are=
 defined directly or defined with the augment-stmt.=C2=A0
YANG sa=
ys absolutely nothing about nested data nodes that contain
top-le=
vel data nodes.

The "mount-point" extens=
ion in YANG Schema Mount also violates
YANG 1.1 in this way. A pl=
ain client that does not support schema-mount
will find container=
 and list elements that contain undefined child nodes.
If the ser=
ver chooses to support schema-mount, the client
is forced to supp=
ort it, and this is a violation of YANG 1.1.

Howev=
er, the yang-data extension cannot possibly interfere with standard
YANG 1.1 statements because it is used to specify data structures
<=
div>that are outside the plain data nodes, instead of over-riding the=

definitions of the plain data nodes.


Andy






--000000000000990448056b3b748f--


From nobody Wed May  2 13:27:42 2018
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 C69F6126DC2 for ; Wed,  2 May 2018 13:27:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzfdwCDpUT8Y for ; Wed,  2 May 2018 13:27:38 -0700 (PDT)
Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (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 A3CBA1241F8 for ; Wed,  2 May 2018 13:27:38 -0700 (PDT)
Received: by mail-oi0-x243.google.com with SMTP id a6-v6so14164488oia.2 for ; Wed, 02 May 2018 13:27:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zxEaONddBpB0/L/BB7bCf2y3mSDtCiZ5V7BT3NT3OdM=; b=FfHbjCerRZACtp+thB92uAWDq4B7zBrolP0vkgWdzHT5SQKwin4L5e2yCaPFC3bte1 llWZmUoqVZZhcZuN295lpOZcq85BTF6O8a0Nm11fD/GNYhWJchsZqhoaZzhf2KzRAxBW FeW6rjKmSdC2cDyUsf/uqAI9W1vqB8nCNO7bu+8/AbiQKxjfXU3QR/DntMSkwWmNFI1x PXdJoR8cr7TSqFV0MhzF8/1I330dw50fjDx9BHakPCyoDpNPt4KmdfjjiLgQjHoQ8bVz pRtugvpHXiixZHncqoWLUAx0cX/1UfnCzuzJgQKZa+/xkrEBWfLxAIpNDLSDC3wPw97c Nf2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zxEaONddBpB0/L/BB7bCf2y3mSDtCiZ5V7BT3NT3OdM=; b=OOmutA6T2GfBxQ4JD/N8V5ewGV5ExO+EOlhZ+njCANWxJAyjdVnA6t0VlqV1Xdehu3 6GjSP0jim9egR9u+kQ+8NQUGZnrXiFtSuDisuqp8JITzSzXIa6iy1wvTzz/wIgWf29CY eoukSK27cNE6c2CrxnUOLlieJwq4BLkPCout87cxXfm/YtQ4wUgZD/5m/sxjTZUllgc6 SUBHqgqGuo2IF3AyXGDA1PG3v/UxevoIXCVys57XZ5+ZFchEaZJGubzzB8giMEytEZcs oN56lfzaYCEPmX2lLRxGkyMQh3LsVHeIfqMVpGeP81uIUAjI8AJl8lQHli10Gy2BfyQI 1GJQ==
X-Gm-Message-State: ALQs6tDsEpikYNr3OEP9E0heB/zEC061QEEvgrQ7cORuAC/wH1BKK58K SNrhfzLFAyiD1Bi/NlfspQWJiTPaAIib4JaW+FyJkovnVFk=
X-Google-Smtp-Source: AB8JxZp+gNVGk7DXSeG8iIqnFOaoBRWP1IeiuDaC43cuOw64pXoLymK6d2ZAhsdu2FX3t0NiPLl0/fBSb/j5a7PAJ9k=
X-Received: by 2002:aca:45d5:: with SMTP id s204-v6mr11641572oia.52.1525292858129;  Wed, 02 May 2018 13:27:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:28f5:0:0:0:0:0 with HTTP; Wed, 2 May 2018 13:27:37 -0700 (PDT)
In-Reply-To: <60E03C57-6239-4C07-8ECE-4FD788B9002A@juniper.net>
References: <60E03C57-6239-4C07-8ECE-4FD788B9002A@juniper.net>
From: Lisa Huang 
Date: Wed, 2 May 2018 13:27:37 -0700
Message-ID: 
To: Kent Watsen 
Cc: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000fcc2bb056b3eea8e"
Archived-At: 
Subject: Re: [netmod] IPR call on draft-ietf-netmod-acl-model-18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 02 May 2018 20:27:41 -0000

--000000000000fcc2bb056b3eea8e
Content-Type: text/plain; charset="UTF-8"

Hi Kent,

No, I'm not aware of any IPR that applies to this draft.

Regards,
Lisa


On Tue, May 1, 2018 at 1:03 PM, Kent Watsen  wrote:

> Thank you, Mahesh and Sonal.
>
> I'm still waiting to hear from Lisa and Dana.  Neither have been heard
> from since the pen moved a couple years ago.  Is anyone aware of Lisa or
> Dana's current email?
>
> Let's give it a few days but, if we don't hear back from them shortly, I
> recommend moving their names from authors to contributors so we can unblock
> the publishing process.
>
> Thanks,
> Kent // shepherd
>
>
> ===== original message =====
>
> Authors, Contributors, WG,
>
> As part of Shepherd write-up for the acl-model draft, we need to ensure
> that all IPR has been declared.  There was an IPR-call before, when there
> was a different set of authors involved, but not since, so it seems prudent
> to do another call now.
>
> Are you aware of any IPR that applies to draft identified above?
>
>
> Please state either:
>     "No, I'm not aware of any IPR that applies to this draft"
>   or
>     "Yes, I'm aware of IPR that applies to this draft"
>
>
> If yes, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3979, 4879, 3669 and 5378 for more details)? Please state
> either:
>     "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
>   or
>     "No, the IPR has not been disclosed"
>
> If no, please provide any additional details you think appropriate.
>
>
> If you are listed as a document author or contributor, please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author and listed
> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
>
>
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under the
> IETF IPR rules which encourages you to notify the IETF if you are aware
> of IPR of others on an IETF contribution, or to refrain from participating
> in any contribution or discussion related to your undisclosed IPR. For
> more information, please see the RFCs listed above and
> https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.
> tools.ietf.org_group_iesg_trac_wiki_IntellectualProperty&d=DwICAg&
> c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=
> 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=yj0hQ9S_
> xraeKbiSv7McZY1diBVVR4EU78hnklrI24I&s=xX-ih-MpZ1qkXhYls1UQDAK7WuTJnOc29n7Z
> p4nk_Gc&e=.
>
> Thank you,
>
> Kent // document shepherd and co-chair
>
>
> PS: Please include all listed in the headers of this message in your
> response.
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=yj0hQ9S_
> xraeKbiSv7McZY1diBVVR4EU78hnklrI24I&s=m-pbImTlMIVO07ILC0SphA-b3D-
> 3urMSOPR3YSWwQXk&e=
>
>
>

--000000000000fcc2bb056b3eea8e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Kent,

No, I'm not aware of any IPR that applies to this =
draft.

Regards,
Lisa


On Tue, May 1=
, 2018 at 1:03 PM, Kent Watsen <kwatsen@juniper.net> wrote=
:
Thank you, Mahesh and Sonal.=C2=A0 



I'm still waiting to hear from Lisa and Dana.=C2=A0 Neither have been h=
eard from since the pen moved a couple years ago.=C2=A0 Is anyone aware of =
Lisa or Dana's current email?



Let's give it a few days but, if we don't hear back from them short=
ly, I recommend moving their names from authors to contributors so we can u=
nblock the publishing process.



Thanks,

Kent // shepherd





=3D=3D=3D=3D=3D original message =3D=3D=3D=3D=3D



Authors, Contributors, WG,



As part of Shepherd write-up for the acl-model draft, we need to ensure tha=
t all IPR has been declared.=C2=A0 There was an IPR-call before, when there=
 was a different set of authors involved, but not since, so it seems pruden=
t to do another call now. 



Are you aware of any IPR that applies to draft identified above?





Please state either:

=C2=A0 =C2=A0 "No, I'm not aware of any IP=
R that applies to this draft"

=C2=A0 or

=C2=A0 =C2=A0 "Yes, I'm aware of IPR that =
applies to this draft"





If yes, has this IPR been disclosed in compliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for more details)? Please state

either:

=C2=A0 =C2=A0 "Yes, the IPR has been disclosed in compliance with IETF=
 IPR rules"

=C2=A0 or

=C2=A0 =C2=A0 "No, the IPR has not been disclosed"



If no, please provide any additional details you think appropriate.





If you are listed as a document author or contributor, please answer the
above by responding to this email regardless of whether or not you are

aware of any relevant IPR. This document will not advance to the next

stage until a response has been received from each author and listed

contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S<=
br>
TO LINES.





If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under the
IETF IPR rules which encourages you to notify the IETF if you are aware

of IPR of others on an IETF contribution, or to refrain from participating<=
br>
in any contribution or discussion related to your undisclosed IPR. For

more information, please see the RFCs listed above and

https://urldefense.proofpoint.com/v2/url?=
u=3Dhttp-3A__trac.tools.ietf.org_group_iesg_trac_wiki_Intell=
ectualProperty&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJd=
cZo&m=3Dyj0hQ9S_xraeKbiSv7McZY1diBVVR4EU78hnklrI24I&s=3Dx=
X-ih-MpZ1qkXhYls1UQDAK7WuTJnOc29n7Zp4nk_Gc&e=3D.



Thank you,



Kent // document shepherd and co-chair





PS: Please include all listed in the headers of this message in your respon=
se.






____________________________=
___________________

netmod mailing list

netmod@ietf.org

ht=
tps://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org=
_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scb=
fh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYa=
GTvjISlaJdcZo&m=3Dyj0hQ9S_xraeKbiSv7McZY1diBVVR4EU78hnkl=
rI24I&s=3Dm-pbImTlMIVO07ILC0SphA-b3D-3urMSOPR3YSWwQXk&e=
=3D









--000000000000fcc2bb056b3eea8e--


From nobody Thu May  3 03:11:12 2018
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 64B421200F1 for ; Thu,  3 May 2018 03:11:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEbt6xQqSBNs for ; Thu,  3 May 2018 03:11:04 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 093E01252BA for ; Thu,  3 May 2018 03:11:04 -0700 (PDT)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 8FB43F9D69877 for ; Thu,  3 May 2018 11:11:00 +0100 (IST)
Received: from DGGEMA406-HUB.china.huawei.com (10.3.20.47) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 3 May 2018 11:11:01 +0100
Received: from DGGEMA502-MBS.china.huawei.com ([169.254.3.74]) by DGGEMA406-HUB.china.huawei.com ([10.3.20.47]) with mapi id 14.03.0361.001; Thu, 3 May 2018 18:10:53 +0800
From: Rohit R Ranade 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] NMDA DataStore Read-Only / Write-able  programmability
Thread-Index: AdPixRIB0M7SoKBRTEKVAgOLu2eK5w==
Date: Thu, 3 May 2018 10:10:53 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6B1F7204@DGGEMA502-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.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6B1F7204DGGEMA502MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [netmod]  NMDA DataStore Read-Only / Write-able  programmability
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 May 2018 10:11:10 -0000

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

Hi All,

Currently I see in the NMDA RFC, that whether a data-store is write-able or=
 read-only is mentioned in the RFC sections, but not in the YANG module. So=
 user cannot know if write-able or not by looking at the NMDA Yang modules =
.

For example  and  are read-only. So the NETCONF  cannot be done on these data-stores.

"If an  operation is invoked on a non-writable
   datastore, then an error is returned, as specified in
   "ietf-netconf-nmda"" =3D=3D> How can ietf-netconf-nmda know at run-time =
whether a data-store supports write or not ? Hard-code ? How to handle for =
new data-stores which use the dynamic identity  ?

With Regards,
Rohit R Ranade


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











Hi All,


 


Currently I see in the NMDA RFC=
, that whether a data-store is write-able or read-only is mentioned in the =
RFC sections, but not in the YANG module. So user cannot know if write-able=
 or not by looking at the NMDA Yang
 modules .


 


For example <intended> an=
d <operational> are read-only. So the NETCONF <edit-data> canno=
t be done on these data-stores.



 


“If an <=
edit-data> operation is invoked on a non-writable


   datastore, then an error is retu=
rned, as specified in


   "ietf-netconf=
-nmda"”
è=
 How can ietf-netconf-nmda know at run-time whether a =
data-store supports write or not ? Hard-code ? How to handle for new data-s=
tores which use the dynamic identity  ?


 


With Regards,=



Rohit R Ranade


 






--_000_991B70D8B4112A4699D5C00DDBBF878A6B1F7204DGGEMA502MBSchi_--


From nobody Thu May  3 03:30:35 2018
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 9164512D889 for ; Thu,  3 May 2018 03:30:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iao2cVx09_PD for ; Thu,  3 May 2018 03:30:32 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E62D12711D for ; Thu,  3 May 2018 03:30:32 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 581F0B66; Thu,  3 May 2018 12:30:30 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id ac_bd0jdYLT5; Thu,  3 May 2018 12:30:30 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu,  3 May 2018 12:30:30 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3336B20035; Thu,  3 May 2018 12:30:30 +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 p8Nziy228yoG; Thu,  3 May 2018 12:30:29 +0200 (CEST)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D264420031; Thu,  3 May 2018 12:30:29 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 6BB5142CB431; Thu,  3 May 2018 12:30:27 +0200 (CEST)
Date: Thu, 3 May 2018 12:30:27 +0200
From: Juergen Schoenwaelder 
To: Rohit R Ranade 
Cc: "netmod@ietf.org" 
Message-ID: <20180503103027.m7ll3tnkcdnakhoy@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Rohit R Ranade , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6B1F7204@DGGEMA502-MBS.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6B1F7204@DGGEMA502-MBS.china.huawei.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] NMDA DataStore Read-Only / Write-able programmability
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 May 2018 10:30:35 -0000

On Thu, May 03, 2018 at 10:10:53AM +0000, Rohit R Ranade wrote:
> Hi All,
> 
> Currently I see in the NMDA RFC, that whether a data-store is write-able or read-only is mentioned in the RFC sections, but not in the YANG module. So user cannot know if write-able or not by looking at the NMDA Yang modules ..
> 
> For example  and  are read-only. So the NETCONF  cannot be done on these data-stores.
> 
> "If an  operation is invoked on a non-writable
>    datastore, then an error is returned, as specified in
>    "ietf-netconf-nmda"" ==> How can ietf-netconf-nmda know at run-time whether a data-store supports write or not ? Hard-code ? How to handle for new data-stores which use the dynamic identity  ?
> 

For well-known datastores, the properties are fixed. A server
implementation will know that  and  is not
writable and clients may know as well. There was some discussion to
expose more datastore metadata at runtime (I think the discussion was
more in the context of the yang library) but this was then left for
future work in order to finish the NMDA work quickly.

/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  3 03:39:59 2018
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 3B40B12D947 for ; Thu,  3 May 2018 03:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.52
X-Spam-Level: 
X-Spam-Status: No, score=-12.52 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuYm0TWF7ZQj for ; Thu,  3 May 2018 03:39:55 -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 2537212D889 for ; Thu,  3 May 2018 03:39:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25784; q=dns/txt; s=iport; t=1525343995; x=1526553595; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=YTqU7qJ8x6tb4R18ALVcbp0ZCYt5TXwH2vNV3YV0e1s=; b=Vwk2ebreIfkxwb1Bddey0zf92MwVTcSpn4BqvSUDZt4x1SQ2byjyKnU9 VthZ7Nia6cO7I+dPCoFpxtuMeu8+7Q7CV5O/hLdV+Ez1K5hPnZPbsEqAb 23UgKa4jgrQYof470R2k/xaWEzBJT0N9Z5dpxOk1rq5b2Onth8yjnX1R3 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAQAT5upa/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJNgVcXYyiMTY1dKYEPkxoUgWQLGAEJhARGAoJONRcBAgE?= =?us-ascii?q?BAQEBAQJsHAyFKAEBAQECAQEBK0EQCwsYIA4nMAYBDAYCAQEQhHMID6ppH4Q?= =?us-ascii?q?5g3CCQolvP4EPI4JogxEBAQKBKwESAQmFagKYFwiFZIJShhAGgXGFXoUKiT+?= =?us-ascii?q?BX4UjgSUdATZhcTMaCBsVO4JDCYVzhRSFPz4wAQEKjhkNFweCGQEB?=
X-IronPort-AV: E=Sophos;i="5.49,358,1520899200"; d="scan'208,217";a="3534780"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2018 10:39:53 +0000
Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w43AdqNo026702; Thu, 3 May 2018 10:39:53 GMT
To: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" 
References: 
From: Robert Wilton 
Message-ID: <903d8476-9e01-2ad7-cfe1-fe02283bb076@cisco.com>
Date: Thu, 3 May 2018 11:39:52 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------EDFBF04F7A6AD250CE8F95BE"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] NETCONF server handling of 'when' statements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 May 2018 10:39:58 -0000

This is a multi-part message in MIME format.
--------------EDFBF04F7A6AD250CE8F95BE
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi Jason,

The Cisco email security filter has somewhat mangled the URLs in your 
message, but my thoughts below ...

On 02/05/2018 16:21, Sterne, Jason (Nokia - CA/Ottawa) wrote:
>
> Hi all,
>
> I've seen some older threads about 'when' handling and they ended up 
> creating a lot of debate about behavior & intentions (and about how 
> well the text is written in the specs).
>
> I'm hoping that the community out there is in agreement on yes vs no 
> for the questions below.
>
> Given the following module:
>
> module test {
>
>  namespace 
> "http://secure-web.cisco.com/17Y2QIXhS6SlnAYxG6R_JjTzP7pmTwW1F-Eg06Aa0sRalUV5358LN3CjHP-LR-MfD47g80JiIgIbUuGpUaYFKxvKv8b5HzDwNkX2Sizzw2gbUBkOvOFtkxCUSgoQl-AM9bU0UjNWmE4Nnrk64L3Zt9pjxyqprJte6HWPQGzLZVx-xey27lchO_GWT4LsmlDt494XoVJOQtcHR5XUjvU-O_mqdXHjgLpZMEG7rsmjru7hXkB6nsDPmlUBD5nwJmP6x1MsX1EluBkJtB0MWNSl3-L78RroFr_dUDcynq2yTyfa5uN_QCCB_kzbe8aPu_pZ9s1i1JslD0GtYrOXCjTpiizC5CJWdMcl3AgN-s-MZ6gI/http%3A%2F%2Ftest.com";
>
>  prefix "test";
>
>  container foo {
>
>  leaf foo-type {
>
>  type enumeration {
>
>  enum "green";
>
>  enum "red";
>
> }
>
>  }
>
>  leaf green-value {
>
>  when "../foo-type = 'green'";
>
>  type uint32;
>
>  }
>
>  leaf red-value {
>
>  when "../foo-type = 'red'";
>
>  type uint32;
>
>  }
>
>  }
>
> }
>
> (A) Assume the candidate is empty initially. Does the following 
> edit-config to the candidate return "OK" ? (only showing the content 
> of the  section):
>
>  xmlns=http://secure-web.cisco.com/1n6yL9gbGW5LZ4loJr_sHzGl3dtOeXtZbr_ymSNNbpnqNC9Uq6XuyUfrAG66jKqWX_DEISNUHnmEoF2yzN01A_ALB4dkI9L6QFnl-aVTS_-M_C5AGJJfI_VulyFBaraLRbIwPKrYvSiG2GR9gto_t6Lh96bdU0ikARiUKQVE2D2UUceA6RypW01ha5ccW6X6GLmU47VUKZ2Q2LS9q-okCyLrkNktXcrYDf_E4Fb1-0Ab0rI4eBHQMKu6YvoSNe0MlCL745ZS9l5qi1busBxlNVt8PZKrxYXRGD3s0Ur7NBP6GQq789J-3GfRuzJL-ks5NqqUwNLLRUe9hgYCfySSzMQjfezZ9lR6EiFVVidvdQa4/http%3A%2F%2Fdummy.com>
>
>  23
>
>  red
>
> 
>
> Does the candidate contain the following after the edit-config ?
>
>  foo-type = red
>
>  red-value = 23
>
Yes.

> Is the result the same if the red-value and foo-type leafs were 
> reversed in the XML above ?
>
Yes, I don't think that ordering matters. Logically you construct a 
updated config tree with all the config changes applied and then check 
that the new tree is valid.

> (B) Assume the candidate is empty initially. Does the following 
> edit-config to the candidate return an error ?
>
>  xmlns=http://secure-web.cisco.com/1n6yL9gbGW5LZ4loJr_sHzGl3dtOeXtZbr_ymSNNbpnqNC9Uq6XuyUfrAG66jKqWX_DEISNUHnmEoF2yzN01A_ALB4dkI9L6QFnl-aVTS_-M_C5AGJJfI_VulyFBaraLRbIwPKrYvSiG2GR9gto_t6Lh96bdU0ikARiUKQVE2D2UUceA6RypW01ha5ccW6X6GLmU47VUKZ2Q2LS9q-okCyLrkNktXcrYDf_E4Fb1-0Ab0rI4eBHQMKu6YvoSNe0MlCL745ZS9l5qi1busBxlNVt8PZKrxYXRGD3s0Ur7NBP6GQq789J-3GfRuzJL-ks5NqqUwNLLRUe9hgYCfySSzMQjfezZ9lR6EiFVVidvdQa4/http%3A%2F%2Fdummy.com>
>
>  23
>
>  green
>
> 
>
I think that it depends on if/when candidate is validated.
Certainly it is not valid in this state.

> Does it also return an error if the red-value and foo-type leafs were 
> reversed in the XML above ?
>
Yes, same answer as above.

> (C) Does the presence of 'when' in a YANG model ever create the need 
> for a NETCONF client to specifically order nodes within a single 
> edit-config to achieve some desired behavior ?
>
No, I don't think that should be required.

> Or do 'when' statements purely put the onus on the server to build a 
> dependency tree with the scope of a single edit-config (to ensure that 
> the input leafs to a 'when' statement are processed before the when 
> statement itself is evaluated, i.e. evaluate the when statements at 
> the end) ?
>
I think that the required logic steps (when the change being committed) is:

1) Construct a new config tree based purely on the  change.
2) Check whether any when statements (anywhere in the config tree) are 
now false, and if so remove the config associated with them.
3) Keep repeating step (2) until there are no more changes to be done.
4) Check that the final "complete config change" is still a valid config 
tree and then continue processing as if this is what had been provided 
by the client in the first place.

Personally, I really dislike the implicit delete behaviour of when 
statements in steps (2) and (3) because I think that it adds a lot of 
unnecessarily complexity in the processing, and has a very surprising 
interaction with NACM. I would much rather that the client was forced 
to delete everything explicitly. I.e. rather than auto deleting some 
config due to an invalid when expression, instead just reject the config 
change with an appropriate error. I would be all for changing this 
behaviour in a future version of YANG. :-)

Thanks,
Rob


> Rgds,
>
> Jason
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://secure-web.cisco.com/1fuFv0na4qfxbvBYug9IKC-mmyzxu1yP8GNikD9y4MUBFLzTufk-XIyIkQQrHLymAFnh5O5vcA-QoCWAFDfBuEsJQy0DpHJfhfVL3yhtZ6B9hHa0OI17Q2MfqLXBvRC3wylOGP9A2ZzeMn9DMara96FtuGPOLmNufjx3D1jE01LjrKo8uu22WTQMoo0Mn2E9HYQcZIL1UA4WJRTDVY7B3mtjkfWXKRQyGBI0ydzAZKkRO1JVLreMh5cv3ste_WLHzwx7LRVLUxNReQ7Lx4_fe5jRlkjJm8oEjVowunA5cLYRCfIgbGu7DJjhGoh4X1oP4yt7U9imcXzfwjGaHFvrtLRKn7YXWyIwWwkA-bzMFPchPR0MkfiYcZkI9LP3mBmcF/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnetmod


--------------EDFBF04F7A6AD250CE8F95BE
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Jason,

    

    The Cisco email security filter has somewhat mangled the URLs in
    your message, but my thoughts below ...

    

    
On 02/05/2018 16:21, Sterne, Jason
      (Nokia - CA/Ottawa) wrote:

    

    

      
      
      
      

        
Hi all,

        

        
I've seen some older threads about 'when'
            handling and they ended up creating a lot of debate about
            behavior & intentions (and about how well the text is
            written in the specs).

        

        
I'm hoping that the community out there is in
            agreement on yes vs no for the questions below.

        

        
Given the following module:

        

        
module test {

        
 namespace
"http://secure-web.cisco.com/17Y2QIXhS6SlnAYxG6R_JjTzP7pmTwW1F-Eg06Aa0sRalUV5358LN3CjHP-LR-MfD47g80JiIgIbUuGpUaYFKxvKv8b5HzDwNkX2Sizzw2gbUBkOvOFtkxCUSgoQl-AM9bU0UjNWmE4Nnrk64L3Zt9pjxyqprJte6HWPQGzLZVx-xey27lchO_GWT4LsmlDt494XoVJOQtcHR5XUjvU-O_mqdXHjgLpZMEG7rsmjru7hXkB6nsDPmlUBD5nwJmP6x1MsX1EluBkJtB0MWNSl3-L78RroFr_dUDcynq2yTyfa5uN_QCCB_kzbe8aPu_pZ9s1i1JslD0GtYrOXCjTpiizC5CJWdMcl3AgN-s-MZ6gI/http%3A%2F%2Ftest.com";

        
 prefix "test";

        

        
 container foo {

        
 leaf foo-type {

        
 type enumeration {

        
 enum "green";

        
 enum "red";
            

        
}

        
 }

        
 leaf green-value {

        
 when "../foo-type = 'green'";

        
 type uint32;

        
 }

        
 leaf red-value {

        
 when "../foo-type = 'red'";

        
 type uint32;

        
 }

        
 }

        
}

        

        

        
(A) Assume the candidate is empty initially.
            Does the following edit-config to the candidate return "OK"
            ? (only showing the content of the
            <config></config> section):

        

        
<root xmlns=http://secure-web.cisco.com/1n6yL9gbGW5LZ4loJr_sHzGl3dtOeXtZbr_ymSNNbpnqNC9Uq6XuyUfrAG66jKqWX_DEISNUHnmEoF2yzN01A_ALB4dkI9L6QFnl-aVTS_-M_C5AGJJfI_VulyFBaraLRbIwPKrYvSiG2GR9gto_t6Lh96bdU0ikARiUKQVE2D2UUceA6RypW01ha5ccW6X6GLmU47VUKZ2Q2LS9q-okCyLrkNktXcrYDf_E4Fb1-0Ab0rI4eBHQMKu6YvoSNe0MlCL745ZS9l5qi1busBxlNVt8PZKrxYXRGD3s0Ur7NBP6GQq789J-3GfRuzJL-ks5NqqUwNLLRUe9hgYCfySSzMQjfezZ9lR6EiFVVidvdQa4/http%3A%2F%2Fdummy.com>

        
 <red-value>23</red-value>

        
 <foo-type>red</foo-type>

        
</root>

        

        
Does the candidate contain the following after
            the edit-config ?

        
 foo-type = red

        
 red-value = 23

      

    

    Yes.

    

    

      

        

        

        
Is the result the same if the red-value and
            foo-type leafs were reversed in the XML above ?

      

    

    Yes, I don't think that ordering matters. Logically you construct a
    updated config tree with all the config changes applied and then
    check that the new tree is valid.

    

    

      

        

        

        
(B) Assume the candidate is empty initially.
            Does the following edit-config to the candidate return an
            error ?
            

        

        
<root xmlns=http://secure-web.cisco.com/1n6yL9gbGW5LZ4loJr_sHzGl3dtOeXtZbr_ymSNNbpnqNC9Uq6XuyUfrAG66jKqWX_DEISNUHnmEoF2yzN01A_ALB4dkI9L6QFnl-aVTS_-M_C5AGJJfI_VulyFBaraLRbIwPKrYvSiG2GR9gto_t6Lh96bdU0ikARiUKQVE2D2UUceA6RypW01ha5ccW6X6GLmU47VUKZ2Q2LS9q-okCyLrkNktXcrYDf_E4Fb1-0Ab0rI4eBHQMKu6YvoSNe0MlCL745ZS9l5qi1busBxlNVt8PZKrxYXRGD3s0Ur7NBP6GQq789J-3GfRuzJL-ks5NqqUwNLLRUe9hgYCfySSzMQjfezZ9lR6EiFVVidvdQa4/http%3A%2F%2Fdummy.com>

        
 <red-value>23</red-value>

        
 <foo-type>green</foo-type>

        
</root>

      

    

    I think that it depends on if/when candidate is validated.

    Certainly it is not valid in this state.

    

    

      

        

        

        
Does it also return an error if the red-value and
            foo-type leafs were reversed in the XML above ?

      

    

    Yes, same answer as above.

    

    

      

        

        

        
(C) Does the presence of 'when' in a YANG model
            ever create the need for a NETCONF client to specifically
            order nodes within a single edit-config to achieve some
            desired behavior ?

      

    

    No, I don't think that should be required.

    

    

      

        

        

        
Or do 'when' statements purely put the onus on
            the server to build a dependency tree with the scope of a
            single edit-config (to ensure that the input leafs to a
            'when' statement are processed before the when statement
            itself is evaluated, i.e. evaluate the when statements at
            the end) ?

      

    

    I think that the required logic steps (when the change being
    committed) is:

    

    1) Construct a new config tree based purely on the
    <edit-config> change.

    2) Check whether any when statements (anywhere in the config tree)
    are now false, and if so remove the config associated with them.

    3) Keep repeating step (2) until there are no more changes to be
    done.

    4) Check that the final "complete config change" is still a valid
    config tree and then continue processing as if this is what had been
    provided by the client in the first place.

    

    Personally, I really dislike the implicit delete behaviour of when
    statements in steps (2) and (3) because I think that it adds a lot
    of unnecessarily complexity in the processing, and has a very
    surprising interaction with NACM. I would much rather that the
    client was forced to delete everything explicitly. I.e. rather than
    auto deleting some config due to an invalid when expression, instead
    just reject the config change with an appropriate error. I would be
    all for changing this behaviour in a future version of YANG. :-)

    

    Thanks,

    Rob

    

    

    

      

        

        

        
Rgds,

        
Jason

        

        

        
 

        
 

        

        

        

        

      

      

      

      

      
_______________________________________________
netmod mailing list
netmod@ietf.org
https://secure-web.cisco.com/1fuFv0na4qfxbvBYug9IKC-mmyzxu1yP8GNikD9y4MUBFLzTufk-XIyIkQQrHLymAFnh5O5vcA-QoCWAFDfBuEsJQy0DpHJfhfVL3yhtZ6B9hHa0OI17Q2MfqLXBvRC3wylOGP9A2ZzeMn9DMara96FtuGPOLmNufjx3D1jE01LjrKo8uu22WTQMoo0Mn2E9HYQcZIL1UA4WJRTDVY7B3mtjkfWXKRQyGBI0ydzAZKkRO1JVLreMh5cv3ste_WLHzwx7LRVLUxNReQ7Lx4_fe5jRlkjJm8oEjVowunA5cLYRCfIgbGu7DJjhGoh4X1oP4yt7U9imcXzfwjGaHFvrtLRKn7YXWyIwWwkA-bzMFPchPR0MkfiYcZkI9LP3mBmcF/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnetmod


    

    

  


--------------EDFBF04F7A6AD250CE8F95BE--


From nobody Thu May  3 03:53:30 2018
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 E2E4112D947 for ; Thu,  3 May 2018 03:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMxPquTi7Ztd for ; Thu,  3 May 2018 03:53: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 83E9312D877 for ; Thu,  3 May 2018 03:53:26 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 65AE11AE030D; Thu,  3 May 2018 12:53:24 +0200 (CEST)
Date: Thu, 03 May 2018 12:53:23 +0200 (CEST)
Message-Id: <20180503.125323.783664077417511029.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: jason.sterne@nokia.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <903d8476-9e01-2ad7-cfe1-fe02283bb076@cisco.com>
References:  <903d8476-9e01-2ad7-cfe1-fe02283bb076@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] NETCONF server handling of 'when' statements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 May 2018 10:53:29 -0000

Robert Wilton  wrote:
> Hi Jason,
> =

> The Cisco email security filter has somewhat mangled the URLs in your=

> message, but my thoughts below ...
> =

> On 02/05/2018 16:21, Sterne, Jason (Nokia - CA/Ottawa) wrote:
> >
> > Hi all,
> >
> > I've seen some older threads about 'when' handling and they ended u=
p
> > creating a lot of debate about behavior & intentions (and about how=

> > well the text is written in the specs).
> >
> > I'm hoping that the community out there is in agreement on yes vs n=
o
> > for the questions below.
> >
> > Given the following module:
> >
> > module test {
> >
> > =A0=A0 namespace
> > "http://secure-web.cisco.com/17Y2QIXhS6SlnAYxG6R_JjTzP7pmTwW1F-Eg06=
Aa0sRalUV5358LN3CjHP-LR-MfD47g80JiIgIbUuGpUaYFKxvKv8b5HzDwNkX2Sizzw2gbU=
BkOvOFtkxCUSgoQl-AM9bU0UjNWmE4Nnrk64L3Zt9pjxyqprJte6HWPQGzLZVx-xey27lch=
O_GWT4LsmlDt494XoVJOQtcHR5XUjvU-O_mqdXHjgLpZMEG7rsmjru7hXkB6nsDPmlUBD5n=
wJmP6x1MsX1EluBkJtB0MWNSl3-L78RroFr_dUDcynq2yTyfa5uN_QCCB_kzbe8aPu_pZ9s=
1i1JslD0GtYrOXCjTpiizC5CJWdMcl3AgN-s-MZ6gI/http%3A%2F%2Ftest.com";
> >
> > =A0=A0 prefix "test";
> >
> > =A0=A0 container foo {
> >
> > =A0=A0=A0=A0 leaf foo-type {
> >
> > =A0=A0=A0=A0=A0=A0 type enumeration {
> >
> > =A0=A0=A0=A0=A0=A0=A0=A0 enum "green";
> >
> > =A0=A0=A0=A0=A0=A0=A0=A0 enum "red";
> >
> > =A0=A0=A0=A0=A0=A0=A0}
> >
> > =A0=A0=A0=A0 }
> >
> > =A0=A0=A0=A0 leaf green-value {
> >
> > =A0=A0=A0=A0=A0=A0 when "../foo-type =3D 'green'";
> >
> > =A0=A0=A0=A0=A0=A0 type uint32;
> >
> > =A0=A0=A0=A0 }
> >
> > =A0=A0=A0=A0 leaf red-value {
> >
> > =A0=A0=A0=A0=A0=A0 when "../foo-type =3D 'red'";
> >
> > =A0=A0=A0=A0=A0=A0 type uint32;
> >
> > =A0=A0=A0=A0 }
> >
> > =A0=A0 }
> >
> > }
> >
> > (A) Assume the candidate is empty initially. Does the following
> > edit-config to the candidate return "OK" ?=A0 (only showing the con=
tent
> > of the  section):
> >
> >  > xmlns=3Dhttp://secure-web.cisco.com/1n6yL9gbGW5LZ4loJr_sHzGl3dtOeXt=
Zbr_ymSNNbpnqNC9Uq6XuyUfrAG66jKqWX_DEISNUHnmEoF2yzN01A_ALB4dkI9L6QFnl-a=
VTS_-M_C5AGJJfI_VulyFBaraLRbIwPKrYvSiG2GR9gto_t6Lh96bdU0ikARiUKQVE2D2UU=
ceA6RypW01ha5ccW6X6GLmU47VUKZ2Q2LS9q-okCyLrkNktXcrYDf_E4Fb1-0Ab0rI4eBHQ=
MKu6YvoSNe0MlCL745ZS9l5qi1busBxlNVt8PZKrxYXRGD3s0Ur7NBP6GQq789J-3GfRuzJ=
L-ks5NqqUwNLLRUe9hgYCfySSzMQjfezZ9lR6EiFVVidvdQa4/http%3A%2F%2Fdummy.co=
m>
> >
> > =A0 23
> >
> > =A0 red
> >
> > 
> >
> > Does the candidate contain the following after the edit-config ?
> >
> > =A0=A0=A0=A0 foo-type =3D red
> >
> > =A0=A0=A0=A0 red-value =3D 23
> >
> Yes.

Yes.

> > Is the result the same if the red-value and foo-type leafs were
> > reversed in the XML above ?
> >
> Yes, I don't think that ordering matters.=A0 Logically you construct =
a
> updated config tree with all the config changes applied and then chec=
k
> that the new tree is valid.

Yes.

> > (B) Assume the candidate is empty initially. Does the following
> > edit-config to the candidate return an error ?
> >
> >  > xmlns=3Dhttp://secure-web.cisco.com/1n6yL9gbGW5LZ4loJr_sHzGl3dtOeXt=
Zbr_ymSNNbpnqNC9Uq6XuyUfrAG66jKqWX_DEISNUHnmEoF2yzN01A_ALB4dkI9L6QFnl-a=
VTS_-M_C5AGJJfI_VulyFBaraLRbIwPKrYvSiG2GR9gto_t6Lh96bdU0ikARiUKQVE2D2UU=
ceA6RypW01ha5ccW6X6GLmU47VUKZ2Q2LS9q-okCyLrkNktXcrYDf_E4Fb1-0Ab0rI4eBHQ=
MKu6YvoSNe0MlCL745ZS9l5qi1busBxlNVt8PZKrxYXRGD3s0Ur7NBP6GQq789J-3GfRuzJ=
L-ks5NqqUwNLLRUe9hgYCfySSzMQjfezZ9lR6EiFVVidvdQa4/http%3A%2F%2Fdummy.co=
m>
> >
> > =A0 23
> >
> > =A0 green
> >
> > 
> >
> I think that it depends on if/when candidate is validated.
> Certainly it is not valid in this state.

'when' expressions are not evaluated at validate time, but in at
edit-config processing time.  See 8.3.2 in RFC 7950.  Our server gives
the following error in this case:

  
    application
    unknown-element
    error
    
    /rpc/edit-config/config/test:foo/test:red-value
  
    /foo/red-value: the 'when' expressio=
n "../foo-type =3D 'red'" failed
    
      red-value
    
  



> > Does it also return an error if the red-value and foo-type leafs we=
re
> > reversed in the XML above ?
> >
> Yes, same answer as above.

Yes.

> =

> > (C) Does the presence of 'when' in a YANG model ever create the nee=
d
> > for a NETCONF client to specifically order nodes within a single
> > edit-config to achieve some desired behavior ?
> >
> No, I don't think that should be required.

Agreed.


/martin

> > Or do 'when' statements purely put the onus on the server to build =
a
> > dependency tree with the scope of a single edit-config (to ensure t=
hat
> > the input leafs to a 'when' statement are processed before the when=

> > statement itself is evaluated, i.e. evaluate the when statements at=

> > the end) ?
> >
> I think that the required logic steps (when the change being
> committed) is:
> =

> 1) Construct a new config tree based purely on the 
> change.
> 2) Check whether any when statements (anywhere in the config tree) ar=
e
> now false, and if so remove the config associated with them.
> 3) Keep repeating step (2) until there are no more changes to be done=
.=

> 4) Check that the final "complete config change" is still a valid
> config tree and then continue processing as if this is what had been
> provided by the client in the first place.
> =

> Personally, I really dislike the implicit delete behaviour of when
> statements in steps (2) and (3) because I think that it adds a lot of=

> unnecessarily complexity in the processing, and has a very surprising=

> interaction with NACM.=A0 I would much rather that the client was for=
ced
> to delete everything explicitly.=A0 I.e. rather than auto deleting so=
me
> config due to an invalid when expression, instead just reject the
> config change with an appropriate error.=A0 I would be all for changi=
ng
> this behaviour in a future version of YANG. :-)
> =

> Thanks,
> Rob
> =

> =

> > Rgds,
> >
> > Jason
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://secure-web.cisco.com/1fuFv0na4qfxbvBYug9IKC-mmyzxu1yP8GNikD=
9y4MUBFLzTufk-XIyIkQQrHLymAFnh5O5vcA-QoCWAFDfBuEsJQy0DpHJfhfVL3yhtZ6B9h=
Ha0OI17Q2MfqLXBvRC3wylOGP9A2ZzeMn9DMara96FtuGPOLmNufjx3D1jE01LjrKo8uu22=
WTQMoo0Mn2E9HYQcZIL1UA4WJRTDVY7B3mtjkfWXKRQyGBI0ydzAZKkRO1JVLreMh5cv3st=
e_WLHzwx7LRVLUxNReQ7Lx4_fe5jRlkjJm8oEjVowunA5cLYRCfIgbGu7DJjhGoh4X1oP4y=
t7U9imcXzfwjGaHFvrtLRKn7YXWyIwWwkA-bzMFPchPR0MkfiYcZkI9LP3mBmcF/https%3=
A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnetmod
> =


From nobody Thu May  3 04:27:52 2018
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 C899112D875 for ; Thu,  3 May 2018 04:27:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhJUmTD34drJ for ; Thu,  3 May 2018 04:27:49 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CABA412D80F for ; Thu,  3 May 2018 04:27:48 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id C31391AE030D; Thu,  3 May 2018 13:27:47 +0200 (CEST)
Date: Thu, 03 May 2018 13:27:47 +0200 (CEST)
Message-Id: <20180503.132747.1307909722991424896.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: jason.sterne@nokia.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <903d8476-9e01-2ad7-cfe1-fe02283bb076@cisco.com>
References:  <903d8476-9e01-2ad7-cfe1-fe02283bb076@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] NETCONF server handling of 'when' statements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 May 2018 11:27:51 -0000

Robert Wilton  wrote:

[...]

> Personally, I really dislike the implicit delete behaviour of when
> statements in steps (2) and (3) because I think that it adds a lot of=

> unnecessarily complexity in the processing, and has a very surprising=

> interaction with NACM.=A0 I would much rather that the client was for=
ced
> to delete everything explicitly.=A0 I.e. rather than auto deleting so=
me
> config due to an invalid when expression, instead just reject the
> config change with an appropriate error.=A0 I would be all for changi=
ng
> this behaviour in a future version of YANG. :-)

This has been discussed quite a lot in the past...  Think of "when" as
a generalized version of "choice".  If you don't want the
auto-deletion aspects of "when", then use "must".  I agree that it is
a sharp tool; so use it with care.  But as with many sharp tools, it
is quite handy when used properly.


/martin

 =



> =

> Thanks,
> Rob
> =

> =

> > Rgds,
> >
> > Jason
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://secure-web.cisco.com/1fuFv0na4qfxbvBYug9IKC-mmyzxu1yP8GNikD=
9y4MUBFLzTufk-XIyIkQQrHLymAFnh5O5vcA-QoCWAFDfBuEsJQy0DpHJfhfVL3yhtZ6B9h=
Ha0OI17Q2MfqLXBvRC3wylOGP9A2ZzeMn9DMara96FtuGPOLmNufjx3D1jE01LjrKo8uu22=
WTQMoo0Mn2E9HYQcZIL1UA4WJRTDVY7B3mtjkfWXKRQyGBI0ydzAZKkRO1JVLreMh5cv3st=
e_WLHzwx7LRVLUxNReQ7Lx4_fe5jRlkjJm8oEjVowunA5cLYRCfIgbGu7DJjhGoh4X1oP4y=
t7U9imcXzfwjGaHFvrtLRKn7YXWyIwWwkA-bzMFPchPR0MkfiYcZkI9LP3mBmcF/https%3=
A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnetmod
> =


From nobody Thu May  3 05:57:50 2018
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 E7E59126C83 for ; Thu,  3 May 2018 05:57:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SA3vlGV5n1Ho for ; Thu,  3 May 2018 05:57:46 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 421A61204DA for ; Thu,  3 May 2018 05:57:46 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 606EF182015B; Thu,  3 May 2018 15:02:32 +0200 (CEST)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 6FE6E1820157; Thu,  3 May 2018 15:02:30 +0200 (CEST)
From: Ladislav Lhotka 
To: Andy Bierman , NetMod WG 
In-Reply-To: 
References: 
Mail-Followup-To: Andy Bierman , NetMod WG 
Date: Thu, 03 May 2018 14:57:51 +0200
Message-ID: <87k1skvquo.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Abusing YANG extensions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 May 2018 12:57:49 -0000

Andy Bierman  writes:

> Hi,
>
> The discussion about yang-data is stuck because the NETMOD WG does not
> understand or does not agree on what it means to abuse a YANG extension
> and use it improperly.

In my view, we should strictly separate the concerns of YANG and
extensions:

1. YANG should deal only with (abstract) schemas and rules for
   determining whether a given instance data tree is valid or not. All
   other considerations should be removed (moved elsewhere).

2. Extensions must not tinker with #1. In other words, if extensions are
   removed, the resulting schemas must be the same and validity rules as
   well.

>
> If a tool implementing a standard cannot do so without implementing
> certain extensions, then those extensions are not optional,
> but rather they are mandatory, and therefore violating YANG 1.1.

Yes.

>
> The NACM extensions are OK because they can be safely ignored
> unless the implementation supports NACM, These extensions
> are only implemented by the server, so the client is not impacted.

Yes, this satisfies #2 above.

>
> The  element is a use-case where YANG fails completely.
> According to YANG, the  element should only contain child nodes
> if they are defined directly or defined with the augment-stmt.
> YANG says absolutely nothing about nested data nodes that contain
> top-level data nodes.
>
> The "mount-point" extension in YANG Schema Mount also violates
> YANG 1.1 in this way. A plain client that does not support schema-mount
> will find container and list elements that contain undefined child nodes.
> If the server chooses to support schema-mount, the client
> is forced to support it, and this is a violation of YANG 1.1.

This is a bit more complicated, the extension itself doesn't cause any
data to appear under the mount point - it is some state data that the
client may understand or not. That's why I think YANG library and schema
mount data have to be treated specially (as metadata describing
datastore organization).

>
> However, the yang-data extension cannot possibly interfere with standard
> YANG 1.1 statements because it is used to specify data structures
> that are outside the plain data nodes, instead of over-riding the
> definitions of the plain data nodes.

YANG inside yang-data has somewhat different rules (described in the
description) and still the text of RFC 7950 has to be interpreted
liberally, e.g. because there is in general no server and hence no YANG
library.

YANG (according to #1 above) should be able to cover such uses out of
the box.

Lada

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

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


From nobody Thu May  3 10:30:09 2018
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 5074912EA8D for ; Thu,  3 May 2018 10:30:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVoqdmtU1ofv for ; Thu,  3 May 2018 10:30:06 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90D5612EA8C for ; Thu,  3 May 2018 10:30:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3764; q=dns/txt; s=iport; t=1525368606; x=1526578206; h=from:to:subject:date:message-id:mime-version; bh=wvcQntWaDB9nq/Q7KJ9JymYVHQ1j1YGwygEdaudyMwQ=; b=fzc6UIEWI8SdMJePzpPRlCPiKzSVzs5bPjEcKpT6H7+2ioAPCzqXisiK g6eKvm5lIEr3u92lBRkwdQldUCqGzGygOavUznubyULr9FXPT+tDYTlzp ejZ7AZEkgfzKtefgMZ3Jq8nIAH0jw6FNQz5LkH7GQ1j5cea+itF4fdTkt A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqAQC9Ruta/4YNJK1TCRoBAQEBAQI?= =?us-ascii?q?BAQEBCAEBAQGCTXZhF2Myg2OIAoxvgT2BSo4qhHCBeAuFCIIWITQYAQIBAQE?= =?us-ascii?q?BAQECbCiFUmgBDD4CBDAnBIQ+ZKlBghyEWINxgkKIHYITgTKHMYMqMIIkApg?= =?us-ascii?q?aCAKOSoxZkBsCERMBgSQBHDiBUnAVZQGCGZBNkDSBGAEB?=
X-IronPort-AV: E=Sophos;i="5.49,359,1520899200";  d="scan'208,217";a="387086947"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2018 17:30:03 +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 w43HU2lg002541 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 3 May 2018 17:30:02 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.1320.4; Thu, 3 May 2018 13:30: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.1320.000; Thu, 3 May 2018 13:30:02 -0400
From: "Acee Lindem (acee)" 
To: NETMOD WG 
Thread-Topic: YANG identities and identityref's 
Thread-Index: AQHT4wRd8VIEfZkF5U2p5jDj2N/hLA==
Date: Thu, 3 May 2018 17:30:01 +0000
Message-ID: <739F53FB-DD16-4AE3-B1D5-C06DC6972FAB@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: multipart/alternative; boundary="_000_739F53FBDD164AE3B1D5C06DC6972FABciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: [netmod] YANG identities and identityref's
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 May 2018 17:30:08 -0000

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

TGV04oCZcyBzYXkgb25lIGRlZmluZSBhIGJhc2UgaWRlbnRpdHkgd2l0aCBhIGhpZXJhcmNoeSBv
ZiBpZGVudGlmeXJlZuKAmXMgdXNpbmcgaXQuIFRoaXMgd2lsbCBhbGxvdyBmb3IgYXVnbWVudGF0
aW9uIGluIGZ1dHVyZSBtb2RlbHMuIFNob3VsZCBvbmUgYWxzbyBkZWZpbmUgYW4gaWRlbnRpdHly
ZWYgZm9yIHRoZSBjbGFzcyBvZiB1bmtub3duIGlkZW50aXRpZXM/IE9yLCBzaG91bGQgb25lIHNp
bXBseSByZXR1cm4gdGhlIGxvd2VzdCBwYXJlbnQgaW4gdGhlIGhpZXJhcmNoeSBtYXRjaGluZyB0
aGUgdmFsdWU/IE1hbnkgdGltZXMsIHRoaXMgd291bGQgYmUgdGhlIGJhc2UgaWRlbnRpdHkuDQoN
ClRoYW5rcywNCkFjZWUNCg==

--_000_739F53FBDD164AE3B1D5C06DC6972FABciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <7BBC9EFBDFB9334D9BF39F9F9015FADC@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBO
ZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N
Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu
TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt
c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5r
LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1
NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3
MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh
bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5
bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9
DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu
IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv
bjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2
M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQiPkxldOKAmXMgc2F5
IG9uZSBkZWZpbmUgYSBiYXNlIGlkZW50aXR5IHdpdGggYSBoaWVyYXJjaHkgb2YgaWRlbnRpZnly
ZWbigJlzIHVzaW5nIGl0LiBUaGlzIHdpbGwgYWxsb3cgZm9yIGF1Z21lbnRhdGlvbiBpbiBmdXR1
cmUgbW9kZWxzLiBTaG91bGQgb25lIGFsc28gZGVmaW5lIGFuIGlkZW50aXR5cmVmIGZvciB0aGUg
Y2xhc3Mgb2YgdW5rbm93biBpZGVudGl0aWVzPw0KIE9yLCBzaG91bGQgb25lIHNpbXBseSByZXR1
cm4gdGhlIGxvd2VzdCBwYXJlbnQgaW4gdGhlIGhpZXJhcmNoeSBtYXRjaGluZyB0aGUgdmFsdWU/
IE1hbnkgdGltZXMsIHRoaXMgd291bGQgYmUgdGhlIGJhc2UgaWRlbnRpdHkuDQo8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjE2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE2LjBw
dCI+QWNlZSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N
Cg==

--_000_739F53FBDD164AE3B1D5C06DC6972FABciscocom_--


From nobody Thu May  3 10:49:43 2018
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 5628E124217 for ; Thu,  3 May 2018 10:49:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4M45rJBGzZU2 for ; Thu,  3 May 2018 10:49:39 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9982124234 for ; Thu,  3 May 2018 10:49:39 -0700 (PDT)
Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id 0660760773 for ; Thu,  3 May 2018 19:49:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1525369778; bh=NipPiK/k6Z79TTJ/b0u4vCecdINtdAfN68kCLwRwCxA=; h=From:To:Date; b=UgWDOuMUHDl2KMV24edDHNaCcNzXxXbldmpYbOtpGxZE41j16V1Gw9u/C7rDMW5qV oPzcPRfni8IUjKjv7InD4OgWjuBHZ/fUZEhB8S0/V6seEiR77uVzSdirhF3IrIE7No UMKyVK1REN1zoARNfR2bFImqjP+zvnPxbzgcI7pQ=
Message-ID: <09f8964cb246be35d82cba2819891cd4210b3bad.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Thu, 03 May 2018 19:49:46 +0200
In-Reply-To: <739F53FB-DD16-4AE3-B1D5-C06DC6972FAB@cisco.com>
References: <739F53FB-DD16-4AE3-B1D5-C06DC6972FAB@cisco.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.1 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] YANG identities and identityref's
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 May 2018 17:49:42 -0000

Hi Acee,

I am not sure what you mean by unknown identities. In general, the identity used
as the base of an identityref (or in Xpath functions derived-from/derived-from-
or-self) should be the most general identity that can match at the given place.

Do you have any example illustrating your case?

Lada


On Thu, 2018-05-03 at 17:30 +0000, Acee Lindem (acee) wrote:
> Let’s say one define a base identity with a hierarchy of identifyref’s using
> it. This will allow for augmentation in future models. Should one also define
> an identityref for the class of unknown identities? Or, should one simply
> return the lowest parent in the hierarchy matching the value? Many times, this
> would be the base identity.
>  
> Thanks,
> Acee
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Thu May  3 11:00:11 2018
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 B4CE612EA9D for ; Thu,  3 May 2018 11:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqmxJAcYFAZU for ; Thu,  3 May 2018 11:00:06 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 970F712E856 for ; Thu,  3 May 2018 11:00:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2358; q=dns/txt; s=iport; t=1525370406; x=1526580006; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=pdNjy+Iw0g7GJoPjjsEFfDv3sgIKpies1DxUkDlZ3gs=; b=kSIUm1YexFN8jWl2gFqKTPswq2KJ3VuutXjlj/a6p+w5zvf3saRbLPj7 HxfKfDI9MvGoOo76c8J+teED1z7iR9DJBWQRuHvM76Eajg9S5OagFuciq Orw54NkwgpKqq25UTJViReOw/F/ipwXDt5SGQS+Dm+KAByDJf09D89LPH Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQBaTeta/40NJK1SAQkZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBg0NheigKg2OIAoxwgT0aIYEPkxuBeAsYC4QDRgIaghY?= =?us-ascii?q?hNBgBAgEBAQEBAQJsHAyFKQEBAQMBASEROhsCAQgYAgImAgICJQsVEAIEARK?= =?us-ascii?q?FDw+pI4IchFiDcII9BYEJhxyCE4EyDIJcgxEBAYE1ASqDADCCJAKYGggCjkq?= =?us-ascii?q?MWZAbAhETAYEkARw4gVJwFTsqAYIYixCFPm+PYYEYAQE?=
X-IronPort-AV: E=Sophos;i="5.49,359,1520899200"; d="scan'208";a="109002529"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2018 18:00:04 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w43Hxx6j020579 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 May 2018 18:00:03 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 3 May 2018 14:00:01 -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.1320.000; Thu, 3 May 2018 14:00:01 -0400
From: "Acee Lindem (acee)" 
To: Ladislav Lhotka , "netmod@ietf.org" 
Thread-Topic: [netmod] YANG identities and identityref's
Thread-Index: AQHT4wcmcoN4Fa9nLE+0HGK7LDbJoKQeSw0A
Date: Thu, 3 May 2018 18:00:01 +0000
Message-ID: <3B5F31C4-1504-4F0D-875D-A9B559B01A82@cisco.com>
References: <739F53FB-DD16-4AE3-B1D5-C06DC6972FAB@cisco.com> <09f8964cb246be35d82cba2819891cd4210b3bad.camel@nic.cz>
In-Reply-To: <09f8964cb246be35d82cba2819891cd4210b3bad.camel@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: <7F4A7DF78E9E9E41BB6237B83734B0F1@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] YANG identities and identityref's
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 May 2018 18:00:09 -0000

SGkgTGFkYSwgDQoNClNvIHlvdSBoYXZlIGEgYmFzZSBpZGVudGlmeSBvZiBmb28tdHlwZSBhbmQg
c3Vib3JkaW5hdGVzIG9mIGZvby10eXBlLTEsIGZvby10eXBlLTIsIC4uLiBmb28tdHlwZS05LiBZ
b3UgaGF2ZSBhIGRhdGEgbGVhZiB0aGF0IHR5cGUgaWRlbnRpdHlyZWYgZm9vLXR5cGUgYnV0IHRo
ZSBhY3R1YWwgaW5zdGFudGlhdGlvbiBpcyBub3Qgb25lIG9mIHRoZSBrbm93biBmb28tdHlwZXMu
IFNob3VsZCBhIGZvby10eXBlLXVua25vd24gYmUgZGVmaW5lZCB0byByZXR1cm4gZm9yIHRoaXMg
Y2FzZSBvciBzaG91bGQgb25lIGp1c3QgcmV0dXJuIGZvby10eXBlPyAgDQoNClRoYW5rcywNCkFj
ZWUNCg0K77u/T24gNS8zLzE4LCAxOjQ5IFBNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBMYWRpc2xh
diBMaG90a2EiIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbGhvdGthQG5p
Yy5jej4gd3JvdGU6DQoNCiAgICBIaSBBY2VlLA0KICAgIA0KICAgIEkgYW0gbm90IHN1cmUgd2hh
dCB5b3UgbWVhbiBieSB1bmtub3duIGlkZW50aXRpZXMuIEluIGdlbmVyYWwsIHRoZSBpZGVudGl0
eSB1c2VkDQogICAgYXMgdGhlIGJhc2Ugb2YgYW4gaWRlbnRpdHlyZWYgKG9yIGluIFhwYXRoIGZ1
bmN0aW9ucyBkZXJpdmVkLWZyb20vZGVyaXZlZC1mcm9tLQ0KICAgIG9yLXNlbGYpIHNob3VsZCBi
ZSB0aGUgbW9zdCBnZW5lcmFsIGlkZW50aXR5IHRoYXQgY2FuIG1hdGNoIGF0IHRoZSBnaXZlbiBw
bGFjZS4NCiAgICANCiAgICBEbyB5b3UgaGF2ZSBhbnkgZXhhbXBsZSBpbGx1c3RyYXRpbmcgeW91
ciBjYXNlPw0KICAgIA0KICAgIExhZGENCiAgICANCiAgICANCiAgICBPbiBUaHUsIDIwMTgtMDUt
MDMgYXQgMTc6MzAgKzAwMDAsIEFjZWUgTGluZGVtIChhY2VlKSB3cm90ZToNCiAgICA+IExldOKA
mXMgc2F5IG9uZSBkZWZpbmUgYSBiYXNlIGlkZW50aXR5IHdpdGggYSBoaWVyYXJjaHkgb2YgaWRl
bnRpZnlyZWbigJlzIHVzaW5nDQogICAgPiBpdC4gVGhpcyB3aWxsIGFsbG93IGZvciBhdWdtZW50
YXRpb24gaW4gZnV0dXJlIG1vZGVscy4gU2hvdWxkIG9uZSBhbHNvIGRlZmluZQ0KICAgID4gYW4g
aWRlbnRpdHlyZWYgZm9yIHRoZSBjbGFzcyBvZiB1bmtub3duIGlkZW50aXRpZXM/IE9yLCBzaG91
bGQgb25lIHNpbXBseQ0KICAgID4gcmV0dXJuIHRoZSBsb3dlc3QgcGFyZW50IGluIHRoZSBoaWVy
YXJjaHkgbWF0Y2hpbmcgdGhlIHZhbHVlPyBNYW55IHRpbWVzLCB0aGlzDQogICAgPiB3b3VsZCBi
ZSB0aGUgYmFzZSBpZGVudGl0eS4NCiAgICA+ICANCiAgICA+IFRoYW5rcywNCiAgICA+IEFjZWUN
CiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQog
ICAgPiBuZXRtb2QgbWFpbGluZyBsaXN0DQogICAgPiBuZXRtb2RAaWV0Zi5vcmcNCiAgICA+IGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQogICAgLS0gDQogICAg
TGFkaXNsYXYgTGhvdGthDQogICAgSGVhZCwgQ1ouTklDIExhYnMNCiAgICBQR1AgS2V5IElEOiAw
eEI4RjkyQjA4QTlGNzZDNjcNCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KICAgIG5ldG1vZCBtYWlsaW5nIGxpc3QNCiAgICBuZXRtb2RA
aWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v
ZA0KICAgIA0KDQo=


From nobody Thu May  3 11:40:53 2018
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 D902512DA06 for ; Thu,  3 May 2018 11:40:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZBnoN4HlKvs for ; Thu,  3 May 2018 11:40:49 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ED2212DA28 for ; Thu,  3 May 2018 11:40:48 -0700 (PDT)
Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id CF2DA600FB; Thu,  3 May 2018 20:40:46 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1525372846; bh=PpCytVAPx10J45MHFEeUkTKZsOlN+NiyMuXejzJ935w=; h=From:To:Date; b=YFxkCCPPlIgGQi6p1dhyJR4bffbYKaZ03UxssX6x3lCMlnaMG7wXp2t3r35oGXMW6 +S7wmYQ1CecqAoQcd/uDxvLUaOEOhqVrTChEsbAw2rxNx+xUm2j7EyQlJKx89a5u/P 5VfE7Qd3lgw+gv746j8BD92SdJ/ij4Og5ZsqOrdM=
Message-ID: <92458ec3b02ba207239df397d4c8fe9cdbdfd244.camel@nic.cz>
From: Ladislav Lhotka 
To: "Acee Lindem (acee)" , "netmod@ietf.org" 
Date: Thu, 03 May 2018 20:40:55 +0200
In-Reply-To: <3B5F31C4-1504-4F0D-875D-A9B559B01A82@cisco.com>
References: <739F53FB-DD16-4AE3-B1D5-C06DC6972FAB@cisco.com> <09f8964cb246be35d82cba2819891cd4210b3bad.camel@nic.cz> <3B5F31C4-1504-4F0D-875D-A9B559B01A82@cisco.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.1 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] YANG identities and identityref's
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 May 2018 18:40:52 -0000

On Thu, 2018-05-03 at 18:00 +0000, Acee Lindem (acee) wrote:
> Hi Lada, 
> 
> So you have a base identify of foo-type and subordinates of foo-type-1, foo-
> type-2, ... foo-type-9. You have a data leaf that type identityref foo-type
> but the actual instantiation is not one of the known foo-types. Should a foo-
> type-unknown be defined to return for this case or should one just return foo-
> type? 

Hmm, the actual instantiation looks like invalid data. If the leaf is an
identityref with "foo-type" as its base, then permitted values are exactly those
"foo-type-[1-9]".

If the server supports a particular type, then I would expect it to implement a
module where the identity corresponding to that type is defined.

Lada 

>  
> 
> Thanks,
> Acee
> 
> On 5/3/18, 1:49 PM, "netmod on behalf of Ladislav Lhotka"  f.org on behalf of lhotka@nic.cz> wrote:
> 
>     Hi Acee,
>     
>     I am not sure what you mean by unknown identities. In general, the
> identity used
>     as the base of an identityref (or in Xpath functions derived-from/derived-
> from-
>     or-self) should be the most general identity that can match at the given
> place.
>     
>     Do you have any example illustrating your case?
>     
>     Lada
>     
>     
>     On Thu, 2018-05-03 at 17:30 +0000, Acee Lindem (acee) wrote:
>     > Let’s say one define a base identity with a hierarchy of identifyref’s
> using
>     > it. This will allow for augmentation in future models. Should one also
> define
>     > an identityref for the class of unknown identities? Or, should one
> simply
>     > return the lowest parent in the hierarchy matching the value? Many
> times, this
>     > would be the base identity.
>     >  
>     > Thanks,
>     > Acee
>     > _______________________________________________
>     > netmod mailing list
>     > netmod@ietf.org
>     > https://www.ietf.org/mailman/listinfo/netmod
>     -- 
>     Ladislav Lhotka
>     Head, CZ.NIC Labs
>     PGP Key ID: 0xB8F92B08A9F76C67
>     
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org
>     https://www.ietf.org/mailman/listinfo/netmod
>     
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Thu May  3 11:52:45 2018
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 4C6C312DA06 for ; Thu,  3 May 2018 11:52:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTFPj_kNWndu for ; Thu,  3 May 2018 11:52:40 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B7D12DA00 for ; Thu,  3 May 2018 11:52:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4036; q=dns/txt; s=iport; t=1525373560; x=1526583160; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/wVWWl4M9fsHbt/PnGTkSAt507ILKN+WrHeZG/XBYNM=; b=gTURdVsY4LjT7Uf9VwkICjGhqGlnMmiCFLioBby3ZYhJOTaC7O9yCeu6 mjecLI2JF6XcSgMUczVfW8m0oJeNOAvXEWfc53qhf9f9C1goAY3qh60fR FII1aOhTzsA6Az7pPJE6NIZOCWHz0lh6m50djAlTeDzDBA2cOsFKoh+KH 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DMAgBlWeta/4QNJK1SAQkZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBg0NheigKg2OUcYE9O4EPkxuBeAsYC4QDRgIaghYhNhY?= =?us-ascii?q?BAgEBAQEBAQJsHAyFKAEBAQECAQEBIRE6GwIBCBgCAiYCAgIlCxUQAgQBEoU?= =?us-ascii?q?HCA+pOYIchFiDb4JCgQmHHIITgTKCaIMRAQGBNQEUgxYwgiQCmBoIAo5KjFm?= =?us-ascii?q?KXoU9AhETAYEkASMFLIFScBU7KgGCGAmLB4U+b49hgRgBAQ?=
X-IronPort-AV: E=Sophos;i="5.49,359,1520899200"; d="scan'208";a="389989044"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2018 18:52:39 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w43IqdCJ009416 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 May 2018 18:52:39 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.1320.4; Thu, 3 May 2018 14:52:38 -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.1320.000; Thu, 3 May 2018 14:52:38 -0400
From: "Acee Lindem (acee)" 
To: Ladislav Lhotka , "netmod@ietf.org" 
Thread-Topic: [netmod] YANG identities and identityref's
Thread-Index: AQHT4wcmcoN4Fa9nLE+0HGK7LDbJoKQeSw0AgABOfID//8A2AA==
Date: Thu, 3 May 2018 18:52:38 +0000
Message-ID: <04CFDAC7-F364-49F0-97D0-64A88986FE26@cisco.com>
References: <739F53FB-DD16-4AE3-B1D5-C06DC6972FAB@cisco.com> <09f8964cb246be35d82cba2819891cd4210b3bad.camel@nic.cz> <3B5F31C4-1504-4F0D-875D-A9B559B01A82@cisco.com> <92458ec3b02ba207239df397d4c8fe9cdbdfd244.camel@nic.cz>
In-Reply-To: <92458ec3b02ba207239df397d4c8fe9cdbdfd244.camel@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: <547A84FAA8064640A3D648CA231D140E@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] YANG identities and identityref's
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 May 2018 18:52:43 -0000

DQoNCu+7v09uIDUvMy8xOCwgMjo0MCBQTSwgIkxhZGlzbGF2IExob3RrYSIgPGxob3RrYUBuaWMu
Y3o+IHdyb3RlOg0KDQogICAgT24gVGh1LCAyMDE4LTA1LTAzIGF0IDE4OjAwICswMDAwLCBBY2Vl
IExpbmRlbSAoYWNlZSkgd3JvdGU6DQogICAgPiBIaSBMYWRhLCANCiAgICA+IA0KICAgID4gU28g
eW91IGhhdmUgYSBiYXNlIGlkZW50aWZ5IG9mIGZvby10eXBlIGFuZCBzdWJvcmRpbmF0ZXMgb2Yg
Zm9vLXR5cGUtMSwgZm9vLQ0KICAgID4gdHlwZS0yLCAuLi4gZm9vLXR5cGUtOS4gWW91IGhhdmUg
YSBkYXRhIGxlYWYgdGhhdCB0eXBlIGlkZW50aXR5cmVmIGZvby10eXBlDQogICAgPiBidXQgdGhl
IGFjdHVhbCBpbnN0YW50aWF0aW9uIGlzIG5vdCBvbmUgb2YgdGhlIGtub3duIGZvby10eXBlcy4g
U2hvdWxkIGEgZm9vLQ0KICAgID4gdHlwZS11bmtub3duIGJlIGRlZmluZWQgdG8gcmV0dXJuIGZv
ciB0aGlzIGNhc2Ugb3Igc2hvdWxkIG9uZSBqdXN0IHJldHVybiBmb28tDQogICAgPiB0eXBlPyAN
CiAgICANCiAgICBIbW0sIHRoZSBhY3R1YWwgaW5zdGFudGlhdGlvbiBsb29rcyBsaWtlIGludmFs
aWQgZGF0YS4gSWYgdGhlIGxlYWYgaXMgYW4NCiAgICBpZGVudGl0eXJlZiB3aXRoICJmb28tdHlw
ZSIgYXMgaXRzIGJhc2UsIHRoZW4gcGVybWl0dGVkIHZhbHVlcyBhcmUgZXhhY3RseSB0aG9zZQ0K
ICAgICJmb28tdHlwZS1bMS05XSIuDQoNClRoZSB3aG9sZSByZWFzb24gdG8gdXNlIGlkZW50aXRp
ZXMgcmF0aGVyIHRoYW4gZW51bXMgaXMgdG8gYWxsb3cgZm9yIGluY3JlbWVudGFsIGV4dGVuc2lv
bi4gV2l0aCByb3V0aW5nIHByb3RvY29scywgaXQgaXMgcG9zc2libGUgaWYgbm90IGxpa2VseSB0
byBoYXZlIGFuIGluc3RhbnRpYXRpb24gb2YgYSBkYXRhIGxlYWYgdGhhdCBpcyB1bmtub3duLiBT
bywgd2UgYWJzb2x1dGVseSBuZWVkIHRvIGhhbmRsZSB0aGlzIGNhc2UuIA0KDQpBY2VlIA0KICAg
IA0KICAgIElmIHRoZSBzZXJ2ZXIgc3VwcG9ydHMgYSBwYXJ0aWN1bGFyIHR5cGUsIHRoZW4gSSB3
b3VsZCBleHBlY3QgaXQgdG8gaW1wbGVtZW50IGENCiAgICBtb2R1bGUgd2hlcmUgdGhlIGlkZW50
aXR5IGNvcnJlc3BvbmRpbmcgdG8gdGhhdCB0eXBlIGlzIGRlZmluZWQuDQogICAgDQogICAgTGFk
YSANCiAgICANCiAgICA+ICANCiAgICA+IA0KICAgID4gVGhhbmtzLA0KICAgID4gQWNlZQ0KICAg
ID4gDQogICAgPiBPbiA1LzMvMTgsIDE6NDkgUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIExhZGlz
bGF2IExob3RrYSIgPG5ldG1vZC1ib3VuY2VzQGlldA0KICAgID4gZi5vcmcgb24gYmVoYWxmIG9m
IGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KICAgID4gDQogICAgPiAgICAgSGkgQWNlZSwNCiAgICA+
ICAgICANCiAgICA+ICAgICBJIGFtIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkgdW5rbm93biBp
ZGVudGl0aWVzLiBJbiBnZW5lcmFsLCB0aGUNCiAgICA+IGlkZW50aXR5IHVzZWQNCiAgICA+ICAg
ICBhcyB0aGUgYmFzZSBvZiBhbiBpZGVudGl0eXJlZiAob3IgaW4gWHBhdGggZnVuY3Rpb25zIGRl
cml2ZWQtZnJvbS9kZXJpdmVkLQ0KICAgID4gZnJvbS0NCiAgICA+ICAgICBvci1zZWxmKSBzaG91
bGQgYmUgdGhlIG1vc3QgZ2VuZXJhbCBpZGVudGl0eSB0aGF0IGNhbiBtYXRjaCBhdCB0aGUgZ2l2
ZW4NCiAgICA+IHBsYWNlLg0KICAgID4gICAgIA0KICAgID4gICAgIERvIHlvdSBoYXZlIGFueSBl
eGFtcGxlIGlsbHVzdHJhdGluZyB5b3VyIGNhc2U/DQogICAgPiAgICAgDQogICAgPiAgICAgTGFk
YQ0KICAgID4gICAgIA0KICAgID4gICAgIA0KICAgID4gICAgIE9uIFRodSwgMjAxOC0wNS0wMyBh
dCAxNzozMCArMDAwMCwgQWNlZSBMaW5kZW0gKGFjZWUpIHdyb3RlOg0KICAgID4gICAgID4gTGV0
4oCZcyBzYXkgb25lIGRlZmluZSBhIGJhc2UgaWRlbnRpdHkgd2l0aCBhIGhpZXJhcmNoeSBvZiBp
ZGVudGlmeXJlZuKAmXMNCiAgICA+IHVzaW5nDQogICAgPiAgICAgPiBpdC4gVGhpcyB3aWxsIGFs
bG93IGZvciBhdWdtZW50YXRpb24gaW4gZnV0dXJlIG1vZGVscy4gU2hvdWxkIG9uZSBhbHNvDQog
ICAgPiBkZWZpbmUNCiAgICA+ICAgICA+IGFuIGlkZW50aXR5cmVmIGZvciB0aGUgY2xhc3Mgb2Yg
dW5rbm93biBpZGVudGl0aWVzPyBPciwgc2hvdWxkIG9uZQ0KICAgID4gc2ltcGx5DQogICAgPiAg
ICAgPiByZXR1cm4gdGhlIGxvd2VzdCBwYXJlbnQgaW4gdGhlIGhpZXJhcmNoeSBtYXRjaGluZyB0
aGUgdmFsdWU/IE1hbnkNCiAgICA+IHRpbWVzLCB0aGlzDQogICAgPiAgICAgPiB3b3VsZCBiZSB0
aGUgYmFzZSBpZGVudGl0eS4NCiAgICA+ICAgICA+ICANCiAgICA+ICAgICA+IFRoYW5rcywNCiAg
ICA+ICAgICA+IEFjZWUNCiAgICA+ICAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQogICAgPiAgICAgPiBuZXRtb2QgbWFpbGluZyBsaXN0DQogICAg
PiAgICAgPiBuZXRtb2RAaWV0Zi5vcmcNCiAgICA+ICAgICA+IGh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQogICAgPiAgICAgLS0gDQogICAgPiAgICAgTGFkaXNs
YXYgTGhvdGthDQogICAgPiAgICAgSGVhZCwgQ1ouTklDIExhYnMNCiAgICA+ICAgICBQR1AgS2V5
IElEOiAweEI4RjkyQjA4QTlGNzZDNjcNCiAgICA+ICAgICANCiAgICA+ICAgICBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gICAgIG5ldG1vZCBt
YWlsaW5nIGxpc3QNCiAgICA+ICAgICBuZXRtb2RAaWV0Zi5vcmcNCiAgICA+ICAgICBodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KICAgID4gICAgIA0KICAgID4g
DQogICAgLS0gDQogICAgTGFkaXNsYXYgTGhvdGthDQogICAgSGVhZCwgQ1ouTklDIExhYnMNCiAg
ICBQR1AgS2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjcNCiAgICANCg0K


From nobody Thu May  3 13:23:13 2018
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 5EE9A12EA90 for ; Thu,  3 May 2018 13:23: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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAUWAUMS1Twj for ; Thu,  3 May 2018 13:23: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 22A7F12DA11 for ; Thu,  3 May 2018 13:23:10 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id C85431AE030D; Thu,  3 May 2018 22:23:07 +0200 (CEST)
Date: Thu, 03 May 2018 22:23:07 +0200 (CEST)
Message-Id: <20180503.222307.1318677205860676080.mbj@tail-f.com>
To: acee@cisco.com
Cc: lhotka@nic.cz, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <04CFDAC7-F364-49F0-97D0-64A88986FE26@cisco.com>
References: <3B5F31C4-1504-4F0D-875D-A9B559B01A82@cisco.com> <92458ec3b02ba207239df397d4c8fe9cdbdfd244.camel@nic.cz> <04CFDAC7-F364-49F0-97D0-64A88986FE26@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] YANG identities and identityref's
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 May 2018 20:23:12 -0000

IkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4gDQo+IA0KPiDv
u79PbiA1LzMvMTgsIDI6NDAgUE0sICJMYWRpc2xhdiBMaG90a2EiIDxsaG90a2FAbmljLmN6PiB3
cm90ZToNCj4gDQo+ICAgICBPbiBUaHUsIDIwMTgtMDUtMDMgYXQgMTg6MDAgKzAwMDAsIEFjZWUg
TGluZGVtIChhY2VlKSB3cm90ZToNCj4gICAgID4gSGkgTGFkYSwgDQo+ICAgICA+IA0KPiAgICAg
PiBTbyB5b3UgaGF2ZSBhIGJhc2UgaWRlbnRpZnkgb2YgZm9vLXR5cGUgYW5kIHN1Ym9yZGluYXRl
cyBvZg0KPiAgICAgPiBmb28tdHlwZS0xLCBmb28tDQo+ICAgICA+IHR5cGUtMiwgLi4uIGZvby10
eXBlLTkuIFlvdSBoYXZlIGEgZGF0YSBsZWFmIHRoYXQgdHlwZSBpZGVudGl0eXJlZg0KPiAgICAg
PiBmb28tdHlwZQ0KPiAgICAgPiBidXQgdGhlIGFjdHVhbCBpbnN0YW50aWF0aW9uIGlzIG5vdCBv
bmUgb2YgdGhlIGtub3duIGZvby10eXBlcy4gU2hvdWxkDQo+ICAgICA+IGEgZm9vLQ0KPiAgICAg
PiB0eXBlLXVua25vd24gYmUgZGVmaW5lZCB0byByZXR1cm4gZm9yIHRoaXMgY2FzZSBvciBzaG91
bGQgb25lIGp1c3QNCj4gICAgID4gcmV0dXJuIGZvby0NCj4gICAgID4gdHlwZT8gDQo+ICAgICAN
Cj4gICAgIEhtbSwgdGhlIGFjdHVhbCBpbnN0YW50aWF0aW9uIGxvb2tzIGxpa2UgaW52YWxpZCBk
YXRhLiBJZiB0aGUgbGVhZiBpcw0KPiAgICAgYW4NCj4gICAgIGlkZW50aXR5cmVmIHdpdGggImZv
by10eXBlIiBhcyBpdHMgYmFzZSwgdGhlbiBwZXJtaXR0ZWQgdmFsdWVzIGFyZQ0KPiAgICAgZXhh
Y3RseSB0aG9zZQ0KPiAgICAgImZvby10eXBlLVsxLTldIi4NCj4gDQo+IFRoZSB3aG9sZSByZWFz
b24gdG8gdXNlIGlkZW50aXRpZXMgcmF0aGVyIHRoYW4gZW51bXMgaXMgdG8gYWxsb3cgZm9yDQo+
IGluY3JlbWVudGFsIGV4dGVuc2lvbi4NCg0KWWVzLg0KDQo+IFdpdGggcm91dGluZyBwcm90b2Nv
bHMsIGl0IGlzIHBvc3NpYmxlIGlmIG5vdA0KPiBsaWtlbHkgdG8gaGF2ZSBhbiBpbnN0YW50aWF0
aW9uIG9mIGEgZGF0YSBsZWFmIHRoYXQgaXMgdW5rbm93bi4gU28sIHdlDQo+IGFic29sdXRlbHkg
bmVlZCB0byBoYW5kbGUgdGhpcyBjYXNlLg0KDQpCdXQgdGhlIGluc3RydW1lbnRhdGlvbiBjb2Rl
IHRoYXQgZmlsbHMgaW4gdGhlIHZhbHVlIChhc3N1bWluZyBpdCBpcw0KY29uZmlnIGZhbHNlKSBr
bm93cyB3aGF0IGl0IGlzLCByaWdodD8gIFRoZW4gaXQgbWlnaHQgYmUgYmV0dGVyIHRvDQpoYXZl
IHRoZSB2ZW5kb3IgZGVmaW5lIGEgcHJvcHJpZXRhdHkgaWRlbnRpdHkgdGhhdCBpcyBkZXJpdmVk
IGZyb20NCmZvby10eXBlLCBhbmQgbGV0IHRoZSBpbnN0cnVtZW50YXRpb24gY29kZSB1c2UgdGhh
dCBpZGVudGl0eS4NCg0KDQovbWFydGluDQoNCj4gQWNlZSANCj4gICAgIA0KPiAgICAgSWYgdGhl
IHNlcnZlciBzdXBwb3J0cyBhIHBhcnRpY3VsYXIgdHlwZSwgdGhlbiBJIHdvdWxkIGV4cGVjdCBp
dCB0bw0KPiAgICAgaW1wbGVtZW50IGENCj4gICAgIG1vZHVsZSB3aGVyZSB0aGUgaWRlbnRpdHkg
Y29ycmVzcG9uZGluZyB0byB0aGF0IHR5cGUgaXMgZGVmaW5lZC4NCj4gICAgIA0KPiAgICAgTGFk
YSANCj4gICAgIA0KPiAgICAgPiAgDQo+ICAgICA+IA0KPiAgICAgPiBUaGFua3MsDQo+ICAgICA+
IEFjZWUNCj4gICAgID4gDQo+ICAgICA+IE9uIDUvMy8xOCwgMTo0OSBQTSwgIm5ldG1vZCBvbiBi
ZWhhbGYgb2YgTGFkaXNsYXYgTGhvdGthIg0KPiAgICAgPiA8bmV0bW9kLWJvdW5jZXNAaWV0DQo+
ICAgICA+IGYub3JnIG9uIGJlaGFsZiBvZiBsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gICAgID4g
DQo+ICAgICA+ICAgICBIaSBBY2VlLA0KPiAgICAgPiAgICAgDQo+ICAgICA+ICAgICBJIGFtIG5v
dCBzdXJlIHdoYXQgeW91IG1lYW4gYnkgdW5rbm93biBpZGVudGl0aWVzLiBJbiBnZW5lcmFsLCB0
aGUNCj4gICAgID4gaWRlbnRpdHkgdXNlZA0KPiAgICAgPiAgICAgYXMgdGhlIGJhc2Ugb2YgYW4g
aWRlbnRpdHlyZWYgKG9yIGluIFhwYXRoIGZ1bmN0aW9ucw0KPiAgICAgPiAgICAgZGVyaXZlZC1m
cm9tL2Rlcml2ZWQtDQo+ICAgICA+IGZyb20tDQo+ICAgICA+ICAgICBvci1zZWxmKSBzaG91bGQg
YmUgdGhlIG1vc3QgZ2VuZXJhbCBpZGVudGl0eSB0aGF0IGNhbiBtYXRjaCBhdCB0aGUNCj4gICAg
ID4gICAgIGdpdmVuDQo+ICAgICA+IHBsYWNlLg0KPiAgICAgPiAgICAgDQo+ICAgICA+ICAgICBE
byB5b3UgaGF2ZSBhbnkgZXhhbXBsZSBpbGx1c3RyYXRpbmcgeW91ciBjYXNlPw0KPiAgICAgPiAg
ICAgDQo+ICAgICA+ICAgICBMYWRhDQo+ICAgICA+ICAgICANCj4gICAgID4gICAgIA0KPiAgICAg
PiAgICAgT24gVGh1LCAyMDE4LTA1LTAzIGF0IDE3OjMwICswMDAwLCBBY2VlIExpbmRlbSAoYWNl
ZSkgd3JvdGU6DQo+ICAgICA+ICAgICA+IExldOKAmXMgc2F5IG9uZSBkZWZpbmUgYSBiYXNlIGlk
ZW50aXR5IHdpdGggYSBoaWVyYXJjaHkgb2YNCj4gICAgID4gICAgID4gaWRlbnRpZnlyZWbigJlz
DQo+ICAgICA+IHVzaW5nDQo+ICAgICA+ICAgICA+IGl0LiBUaGlzIHdpbGwgYWxsb3cgZm9yIGF1
Z21lbnRhdGlvbiBpbiBmdXR1cmUgbW9kZWxzLiBTaG91bGQgb25lDQo+ICAgICA+ICAgICA+IGFs
c28NCj4gICAgID4gZGVmaW5lDQo+ICAgICA+ICAgICA+IGFuIGlkZW50aXR5cmVmIGZvciB0aGUg
Y2xhc3Mgb2YgdW5rbm93biBpZGVudGl0aWVzPyBPciwgc2hvdWxkIG9uZQ0KPiAgICAgPiBzaW1w
bHkNCj4gICAgID4gICAgID4gcmV0dXJuIHRoZSBsb3dlc3QgcGFyZW50IGluIHRoZSBoaWVyYXJj
aHkgbWF0Y2hpbmcgdGhlIHZhbHVlPyBNYW55DQo+ICAgICA+IHRpbWVzLCB0aGlzDQo+ICAgICA+
ICAgICA+IHdvdWxkIGJlIHRoZSBiYXNlIGlkZW50aXR5Lg0KPiAgICAgPiAgICAgPiAgDQo+ICAg
ICA+ICAgICA+IFRoYW5rcywNCj4gICAgID4gICAgID4gQWNlZQ0KPiAgICAgPiAgICAgPiBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgPiAgICAg
PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ICAgICA+ICAgICA+IG5ldG1vZEBpZXRmLm9yZw0KPiAg
ICAgPiAgICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K
PiAgICAgPiAgICAgLS0gDQo+ICAgICA+ICAgICBMYWRpc2xhdiBMaG90a2ENCj4gICAgID4gICAg
IEhlYWQsIENaLk5JQyBMYWJzDQo+ICAgICA+ICAgICBQR1AgS2V5IElEOiAweEI4RjkyQjA4QTlG
NzZDNjcNCj4gICAgID4gICAgIA0KPiAgICAgPiAgICAgX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgID4gICAgIG5ldG1vZCBtYWlsaW5nIGxpc3QN
Cj4gICAgID4gICAgIG5ldG1vZEBpZXRmLm9yZw0KPiAgICAgPiAgICAgaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gICAgID4gICAgIA0KPiAgICAgPiANCj4g
ICAgIC0tIA0KPiAgICAgTGFkaXNsYXYgTGhvdGthDQo+ICAgICBIZWFkLCBDWi5OSUMgTGFicw0K
PiAgICAgUEdQIEtleSBJRDogMHhCOEY5MkIwOEE5Rjc2QzY3DQo+ICAgICANCj4gDQo+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldG1vZCBtYWls
aW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vbmV0bW9kDQo=


From nobody Thu May  3 13:31:06 2018
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 CDC3712EABF for ; Thu,  3 May 2018 13:31:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Q-uliLYZSIZ for ; Thu,  3 May 2018 13:31:02 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35B2126CC7 for ; Thu,  3 May 2018 13:31:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6410; q=dns/txt; s=iport; t=1525379461; x=1526589061; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wwuGjUV7DulaJn6t+ZF8M8ctCNcfq9Zs2EIGVfmHfuw=; b=gjefpZeZBRJ+YnrYPdjBZ0LUV2WvM2OGJo7h+fELCuKQQXKJC0e2htV+ HUpBk8xO6+OeaSIz/+6jLp3H09l0tQw0/i4pq0Wi+lqMAqOtap40dM198 lwGNp7XEq5wMcPJddzoexwKM5FbxaBJWw8cTMsKD6RtzR8QnfuUxFASSQ c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQDtcOta/4cNJK1SAQkZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBg0NheigKg2OIAoxvgT07gQ+TG4F4CxgLhANGAhqCFiE?= =?us-ascii?q?0GAECAQEBAQEBAmwcDIUoAQEBAQIBAQEhEToLEAIBCA4KAgImAgICJQsVEAI?= =?us-ascii?q?EDgWFBwgPqSyCHIRYg22CQoEJhxyCE4EygmiDEQEBgTUBFBaDADCCJAKQeoc?= =?us-ascii?q?gCAKOSoxZil6FPQIREwGBJAEcOECBEnAVOyoBghgJiweFPm+PYYEYAQE?=
X-IronPort-AV: E=Sophos;i="5.49,359,1520899200"; d="scan'208";a="109036593"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2018 20:31:00 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w43KUxNG028513 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 May 2018 20:31:00 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 3 May 2018 16:30:59 -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.1320.000; Thu, 3 May 2018 16:30:59 -0400
From: "Acee Lindem (acee)" 
To: Martin Bjorklund 
CC: "lhotka@nic.cz" , "netmod@ietf.org" 
Thread-Topic: [netmod] YANG identities and identityref's
Thread-Index: AQHT4wcmcoN4Fa9nLE+0HGK7LDbJoKQeSw0AgABOfID//8A2AIAAXFiA//+/JAA=
Date: Thu, 3 May 2018 20:30:59 +0000
Message-ID: <1B80C265-E8CE-4A14-9DC2-F96B58A1E0AF@cisco.com>
References: <3B5F31C4-1504-4F0D-875D-A9B559B01A82@cisco.com> <92458ec3b02ba207239df397d4c8fe9cdbdfd244.camel@nic.cz> <04CFDAC7-F364-49F0-97D0-64A88986FE26@cisco.com> <20180503.222307.1318677205860676080.mbj@tail-f.com>
In-Reply-To: <20180503.222307.1318677205860676080.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.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] YANG identities and identityref's
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 May 2018 20:31:05 -0000

DQoNCu+7v09uIDUvMy8xOCwgNDoyMyBQTSwgIk1hcnRpbiBCam9ya2x1bmQiIDxtYmpAdGFpbC1m
LmNvbT4gd3JvdGU6DQoNCiAgICAiQWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5jb20+
IHdyb3RlOg0KICAgID4gDQogICAgPiANCiAgICA+IE9uIDUvMy8xOCwgMjo0MCBQTSwgIkxhZGlz
bGF2IExob3RrYSIgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KICAgID4gDQogICAgPiAgICAgT24g
VGh1LCAyMDE4LTA1LTAzIGF0IDE4OjAwICswMDAwLCBBY2VlIExpbmRlbSAoYWNlZSkgd3JvdGU6
DQogICAgPiAgICAgPiBIaSBMYWRhLCANCiAgICA+ICAgICA+IA0KICAgID4gICAgID4gU28geW91
IGhhdmUgYSBiYXNlIGlkZW50aWZ5IG9mIGZvby10eXBlIGFuZCBzdWJvcmRpbmF0ZXMgb2YNCiAg
ICA+ICAgICA+IGZvby10eXBlLTEsIGZvby0NCiAgICA+ICAgICA+IHR5cGUtMiwgLi4uIGZvby10
eXBlLTkuIFlvdSBoYXZlIGEgZGF0YSBsZWFmIHRoYXQgdHlwZSBpZGVudGl0eXJlZg0KICAgID4g
ICAgID4gZm9vLXR5cGUNCiAgICA+ICAgICA+IGJ1dCB0aGUgYWN0dWFsIGluc3RhbnRpYXRpb24g
aXMgbm90IG9uZSBvZiB0aGUga25vd24gZm9vLXR5cGVzLiBTaG91bGQNCiAgICA+ICAgICA+IGEg
Zm9vLQ0KICAgID4gICAgID4gdHlwZS11bmtub3duIGJlIGRlZmluZWQgdG8gcmV0dXJuIGZvciB0
aGlzIGNhc2Ugb3Igc2hvdWxkIG9uZSBqdXN0DQogICAgPiAgICAgPiByZXR1cm4gZm9vLQ0KICAg
ID4gICAgID4gdHlwZT8gDQogICAgPiAgICAgDQogICAgPiAgICAgSG1tLCB0aGUgYWN0dWFsIGlu
c3RhbnRpYXRpb24gbG9va3MgbGlrZSBpbnZhbGlkIGRhdGEuIElmIHRoZSBsZWFmIGlzDQogICAg
PiAgICAgYW4NCiAgICA+ICAgICBpZGVudGl0eXJlZiB3aXRoICJmb28tdHlwZSIgYXMgaXRzIGJh
c2UsIHRoZW4gcGVybWl0dGVkIHZhbHVlcyBhcmUNCiAgICA+ICAgICBleGFjdGx5IHRob3NlDQog
ICAgPiAgICAgImZvby10eXBlLVsxLTldIi4NCiAgICA+IA0KICAgID4gVGhlIHdob2xlIHJlYXNv
biB0byB1c2UgaWRlbnRpdGllcyByYXRoZXIgdGhhbiBlbnVtcyBpcyB0byBhbGxvdyBmb3INCiAg
ICA+IGluY3JlbWVudGFsIGV4dGVuc2lvbi4NCiAgICANCiAgICBZZXMuDQogICAgDQogICAgPiBX
aXRoIHJvdXRpbmcgcHJvdG9jb2xzLCBpdCBpcyBwb3NzaWJsZSBpZiBub3QNCiAgICA+IGxpa2Vs
eSB0byBoYXZlIGFuIGluc3RhbnRpYXRpb24gb2YgYSBkYXRhIGxlYWYgdGhhdCBpcyB1bmtub3du
LiBTbywgd2UNCiAgICA+IGFic29sdXRlbHkgbmVlZCB0byBoYW5kbGUgdGhpcyBjYXNlLg0KICAg
IA0KICAgIEJ1dCB0aGUgaW5zdHJ1bWVudGF0aW9uIGNvZGUgdGhhdCBmaWxscyBpbiB0aGUgdmFs
dWUgKGFzc3VtaW5nIGl0IGlzDQogICAgY29uZmlnIGZhbHNlKSBrbm93cyB3aGF0IGl0IGlzLCBy
aWdodD8NCg0KTm8gLSB0aGVyZSBhcmUgbXVsdGlwbGUgZGV2aWNlcyBpbiB0aGUgbmV0d29yayBh
bmQgdGhleSBjb3VsZCBoYXZlIGRpZmZlcmVudCBsZXZlbCBvZiBzdXBwb3J0LiBGb3IgZXhhbXBs
ZSwgT1NQRiB3aWxsIGFjY2VwdCBPU1BGIExpbmsgU3RhdGUgQWR2ZXJ0aXNlbWVudCAoTFNBKSBU
TFYgdHlwZXMgdGhhdCBpdCBkb2Vzbid0IHlldCB1bmRlcnN0YW5kLiBUaGUgT1NQRiBMaW5rIFN0
YXRlIERhdGFiYXNlIGNhbiBiZSByZXRyaWV2ZWQgdmlhIGEgWUFORyBtb2RlbC4gVGhpcyBzZWVt
cyBsaWtlIGEgcHJldHR5IGJhc2ljIHVzZSBjYXNlIHRvIG1lLiANCg0KICBUaGVuIGl0IG1pZ2h0
IGJlIGJldHRlciB0bw0KICAgIGhhdmUgdGhlIHZlbmRvciBkZWZpbmUgYSBwcm9wcmlldGF0eSBp
ZGVudGl0eSB0aGF0IGlzIGRlcml2ZWQgZnJvbQ0KICAgIGZvby10eXBlLCBhbmQgbGV0IHRoZSBp
bnN0cnVtZW50YXRpb24gY29kZSB1c2UgdGhhdCBpZGVudGl0eS4NCg0KT3IgZGVmaW5lIHRoZSBm
b28tdHlwZS11bmtub3duIGluIHRoZSBtb2RlbCBzaW5jZSB0aGlzIGlzIHN1Y2ggYSBjb21tb24g
Y2FzZS4gIA0KDQpUaGFua3MsDQpBY2VlIA0KICAgIA0KICAgIA0KICAgIC9tYXJ0aW4NCiAgICAN
CiAgICA+IEFjZWUgDQogICAgPiAgICAgDQogICAgPiAgICAgSWYgdGhlIHNlcnZlciBzdXBwb3J0
cyBhIHBhcnRpY3VsYXIgdHlwZSwgdGhlbiBJIHdvdWxkIGV4cGVjdCBpdCB0bw0KICAgID4gICAg
IGltcGxlbWVudCBhDQogICAgPiAgICAgbW9kdWxlIHdoZXJlIHRoZSBpZGVudGl0eSBjb3JyZXNw
b25kaW5nIHRvIHRoYXQgdHlwZSBpcyBkZWZpbmVkLg0KICAgID4gICAgIA0KICAgID4gICAgIExh
ZGEgDQogICAgPiAgICAgDQogICAgPiAgICAgPiAgDQogICAgPiAgICAgPiANCiAgICA+ICAgICA+
IFRoYW5rcywNCiAgICA+ICAgICA+IEFjZWUNCiAgICA+ICAgICA+IA0KICAgID4gICAgID4gT24g
NS8zLzE4LCAxOjQ5IFBNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBMYWRpc2xhdiBMaG90a2EiDQog
ICAgPiAgICAgPiA8bmV0bW9kLWJvdW5jZXNAaWV0DQogICAgPiAgICAgPiBmLm9yZyBvbiBiZWhh
bGYgb2YgbGhvdGthQG5pYy5jej4gd3JvdGU6DQogICAgPiAgICAgPiANCiAgICA+ICAgICA+ICAg
ICBIaSBBY2VlLA0KICAgID4gICAgID4gICAgIA0KICAgID4gICAgID4gICAgIEkgYW0gbm90IHN1
cmUgd2hhdCB5b3UgbWVhbiBieSB1bmtub3duIGlkZW50aXRpZXMuIEluIGdlbmVyYWwsIHRoZQ0K
ICAgID4gICAgID4gaWRlbnRpdHkgdXNlZA0KICAgID4gICAgID4gICAgIGFzIHRoZSBiYXNlIG9m
IGFuIGlkZW50aXR5cmVmIChvciBpbiBYcGF0aCBmdW5jdGlvbnMNCiAgICA+ICAgICA+ICAgICBk
ZXJpdmVkLWZyb20vZGVyaXZlZC0NCiAgICA+ICAgICA+IGZyb20tDQogICAgPiAgICAgPiAgICAg
b3Itc2VsZikgc2hvdWxkIGJlIHRoZSBtb3N0IGdlbmVyYWwgaWRlbnRpdHkgdGhhdCBjYW4gbWF0
Y2ggYXQgdGhlDQogICAgPiAgICAgPiAgICAgZ2l2ZW4NCiAgICA+ICAgICA+IHBsYWNlLg0KICAg
ID4gICAgID4gICAgIA0KICAgID4gICAgID4gICAgIERvIHlvdSBoYXZlIGFueSBleGFtcGxlIGls
bHVzdHJhdGluZyB5b3VyIGNhc2U/DQogICAgPiAgICAgPiAgICAgDQogICAgPiAgICAgPiAgICAg
TGFkYQ0KICAgID4gICAgID4gICAgIA0KICAgID4gICAgID4gICAgIA0KICAgID4gICAgID4gICAg
IE9uIFRodSwgMjAxOC0wNS0wMyBhdCAxNzozMCArMDAwMCwgQWNlZSBMaW5kZW0gKGFjZWUpIHdy
b3RlOg0KICAgID4gICAgID4gICAgID4gTGV04oCZcyBzYXkgb25lIGRlZmluZSBhIGJhc2UgaWRl
bnRpdHkgd2l0aCBhIGhpZXJhcmNoeSBvZg0KICAgID4gICAgID4gICAgID4gaWRlbnRpZnlyZWbi
gJlzDQogICAgPiAgICAgPiB1c2luZw0KICAgID4gICAgID4gICAgID4gaXQuIFRoaXMgd2lsbCBh
bGxvdyBmb3IgYXVnbWVudGF0aW9uIGluIGZ1dHVyZSBtb2RlbHMuIFNob3VsZCBvbmUNCiAgICA+
ICAgICA+ICAgICA+IGFsc28NCiAgICA+ICAgICA+IGRlZmluZQ0KICAgID4gICAgID4gICAgID4g
YW4gaWRlbnRpdHlyZWYgZm9yIHRoZSBjbGFzcyBvZiB1bmtub3duIGlkZW50aXRpZXM/IE9yLCBz
aG91bGQgb25lDQogICAgPiAgICAgPiBzaW1wbHkNCiAgICA+ICAgICA+ICAgICA+IHJldHVybiB0
aGUgbG93ZXN0IHBhcmVudCBpbiB0aGUgaGllcmFyY2h5IG1hdGNoaW5nIHRoZSB2YWx1ZT8gTWFu
eQ0KICAgID4gICAgID4gdGltZXMsIHRoaXMNCiAgICA+ICAgICA+ICAgICA+IHdvdWxkIGJlIHRo
ZSBiYXNlIGlkZW50aXR5Lg0KICAgID4gICAgID4gICAgID4gIA0KICAgID4gICAgID4gICAgID4g
VGhhbmtzLA0KICAgID4gICAgID4gICAgID4gQWNlZQ0KICAgID4gICAgID4gICAgID4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+ICAgICA+ICAg
ICA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCiAgICA+ICAgICA+ICAgICA+IG5ldG1vZEBpZXRmLm9y
Zw0KICAgID4gICAgID4gICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9uZXRtb2QNCiAgICA+ICAgICA+ICAgICAtLSANCiAgICA+ICAgICA+ICAgICBMYWRpc2xhdiBM
aG90a2ENCiAgICA+ICAgICA+ICAgICBIZWFkLCBDWi5OSUMgTGFicw0KICAgID4gICAgID4gICAg
IFBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nw0KICAgID4gICAgID4gICAgIA0KICAgID4g
ICAgID4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQogICAgPiAgICAgPiAgICAgbmV0bW9kIG1haWxpbmcgbGlzdA0KICAgID4gICAgID4gICAgIG5l
dG1vZEBpZXRmLm9yZw0KICAgID4gICAgID4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vbmV0bW9kDQogICAgPiAgICAgPiAgICAgDQogICAgPiAgICAgPiANCiAgICA+
ICAgICAtLSANCiAgICA+ICAgICBMYWRpc2xhdiBMaG90a2ENCiAgICA+ICAgICBIZWFkLCBDWi5O
SUMgTGFicw0KICAgID4gICAgIFBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nw0KICAgID4g
ICAgIA0KICAgID4gDQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KICAgID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KICAgID4gbmV0bW9kQGlldGYu
b3JnDQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K
ICAgIA0KDQo=


From nobody Thu May  3 14:04:48 2018
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 36ED3126CC7 for ; Thu,  3 May 2018 14:04:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQy4tuVM5FZ3 for ; Thu,  3 May 2018 14:04:44 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C96DF1201F2 for ; Thu,  3 May 2018 14:04:43 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 94F174D7; Thu,  3 May 2018 23:04:42 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id RTnpR5v5MCyt; Thu,  3 May 2018 23:04:42 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu,  3 May 2018 23:04:42 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 462F320035; Thu,  3 May 2018 23:04:42 +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 oUX8ncV_HXjQ; Thu,  3 May 2018 23:04:42 +0200 (CEST)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CFC7920031; Thu,  3 May 2018 23:04:41 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id E445B42CBB97; Thu,  3 May 2018 23:04:38 +0200 (CEST)
Date: Thu, 3 May 2018 23:04:38 +0200
From: Juergen Schoenwaelder 
To: "Acee Lindem (acee)" 
Cc: Martin Bjorklund , "netmod@ietf.org" 
Message-ID: <20180503210438.rwpk6b37krvjjxuo@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: "Acee Lindem (acee)" , Martin Bjorklund , "netmod@ietf.org" 
References: <3B5F31C4-1504-4F0D-875D-A9B559B01A82@cisco.com> <92458ec3b02ba207239df397d4c8fe9cdbdfd244.camel@nic.cz> <04CFDAC7-F364-49F0-97D0-64A88986FE26@cisco.com> <20180503.222307.1318677205860676080.mbj@tail-f.com> <1B80C265-E8CE-4A14-9DC2-F96B58A1E0AF@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1B80C265-E8CE-4A14-9DC2-F96B58A1E0AF@cisco.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] YANG identities and identityref's
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 May 2018 21:04:47 -0000

On Thu, May 03, 2018 at 08:30:59PM +0000, Acee Lindem (acee) wrote:
> 
> No - there are multiple devices in the network and they could have different level of support. For example, OSPF will accept OSPF Link State Advertisement (LSA) TLV types that it doesn't yet understand. The OSPF Link State Database can be retrieved via a YANG model. This seems like a pretty basic use case to me. 

If multiple different TLVs that are unknown to the server but that
exist in the link state database all map to a single unknown identity,
then you loose potentially important information. Perhaps you have no
other choice than modeling TLVs using tag numbers instead of
identities.

/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  3 23:23:11 2018
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 5BDE3126CF6; Thu,  3 May 2018 23:23:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMDbOl2gPZ0K; Thu,  3 May 2018 23:23:09 -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 8985A12421A; Thu,  3 May 2018 23:23:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=199; q=dns/txt; s=iport; t=1525414988; x=1526624588; h=to:subject:from:cc:message-id:date:mime-version: content-transfer-encoding; bh=AMNxHr9F3EG52X6vh5CGpUjbvB470Wevo7yV2f62E9o=; b=clC+56xBoC+VnV7t34qsHkRB7b72Y+cJl5JQ8I1DR+uBdGLpr9P3J24X Yw2edGeLY/c9C5wr4sKARwxtojPX+wf7hewZp8ono8MDnG8Wo0B8b+g9C sIUl7z2jBY9jrluExX/mG/ZqPB1JqWxCg9MBX+gzcgNHh2F9GXQOhYJkb s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByBgCN++ta/xbLJq1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYQleiiDbYgdQ41OEoE4lRMLG4RRglY4FAECAQEBAQEBAmwcDIV?= =?us-ascii?q?SFUE1AiYCbAgBAYUPp3WCHIRYg2uCQoEJiHA/gTKHOwEBaoI0glQChyiGCIp?= =?us-ascii?q?rCIE4hCyIYgaBJwFJhV6FCosihSOBJTMhJoEsMxoIGxWCfgmLB4VAPTCOAoI?= =?us-ascii?q?3AQE?=
X-IronPort-AV: E=Sophos;i="5.49,361,1520899200";  d="scan'208";a="3553509"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 May 2018 06:23:07 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w446N6fb029014; Fri, 4 May 2018 06:23:06 GMT
To: draft-ietf-netmod-sub-intf-vlan-model@ietf.org
From: Benoit Claise 
Cc: NETMOD Working Group 
Message-ID: <24df3bb0-ed42-a755-376b-e971a44d274f@cisco.com>
Date: Fri, 4 May 2018 08:23:06 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: [netmod] Mail regarding draft-ietf-netmod-sub-intf-vlan-model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 04 May 2018 06:23:10 -0000

Hi,

Note that draft-ietf-netmod-sub-intf-vlan-model expired.
As a consequence, we're not extracting the YANG module(s) any longer in 
the IETF and yangcatalog.org toolchain.

Regards, Benoit


From nobody Fri May  4 14:22:43 2018
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 35DEE12DA15 for ; Fri,  4 May 2018 14:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 VyBOWSu2x_Mi for ; Fri,  4 May 2018 14:22:40 -0700 (PDT)
Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0311612D9FE for ; Fri,  4 May 2018 14:22:39 -0700 (PDT)
Received: from nitebug.localdomain (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id C90B1242EC1; Fri,  4 May 2018 23:22:36 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1525468956; bh=S4dtF3QpuhHK1KbC4dmBMyBhPCF/dAQ5CXdU87NI5as=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=E2PlyD0QNTZH1JKrWKmtKb7+/KagpaWfvTtbt7iGmBxS2uc234jg8U6rzCeuM05b7 CS3AhCGLoEAcsAQeNN0RdjfRBYpGLnGjL7Q3JPwXn3KQcGAWWhwTldDV+K8Dj9WY2Z 5ajFuf3mNE4O53aHpNNebCQF2u7QytrVE93g90A8=
To: Martin Bjorklund , lhotka@nic.cz
Cc: netmod@ietf.org
References: <87muxq1pk9.fsf@nic.cz>  <065a363753a67ee12f8bde6224009207b5fe7ee7.camel@nic.cz> <20180427.120325.419501937185262392.mbj@tail-f.com>
From: Robert Varga 
Message-ID: 
Date: Fri, 4 May 2018 23:22:36 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <20180427.120325.419501937185262392.mbj@tail-f.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pDbTH853j0pEOTwYbX6oECB7PJEUQGMQT"
Archived-At: 
Subject: Re: [netmod] yang-data-ext issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 04 May 2018 21:22:42 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--pDbTH853j0pEOTwYbX6oECB7PJEUQGMQT
Content-Type: multipart/mixed; boundary="EQdTd3zoV2Mhvo7Ygc8WBl2tV5dLLM1Ky";
 protected-headers="v1"
From: Robert Varga 
To: Martin Bjorklund , lhotka@nic.cz
Cc: netmod@ietf.org
Message-ID: 
Subject: Re: [netmod] yang-data-ext issues
References: <87muxq1pk9.fsf@nic.cz>
 
 <065a363753a67ee12f8bde6224009207b5fe7ee7.camel@nic.cz>
 <20180427.120325.419501937185262392.mbj@tail-f.com>
In-Reply-To: <20180427.120325.419501937185262392.mbj@tail-f.com>

--EQdTd3zoV2Mhvo7Ygc8WBl2tV5dLLM1Ky
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 27/04/18 12:03, Martin Bjorklund wrote:
>> It would be great to remove NETCONF specifics from YANG and I'd be wil=
ling to
>> contribute to this work.
> This is a different topic though.

+1 and count me in, please.

Thanks,
Robert


--EQdTd3zoV2Mhvo7Ygc8WBl2tV5dLLM1Ky--

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

-----BEGIN PGP SIGNATURE-----

iQI/BAEBCgApFiEEdj+N7pgGP1gKvbdQJKB0S2uuNdsFAlrszxwLHG5pdGVAaHEu
c2sACgkQJKB0S2uuNdvRCA//er5+aaGMYRbnJ24pJ1PmQtU2gtMDhT+sQdldRdqp
pMmtUbZ1Qlr52dPY+6Ik38KFOq8q6Ls41pPwmoLN+kOqG0PUJqnDd8TXdqbOSQur
1R/qX8a8LBPa//d/FjK1S7gvH/NVLDKqqouel7Tp28mhHbRxnWtwElbDK0iaQMEh
XeYZVw/KhatWe8uwcpXbN/kRNZ86WSMVwQNY8Y99ImcKgJBG2E0vErZFXbiB/So3
LMXzEKxJGg1FPf0M4Ig2AcozQ6ehSSRAA+hRH5t2lMebRxuQkA7+xbeiAVoMyBv8
OGCr54omP/5vX8kJEmCIunJA7b+bEsUjZ7zndlnHhm2mVDzJsnzZtl+mbz+VGFZA
9IwUWtl5Id7pUYpfVs5Hf4t41IIHuyjUl+On27nRYUw74n3eohVk5MGrCv8VfcQy
O+1KenYBvauVHmD1KcjfHFQ+fJxd+Ozx5dgBvVsPzvEhxciJNz4GL7CIZttWzzJp
Tp0eT62rmfGYGiuX9ZMGmsfnscCssRs/JzvbBTDAhCCMtQffVA3CpUQyDIiOSk3L
oySgLkba4sDvi/NCxyamjUiFhQl/OltRtxYZbXZXWs5BxPrrSp6xU4S5GxKRv8Nd
kZvp9HyHMX2fUMH2PPF4Zn4pcNqYr9pHSYFQEPTNyFBUHdsAADmOKV5smSL0pde9
3p4=
=q/7t
-----END PGP SIGNATURE-----

--pDbTH853j0pEOTwYbX6oECB7PJEUQGMQT--


From nobody Fri May  4 14:32:19 2018
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 AE1C612DA11 for ; Fri,  4 May 2018 14:32:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 SKIxL9b8_1Vz for ; Fri,  4 May 2018 14:32:16 -0700 (PDT)
Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D0C312D9FE for ; Fri,  4 May 2018 14:32:16 -0700 (PDT)
Received: from nitebug.localdomain (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id 772F9242EC1; Fri,  4 May 2018 23:32:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1525469534; bh=Evv3ADaP7zf2HXDzmgPCl+oLbJy09mW29pIKSKcMpzQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=LJvCZO41KXCkkRhu2KKA78Bce6P7IPvc4ua4m0schC4I2iqpkNHEro3EWBvxBUSiO 7AxiBhRsjhNWn6zB8QmqLcCLech4H8OHPCL1ajrBF6an11xzozfsPxZzE912Kestet PGIJXK2Ntm6zYWHYkA+wAsiJcxBIjrJZzSX3DMxE=
To: Martin Bjorklund , lhotka@nic.cz
Cc: netmod@ietf.org
References: <87muxq1pk9.fsf@nic.cz>  <065a363753a67ee12f8bde6224009207b5fe7ee7.camel@nic.cz> <20180427.120325.419501937185262392.mbj@tail-f.com>
From: Robert Varga 
Message-ID: <6e687971-7135-e16a-de6d-2275fd809a6e@hq.sk>
Date: Fri, 4 May 2018 23:32:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <20180427.120325.419501937185262392.mbj@tail-f.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RK3q4vG4SSYHhI1BNMg4miaGSz6MuEyix"
Archived-At: 
Subject: Re: [netmod] yang-data-ext issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 04 May 2018 21:32:17 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--RK3q4vG4SSYHhI1BNMg4miaGSz6MuEyix
Content-Type: multipart/mixed; boundary="p8Rp840YzXRqy8l7GYpVQ847E9xuX1h2z";
 protected-headers="v1"
From: Robert Varga 
To: Martin Bjorklund , lhotka@nic.cz
Cc: netmod@ietf.org
Message-ID: <6e687971-7135-e16a-de6d-2275fd809a6e@hq.sk>
Subject: Re: [netmod] yang-data-ext issues
References: <87muxq1pk9.fsf@nic.cz>
 
 <065a363753a67ee12f8bde6224009207b5fe7ee7.camel@nic.cz>
 <20180427.120325.419501937185262392.mbj@tail-f.com>
In-Reply-To: <20180427.120325.419501937185262392.mbj@tail-f.com>

--p8Rp840YzXRqy8l7GYpVQ847E9xuX1h2z
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 27/04/18 12:03, Martin Bjorklund wrote:
>>> This is true. We used to do this before yang-data was available.
>> If I remember correctly, the stuff was inside groupings that were not =
used
>> anywhere.
> Which doesn't quite work, since no namespace is attached to the nodes.
>=20

True, but that is can boil down to a simple data transplant:

1) treat the nodes declared in a grouping to be defined underneath their
containing grouping identifier
2) recognized when grouping instantiations are data-compatible (i.e.
disregarding namespace)

Unlike an extension, this behavior becomes default-on, not something you
opt into by using an extension -- which would necessitate a revision of
existing modules take advantage of.

Regards,
Robert

P.S.: OpenDaylight Java Bindinds do this to a certain, not perfect, exten=
t.


--p8Rp840YzXRqy8l7GYpVQ847E9xuX1h2z--

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

-----BEGIN PGP SIGNATURE-----

iQI/BAEBCgApFiEEdj+N7pgGP1gKvbdQJKB0S2uuNdsFAlrs0V4LHG5pdGVAaHEu
c2sACgkQJKB0S2uuNduKRg/7ByDHIrZPExYsP4FcOkXMHPIZBcc8J6NrNCenquxW
ojpNvwAvlWsDg4pOXMj0cGQC5QrS6CWBg56eSNnyARZT84ZtvUbIAQr9tXLB+VcV
O1e5GNqQQAIFpIqAZzktMGRa1GUbGH9hpXJeQ9s8wnStrPgW89A+XeLIhOaXALHq
z8UniYDvvW+pNZYWRjKgO5OETpsWmXx5EUGpJmrXCBivF0AovVexCFWS1HMscTBH
3CwxvoZAhCGv/umtyPZxO/siOrvGXxU9f18GNPwZZE7pV8cQZd+qCwGhpEtfgEGT
K1OiyceTa7n8nFxeh5XFLj3kTIqAUTIe39eBoinQpTaY2lilT3ASm5tJb6T2C52G
VUEQxiXJ1P5zVhbP57ZRWM/dh+Najr2hWE1q/nR5bwXUqj58lQDAFF3jk007QMeJ
atdWeUfsm6eSkFdjQrsyK5PM/ma02mlMTOvl36eGNxfn4wpwUBumbVdqGq64yHOk
MT/KDKZuyIMWOMVcm4D0ZKZGUhs6Naz7vHQVpcmxqKSpbCT7g48oRsUDfMZ2Sffw
RmQ0mEHNvGi+MCseU5DitLz1rbVCWmys/ammbrD7Q+dUm2VbCvmw0upTE9jiPnRz
z+hE2P7unom/MfnZ8U4cFwZ2Rs9lvehPuUVl6MtvKURx1ZLoZ48lhjxo7hiBPP6Z
qEQ=
=WGG5
-----END PGP SIGNATURE-----

--RK3q4vG4SSYHhI1BNMg4miaGSz6MuEyix--


From nobody Tue May  8 19:31:31 2018
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 BACCC12D877 for ; Tue,  8 May 2018 19:31:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.94
X-Spam-Level: 
X-Spam-Status: No, score=-3.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFaOKTZgTC9X for ; Tue,  8 May 2018 19:31:28 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D50631200E5 for ; Tue,  8 May 2018 19:31:27 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id D86AE64F7FA25 for ; Wed,  9 May 2018 03:31:23 +0100 (IST)
Received: from DGGEMA422-HUB.china.huawei.com (10.1.198.155) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 9 May 2018 03:31:24 +0100
Received: from DGGEMA502-MBS.china.huawei.com ([169.254.3.91]) by dggema422-hub.china.huawei.com ([10.1.198.155]) with mapi id 14.03.0382.000; Wed, 9 May 2018 10:31:15 +0800
From: Rohit R Ranade 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] Query about draft-ietf-netconf-rfc7895bis-06
Thread-Index: AdPnPP5v6upIMk70QLabNfGFekjJXA==
Date: Wed, 9 May 2018 02:31:15 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6B203A98@DGGEMA502-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.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6B203A98DGGEMA502MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [netmod]  Query about draft-ietf-netconf-rfc7895bis-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 May 2018 02:31:30 -0000

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

Hi All,


1.       "import-only-module" is currently under the "module-set" list. How=
 does the client benefit by learning which module-set imports which modules=
 ?

2.       Whether we can keep the "import-only-module" as a sibling to modul=
e-set. And let it list all the imported modules.

3.  Section 3 mentions the text  "A common use case is the operational stat=
e datastore schema which is a
  superset of the schema used by conventional configuration datastores. ". =
=3D=3D> I think it should be "maybe a superset" based on Point 3 of "Object=
ives" section.

4.       Also I feel the text about "netconf-capability-change" notificatio=
n based on yang-library checksum should be moved to the NETCONF NMDA draft.=
  Is it not more suitable there ?

With Regards,
Rohit R Ranade


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











Hi All,


 



1=
.   &=
nbsp;  
“import-only-module” is curren=
tly under the “module-set” list. How does the client benefit by
 learning which module-set imports which modules ? 



2=
.   &=
nbsp;  
Whether we can keep the=
 “import-only-module” as a sibling to module-set. And let it li=
st all the imported modules.




3=
. 
Section 3 mentions the =
text  “A common use case is the oper=
ational state datastore schema which is a


  superset of the schema used by co=
nventional configuration datastores. “.
è I think it should be =
220;maybe a superset” based on Point 3 of “Objectives=
221; section.



4=
.   &=
nbsp;  
Also I feel the text ab=
out “netconf-capability-change” notification based on yang-library checksum
 should be moved to the NETCONF NMDA draft.  Is it not more suitable t=
here ?


 


With Regards,=



Rohit R Ranade


 






--_000_991B70D8B4112A4699D5C00DDBBF878A6B203A98DGGEMA502MBSchi_--


From nobody Tue May  8 22:46:04 2018
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 B5844127058 for ; Tue,  8 May 2018 22:46:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLO2bsGXeZLX for ; Tue,  8 May 2018 22:46:01 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93BA7126DC2 for ; Tue,  8 May 2018 22:46:01 -0700 (PDT)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 224E9A49F1E9E for ; Wed,  9 May 2018 06:45:57 +0100 (IST)
Received: from DGGEMA402-HUB.china.huawei.com (10.3.20.43) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 9 May 2018 06:45:57 +0100
Received: from DGGEMA502-MBS.china.huawei.com ([169.254.3.91]) by DGGEMA402-HUB.china.huawei.com ([10.3.20.43]) with mapi id 14.03.0382.000; Wed, 9 May 2018 13:45:46 +0800
From: Rohit R Ranade 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] Query about draft-ietf-netconf-rfc7895bis-06 - Part -2
Thread-Index: AdPnWAIRsRBoDLkCS9SLDJeEL+Qjrg==
Date: Wed, 9 May 2018 05:45:46 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6B204BBA@DGGEMA502-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.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6B204BBADGGEMA502MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] Query about draft-ietf-netconf-rfc7895bis-06 - Part -2
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 May 2018 05:46:04 -0000

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

Hi All,

Continuing with the below queries.

5.  For a module like "ietf-netconf-notifications", which implements only n=
otifications. I think this module is not suitable to be put in any of the d=
ata-stores. So a separate module-set has to be prepared for such modules bu=
t not included in any data-store. Is it correct ?
6. Similar logic will apply to any module which only defines "rpc" statemen=
ts also I think. Whether need to update the yang-library draft text mention=
ing these two scenarios ?

With Regards,
Rohit R Ranade

From: Rohit R Ranade
Sent: 09 May 2018 08:01
To: netmod@ietf.org
Subject: [netmod] Query about draft-ietf-netconf-rfc7895bis-06

Hi All,


1.       "import-only-module" is currently under the "module-set" list. How=
 does the client benefit by learning which module-set imports which modules=
 ?

2.       Whether we can keep the "import-only-module" as a sibling to modul=
e-set. And let it list all the imported modules.

3.  Section 3 mentions the text  "A common use case is the operational stat=
e datastore schema which is a
  superset of the schema used by conventional configuration datastores. ". =
=3D=3D> I think it should be "maybe a superset" based on Point 3 of "Object=
ives" section.

4.       Also I feel the text about "netconf-capability-change" notificatio=
n based on yang-library checksum should be moved to the NETCONF NMDA draft.=
  Is it not more suitable there ?

With Regards,
Rohit R Ranade


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











Hi All,=



&n=
bsp;


Continu=
ing with the below queries.


&n=
bsp;


5. =
; For a module like “ietf-netconf-notifications”, which impleme=
nts only notifications. I think this module is not suitable to be put in an=
y of the data-stores. So a separate module-set has to be
 prepared for such modules but not included in any data-store. Is it correc=
t ?


6. Simi=
lar logic will apply to any module which only defines “rpc” sta=
tements also I think. Whether need to update the yang-library draft text me=
ntioning these two scenarios ?


&n=
bsp;


With Re=
gards,




Rohit R=
 Ranade




&n=
bsp;






From: Rohit R Ranade


Sent: 09 May 2018 08:01

To: netmod@ietf.org

Subject: [netmod] Query about draft-ietf-netconf-rfc7895bis-06<=
/o:p>






 


Hi All,


 



1=
.   &=
nbsp;  
“import-only-module” is curren=
tly under the “module-set” list. How does the client benefit by
 learning which module-set imports which modules ? 



2=
.   &=
nbsp;  
Whether we can keep the=
 “import-only-module” as a sibling to module-set. And let it li=
st all the imported modules.




3=
. 
Section 3 mentions the =
text  “A common use case is the oper=
ational state datastore schema which is a


  superset of the schema used by co=
nventional configuration datastores. “.
è I think it should be =
220;maybe a superset” based on Point 3 of “Objectives=
221; section.



4=
.   &=
nbsp;  
Also I feel the text ab=
out “netconf-capability-change” notification based on yang-library checksum
 should be moved to the NETCONF NMDA draft.  Is it not more suitable t=
here ?


 


With Regards,=



Rohit R Ranade


 






--_000_991B70D8B4112A4699D5C00DDBBF878A6B204BBADGGEMA502MBSchi_--


From nobody Tue May  8 23:12:09 2018
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 45DB3126DED for ; Tue,  8 May 2018 23:12:07 -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 USiVC9VS54Oi for ; Tue,  8 May 2018 23:12:05 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71E1126BF6 for ; Tue,  8 May 2018 23:12:04 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 2C4A466E; Wed,  9 May 2018 08:12:02 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id CnQ0rL9c_Eae; Wed,  9 May 2018 08:12:01 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed,  9 May 2018 08:12:02 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1657620035; Wed,  9 May 2018 08:12:02 +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 7wotNzqd--0Q; Wed,  9 May 2018 08:12:01 +0200 (CEST)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B399220031; Wed,  9 May 2018 08:12:01 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 4710B42D0298; Wed,  9 May 2018 08:12:01 +0200 (CEST)
Date: Wed, 9 May 2018 08:12:01 +0200
From: Juergen Schoenwaelder 
To: Rohit R Ranade 
Cc: "netmod@ietf.org" 
Message-ID: <20180509061200.skr4jricsqg5rom4@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Rohit R Ranade , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6B204BBA@DGGEMA502-MBS.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6B204BBA@DGGEMA502-MBS.china.huawei.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] Query about draft-ietf-netconf-rfc7895bis-06 - Part -2
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 May 2018 06:12:07 -0000

On Wed, May 09, 2018 at 05:45:46AM +0000, Rohit R Ranade wrote:
> Hi All,
> 
> Continuing with the below queries.
> 
> 5.  For a module like "ietf-netconf-notifications", which implements only notifications. I think this module is not suitable to be put in any of the data-stores. So a separate module-set has to be prepared for such modules but not included in any data-store. Is it correct ?

> 6. Similar logic will apply to any module which only defines "rpc" statements also I think. Whether need to update the yang-library draft text mentioning these two scenarios ?

RFC 8342 says that the XPath context for notifications, rpc, and
actions is the operational state of the server. For actions, RFC 8342
is even more explicit (since they are bound to a data node, which btw
can also be true for some notifications): RFC 8342 says that actions
are always invoked in the context of the operational state
datastore.

/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  8 23:30:42 2018
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 BD91A12785F for ; Tue,  8 May 2018 23:30:41 -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 vaoRqf9onK7l for ; Tue,  8 May 2018 23:30:40 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC996126CC7 for ; Tue,  8 May 2018 23:30:39 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id B6AC63B; Wed,  9 May 2018 08:30:38 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id jkiouH_jRIMz; Wed,  9 May 2018 08:30:38 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed,  9 May 2018 08:30:38 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A13B520036; Wed,  9 May 2018 08:30:38 +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 kL_MJixTqexF; Wed,  9 May 2018 08:30:38 +0200 (CEST)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3776F20031; Wed,  9 May 2018 08:30:38 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id CAFA342D068C; Wed,  9 May 2018 08:30:34 +0200 (CEST)
Date: Wed, 9 May 2018 08:30:34 +0200
From: Juergen Schoenwaelder 
To: Rohit R Ranade 
Cc: "netmod@ietf.org" 
Message-ID: <20180509063034.iclb6vbbua5nqu6p@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Rohit R Ranade , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6B203A98@DGGEMA502-MBS.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6B203A98@DGGEMA502-MBS.china.huawei.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] Query about draft-ietf-netconf-rfc7895bis-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 May 2018 06:30:42 -0000

On Wed, May 09, 2018 at 02:31:15AM +0000, Rohit R Ranade wrote:
> Hi All,
> 
> 
> 1.       "import-only-module" is currently under the "module-set" list. How does the client benefit by learning which module-set imports which modules ?

              All non import-only modules of the schema are implemented
              with their associated features and deviations.

Modules in module-set/module are modules a datastore referencing the
module set implements, modules in module-set/import-only-module are
modules a datastore referencing the module set only imports from.
 
> 2.       Whether we can keep the "import-only-module" as a sibling to module-set. And let it list all the imported modules.

A module set is a self contained set of modules and import only modules.

> 3.  Section 3 mentions the text  "A common use case is the operational state datastore schema which is a
>   superset of the schema used by conventional configuration datastores. ". ==> I think it should be "maybe a superset" based on Point 3 of "Objectives" section.

Perhaps 'which is commonly a superset'. But note that the point 3 in
the objectives also covers any future datastores such as ephemeral
datastores what may have data models that do not relate to
.

> 4.       Also I feel the text about "netconf-capability-change" notification based on yang-library checksum should be moved to the NETCONF NMDA draft.  Is it not more suitable there ?

The reason is that NMDA is a very generic architectural document and
as such it should not detail specifics of concrete notifications.
These details belong into the specific documents. The NMDA document is
a root of a document dependency tree, we should not create a mesh of
document dependencies.

/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  9 02:12:30 2018
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 5405F12EB1B for ; Wed,  9 May 2018 02:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqwEHchfe3pb for ; Wed,  9 May 2018 02:12:26 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFBDA127241 for ; Wed,  9 May 2018 02:12:26 -0700 (PDT)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 22FD7B4BCD056; Wed,  9 May 2018 10:12:22 +0100 (IST)
Received: from DGGEMA404-HUB.china.huawei.com (10.3.20.45) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 9 May 2018 10:12:23 +0100
Received: from DGGEMA502-MBS.china.huawei.com ([169.254.3.91]) by DGGEMA404-HUB.china.huawei.com ([10.3.20.45]) with mapi id 14.03.0382.000; Wed, 9 May 2018 17:12:12 +0800
From: Rohit R Ranade 
To: Juergen Schoenwaelder 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod]  Query about draft-ietf-netconf-rfc7895bis-06
Thread-Index: AQHT519Lh2VAkGc+h06X2TPb9R04RKQnGvNA
Date: Wed, 9 May 2018 09:12:12 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6B204D26@DGGEMA502-MBS.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6B203A98@DGGEMA502-MBS.china.huawei.com> <20180509063034.iclb6vbbua5nqu6p@elstar.local>
In-Reply-To: <20180509063034.iclb6vbbua5nqu6p@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] Query about draft-ietf-netconf-rfc7895bis-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 May 2018 09:12:28 -0000

On Wed, May 09, 2018 at 02:31:15AM +0000, Rohit R Ranade wrote:
> Hi All,
>=20
>=20
> 1.       "import-only-module" is currently under the "module-set" list. H=
ow does the client benefit by learning which module-set imports which modul=
es ?

              All non import-only modules of the schema are implemented
              with their associated features and deviations.

Modules in module-set/module are modules a datastore referencing the module=
 set implements, modules in module-set/import-only-module are modules a dat=
astore referencing the module set only imports from.
=20
> 2.       Whether we can keep the "import-only-module" as a sibling to mod=
ule-set. And let it list all the imported modules.

A module set is a self contained set of modules and import only modules.

[Rohit R Ranade] One use-case I thought of was that a client was concerned =
with only some data-stores. So they can download the schema of only those m=
odules and their imported modules of their data-stores of interest. But if =
this was the case, then the "checksum" is of no use to them, as they will n=
ot know whether their intended data-store changed or not. Is there any othe=
r use-case for the import-only-module being part of module-set ?

> 3.  Section 3 mentions the text  "A common use case is the operational st=
ate datastore schema which is a
>   superset of the schema used by conventional configuration datastores. "=
. =3D=3D> I think it should be "maybe a superset" based on Point 3 of "Obje=
ctives" section.

Perhaps 'which is commonly a superset'. But note that the point 3 in the ob=
jectives also covers any future datastores such as ephemeral datastores wha=
t may have data models that do not relate to .
[Rohit R Ranade] I agree, your suggestion for this change is better.=20

> 4.       Also I feel the text about "netconf-capability-change" notificat=
ion based on yang-library checksum should be moved to the NETCONF NMDA draf=
t.  Is it not more suitable there ?

The reason is that NMDA is a very generic architectural document and as suc=
h it should not detail specifics of concrete notifications.
These details belong into the specific documents. The NMDA document is a ro=
ot of a document dependency tree, we should not create a mesh of document d=
ependencies.
[Rohit R Ranade] Please note I mentioned " should be moved to the NETCONF N=
MDA draft ", by which I meant draft-ietf-netconf-nmda-netconf-05, not the R=
FC 8342

/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 Wed May  9 02:54:23 2018
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 26EBE12EB88 for ; Wed,  9 May 2018 02:54:11 -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 4CwUw-o-fHlL for ; Wed,  9 May 2018 02:54:05 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 824A612EB96 for ; Wed,  9 May 2018 02:53:56 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 534753B; Wed,  9 May 2018 11:53:55 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id vf8kwrSZd5Pl; Wed,  9 May 2018 11:53:54 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed,  9 May 2018 11:53:55 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3DACE20035; Wed,  9 May 2018 11:53:55 +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 Qna_gd6XbuOR; Wed,  9 May 2018 11:53:54 +0200 (CEST)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9961A20031; Wed,  9 May 2018 11:53:54 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id B4CB542D0C37; Wed,  9 May 2018 11:53:52 +0200 (CEST)
Date: Wed, 9 May 2018 11:53:52 +0200
From: Juergen Schoenwaelder 
To: Rohit R Ranade 
Cc: "netmod@ietf.org" 
Message-ID: <20180509095352.zahi7yuljb7ucd4x@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Rohit R Ranade , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6B203A98@DGGEMA502-MBS.china.huawei.com> <20180509063034.iclb6vbbua5nqu6p@elstar.local> <991B70D8B4112A4699D5C00DDBBF878A6B204D26@DGGEMA502-MBS.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6B204D26@DGGEMA502-MBS.china.huawei.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] Query about draft-ietf-netconf-rfc7895bis-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 May 2018 09:54:22 -0000

On Wed, May 09, 2018 at 09:12:12AM +0000, Rohit R Ranade wrote:
> On Wed, May 09, 2018 at 02:31:15AM +0000, Rohit R Ranade wrote:
> > Hi All,
> > 
> > 
> > 1.       "import-only-module" is currently under the "module-set" list. How does the client benefit by learning which module-set imports which modules ?
> 
>               All non import-only modules of the schema are implemented
>               with their associated features and deviations.
> 
> Modules in module-set/module are modules a datastore referencing the module set implements, modules in module-set/import-only-module are modules a datastore referencing the module set only imports from.
>  
> > 2.       Whether we can keep the "import-only-module" as a sibling to module-set. And let it list all the imported modules.
> 
> A module set is a self contained set of modules and import only modules.
> 
> [Rohit R Ranade] One use-case I thought of was that a client was concerned with only some data-stores. So they can download the schema of only those modules and their imported modules of their data-stores of interest. But if this was the case, then the "checksum" is of no use to them, as they will not know whether their intended data-store changed or not. Is there any other use-case for the import-only-module being part of module-set ?

The checksum indicates a change in YANG library. If a client is only
interested in some datastore schemas, then the client may reload data
even though the specific datastore schema did not change. There were
versions with more checksum objects but at the end we removed them and
kept only the one that is essential to keep. Note, if you use
RESTCONF, then ETAGS may help with more granular checks. (In fact,
instead of spreading checksum objects all over, it seems RESTCONF does
not really need them and if NETCONF needs more granular chance checks,
it seems a generic solution that can work on arbitrary subtrees is a
better solution than spreading checksum objects everywhere.

The use-case for import-only-modules being part of a module set is to
allow a module-sets to be referential complete, i.e., different
module-sets may have diffferent import-only-modules.
 
> > 4.       Also I feel the text about "netconf-capability-change" notification based on yang-library checksum should be moved to the NETCONF NMDA draft.  Is it not more suitable there ?
> 
> The reason is that NMDA is a very generic architectural document and as such it should not detail specifics of concrete notifications.
> These details belong into the specific documents. The NMDA document is a root of a document dependency tree, we should not create a mesh of document dependencies.
> [Rohit R Ranade] Please note I mentioned " should be moved to the NETCONF NMDA draft ", by which I meant draft-ietf-netconf-nmda-netconf-05, not the RFC 8342

Sorry for my mis-understanding. YANG library defines the checksum and
the checksum may trigger a netconf-capability-change notification, so
this is likely why talk about the netconf-capability-change notification
in YANG library.

/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  9 09:15:19 2018
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 27398126E01 for ; Wed,  9 May 2018 09:15:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.611
X-Spam-Level: 
X-Spam-Status: No, score=-12.611 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRvea-Gn9_2Y for ; Wed,  9 May 2018 09:15:15 -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 EEFB5126C83 for ; Wed,  9 May 2018 09:15:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3756; q=dns/txt; s=iport; t=1525882515; x=1527092115; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=KdQhZdNCloK/4pKNkYz4Kr3xhtyCo0w3J+AzY0yd1Yw=; b=A9SHXhvveYW44CUdfAdg63+XkNUmF8u4M+Orz7la8Y99fqRibV0N/cpM XOHvufYnDlQGqSl4WZPkuQBrZB4BUi34LgkY5rDErXdQhSdu5fT3JLWBk Ev4s+o1bku8VgGc/zetYEQ60X67B00Uy+3lI0zbLga55ucU3lZGhTbg5N o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAwB7HfNa/xbLJq1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYUehBeIYI1jKYEPkz6BZAuEbAKDDjcVAQIBAQEBAQECbCiFKAE?= =?us-ascii?q?BAQECASMPAQU1HAsYAgImAgJXBgEMCAEBF4MIgXkIpzkRgSCCHIRYg2yCSIE?= =?us-ascii?q?JiHA/gQ8jgmiEW4MYglQCmCwIjkkGgTWDYII9hRGLK4UkgSUyIoFSMxoIGxU?= =?us-ascii?q?7gkSCHxeOGD6RVAEB?=
X-IronPort-AV: E=Sophos;i="5.49,382,1520899200";  d="scan'208";a="3682284"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 May 2018 16:15:13 +0000
Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w49GFCSA022480; Wed, 9 May 2018 16:15:12 GMT
To: Rohit R Ranade , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6B203A98@DGGEMA502-MBS.china.huawei.com> <20180509063034.iclb6vbbua5nqu6p@elstar.local> <991B70D8B4112A4699D5C00DDBBF878A6B204D26@DGGEMA502-MBS.china.huawei.com> <20180509095352.zahi7yuljb7ucd4x@elstar.local>
From: Robert Wilton 
Message-ID: <1e103670-31e9-0c20-0cfa-86526e7486d8@cisco.com>
Date: Wed, 9 May 2018 17:15:12 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <20180509095352.zahi7yuljb7ucd4x@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Query about draft-ietf-netconf-rfc7895bis-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 May 2018 16:15:17 -0000

Hi Juergen,


On 09/05/2018 10:53, Juergen Schoenwaelder wrote:
> On Wed, May 09, 2018 at 09:12:12AM +0000, Rohit R Ranade wrote:
>> On Wed, May 09, 2018 at 02:31:15AM +0000, Rohit R Ranade wrote:
>>> Hi All,
>>>
>>>
>>> 1.       "import-only-module" is currently under the "module-set" list. How does the client benefit by learning which module-set imports which modules ?
>>                All non import-only modules of the schema are implemented
>>                with their associated features and deviations.
>>
>> Modules in module-set/module are modules a datastore referencing the module set implements, modules in module-set/import-only-module are modules a datastore referencing the module set only imports from.
>>   
>>> 2.       Whether we can keep the "import-only-module" as a sibling to module-set. And let it list all the imported modules.
>> A module set is a self contained set of modules and import only modules.
>>
>> [Rohit R Ranade] One use-case I thought of was that a client was concerned with only some data-stores. So they can download the schema of only those modules and their imported modules of their data-stores of interest. But if this was the case, then the "checksum" is of no use to them, as they will not know whether their intended data-store changed or not. Is there any other use-case for the import-only-module being part of module-set ?
> The checksum indicates a change in YANG library. If a client is only
> interested in some datastore schemas, then the client may reload data
> even though the specific datastore schema did not change. There were
> versions with more checksum objects but at the end we removed them and
> kept only the one that is essential to keep. Note, if you use
> RESTCONF, then ETAGS may help with more granular checks. (In fact,
> instead of spreading checksum objects all over, it seems RESTCONF does
> not really need them and if NETCONF needs more granular chance checks,
> it seems a generic solution that can work on arbitrary subtrees is a
> better solution than spreading checksum objects everywhere.
+1 for a generic solution.

At the moment RFC 8040 states that ETAGS only apply to configuration, so 
they don't necessarily help with operational data.

Perhaps we should be introducing something like ETAG support for 
operational as well.  Although, we would need to careful consider the 
implementation performance impact.  Given that operational data may come 
from multiple daemons, it may be very hard to efficiently generate 
reliable ETAGs that span across large chunks of operational data.

Thanks,
Rob


>
> The use-case for import-only-modules being part of a module set is to
> allow a module-sets to be referential complete, i.e., different
> module-sets may have diffferent import-only-modules.
>   
>>> 4.       Also I feel the text about "netconf-capability-change" notification based on yang-library checksum should be moved to the NETCONF NMDA draft.  Is it not more suitable there ?
>> The reason is that NMDA is a very generic architectural document and as such it should not detail specifics of concrete notifications.
>> These details belong into the specific documents. The NMDA document is a root of a document dependency tree, we should not create a mesh of document dependencies.
>> [Rohit R Ranade] Please note I mentioned " should be moved to the NETCONF NMDA draft ", by which I meant draft-ietf-netconf-nmda-netconf-05, not the RFC 8342
> Sorry for my mis-understanding. YANG library defines the checksum and
> the checksum may trigger a netconf-capability-change notification, so
> this is likely why talk about the netconf-capability-change notification
> in YANG library.
>
> /js
>


From nobody Wed May  9 09:47:43 2018
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 F2281126D85 for ; Wed,  9 May 2018 09:47:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 mO9IuzEGPktP for ; Wed,  9 May 2018 09:47:40 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ACC3126BF7 for ; Wed,  9 May 2018 09:47:38 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id B105D66E; Wed,  9 May 2018 18:47:37 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Crj0W-UsVpFI; Wed,  9 May 2018 18:47:37 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed,  9 May 2018 18:47:37 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9AFE620035; Wed,  9 May 2018 18:47:37 +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 2mKkMGLRx90e; Wed,  9 May 2018 18:47:37 +0200 (CEST)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3B12620031; Wed,  9 May 2018 18:47:37 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 1A82642D16B9; Wed,  9 May 2018 18:47:35 +0200 (CEST)
Date: Wed, 9 May 2018 18:47:35 +0200
From: Juergen Schoenwaelder 
To: Robert Wilton 
Cc: Rohit R Ranade , "netmod@ietf.org" 
Message-ID: <20180509164735.nkwvt52wk76lm6p2@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , Rohit R Ranade , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6B203A98@DGGEMA502-MBS.china.huawei.com> <20180509063034.iclb6vbbua5nqu6p@elstar.local> <991B70D8B4112A4699D5C00DDBBF878A6B204D26@DGGEMA502-MBS.china.huawei.com> <20180509095352.zahi7yuljb7ucd4x@elstar.local> <1e103670-31e9-0c20-0cfa-86526e7486d8@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <1e103670-31e9-0c20-0cfa-86526e7486d8@cisco.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] Query about draft-ietf-netconf-rfc7895bis-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 May 2018 16:47:42 -0000

On Wed, May 09, 2018 at 05:15:12PM +0100, Robert Wilton wrote:
> +1 for a generic solution.
> 
> At the moment RFC 8040 states that ETAGS only apply to configuration, so
> they don't necessarily help with operational data.
> 
> Perhaps we should be introducing something like ETAG support for operational
> as well. Although, we would need to careful consider the implementation
> performance impact. Given that operational data may come from multiple
> daemons, it may be very hard to efficiently generate reliable ETAGs that
> span across large chunks of operational data.

Yes, there is fast changing data and slow changing data, there is
expensive data (in terms of instrumentation) and there is inexpensive
data. I think the solution is to let the server decide an which data
to provide etags (or something equivalent). HTTP also has all the
Cache-Control magic - I have no clue whether RESTCONF implementations
and in particular RESTCONF clients do honor HTTP caching mechanisms
and maintain local caches at the HTTP interaction level. It seems HTTP
has a lot to offer here (no surprise) and it is not clear what needs
backporting to NETCONF or whether we are better off making RESTCONF do
all the things NETCONF does - or we do both and the implementations
will ultimately decide. In the long run, maintaining two protocols
providing similar functionality does not seem to be effective.

/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  9 09:53:51 2018
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 DAECC126D85 for ; Wed,  9 May 2018 09:53:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 dmN3ejcFubSU for ; Wed,  9 May 2018 09:53:48 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4389126BF7 for ; Wed,  9 May 2018 09:53:48 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 67F5266E; Wed,  9 May 2018 18:53:47 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id ZfeqMWpJEqzo; Wed,  9 May 2018 18:53:46 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed,  9 May 2018 18:53:47 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2BE7520035; Wed,  9 May 2018 18:53:47 +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 QXOLwvbca5EW; Wed,  9 May 2018 18:53:46 +0200 (CEST)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E35EA20031; Wed,  9 May 2018 18:53:46 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id C1F2942D172B; Wed,  9 May 2018 18:53:46 +0200 (CEST)
Date: Wed, 9 May 2018 18:53:46 +0200
From: Juergen Schoenwaelder 
To: Robert Wilton 
Cc: Rohit R Ranade , "netmod@ietf.org" 
Message-ID: <20180509165346.yfgnqoew6jbk32x5@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , Rohit R Ranade , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6B203A98@DGGEMA502-MBS.china.huawei.com> <20180509063034.iclb6vbbua5nqu6p@elstar.local> <991B70D8B4112A4699D5C00DDBBF878A6B204D26@DGGEMA502-MBS.china.huawei.com> <20180509095352.zahi7yuljb7ucd4x@elstar.local> <1e103670-31e9-0c20-0cfa-86526e7486d8@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1e103670-31e9-0c20-0cfa-86526e7486d8@cisco.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] Query about draft-ietf-netconf-rfc7895bis-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 May 2018 16:53:50 -0000

On Wed, May 09, 2018 at 05:15:12PM +0100, Robert Wilton wrote:
> 
> At the moment RFC 8040 states that ETAGS only apply to configuration, so
> they don't necessarily help with operational data.
>

Do you refer to this:

   The server MUST maintain an entity-tag for the top-level
   {+restconf}/data resource.  This entity-tag is only affected by
   configuration data resources and MUST NOT be updated for changes to
   non-configuration data.

Well, this talks about {+restconf}/data and specifically the top-level
resource and draft-ietf-netconf-nmda-restconf-04.txt seems to be silent
about entity-tags for {+restconf}/ds/ resources...

/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  9 10:01:17 2018
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 3C19C1275F4 for ; Wed,  9 May 2018 10:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.611
X-Spam-Level: 
X-Spam-Status: No, score=-12.611 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 137SuvjXSjOv for ; Wed,  9 May 2018 10:01:14 -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 6E5141200F1 for ; Wed,  9 May 2018 10:01:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2402; q=dns/txt; s=iport; t=1525885274; x=1527094874; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=dATP6C6XRs7MPILcEr9DcTcAE3yFOCj93YtC9dEWI8Q=; b=EmKxXRib/OGbMoCFjtRoYP0vG7AA3W8KKaIyWepyh/MUFnOXYDk8a9x/ gcTTHwWcqMVet0i3FegzED3rLoMmEzFFNO8zhjIOukFofrYfhgGqqtYrb BCQqePpZXV++3j3Y+pas1ZVmg+FaOzoiwoGTBSrSqKlg20QmrD5zLsaUl A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAwBTKPNa/xbLJq1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYMUgRB6hBeIYI1jKYEPkyqBeAuEbAKDDjYWAQIBAQEBAQECbCi?= =?us-ascii?q?FKAEBAQECASMPAQVGCwsYAgImAgJXBgEMCAEBF4MIAoF3CKkAghyEWINtgki?= =?us-ascii?q?BCYhwP4EPI4JohF2DFoJUApgsCI5JBoE1hh2FEYdCg2mFJIElIwEwgVIzGgg?= =?us-ascii?q?bFYJ/kE4+kVQBAQ?=
X-IronPort-AV: E=Sophos;i="5.49,382,1520899200";  d="scan'208";a="3737424"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 May 2018 17:01:12 +0000
Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w49H1C0x030890; Wed, 9 May 2018 17:01:12 GMT
To: Rohit R Ranade , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6B203A98@DGGEMA502-MBS.china.huawei.com> <20180509063034.iclb6vbbua5nqu6p@elstar.local> <991B70D8B4112A4699D5C00DDBBF878A6B204D26@DGGEMA502-MBS.china.huawei.com> <20180509095352.zahi7yuljb7ucd4x@elstar.local> <1e103670-31e9-0c20-0cfa-86526e7486d8@cisco.com> <20180509164735.nkwvt52wk76lm6p2@elstar.local>
From: Robert Wilton 
Message-ID: 
Date: Wed, 9 May 2018 18:01:12 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <20180509164735.nkwvt52wk76lm6p2@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Query about draft-ietf-netconf-rfc7895bis-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 May 2018 17:01:16 -0000

On 09/05/2018 17:47, Juergen Schoenwaelder wrote:
> On Wed, May 09, 2018 at 05:15:12PM +0100, Robert Wilton wrote:
>> +1 for a generic solution.
>>
>> At the moment RFC 8040 states that ETAGS only apply to configuration, so
>> they don't necessarily help with operational data.
>>
>> Perhaps we should be introducing something like ETAG support for operational
>> as well.  Although, we would need to careful consider the implementation
>> performance impact.  Given that operational data may come from multiple
>> daemons, it may be very hard to efficiently generate reliable ETAGs that
>> span across large chunks of operational data.
> Yes, there is fast changing data and slow changing data, there is
> expensive data (in terms of instrumentation) and there is inexpensive
> data. I think the solution is to let the server decide an which data
> to provide etags (or something equivalent).
This sounds like a reasonable starting point.

>   HTTP also has all the
> Cache-Control magic - I have no clue whether RESTCONF implementations
> and in particular RESTCONF clients do honor HTTP caching mechanisms
> and maintain local caches at the HTTP interaction level.
I don't know either.

>   It seems HTTP
> has a lot to offer here (no surprise) and it is not clear what needs
> backporting to NETCONF or whether we are better off making RESTCONF do
> all the things NETCONF does - or we do both and the implementations
> will ultimately decide. In the long run, maintaining two protocols
> providing similar functionality does not seem to be effective.
I think that having the flexibility of a binary encoding is likely to 
become more important over time, particularly for dynamic configuration, 
or streaming telemetry.  From the previous discussions, it looks almost 
trivial to add binary encoding support into RESTCONF, but a lot of work 
to add it to NETCONF.

One thing that I prefer in RESTCONF is being able to provide a config 
update as a single tree update that includes both merge and delete 
operations as annotations within the tree.  This seems like an efficient 
way to generate and send a delta of a configuration from a client to the 
server.

But possibly a useful discussion to have may be what the members of the 
NETCONF WG perceives is the future for the IETF network management 
protocols.

Thanks,
Rob

>
> /js
>


From nobody Wed May  9 11:38:49 2018
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 88BCF12DA42; Wed,  9 May 2018 11:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDuyqCjsL63V; Wed,  9 May 2018 11:38:30 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 C19E912DA4C; Wed,  9 May 2018 11:38:30 -0700 (PDT)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w49HtEgl001738; Wed, 9 May 2018 10:57:47 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=eTDH6LwaP29K3Ni91vc9/zER6p7J/W48R+9G0ci2PrU=; b=y6YkkagZx5Vj5yevdhDcbsq6bIEb09DkMOagbO33QzbxpJjziXKTaves/Q7LX+OQsGqa 5dgDoVhUfhPMVwOiuaU1/c2GhYZRG4k+WwLXioEvMdb2DSysA5M5QZQKKVfeIr4SNvka N0whh6A8lR/Ykmv4lugnFQNAnQMv7SUO8p5RC4jzl3kvtLmXPp7lrJxJHAedOwcY0jH+ GjM/blOLbSla4w9ur3lOaz8FUWfMTZN+yHejV04JRTJgnDtb3ASwI2XouP1grw1MyRfQ ZwMMpbDNS4IND8fWNjAARjptaHvo8n8O1x0ctQl70lCaycY/gzvXV2qEPlAr3LE67OO7 fw== 
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0087.outbound.protection.outlook.com [207.46.163.87]) by mx0a-00273201.pphosted.com with ESMTP id 2hv375gbej-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 09 May 2018 10:57:47 -0700
Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4390.namprd05.prod.outlook.com (52.135.202.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.755.10; Wed, 9 May 2018 17:57:44 +0000
Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::5c50:c79f:dbd0:7a9a]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::5c50:c79f:dbd0:7a9a%13]) with mapi id 15.20.0755.012; Wed, 9 May 2018 17:57:44 +0000
From: Kent Watsen 
To: Robert Wilton , Rohit R Ranade , "netmod@ietf.org" 
CC: "netconf@ietf.org" 
Thread-Topic: [netmod] Query about draft-ietf-netconf-rfc7895bis-06
Thread-Index: AQHT519EfXff3JwfEEO4oZoD0HXP46QnHOIAgAALpACAAGqLAIAACQ2AgAADzgD//8y8gA==
Date: Wed, 9 May 2018 17:57:44 +0000
Message-ID: 
References: <991B70D8B4112A4699D5C00DDBBF878A6B203A98@DGGEMA502-MBS.china.huawei.com> <20180509063034.iclb6vbbua5nqu6p@elstar.local> <991B70D8B4112A4699D5C00DDBBF878A6B204D26@DGGEMA502-MBS.china.huawei.com> <20180509095352.zahi7yuljb7ucd4x@elstar.local> <1e103670-31e9-0c20-0cfa-86526e7486d8@cisco.com> <20180509164735.nkwvt52wk76lm6p2@elstar.local> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB4390; 7:F3FA82jtmTPKfyZXdvDRxsZ2fHussv3VJ0nlq3w2bJLha1DIR4Z0aG6zR6t2T2QBdlNOqw+bBfT33+65kviRA7L1b3frbmT+sxGplfUB3wFjFQkpYTbRXez4yOKHCQJMhMLzSfER5J4QbiIe7rD8vtD6Uegf1QFOxAGIHAu5o+8zh7yBckWkCWdEmnWzMnnVJvdcSMG0wsaFCXxDesein2PYp55VyxQYlIyT+vpyf2/0JoACbh/k66cQcjdzhzUt
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4390; 
x-ms-traffictypediagnostic: BYAPR05MB4390:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:BYAPR05MB4390; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4390; 
x-forefront-prvs: 0667289FF8
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(39380400002)(39860400002)(366004)(376002)(189003)(199004)(5250100002)(81156014)(81166006)(99286004)(186003)(76176011)(2501003)(8676002)(6506007)(33656002)(6116002)(106356001)(5660300001)(105586002)(102836004)(93886005)(4326008)(3846002)(229853002)(6436002)(476003)(2616005)(53936002)(83716003)(6246003)(8936002)(68736007)(97736004)(36756003)(86362001)(82746002)(2906002)(478600001)(58126008)(446003)(3280700002)(2900100001)(26005)(3660700001)(316002)(305945005)(7736002)(66066001)(6512007)(14454004)(11346002)(6486002)(110136005)(25786009)(486006); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4390; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: VNa3kNRuoW66hhnZ3y5m1WHhnY+VI0p+vhoN5pIZ9FJ51+0lIT8EFtzLGBxhThPtxmzgTd+1DhvxE+/H/Z6fw3NFUtgxk0A9Zr5GE9FrkbMGUj8hdZSAJLx43Q9Hd65SlDdaUGBsLsRnLGtm43Tj2b18g0HffRGXpPr6ny7HsJVkcAUrlBex4Wa8o0Tum9io
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <99D7C56F8727074F82B7355D62B6597A@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 1d3b0ce7-5845-4b0f-1725-08d5b5d65e00
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 1d3b0ce7-5845-4b0f-1725-08d5b5d65e00
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2018 17:57:44.7017 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4390
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-09_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=660 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805090168
Archived-At: 
Subject: Re: [netmod] Query about draft-ietf-netconf-rfc7895bis-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 May 2018 18:38:39 -0000

WytuZXRjb25mLCBzaW5jZSB0aGlzIGRpc2N1c3Npb24gcmVnYXJkcyBhIG5ldGNvbmYgZHJhZnRd
DQoNCj4gQnV0IHBvc3NpYmx5IGEgdXNlZnVsIGRpc2N1c3Npb24gdG8gaGF2ZSBtYXkgYmUgd2hh
dCB0aGUgbWVtYmVycyBvZiB0aGUgDQo+IE5FVENPTkYgV0cgcGVyY2VpdmVzIGlzIHRoZSBmdXR1
cmUgZm9yIHRoZSBJRVRGIG5ldHdvcmsgbWFuYWdlbWVudCANCj4gcHJvdG9jb2xzLg0KDQpJJ20g
YW4gYWR2b2NhdGUgZm9yIFJFU1RDT05GIGJlaW5nIGFzIGNhcGFibGUgYXMgTkVUQ09ORiwgYW5k
IHBlcmhhcHMNCm1vcmUgY2FwYWJsZSAoZS5nLiwgYmluYXJ5IGVuY29kaW5nLCBldGFncywgZXRj
LikuDQoNCkl0IHdvdWxkIGJlIG5pY2UgdG8gY29uc29saWRhdGUgb24gb25lIHByb3RvY29sLCBi
dXQgSSBkb24ndCBrbm93IGhvdw0KbWFya2V0IGZvcmNlcyB3b3VsZCBldmVyIGFsbG93IHVzIHRv
IGRvIHRoYXQuLi4NCg0KS2VudCAvLyBjb250cmlidXRvcg0KDQoNCg==


From nobody Thu May 10 10:07:33 2018
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 D593912EB73 for ; Thu, 10 May 2018 10:07:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6cWVTpiBtcW for ; Thu, 10 May 2018 10:07:26 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0091.outbound.protection.outlook.com [104.47.1.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FD512EB94 for ; Thu, 10 May 2018 10:07:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IJ/zh9YyYX4YmKCuAOs9Mi2AB4wR8HyUv25G2voijgk=; b=UHIl42KOPb8nhRq42KlTevqMM38+cAyDzTnbr6HtNEiPtjfrl0aBlxmz2HdXW3V/+WBYPkZCsm/4MatBaDAVuW9WmPft1/gMB0UrLh9VvMO/z6WIdjQFfY/IsEC5OErBnPu8pxrgcaE/+Rkvn1L2SJ0exfOAiOYPnDkmSUWcI3E=
Received: from AM0PR07MB3844.eurprd07.prod.outlook.com (52.134.82.20) by AM0PR07MB4050.eurprd07.prod.outlook.com (52.134.83.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.10; Thu, 10 May 2018 17:07:23 +0000
Received: from AM0PR07MB3844.eurprd07.prod.outlook.com ([fe80::c65:ce3c:f99e:3132]) by AM0PR07MB3844.eurprd07.prod.outlook.com ([fe80::c65:ce3c:f99e:3132%3]) with mapi id 15.20.0755.012; Thu, 10 May 2018 17:07:23 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" 
To: "netmod@ietf.org" 
Thread-Topic: NMDA - different valid keys for config vs state
Thread-Index: AdPogD1+2NIcwEznSqKvxUfMt6AfTA==
Date: Thu, 10 May 2018 17:07:23 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jason.sterne@nokia.com; 
x-originating-ip: [135.245.20.0]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB4050; 7:gBlZMvwDD2mTl56nsRpYqoCzCOelqcBIaS0kJF0eS7a5xSP9HdcWtZISJ7z1Lv+btH9+AH8INfzbq2d3pk2O+D7xziB7mhd1mthmV7pvxVRvOLGb73lfV/IGeAO7AHCZUJZKptI7jaUiEKyri3PdB+6Uq+j7VzNiUzb0TvzbK3ucOfZ8To3+ZoND2m4f3fjE3srK8SnHVq80dh0YYPGd7KPrUmVI3fAsQFubfHX+v133d8SmlyhehGVb0hUeoNbV
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(48565401081)(2017052603328)(7193020); SRVR:AM0PR07MB4050; 
x-ms-traffictypediagnostic: AM0PR07MB4050:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231254)(11241501184)(806099)(944501410)(52105095)(93006095)(93001095)(3002001)(6055026)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:AM0PR07MB4050; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB4050; 
x-forefront-prvs: 066898046A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(396003)(39860400002)(346002)(376002)(366004)(199004)(189003)(53754006)(186003)(81156014)(81166006)(6436002)(7736002)(1730700003)(86362001)(316002)(26005)(74316002)(8676002)(68736007)(55016002)(6506007)(2351001)(106356001)(486006)(105586002)(102836004)(478600001)(476003)(3660700001)(33656002)(3280700002)(2501003)(6916009)(6116002)(2900100001)(790700001)(54896002)(6306002)(7696005)(3846002)(5660300001)(53936002)(5630700001)(25786009)(97736004)(14454004)(66066001)(2906002)(99286004)(8936002)(5250100002)(5640700003)(9686003)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4050; H:AM0PR07MB3844.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: pTxx3UcH57yL8laWDYIGSq7QM8dqQOJZe0qFT574W+X3HzKC1+Jni+AhUT/BLstRAxeUYhp01djIJwPlTGWGs1q7VRKTKu+it6dRNqge8LJ2/EI8XYyaG5ehihtM4/rNF0uA36MvXVJ7OohAsqb70dBcuxkV3jsUGev9ekEs0S80DJX9cqSGZj687jTtZe++sv426UXLlv2SJI1r8K2rtGHx+eZe9bfLplXhAXt2Vwo=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM0PR07MB3844939D2446BE899F0B06439B980AM0PR07MB3844eurp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 321bb1f5-fe78-4281-a60b-08d5b6987fac
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 321bb1f5-fe78-4281-a60b-08d5b6987fac
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2018 17:07:23.5267 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4050
Archived-At: 
Subject: [netmod] NMDA - different valid keys for config vs state
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 May 2018 17:07:31 -0000

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

Hi all,

In the NMDA approach we're trying to combine config & state into the same c=
ommon tree structure.   i.e. For a given list, model a single list that con=
tains both config & state, vs separate lists for each of config & state.

But what happens when the valid value space for config vs state is differen=
t ?   For example -> what if an implementation has internally created inter=
faces with names that start with '_internal_' and doesn't allow configurati=
on of those interfaces ?

If there were separate config vs state lists then the config list may have =
a pattern associated with the key that disallows names that start with '_in=
ternal_'.

To keep the spirit of NMDA it would be a shame to split into separate confi=
g & state lists for this case.  Any recommendations ?

1) make the 'pattern' for the key be a superset (i.e. allow _internal_) and=
 then just reject config requests for _internal_ interfaces (e.g. at commit=
 time) ?

2) make the 'pattern' more strict to match config, and then return _interna=
l_ interfaces for state queries (that in theory break the pattern for the k=
ey) ?

3) other suggestions ?

Another example could be an integer key that has a larger range for state t=
han it does for config (i.e. IDs >1000 are for internal entries only, not c=
onfigurable).

Rgds,
Jason

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











Hi all,


 


In the NMDA approach we're tryi=
ng to combine config & state into the same common tree structure. =
  i.e. For a given list, model a single list that contains both config=
 & state, vs separate lists for each of config & state.<=
/span>


 


But what happens when the valid=
 value space for config vs state is different ?   For example -&g=
t; what if an implementation has internally created interfaces with names t=
hat start with '_internal_' and doesn't allow
 configuration of those interfaces ?


 


If there were separate config v=
s state lists then the config list may have a pattern associated with the k=
ey that disallows names that start with '_internal_'.


 


To keep the spirit of NMDA it w=
ould be a shame to split into separate config & state lists for this ca=
se.  Any recommendations ?


 


1) make the 'pattern' for the k=
ey be a superset (i.e. allow _internal_) and then just reject config=
 requests for _internal_ interfaces (e.g. at commit time) ?


 


2) make the 'pattern' more stri=
ct to match config, and then return _internal_ interfaces for state =
queries (that in theory break the pattern for the key) ?<=
/p>

 


3) other suggestions ?


 


Another example could be an int=
eger key that has a larger range for state than it does for config (i.e. ID=
s >1000 are for internal entries only, not configurable).


 


Rgds,


Jason






--_000_AM0PR07MB3844939D2446BE899F0B06439B980AM0PR07MB3844eurp_--


From nobody Thu May 10 10:23:49 2018
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 EA5CD12D95E for ; Thu, 10 May 2018 10:23:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MD-u51ZinDw for ; Thu, 10 May 2018 10:23:46 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6807D124B17 for ; Thu, 10 May 2018 10:23:46 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 3A3F66B6; Thu, 10 May 2018 19:23:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id cRymVMiC3207; Thu, 10 May 2018 19:23:44 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 10 May 2018 19:23:45 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 213B520035; Thu, 10 May 2018 19:23:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 66X6veT2QCTm; Thu, 10 May 2018 19:23:44 +0200 (CEST)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B02320031; Thu, 10 May 2018 19:23:44 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 6E77842DF649; Thu, 10 May 2018 19:23:43 +0200 (CEST)
Date: Thu, 10 May 2018 19:23:43 +0200
From: Juergen Schoenwaelder 
To: "Sterne, Jason (Nokia - CA/Ottawa)" 
Cc: "netmod@ietf.org" 
Message-ID: <20180510172343.2uvlur2o2ypodbmk@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] NMDA - different valid keys for config vs state
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 May 2018 17:23:49 -0000

On Thu, May 10, 2018 at 05:07:23PM +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote:
> Hi all,
> 
> In the NMDA approach we're trying to combine config & state into the same common tree structure.   i.e. For a given list, model a single list that contains both config & state, vs separate lists for each of config & state.
>

NMDA uses different datastores, only configured leafs appear in the
configuration datastores.

> But what happens when the valid value space for config vs state is different ?   For example -> what if an implementation has internally created interfaces with names that start with '_internal_' and doesn't allow configuration of those interfaces ?

These interfaces will appear in  but not in  and
. They will also have a proper origin tag.
 
> If there were separate config vs state lists then the config list may have a pattern associated with the key that disallows names that start with '_internal_'.

Oh, you are concerned about your implementation not allowing
_internal_ for a configured interface? Well, in that case, I think the
server needs to reject the creation of such an interface.
 
> To keep the spirit of NMDA it would be a shame to split into separate config & state lists for this case.  Any recommendations ?
> 
> 1) make the 'pattern' for the key be a superset (i.e. allow _internal_) and then just reject config requests for _internal_ interfaces (e.g. at commit time) ?

This seems the way to go. The loopback interface is often system
created and it is commonly called 'lo' or something like this. I
assume a server will reject a request to create an interface named
'lo' which is a vlan interface on top of an ethernet interface.
Looking at RFC 7223, I found that the description of
/interfaces/interface/name talks quite a bit about the fact that a
system may put restrictions on the names that are accepted.

> 2) make the 'pattern' more strict to match config, and then return _internal_ interfaces for state queries (that in theory break the pattern for the key) ?

I think the type of key leafs should allow all possible key values.

> 3) other suggestions ?

With the new YANG library, I think one could have a deviation that
narrows down the type for the configuration datastore schemas. But
then people do not like deviations...

> Another example could be an integer key that has a larger range for state than it does for config (i.e. IDs >1000 are for internal entries only, not configurable).

Perhaps concrete text in the description statement is the simplest
solution.

/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 10 10:27:58 2018
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 8EA2B12DA46 for ; Thu, 10 May 2018 10:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level: 
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRx3MEyjeOjv for ; Thu, 10 May 2018 10:27:54 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1118512DA25 for ; Thu, 10 May 2018 10:27:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12422; q=dns/txt; s=iport; t=1525973273; x=1527182873; h=from:to:subject:date:message-id:mime-version; bh=PyINzse/smplJl/f7p+9PdVfF1bENNlZzbJQm/AU80U=; b=L8WLQAJKOPOJqMbcT9i8jltU3k83OUNQB5C41ruLBGzww6fZY70QJ70z HtvzS4htkeyfhkJYmOChuN36VhctGrPs6sFOv0MuZVNvRxh2L3yFtEZUw ukZ/DEAOr/tie5JqjMheiG22DssoPNxk5m/lNXoOrIhrz/fMVD0WHaMyJ 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAQBggPRa/4gNJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJNdmF7KAqDZ4gDjG2BeYEPjjyEdxSBZAsshEAcgmYhNBg?= =?us-ascii?q?BAgEBAQEBAQJsKIUoAQYjBGQBCBEDAQIrAgQwHQoEARKDIwKBG2SrVYFpM4h?= =?us-ascii?q?EgkiIJYFUP4EPI4JohEABEgE/gmAwgiQCiCCIY4cqCQKOTYxlgiuOBAIREwG?= =?us-ascii?q?BJAEcOGFxcBU7KgGCGAmQRW+BFYxsgR8BgRcBAQ?=
X-IronPort-AV: E=Sophos;i="5.49,386,1520899200";  d="scan'208,217";a="390394374"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2018 17:27:52 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w4AHRqSG029570 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 10 May 2018 17:27:52 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 10 May 2018 12:27:51 -0500
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1320.000; Thu, 10 May 2018 12:27:51 -0500
From: "Reshad Rahman (rrahman)" 
To: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" 
Thread-Topic: [netmod] NMDA - different valid keys for config vs state
Thread-Index: AQHT6IQ52NIcwEznSqKvxUfMt6AfTA==
Date: Thu, 10 May 2018 17:27:51 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.212.63]
Content-Type: multipart/alternative; boundary="_000_F9CB1241DC5A48AB97A188AD3D83E8BBciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] NMDA - different valid keys for config vs state
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 May 2018 17:27:57 -0000

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

SSB0aG91Z2h0IHRoaXMgaGFkIGJlZW4gZGlzY3Vzc2VkIHByZXZpb3VzbHkgYnV0IGNvdWxkbuKA
mXQgZmluZCB0aGUgZW1haWwuDQoNCklNTyAgb3B0aW9uIDEpIG1ha2VzIG1vcmUgc2Vuc2UsIHRo
ZSBrZXkgcmFuZ2Ugc2hvdWxkIGJlIGEgc3VwZXJzZXQgb2YgY29uZmlnIGFuZCBvcGVyIHNpbmNl
IHRoZSBtb2RlbCBhcHBsaWVzIHRvIGJvdGguIERvbuKAmXQga25vdyBpZiB0aGVyZeKAmXMgYW55
IG1lY2hhbmlzbSB3aGljaCBhbGxvd3MgZm9yIGRpZmZlcmVudCByYW5nZSBwZXIgZGF0YXN0b3Jl
Lg0KDQpSZWdhcmRzLA0KUmVzaGFkLg0KDQpGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGll
dGYub3JnPiBvbiBiZWhhbGYgb2YgIlN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EvT3R0YXdhKSIg
PGphc29uLnN0ZXJuZUBub2tpYS5jb20+DQpEYXRlOiBUaHVyc2RheSwgTWF5IDEwLCAyMDE4IGF0
IDE6MDcgUE0NClRvOiAibmV0bW9kQGlldGYub3JnIiA8bmV0bW9kQGlldGYub3JnPg0KU3ViamVj
dDogW25ldG1vZF0gTk1EQSAtIGRpZmZlcmVudCB2YWxpZCBrZXlzIGZvciBjb25maWcgdnMgc3Rh
dGUNCg0KSGkgYWxsLA0KDQpJbiB0aGUgTk1EQSBhcHByb2FjaCB3ZSdyZSB0cnlpbmcgdG8gY29t
YmluZSBjb25maWcgJiBzdGF0ZSBpbnRvIHRoZSBzYW1lIGNvbW1vbiB0cmVlIHN0cnVjdHVyZS4g
ICBpLmUuIEZvciBhIGdpdmVuIGxpc3QsIG1vZGVsIGEgc2luZ2xlIGxpc3QgdGhhdCBjb250YWlu
cyBib3RoIGNvbmZpZyAmIHN0YXRlLCB2cyBzZXBhcmF0ZSBsaXN0cyBmb3IgZWFjaCBvZiBjb25m
aWcgJiBzdGF0ZS4NCg0KQnV0IHdoYXQgaGFwcGVucyB3aGVuIHRoZSB2YWxpZCB2YWx1ZSBzcGFj
ZSBmb3IgY29uZmlnIHZzIHN0YXRlIGlzIGRpZmZlcmVudCA/ICAgRm9yIGV4YW1wbGUgLT4gd2hh
dCBpZiBhbiBpbXBsZW1lbnRhdGlvbiBoYXMgaW50ZXJuYWxseSBjcmVhdGVkIGludGVyZmFjZXMg
d2l0aCBuYW1lcyB0aGF0IHN0YXJ0IHdpdGggJ19pbnRlcm5hbF8nIGFuZCBkb2Vzbid0IGFsbG93
IGNvbmZpZ3VyYXRpb24gb2YgdGhvc2UgaW50ZXJmYWNlcyA/DQoNCklmIHRoZXJlIHdlcmUgc2Vw
YXJhdGUgY29uZmlnIHZzIHN0YXRlIGxpc3RzIHRoZW4gdGhlIGNvbmZpZyBsaXN0IG1heSBoYXZl
IGEgcGF0dGVybiBhc3NvY2lhdGVkIHdpdGggdGhlIGtleSB0aGF0IGRpc2FsbG93cyBuYW1lcyB0
aGF0IHN0YXJ0IHdpdGggJ19pbnRlcm5hbF8nLg0KDQpUbyBrZWVwIHRoZSBzcGlyaXQgb2YgTk1E
QSBpdCB3b3VsZCBiZSBhIHNoYW1lIHRvIHNwbGl0IGludG8gc2VwYXJhdGUgY29uZmlnICYgc3Rh
dGUgbGlzdHMgZm9yIHRoaXMgY2FzZS4gIEFueSByZWNvbW1lbmRhdGlvbnMgPw0KDQoxKSBtYWtl
IHRoZSAncGF0dGVybicgZm9yIHRoZSBrZXkgYmUgYSBzdXBlcnNldCAoaS5lLiBhbGxvdyBfaW50
ZXJuYWxfKSBhbmQgdGhlbiBqdXN0IHJlamVjdCBjb25maWcgcmVxdWVzdHMgZm9yIF9pbnRlcm5h
bF8gaW50ZXJmYWNlcyAoZS5nLiBhdCBjb21taXQgdGltZSkgPw0KDQoyKSBtYWtlIHRoZSAncGF0
dGVybicgbW9yZSBzdHJpY3QgdG8gbWF0Y2ggY29uZmlnLCBhbmQgdGhlbiByZXR1cm4gX2ludGVy
bmFsXyBpbnRlcmZhY2VzIGZvciBzdGF0ZSBxdWVyaWVzICh0aGF0IGluIHRoZW9yeSBicmVhayB0
aGUgcGF0dGVybiBmb3IgdGhlIGtleSkgPw0KDQozKSBvdGhlciBzdWdnZXN0aW9ucyA/DQoNCkFu
b3RoZXIgZXhhbXBsZSBjb3VsZCBiZSBhbiBpbnRlZ2VyIGtleSB0aGF0IGhhcyBhIGxhcmdlciBy
YW5nZSBmb3Igc3RhdGUgdGhhbiBpdCBkb2VzIGZvciBjb25maWcgKGkuZS4gSURzID4xMDAwIGFy
ZSBmb3IgaW50ZXJuYWwgZW50cmllcyBvbmx5LCBub3QgY29uZmlndXJhYmxlKS4NCg0KUmdkcywN
Ckphc29uDQo=

--_000_F9CB1241DC5A48AB97A188AD3D83E8BBciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <4248163FE86B454AA6D0DB2B6A6137AA@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj
OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t
c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z
ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls
ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm
Ow0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6
bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K
CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3
OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT
ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJv
ZHkgbGFuZz0iRU4tQ0EiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xh
c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s
b3I6YmxhY2siPkkgdGhvdWdodCB0aGlzIGhhZCBiZWVuIGRpc2N1c3NlZCBwcmV2aW91c2x5IGJ1
dCBjb3VsZG7igJl0IGZpbmQgdGhlIGVtYWlsLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6
YmxhY2siPklNTyAmbmJzcDtvcHRpb24gMSkgbWFrZXMgbW9yZSBzZW5zZSwgdGhlIGtleSByYW5n
ZSBzaG91bGQgYmUgYSBzdXBlcnNldCBvZiBjb25maWcgYW5kIG9wZXIgc2luY2UgdGhlIG1vZGVs
IGFwcGxpZXMgdG8gYm90aC4gRG9u4oCZdCBrbm93IGlmIHRoZXJl4oCZcyBhbnkgbWVjaGFuaXNt
IHdoaWNoIGFsbG93cyBmb3IgZGlmZmVyZW50IHJhbmdlIHBlciBkYXRhc3RvcmUuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs
YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SZXNoYWQuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0
O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu
MHB0O2NvbG9yOmJsYWNrIj5uZXRtb2QgJmx0O25ldG1vZC1ib3VuY2VzQGlldGYub3JnJmd0OyBv
biBiZWhhbGYgb2YgJnF1b3Q7U3Rlcm5lLCBKYXNvbiAoTm9raWEgLSBDQS9PdHRhd2EpJnF1b3Q7
ICZsdDtqYXNvbi5zdGVybmVAbm9raWEuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2Rh
eSwgTWF5IDEwLCAyMDE4IGF0IDE6MDcgUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90O25ldG1vZEBp
ZXRmLm9yZyZxdW90OyAmbHQ7bmV0bW9kQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwv
Yj5bbmV0bW9kXSBOTURBIC0gZGlmZmVyZW50IHZhbGlkIGtleXMgZm9yIGNvbmZpZyB2cyBzdGF0
ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
YSBuYW1lPSJfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIGFsbCw8L3Nw
YW4+PG86cD48L286cD48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBsYW5nPSJFTi1V
UyI+SW4gdGhlIE5NREEgYXBwcm9hY2ggd2UncmUgdHJ5aW5nIHRvIGNvbWJpbmUgY29uZmlnICZh
bXA7IHN0YXRlIGludG8gdGhlIHNhbWUgY29tbW9uIHRyZWUgc3RydWN0dXJlLiZuYnNwOyZuYnNw
OyBpLmUuIEZvciBhIGdpdmVuIGxpc3QsIG1vZGVsIGEgc2luZ2xlIGxpc3QgdGhhdCBjb250YWlu
cyBib3RoIGNvbmZpZyAmYW1wOyBzdGF0ZSwNCiB2cyBzZXBhcmF0ZSBsaXN0cyBmb3IgZWFjaCBv
ZiBjb25maWcgJmFtcDsgc3RhdGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv
ZHkiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y
aWdpbmFsQm9keSI+PHNwYW4gbGFuZz0iRU4tVVMiPkJ1dCB3aGF0IGhhcHBlbnMgd2hlbiB0aGUg
dmFsaWQgdmFsdWUgc3BhY2UgZm9yIGNvbmZpZyB2cyBzdGF0ZSBpcyBkaWZmZXJlbnQgPyZuYnNw
OyZuYnNwOyBGb3IgZXhhbXBsZSAtJmd0OyB3aGF0IGlmIGFuIGltcGxlbWVudGF0aW9uIGhhcyBp
bnRlcm5hbGx5IGNyZWF0ZWQgaW50ZXJmYWNlcyB3aXRoIG5hbWVzIHRoYXQNCiBzdGFydCB3aXRo
ICdfPGk+aW50ZXJuYWw8L2k+XycgYW5kIGRvZXNuJ3QgYWxsb3cgY29uZmlndXJhdGlvbiBvZiB0
aG9zZSBpbnRlcmZhY2VzID88L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+
PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu
YWxCb2R5Ij48c3BhbiBsYW5nPSJFTi1VUyI+SWYgdGhlcmUgd2VyZSBzZXBhcmF0ZSBjb25maWcg
dnMgc3RhdGUgbGlzdHMgdGhlbiB0aGUgY29uZmlnIGxpc3QgbWF5IGhhdmUgYSBwYXR0ZXJuIGFz
c29jaWF0ZWQgd2l0aCB0aGUga2V5IHRoYXQgZGlzYWxsb3dzIG5hbWVzIHRoYXQgc3RhcnQgd2l0
aCAnXzxpPmludGVybmFsPC9pPl8nLjwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC
b2R5Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP
cmlnaW5hbEJvZHkiPjxzcGFuIGxhbmc9IkVOLVVTIj5UbyBrZWVwIHRoZSBzcGlyaXQgb2YgTk1E
QSBpdCB3b3VsZCBiZSBhIHNoYW1lIHRvIHNwbGl0IGludG8gc2VwYXJhdGUgY29uZmlnICZhbXA7
IHN0YXRlIGxpc3RzIGZvciB0aGlzIGNhc2UuJm5ic3A7IEFueSByZWNvbW1lbmRhdGlvbnMgPzwv
c3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBsYW5nPSJFTi1VUyI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIGxhbmc9
IkVOLVVTIj4xKSBtYWtlIHRoZSAncGF0dGVybicgZm9yIHRoZSBrZXkgYmUgYSBzdXBlcnNldCAo
aS5lLiBhbGxvdyBfPGk+aW50ZXJuYWw8L2k+XykgYW5kIHRoZW4ganVzdCByZWplY3QgY29uZmln
IHJlcXVlc3RzIGZvciBfPGk+aW50ZXJuYWw8L2k+XyBpbnRlcmZhY2VzIChlLmcuIGF0IGNvbW1p
dCB0aW1lKSA/PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIGxh
bmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+
PHNwYW4gbGFuZz0iRU4tVVMiPjIpIG1ha2UgdGhlICdwYXR0ZXJuJyBtb3JlIHN0cmljdCB0byBt
YXRjaCBjb25maWcsIGFuZCB0aGVuIHJldHVybiBfPGk+aW50ZXJuYWw8L2k+XyBpbnRlcmZhY2Vz
IGZvciBzdGF0ZSBxdWVyaWVzICh0aGF0IGluIHRoZW9yeSBicmVhayB0aGUgcGF0dGVybiBmb3Ig
dGhlIGtleSkgPzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBs
YW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki
PjxzcGFuIGxhbmc9IkVOLVVTIj4zKSBvdGhlciBzdWdnZXN0aW9ucyA/PC9zcGFuPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9v
a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gbGFuZz0iRU4tVVMiPkFub3Ro
ZXIgZXhhbXBsZSBjb3VsZCBiZSBhbiBpbnRlZ2VyIGtleSB0aGF0IGhhcyBhIGxhcmdlciByYW5n
ZSBmb3Igc3RhdGUgdGhhbiBpdCBkb2VzIGZvciBjb25maWcgKGkuZS4gSURzICZndDsxMDAwIGFy
ZSBmb3IgaW50ZXJuYWwgZW50cmllcyBvbmx5LCBub3QgY29uZmlndXJhYmxlKS48L3NwYW4+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z
by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwv
c3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBsYW5nPSJFTi1VUyI+
Umdkcyw8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gbGFuZz0i
RU4tVVMiPkphc29uPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5
Pg0KPC9odG1sPg0K

--_000_F9CB1241DC5A48AB97A188AD3D83E8BBciscocom_--


From nobody Fri May 11 01:22:35 2018
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 A0D0512E87B for ; Fri, 11 May 2018 01:22:34 -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 vHSrFZlLA7UU for ; Fri, 11 May 2018 01:22:31 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 54FBE12E874 for ; Fri, 11 May 2018 01:22:31 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id B1372182015D; Fri, 11 May 2018 10:28:05 +0200 (CEST)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 85E251820157; Fri, 11 May 2018 10:28:02 +0200 (CEST)
From: Ladislav Lhotka 
To: Juergen Schoenwaelder , "Sterne\, Jason \(Nokia - CA\/Ottawa\)" 
Cc: "netmod\@ietf.org" 
In-Reply-To: <20180510172343.2uvlur2o2ypodbmk@elstar.local>
References:  <20180510172343.2uvlur2o2ypodbmk@elstar.local>
Mail-Followup-To: Juergen Schoenwaelder , "Sterne\, Jason \(Nokia - CA\/Ottawa\)" , "netmod\@ietf.org" 
Date: Fri, 11 May 2018 10:22:39 +0200
Message-ID: <87zi16ob3k.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] NMDA - different valid keys for config vs state
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 May 2018 08:22:35 -0000

Juergen Schoenwaelder  writes:

> On Thu, May 10, 2018 at 05:07:23PM +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote:
>> Hi all,
>> 
>> In the NMDA approach we're trying to combine config & state into the same common tree structure.   i.e. For a given list, model a single list that contains both config & state, vs separate lists for each of config & state.
>>
>
> NMDA uses different datastores, only configured leafs appear in the
> configuration datastores.
>
>> But what happens when the valid value space for config vs state is different ?   For example -> what if an implementation has internally created interfaces with names that start with '_internal_' and doesn't allow configuration of those interfaces ?
>
> These interfaces will appear in  but not in  and
> . They will also have a proper origin tag.
>  
>> If there were separate config vs state lists then the config list may have a pattern associated with the key that disallows names that start with '_internal_'.
>
> Oh, you are concerned about your implementation not allowing
> _internal_ for a configured interface? Well, in that case, I think the
> server needs to reject the creation of such an interface.
>  
>> To keep the spirit of NMDA it would be a shame to split into separate config & state lists for this case.  Any recommendations ?
>> 
>> 1) make the 'pattern' for the key be a superset (i.e. allow _internal_) and then just reject config requests for _internal_ interfaces (e.g. at commit time) ?
>
> This seems the way to go. The loopback interface is often system
> created and it is commonly called 'lo' or something like this. I
> assume a server will reject a request to create an interface named
> 'lo' which is a vlan interface on top of an ethernet interface.
> Looking at RFC 7223, I found that the description of
> /interfaces/interface/name talks quite a bit about the fact that a
> system may put restrictions on the names that are accepted.
>
>> 2) make the 'pattern' more strict to match config, and then return _internal_ interfaces for state queries (that in theory break the pattern for the key) ?
>
> I think the type of key leafs should allow all possible key values.
>
>> 3) other suggestions ?
>
> With the new YANG library, I think one could have a deviation that
> narrows down the type for the configuration datastore schemas. But
> then people do not like deviations...

I thought the idea was (as the examples in 7895bis show) to have one
module-set that is shared in schemas for both config datastores and
. But then deviations cannot be used to differentiate
between those schemas because deviations are specified per module-set.

Lada

>
>> Another example could be an integer key that has a larger range for state than it does for config (i.e. IDs >1000 are for internal entries only, not configurable).
>
> Perhaps concrete text in the description statement is the simplest
> solution.
>
> /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
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Mon May 14 07:03:47 2018
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 5B3EE12E9A1 for ; Mon, 14 May 2018 07:03:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level: 
X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=RK9Q16JY; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.com header.b=cjSfEIE7
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uC8RJaG_aALU for ; Mon, 14 May 2018 07:03:35 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 3AC9F12E8AC for ; Mon, 14 May 2018 07:03:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1526306612; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=VvPvksWdRk1UXu/UCpJXwYVxTv3NCO2NsveKWI9v0ZI=; b=RK9Q16JY7rkKoose1oaforl5Vjp4CG9YU+LnrRIkcdC75uOqL4RMBgTb5CqjvOB3 TBfB/EpMdyeKLQSyl6JvNdKUJhbU/Ywpg3mHn2VgjNCTb6GV5nqPqKraqKy07JBI hw/ZwmeV+A1sA88yqrguPRfu3iUTJfnsAMBHuQI6148=;
X-AuditID: c1b4fb30-e77ff7000000169b-5b-5af99733a815
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 81.98.05787.33799FA5; Mon, 14 May 2018 16:03:32 +0200 (CEST)
Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSHC012.ericsson.se (153.88.183.54) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 14 May 2018 16:03:18 +0200
Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 14 May 2018 16:03:17 +0200
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 14 May 2018 16:03:17 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=L8MHkb6s6d26+vq0b0/7LcwFKvDdpzFWOgo/XhihbbE=; b=cjSfEIE7wv44kUf2eEkW6z1s7Nh4qvzQbboy5bBXeSgIGlDp27Jh9DOOljCf/dfjlNx6pwO+aLg2vSbCeflZSMuWvWL6vdfHE/gN3lCI1lpjLs9VqhCz1nmuECJ4f185d28gSPYBKBOsX+cWF52YKQKgVV1YNNh5dXh4vVKUL2o=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
Received: from [159.107.197.31] (89.135.192.225) by AM2PR07MB0482.eurprd07.prod.outlook.com (2a01:111:e400:8406::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.776.4; Mon, 14 May 2018 14:03:15 +0000
To: Lou Berger , NETMOD Working Group 
CC: NetMod Chairs , Robert Wilton 
References: 
From: Balazs Lengyel 
Message-ID: <4a480b5d-b2d6-724e-e5d7-924ce0260f7f@ericsson.com>
Date: Mon, 14 May 2018 16:03:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Originating-IP: [89.135.192.225]
X-ClientProxiedBy: HE1PR0701CA0046.eurprd07.prod.outlook.com (2603:10a6:3:9e::14) To AM2PR07MB0482.eurprd07.prod.outlook.com (2a01:111:e400:8406::17)
X-MS-PublicTrafficType: Email
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:AM2PR07MB0482; 
X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0482; 3:KjXuU3rhogs7wnAz6X6gYULKMJFf0lBvU9/s2htx6MtUSr8TD2+Ih+GyYIK46uMhn14WuP9+WgNsgHC+fBA5Q7gqiVmk1yiBr2DKNrzwgcVtqO5xx1lFDPF9XlCicMZYRrRkYj/nWWwaBAcjNzSEQyx5BXqZweUf3z/JajQbFB2aqNtS603z+jm9WAYynthRgyB0xJR7pOsk+XnUyd9bpOS6SAC/Y8qyw2Y3AU6xRGHDspU0LctxhfYyRav0fM2l; 25:sVv34rfOXo2mnhYwxPZmGpjXVZny7AishyCQtxHDxvFiy/szljygIul5z3POBs1Xy3XZW8Z/amExQfpXW4CtzLq2Q3Ydi4EL1TRIpkVA7ZU7VSJBir1qtV/KrNjoX1WHxJuoFOLK5hdYO/iiAPAeOpLb6KJ2BMfyRB8v9+DdtNglmpghhPTcKFiGUNpoWTN/19wQ3ferO3B+hrTMlII7+/jODvN570KlrNnvhSad7EexErLiK/3Nsy9mObFYfbzOveXEDHwheo7mn6ucapxAoenhYib/WAtCrsH81S6YvupxhfK46efX8CH2iwMnoko1K5Mnve4SR59AUygpjGR40w==; 31:O8UNaPFVuDcfVavzmCVZ8SNab0Qdyud78JetED6CGUjHaNoG8VhuuOaSId+GNNXaZDOOw8Ep2BpemQlrCS7uBTYzFC5ocRa97wp1Mf/5YSATwYF3CbnsxMIYrL+CUOHJcZkoYiNl2TwSNZEoQmCuy94tbfofFVLXtw7YSuW1hUKBWQJqrDvs6BYhvNS6v1vz6/zYEokxXQBN0RNqZJ9RyURSiNfv3Git/ISO3o9d2rc=
X-MS-TrafficTypeDiagnostic: AM2PR07MB0482:
X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0482; 20:abz/7yKKjX07eAQVBjLPrG9b8G8ojS1nbqo4oHWEoNkhUEU1efh47fVzEunvDsr+RV73I6z2IhuPVc08w72AxaIsmqejL/HuergZONoIC6XC6k+8+n42T0XME5ayCBa50bpGZ04CuwGaReNEvfu9sClReCZtsRdy2DkhQaTkgsh0YL9QctHevRtDPo5Ug6Fgtd6QZZ2SUf1v8rskeUJMurfudkmHuGb8BDabNX58wh9EWEbHhHYHMCtWmU7Wf0uyW6hpAEnlCJcVKDa67QVpizy9gpriQguyQZAPwr84CiKy2eYqeTncKgYYzeMLHt3yemhL6wbAUQV00hwSBO9rDkfmkgWk0nUmwxVzSocqCRx1SnnadzokISPN86n/V2WcwnIFGDFNRI3ehSS4kj7k5UjkzLx8NKqjb2/m48OLEG0ZmzLGiih/FYMIX5LD1so0MV5G9dUmongXMqQoNWMR/M/hwTDNt7NZKhQJmToo8/OQ4nvrMnwrZNIlvkr+N16J; 4:cJ9FUdz2uEzEqiKz5J0LpxrXXKTpU1IC2t5/mQ3bMLVUBX4cyvx2Vz+tfpayZJRQs3dqIiK/E35qoGeHIMJNjr6amIL9ryIqYrY//OQvraO+B8Ww72ZKbK0g82Dk10DhLAt/uo7Rsx5lr0R4qG+j4nBbryKowsSaG/cegpRJnckH2MVuSLXWYC9t0ptBZTl9WMxVonRAxdAfRz1nZ94oRIZXvy/vvIxD7T69V6K5iHIZGWm6VFB7zmdCOpEi37RRj1ZcLeDHKEIH4snesV1BBS2M6pJpel4n1lxqM+2m3lr/0LVwxRGf1CiluYqA4V3t6dh2+P9QegpMbqfzc6KKYwNbCJKqB1FWA+RuTnjK7VA=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(120809045254105);
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:AM2PR07MB0482; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0482; 
X-Forefront-PRVS: 067270ECAF
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(39860400002)(39380400002)(366004)(376002)(396003)(346002)(252514010)(199004)(189003)(53936002)(106356001)(97736004)(6116002)(86362001)(31686004)(3846002)(44832011)(7736002)(305945005)(6246003)(5660300001)(65826007)(230700001)(105586002)(6306002)(2906002)(31696002)(16576012)(316002)(67846002)(66066001)(65956001)(8676002)(2616005)(50466002)(47776003)(110136005)(58126008)(8936002)(476003)(53546011)(386003)(4326008)(54906003)(478600001)(65806001)(81166006)(81156014)(966005)(956004)(6486002)(36756003)(68736007)(64126003)(446003)(229853002)(49976009)(186003)(26005)(11346002)(52116002)(76176011)(25786009)(2486003)(23676004)(16526019)(52146003)(6666003)(486006)(59450400001)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0482; H:[159.107.197.31]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTJQUjA3TUIwNDgyOzIzOnJVVFhGVlRTS2Y5ZTNzNjVURFM0V1NuVzgv?= =?utf-8?B?c3EyWkxDRmNmKzVJU3hWSFpRVkpPUlg5UlBMMVFHaEpoa0hQRzFOMXBaYTZC?= =?utf-8?B?OXNaVlI5ZFhUVjRxMENLT01KWjZPRXBTNkdLbyswTnhuYXZ2YW5HSHpIWjZl?= =?utf-8?B?SXhmUEVQRExCeGJxbVBvVmtXMDYyRGo4b2hmeG4vbmRuaGdUZ3A0S0c0N1FJ?= =?utf-8?B?YmJNMG1zbkFzT2NGS1dWRTVVd1lMSUlvU3dybGRwY1IwN25qUDZsV3cvQUJQ?= =?utf-8?B?RGt6ekk3bm9HOXZxZkV1cFdRWVZBNmVOMjRpaHpyRXBuSU1kOVE2c2JTdFh2?= =?utf-8?B?SEIvb25jNTBEQW5peWRlTUU5RE1GYnB5SHFJWDAvVVJBaUFTTEo2d0ZZcEdi?= =?utf-8?B?ekxQNWJrdmZnMFJROFY3WDZJSktWdGsyVS9IcmhaU0tYaXNLS01YMXlocU0r?= =?utf-8?B?MG94c3A1dlZTbnFvSHE0UXVjejJPT2xuT2FkYUh5L0J6RFJEd3dBVkdTT1M0?= =?utf-8?B?SFlGWDI3d2g2MkRCcU4vWS9BSUF6NlBrMUR0elFGcXh5QVNQUklNN2ZuZ3hW?= =?utf-8?B?VVhuSlRxSHJoMmxiQW5ER2NDZklvQ1RQeUtVT3RPL3FTZjBzckYrQVJyYnA4?= =?utf-8?B?QjA1SXlzVlQzc1RSQStEN2x2cm5IN3dKNFBTWjZiazZFa0pjWjlQd3hJZnlV?= =?utf-8?B?d3FmTU8wUVhmNzFYRjlKbjljVFd5T056T3JkV3FKeUFveTJ1ellPSmpyVWJy?= =?utf-8?B?eE9uTThkR0QyRVhwYnFHZUhkTzJqQWFqT3hXbDZoSUNxWE1CeG1MUll1N09l?= =?utf-8?B?Q3lweVQxZWFKRUo1WVdZQmE3ZjNJRGdWQWthSGFNcG1UNUtpcG1qTlZmZDFk?= =?utf-8?B?MlpmL3RmekZ6aUt3dUc4WTFWMzZ6eTV6ay8vRWt6VGhLNkZSd3hFRFUyRUxW?= =?utf-8?B?SXBOVWtSM0ZCTG5uMmtQc1BEdWl4N2I5dktyTXE3UHl2Mjl5U1BicFRkcmJP?= =?utf-8?B?RDcvd0M2RytEMGxzYkpEN2FiTXhDZ0ErczROeXYzY3BxZ3VGdGJtZWJHQnpS?= =?utf-8?B?QmRVRG56TUtBaUVtb3NJRFBPTVRqVEkxU2xmK2RwSFlFTUJyMW5Qck1kOURw?= =?utf-8?B?ZldLMXBsd1hzQnJHUHNIOUZsUDlES0tYenJ0UE00TjN0aHlKeUpid3pXeldx?= =?utf-8?B?ZS9BcjZnN0t0dFpKYlM0eC9XQjNacHhQeDZyUVp0M1V4MWlnMjl3NFJoYVpj?= =?utf-8?B?ajFZS3ZMSk9VS2ZWZndtUHdnZjdscUIrYUlqaTRtTEcwa2cwaWlQZWR3Tk50?= =?utf-8?B?a1Vlc1JobkpkQUxVVGpZeDNWS0c1Z3VWTDEreXhYbXNTZ0sveWd1ai9mQmN1?= =?utf-8?B?dEdJN1Vicmt4dFhwUjdZeXdMK2p1dGlrMmR4K0ZNUUsxU0luY214VzJ5WHVU?= =?utf-8?B?VU1qam8rcS9RUEphYzVleXB3R1NWWW1tYmdZa3hNTkpENWRKUHMvVml1KzdF?= =?utf-8?B?SGdXdk9qWXNIemVmTzExeDRIRjNldXJsc1kxUE9vY0VxTUNKNmR6QklOVW12?= =?utf-8?B?ZkpCaHdBRHUvRVFiaWlwVDM2TzExUzQ4RU5Qc3BMdmRoV1laWEJ6NytHL3dQ?= =?utf-8?B?c2JhcHh2RXV2RlZ3dEM4ejhseUhHem52alVxSVlIcnpvRnFCQTU1Q0VUKzBP?= =?utf-8?B?M3c1MjczaThIb2o1aWdqcGo3WjdnK1lNY2FMK0RmVEMxMHlscCtHQkFXTitD?= =?utf-8?B?Wkt2MHgxb3M4Z1psOFhLZjF5WDRIU1YvcGszWnF0WDRlWWNwR1FFZk0zdFNI?= =?utf-8?B?ejBWZzFybDFTYm1JY0ZaUXdRZ1NsWmNxN1hjVHQzeGg4MW9PUlRLVG92M0tj?= =?utf-8?B?eWRJYWFGNXRqOElGNDkrU2k3Mk5qQTNibDFQejBKdkppZnZYdUVVZDFRNitx?= =?utf-8?B?d1E3Um1BcmpmVUlWbUpaQ3RxMnVYeWRkOG9ROGhiajV6NGxCRFVBRUNQclN4?= =?utf-8?B?ZUlndlhxNFFQWmlxV3lQaFNJcGtVaWFZMndDYkMxUEJsYWhSYU5peEZOck9r?= =?utf-8?B?K2ZJajVTcWZ6V2s1NFFBcE40Tm5aQmdkdWtiNzkzaldKODkvdTE3NStBTjFQ?= =?utf-8?Q?rFqFHz91QjLtb3H5an7nqtaGou5cGmZ/QshRCS2dZMWL?=
X-Microsoft-Antispam-Message-Info: 7Xe0KKt9U69CPvcQ6fg86tNcZSNi7dz2BqfLp6AlOkOwhoJ8B+fJlhuRpSja/NpDgWATRVBCygrDFOOELTRtw0dadQeqdsoGKZTbLypdjGITOX0aU6STQ7tKrIy569YLfrvlMKZJNSSbkmRv1DuwjMc2Sb0ILJ8FsyEdA4snuZj9/sUhE4LM4+jG58iAlyUH
X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0482; 6:jZhkOCDPF0KCIJV/4j7beJuTMMK+0/pFS3lwlTOHUiH2s1k/0JS8N9jQQ192rLFNhJEwibyI+AKY6Rn0M+eOGJJHWlOqOw9PkfMzxFYZ7yEpvG/iG9aDp4FVQzXP9jt3PwfxsqumzJ94wn/x6DxP1kTGnmG1QLSsh4PFvZ5R8Ew94WDLu26RtebMPhAJaKCeKKuv5MaYjus91+F7lDSI9fxVlHJj7xbtGhO8ltVp4aaiao5RIpBp5HOYqD2lsXxD9gx9BRgMyCHCNcR+IARgFN7INta+LqwfAG4twJpVTAjvu+LkHlvSzXvL3VskSL0LYInDMExw/6DViz/3WM2pVTeM3ryFQV/8//lJYb6Qiy9cNKiJS1nucLvh2GnsLO6VwukaGye34NPNt96P3F342uPJ3opahLEPbkVI5JB1HDjR2bIK9oDil6+TpTAAwmJKF/eN0qPdLfupY2uSZpMIwg==; 5:5pZJL2U2FMlepjv3kbiGnX7NHQjdBJXdK5QDMtpQ93kUcR5MibAjHbKTHTqep51yzDec2ZoiD71FmteE/RJLDa5jsfyUKg/A4RWORyx40xJ2UahrhrGBuLPfURQRfdJKhRx5skg7Dc8la7gtRAwh5ECZMqUIJ8FKdt+Sg1WkBOs=; 24:effu3ZCZfagWuo7/bWNO6Q8bCcOBM3Pr7/0tg6wblPhApg0peieiFXjAUfPqRoyZGCCO1eZ39rODv6ipRvckelJ20ASUh89n3kk4DTq+R80=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0482; 7:VGm5IfsSc+JOBr1Ob0ddo4qrlSz3ih8gKgFMFfunGEBwU9ZbcU+AhR/M5pvCAIUU9qCv5YYAYYZVHZru7amrrEV4SRBYPcKRkmX/r6k1zxalBHjQGBsoCJmB2HJNx3uIH2AuuFKEI4sRK0I7zPILoVeUqSLMMlUzKgfKZooucb81L9YyHWypNtTv01CUoNYrdvRiqkl94ktURPmTSC6JtqxzXzkjzdniQ1ZpgfM5KKWyuYilKCZuD3g41f5in8ad
X-MS-Office365-Filtering-Correlation-Id: 65ec7f38-3b24-406f-29f7-08d5b9a370b8
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 May 2018 14:03:15.9718 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 65ec7f38-3b24-406f-29f7-08d5b9a370b8
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0482
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUyM2K7ma7J9J9RBpO38Vh0NL9lsVjdq2Yx /2Ijq0XnomIHFo+Fs56zeCxZ8pPJ48OmZrYA5igum5TUnMyy1CJ9uwSujMc7lrAWvBauaJix j6WB8RV/FyMnh4SAicTnDYsZQWwhgSOMEv/eVXUxcgHZWxglJh5dyAbhfGOU+L7sLhNE1RIm iVPrY0ASLAKfmCT2/P7OCpJgFIiT2LlmIStERxtQYvYcFpCEsIC5xJUvE8CKRAQ8JY5MPQE2 iVkgTGJ34yIWiKnWEjtXfQS7g03ASGJq/3mgOAcHr4C9xMPfHiAmi4CqxLaNYiAVogIxEj+O doF18goISpyc+QTM5hSwkbj5aRcLxHQLiZnzzzNC2PIS29/OYYawxSVuPZnPBPG9ksSlL9NY IOyZjBLN3zghrtGQeHjhLytEXFbi6FmQT7iA7G2MEvPvfmGGcBrYJS52nYaapCWxbNMdVojE EnaJ1vUvGUGulhDIlrjzXRGixltiZ/9UZghbTuJU7zmmCYyGs5A8MQvJ4bOQHD4LyeELGFlW MYoWpxYn5aYbGemlFmUmFxfn5+nlpZZsYgSmk4NbfhvsYHz53PEQowAHoxIPb2PHzygh1sSy 4srcQ4wSHMxKIry7jYBCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeS38NkcJCaQnlqRmp6YWpBbB ZJk4OKUaGC1uL8peuH+B9xWfzV+LUr0+PdnyUtmf8+FrqYbLlbeWiEoe37pD1a4+4037nry/ D8P0vu73UrlXdEfz+Fz1P3t35aQ03d51bf6HlU6/s59HlPgIdjP3BERNLT204OqB5Bsb78Ss f7AiZInJlNWenMZZ7y+f+Ri3btl00ZXSwolLJ/C/PfelIVZOiaU4I9FQi7moOBEA9EirliMD AAA=
Archived-At: 
Subject: Re: [netmod] YANG Model Versioning Design Team
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 May 2018 14:03:39 -0000

Hello,

As one of the authors I am most interested in joining this work.

regards Balazs


On 4/20/2018 5:14 PM, Lou Berger wrote:
> Hi,
>
> As discussed at the NETMOD WG session in IETF 101, London, we would like
> to set up a design team for YANG versioning.
>
> The proposed charter for the design team is as follows:
>
> The YANG Model Versioning Design Team is chartered to propose a revised
> approach to supporting YANG module updates.  The existing approach is
> described in [1], and related issues have been discussed at IETF 100
> [2], IETF 101 [3] and in [4].  The Design Team will document the current
> problem, related requirements and objections, and lead the WG related
> discussion to ensure consensus.  The result of this effort is expected
> to be an individual draft which may be adopted by the WG per normal
> process. The goal of the design team is to have this draft published
> prior to IETF 102.
>
> The Design Team is also expected to explore the possible solution space
> and propose a single solution to the WG in the form of an individual
> document.  The goal of the design team is to have an initial version of
> this draft available prior to IETF 103, and to help with the effort of
> achieving WG adoption of the draft.  The Design Team is expected to
> close once there is WG draft providing a revised solution to supporting
> YANG module updates.
>
> We have asked Rob Wilton to lead the DT and would like to ask that those
> who are interested in joining the design team please contact the chairs
> and Rob Wilton. Note if you have already sent mail to the chairs
> regarding volunteering, there is no need to send an additional e-mail.
> If you volunteer and are not asked to join, please know that you will
> have ample opportunity to provide input as any documents produced by the
> DT will follow normal WG process, starting with a normal WG adoption call.
>
> Thank you,
> NETMOD WG Chairs
>
> [1] https://tools.ietf.org/html/rfc7950#section-11
> [2] https://datatracker.ietf.org/meeting/100/session/netmod
> [3] https://datatracker.ietf.org/meeting/101/session/netmod
> [4] https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update
>
> _______________________________________________
> 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 Mon May 14 08:26:26 2018
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 E7C2212D952; Mon, 14 May 2018 08:26:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDDXKbsUr8CJ; Mon, 14 May 2018 08:26:10 -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 068D612E8DE; Mon, 14 May 2018 08:26:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=572; q=dns/txt; s=iport; t=1526311566; x=1527521166; h=to:from:subject:cc:message-id:date:mime-version: content-transfer-encoding; bh=1EkRJGJ5NzVF5v3JcFJf3jItm4O5FFAIKjWu0rvOPGo=; b=gIttqUV8FdGsYP7FNKjxkyTp64DbKXD4qOS2YPXP4erWrB4Dfgs2/qMS wsDrYGezZ4F45qXpUY/4j/z0NnHl2vU2FNsikb7clA8P/un9wbhVeW1FH dVlTzELgtb3Y5OSzzdEiSJWdJ9W211aVB+m50fVrT4IM3u23e9dAppNvH I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAwDCqfla/xbLJq1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYMYggeEGohijWCBOJUqC4RsgzQ4FAECAQEBAQEBAmwdC4VSDwE?= =?us-ascii?q?FQTUCJgJfDQgBAYMfggGqYYIchFiDZYIngQmIcD+BMopbglQChzAshVyKfgm?= =?us-ascii?q?OSwaBKA6DZYI9hReLOoUpgSUzIYFSMxoIGxWCf4MwAQmNFD6RGQEB?=
X-IronPort-AV: E=Sophos;i="5.49,400,1520899200";  d="scan'208";a="3776936"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 May 2018 15:26:04 +0000
Received: from [10.61.242.224] ([10.61.242.224]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w4EFQ3HH031291; Mon, 14 May 2018 15:26:04 GMT
To: "netmod@ietf.org" 
From: Robert Wilton 
Cc: netmod-ver-dt@ietf.org
Message-ID: 
Date: Mon, 14 May 2018 16:26:03 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: [netmod] YANG Model Versioning Design Team
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 May 2018 15:26:14 -0000

The YANG model versioning design team alias (netmod-ver-dt) has now been 
set up.

I have subscribed everyone that expressed an interest in joining the 
design team.  Of course, if anyone wishes to no longer participate then 
please let me know and I'll remove them.  Conversely, if you have 
previously expressed an interest in joining the design team, but I have 
failed to add you, then please let me know, and I'll correct that.

Apologies that this has taken a while to get going, but hopefully we can 
now quickly start making progress.

Thanks,
Rob


From nobody Mon May 14 08:27:10 2018
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 E98FD12421A; Mon, 14 May 2018 08:27:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FurcqzuK638M; Mon, 14 May 2018 08:27:07 -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 E8E3512E872; Mon, 14 May 2018 08:26:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2690; q=dns/txt; s=iport; t=1526311611; x=1527521211; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=rPfYzZwHmva2AqcejSVYHGKC8VK6tomsUGI0DZ/5f7A=; b=HImLG/ES6ZY+Cj005CUmra1BPRFu3x1DwOblQE9AAqEwNcQCL4NjY/HJ GY0xQf9qMlc+pujQlQH9O4yTPXLIm4rG2lGov11vlSFKz8fXU1nUPaj7c QqCmiaT7yXc+aPkUKPsHr2kdOhkjQ3wGd2T74ohvhc9jIWxN63lFEuq9O g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AgD6qfla/xbLJq1cARgBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGEJHsog3KIYo1gKYEPlSoLGAuEA0YCgzI4FAECAQEBAQE?= =?us-ascii?q?BAmwcDIUpAQEEAQEhDwEFNgsQCxgCAiYCAicwBgEMBgIBAReDCAKBfw+qVYI?= =?us-ascii?q?chFiDZYIiBYEJiHA/gTKCMzWDEQEBAgGBOgMBAYMeglQCh1yQWgmFZ4hkBoE?= =?us-ascii?q?2g2WCPYUXh0iCDYFlhSmBJTMhgVIzGggbFTuCQ4sQhT0CPjARjhIHCBeCIAE?= =?us-ascii?q?B?=
X-IronPort-AV: E=Sophos;i="5.49,400,1520899200";  d="scan'208";a="3831198"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 May 2018 15:26:48 +0000
Received: from [10.61.242.224] ([10.61.242.224]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w4EFQm2e031056; Mon, 14 May 2018 15:26:48 GMT
To: Balazs Lengyel , Lou Berger , NETMOD Working Group 
Cc: NetMod Chairs 
References:  <4a480b5d-b2d6-724e-e5d7-924ce0260f7f@ericsson.com>
From: Robert Wilton 
Message-ID: 
Date: Mon, 14 May 2018 16:26:48 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <4a480b5d-b2d6-724e-e5d7-924ce0260f7f@ericsson.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] YANG Model Versioning Design Team
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 May 2018 15:27:09 -0000

Hi Balazs,

Sorry, but we have been a bit slow getting this going with various 
holidays and folks being away.

The design team alias is now active, and you are included.

Thanks,
Rob


On 14/05/2018 15:03, Balazs Lengyel wrote:
> Hello,
>
> As one of the authors I am most interested in joining this work.
>
> regards Balazs
>
>
> On 4/20/2018 5:14 PM, Lou Berger wrote:
>> Hi,
>>
>> As discussed at the NETMOD WG session in IETF 101, London, we would like
>> to set up a design team for YANG versioning.
>>
>> The proposed charter for the design team is as follows:
>>
>> The YANG Model Versioning Design Team is chartered to propose a revised
>> approach to supporting YANG module updates.  The existing approach is
>> described in [1], and related issues have been discussed at IETF 100
>> [2], IETF 101 [3] and in [4].  The Design Team will document the current
>> problem, related requirements and objections, and lead the WG related
>> discussion to ensure consensus.  The result of this effort is expected
>> to be an individual draft which may be adopted by the WG per normal
>> process. The goal of the design team is to have this draft published
>> prior to IETF 102.
>>
>> The Design Team is also expected to explore the possible solution space
>> and propose a single solution to the WG in the form of an individual
>> document.  The goal of the design team is to have an initial version of
>> this draft available prior to IETF 103, and to help with the effort of
>> achieving WG adoption of the draft.  The Design Team is expected to
>> close once there is WG draft providing a revised solution to supporting
>> YANG module updates.
>>
>> We have asked Rob Wilton to lead the DT and would like to ask that those
>> who are interested in joining the design team please contact the chairs
>> and Rob Wilton. Note if you have already sent mail to the chairs
>> regarding volunteering, there is no need to send an additional e-mail.
>> If you volunteer and are not asked to join, please know that you will
>> have ample opportunity to provide input as any documents produced by the
>> DT will follow normal WG process, starting with a normal WG adoption 
>> call.
>>
>> Thank you,
>> NETMOD WG Chairs
>>
>> [1] https://tools.ietf.org/html/rfc7950#section-11
>> [2] https://datatracker.ietf.org/meeting/100/session/netmod
>> [3] https://datatracker.ietf.org/meeting/101/session/netmod
>> [4] https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>


From nobody Wed May 16 07:19:58 2018
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 D96E6127078 for ; Wed, 16 May 2018 07:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Im7asO4Rrdg5 for ; Wed, 16 May 2018 07:19:54 -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 41963120047 for ; Wed, 16 May 2018 07:19:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2221; q=dns/txt; s=iport; t=1526480394; x=1527689994; h=references:to:from:subject:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=I+9DxzRfrKf+jxZV+8LCy7dUqXRXBCjjcV8u3zQ8r50=; b=PteiIZ2vvO0loFATazKFmlIfZdve6ImmiY4iSjYgjzVHEEXNX3nRc62c wm9JfTzzLkFBeE4OVhvu6wOHiolnCOA/ou8sOYrfWXc9YnE/ABVzLG3r3 Y/UH43vVnCjBGB3RtMMz5Ytd6TDXtRf3D7eJCguhif+otXd1Hh0MB1I7k M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CCAQB7Pfxa/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYQkfCiDdIhijg+BD5MyFIFkCyWERwKDQDYWAQIBAQEBAQE?= =?us-ascii?q?CbBwBC4UoAQYjDwFEEhwDAQIDAhEVAgJNAggGDQYCAQGDHwKBfw+qRYIciEa?= =?us-ascii?q?CJ4EJiHI/gTKCaYMRAQECAQEWgQGBBIJBglQCjByMJQmFaIhlBoE3PoMsgj0?= =?us-ascii?q?ihHeHTIIQhxKBJSMDLoFSTSMVGoJkCYsHhVojMAEQjzABAQ?=
X-IronPort-AV: E=Sophos;i="5.49,406,1520899200";  d="scan'208";a="3826638"
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; 16 May 2018 14:19:52 +0000
Received: from [10.229.13.184] ([10.229.13.184]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w4GEJqCR031810 for ; Wed, 16 May 2018 14:19:52 GMT
References: <152639651334.3819.3921515969627378751.idtracker@ietfa.amsl.com>
To: "netmod@ietf.org" 
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDyDmj4RBADa/Icz5Xl+cJUGNxC/tWgXWqcA9VA8GN+PeqKhXS0BnVHntdsQxbpFUUKK 4ld0Zex/Rec1jgC/ikExJHHIee8ZVcHqP+tsWexi83/ZvEdzI95diBp2Is5fYp8P8hdIBNQS Ooc1jVYrTJUaZgJK2uBzbkh/WbipwsQbueRzXqPORwCgsPNrStLzqOpjrA7FdUz/JVQf5+8D /1SiKAOFiW4TxY+fS09lqiLs3mbXjvw23iQwLxje4vBd4+b9iAUWOsSretSKv6OE9ZlD4FYe a8HmMgEkuKfXGc8GvTq4J1uHZ0gcVbrBGmxAUBPPaAENYEJfJf7dcysKVAl14ZQVIvzAGJAZ HGuegD7uekGKnOEA61R3ze4aM2zNA/96I77l0qiMc6J7gXmiD5uxC7FsSCFj5sqTYMgBqzIY EZjU/tTUbth84xcRi4X0WNkaILqq1mOcBfmzQMvzG1n1CydmJU6iF1ewle6cIui9TQYg5CES rJF7xid4vVXRz+xi6hc1+0bSaoJa3sfpNrSSr0lKGdWHZozWdQjOvTMCXc1CSm9lIE1hcmN1 cyBDbGFya2UgKEZyZWVCU0QgY29tbWl0dGVyIGFkZHJlc3MpIDxtYXJjdXNARnJlZUJTRC5v cmc+wl8EExECABcFAjyuLU0FCwcKAwQDFQMCAxYCAQIXgAASCRBvaI+K/hTPhwdlR1BHAAEB 7U0AoICIVoBe9B8bo1lrvHh+UF7GY/WaAJ9C2mCThFrmqxCr2bCtR12UoPCPqs7ATQQ8g5pA EAQAqk1J4LBDLeWs6ZOkPDYYcKCSAu0qlzEf5YP/TcSeZcjJyXILgesFXcayoy1v7ILPQSXj 4p5uzRyn0fuGqiTvajjxMZz1aSkvgGyS+gc+PDmi4SJ2N/tX2isrul8MK+NGeUsLuZaM1JKh gKpq9yuu3D3ELG7ESga7xsOs1V/sSd8AAwUD/20XByIlsUUC/65KG/DQ1WfX2gNuy5If9tSP Q6h1Lno5Hv3ow3ktybIoQSxbcBo28nA/Gzg5NFGVkkqfOkH2xtS6V0K/WjzsrloBHCPFiKp2 yHpXfKubxl8yefQPTMj8hLwlBKrNiN1fz5/629TIkEwDwrUwHxQreE7FAzPMqHORwkYEGBEC AAYFAjyDmkAACgkQb2iPiv4Uz4cnuQCfX1zNrahRTWz/HRpF7ms8qZqzdOIAn1uuu6Jst43p DzanBHUOBzUP6ymA
Organization: Cisco
X-Forwarded-Message-Id: <152639651334.3819.3921515969627378751.idtracker@ietfa.amsl.com>
Message-ID: <8c07864e-d277-a690-96bb-73a0cce65725@cisco.com>
Date: Wed, 16 May 2018 10:18:35 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <152639651334.3819.3921515969627378751.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: [netmod] Fwd: New Version Notification for draft-clacla-netmod-yang-model-update-04.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 May 2018 14:19:57 -0000

Ahead of the first DT meeting, we have submitted a new version of the
draft that takes into account a number of comments that were raised
during the IETF101 presentation, as well as some discussion after the
meeting with Martin.  More specifically:

* Discuss import by semantic version

* Add an extension status-description to track deprecated
  and obsolete reasons.

* Drop the text around "maybe" needing a new module name.  If you need a
 new module, you create a new module

* Add the ability to assert that deprecated and obsolete nodes are
implemented or not.

There were many other textual changes to get to the heart of the problem
and proposal sooner and hopefully make it easier to read.

Joe

-------- Forwarded Message --------
Subject: New Version Notification for
draft-clacla-netmod-yang-model-update-04.txt
Date: Tue, 15 May 2018 08:01:53 -0700
From: internet-drafts@ietf.org
To: Benoit Claise , Kevin D'Souza ,
Balazs Lengyel , Joe Clarke 


A new version of I-D, draft-clacla-netmod-yang-model-update-04.txt
has been successfully submitted by Joe Clarke and posted to the
IETF repository.

Name:		draft-clacla-netmod-yang-model-update
Revision:	04
Title:		New YANG Module Update Procedure
Document date:	2018-05-15
Group:		Individual Submission
Pages:		22
URL:
https://www.ietf.org/internet-drafts/draft-clacla-netmod-yang-model-update-04.txt
Status:
https://datatracker.ietf.org/doc/draft-clacla-netmod-yang-model-update/
Htmlized:
https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04
Htmlized:
https://datatracker.ietf.org/doc/html/draft-clacla-netmod-yang-model-update
Diff:
https://www.ietf.org/rfcdiff?url2=draft-clacla-netmod-yang-model-update-04

Abstract:
   This document specifies a new YANG module update procedure in case of
   backward-incompatible changes, as an alternative proposal to the YANG
   1.1 specifications.  This document updates RFC 7950.




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.

The IETF Secretariat


From nobody Wed May 16 20:57:37 2018
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 6199712E8A7 for ; Wed, 16 May 2018 20:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bi12bTbDq18x for ; Wed, 16 May 2018 20:57:33 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A79D12E8A5 for ; Wed, 16 May 2018 20:57:33 -0700 (PDT)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 93FA5910DB650 for ; Thu, 17 May 2018 04:57:30 +0100 (IST)
Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 17 May 2018 04:57:31 +0100
Received: from DGGEML510-MBS.china.huawei.com ([169.254.3.215]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0382.000; Thu, 17 May 2018 11:57:22 +0800
From: Rohit R Ranade 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] NMDA System controlled resource
Thread-Index: AdPtkflME8Sn/pZvSPiqMr4/Yzk5pg==
Date: Thu, 17 May 2018 03:57:22 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BBAAC22@dggeml510-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.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BBAAC22dggeml510mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [netmod]  NMDA System controlled resource
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 May 2018 03:57:36 -0000

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

Hi All,

RFC 8342 has below statement in Section 5.3.3
"If a system-controlled resource has
   matching configuration in  when it appears, the system will
   try to apply the configuration; this causes the configuration to
   appear in  eventually (if application of the
   configuration was successful).
"
Why does application of configuration for system-controlled resources depen=
d on whether  has configurations for that resource ? The configur=
ation will still get applied as part of "system" configuration as shown in =
examples in Section C.1 in the same RFC given below

"In addition to filling in the default value for the auto-negotiation
   enabled leaf, a loopback interface entry is also automatically
instantiated by the system.  All of this is reflected in
   ."


With Regards,
Rohit R Ranade

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











Hi All,


 


RFC 8342 has below statement in=
 Section 5.3.3


“If a syste=
m-controlled resource has


   matching configuration in <in=
tended> when it appears, the system will


   try to apply the configuration; =
this causes the configuration to


   appear in <operational> ev=
entually (if application of the


   configuration was successful).


“


Why does application of configu=
ration for system-controlled resources depend on whether <intended> h=
as configurations for that resource ? The configuration will still get appl=
ied as part of “system” configuration as shown
 in examples in Section C.1 in the same RFC given below

 


“In additio=
n to filling in the default value for the auto-negotiation


   enabled leaf, a loopback interfa=
ce entry is also automatically


instantiated by the system.  All of this=
 is reflected in


  
<operational>.”


 


 


With Regards,=



Rohit R Ranade






--_000_991B70D8B4112A4699D5C00DDBBF878A6BBAAC22dggeml510mbschi_--


From nobody Thu May 17 01:58:56 2018
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 913B112E868 for ; Thu, 17 May 2018 01:58:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level: 
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOMwXFi67814 for ; Thu, 17 May 2018 01:58:53 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AB9B12AF83 for ; Thu, 17 May 2018 01:58:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9813; q=dns/txt; s=iport; t=1526547532; x=1527757132; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=nIRZ+luJKQ4ETJl7n23TRSIrZCT3qntOxVgDNxSKRbU=; b=cNe0BlUHbM3R/n7ha2WaBjq2vh8l//Ffx51XTQHHFEBJpaWgssqHEafl XGpjXWWwKyPDRV6LvJXnsNmPUKLeCbpdCDHZqcv37BAPuekLi/3fGyxQa 1E4gbo8e9QVPnW7J+P/CNAEPlEMgD6Y+X8BI8hZ+sGxoziJy7ZN/M6eFO M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AgDvQ/1a/xbLJq1bGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYJNgVd9KIxWjWcpgQ+OP4R3gXgLGAEKhANGAoItNhYBAgEBAQE?= =?us-ascii?q?BAQJsHAyFKQEBBAEBK0EbCxguJzAGAQwGAgEBgx8CgX8PqGMfhDmDdYIiBYo?= =?us-ascii?q?CP4EPI4JpgxEBAYc0AphGCY5PBodehRqLRYUrgSUiATGBUjMaCBsVO4JDixC?= =?us-ascii?q?FPz4wjzcBAQ?=
X-IronPort-AV: E=Sophos;i="5.49,390,1520899200"; d="scan'208,217";a="3848759"
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 2018 08:58:50 +0000
Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w4H8wnZw012426; Thu, 17 May 2018 08:58:50 GMT
To: Rohit R Ranade , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6BBAAC22@dggeml510-mbs.china.huawei.com>
From: Robert Wilton 
Message-ID: <4da2b372-d950-80c6-5a8e-9fa58951f6a8@cisco.com>
Date: Thu, 17 May 2018 09:58:49 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BBAAC22@dggeml510-mbs.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------94A9D9705A0BC413E4C3CA6E"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] NMDA System controlled resource
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 May 2018 08:58:55 -0000

This is a multi-part message in MIME format.
--------------94A9D9705A0BC413E4C3CA6E
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi Rohit,

Section 5.3.2 states that you allowed to have configuration in 
/ for resources that could be present on the device 
but are not currently present. The canonical example would be interface 
configuration for an interface on a linecard that isn't operational 
(either because it isn't present, or hasn't completely initialized).

Section 5.3.3 is saying that if the linecard becomes operational, then 
it may instantiate system controlled entries (in ) for 
those interfaces. It also states that if there also happens to be 
configuration in / for those interfaces then that 
configuration will also get applied as those interfaces as instantiated 
in . All of the configuration that has been successfully 
applied would also appear in .

Thanks,
Rob


On 17/05/2018 04:57, Rohit R Ranade wrote:
>
> Hi All,
>
> RFC 8342 has below statement in Section 5.3.3
>
> If a system-controlled resource has
>
>  matching configuration in  when it appears, the system will
>
>  try to apply the configuration; this causes the configuration to
>
>  appear in  eventually (if application of the
>
>  configuration was successful).
>
> 
>
> Why does application of configuration for system-controlled resources 
> depend on whether  has configurations for that resource ? 
> The configuration will still get applied as part of system 
> configuration as shown in examples in Section C.1 in the same RFC 
> given below
>
> In addition to filling in the default value for the auto-negotiation
>
>  enabled leaf, a loopback interface entry is also automatically
>
> instantiated by the system. All of this is reflected in
>
> .
>
> With Regards,
>
> Rohit R Ranade
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--------------94A9D9705A0BC413E4C3CA6E
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Rohit,

    
Section 5.3.2 states that you allowed to have configuration in
      <running>/<intended> for resources that could be
      present on the device but are not currently present. The
      canonical example would be interface configuration for an
      interface on a linecard that isn't operational (either because it
      isn't present, or hasn't completely initialized).

    
Section 5.3.3 is saying that if the linecard becomes operational,
      then it may instantiate system controlled entries (in
      <operational>) for those interfaces. It also states that if
      there also happens to be configuration in
      <running>/<intended> for those interfaces then that
      configuration will also get applied as those interfaces as
      instantiated in <operational>. All of the configuration
      that has been successfully applied would also appear in
      <operational>.

    

    
Thanks,

      Rob

    

    

    
On 17/05/2018 04:57, Rohit R Ranade
      wrote:

    

    

      
      
      
      

        
Hi All,

        

        
RFC 8342 has below
            statement in Section 5.3.3

        
If a system-controlled
            resource has

        
 matching
            configuration in <intended> when it appears, the
            system will

        
 try to apply the
            configuration; this causes the configuration to

        
 appear in
            <operational> eventually (if application of the

        
 configuration was
            successful).

        

        
Why does application of
            configuration for system-controlled resources depend on
            whether <intended> has configurations for that
            resource ? The configuration will still get applied as part
            of system configuration as shown in examples in Section
            C.1 in the same RFC given below

        

        
In addition to filling
            in the default value for the auto-negotiation

        
 enabled leaf, a
            loopback interface entry is also automatically

        
instantiated by the
            system. All of this is reflected in

        

          <operational>.

        

        

        
With Regards,

        
Rohit R Ranade

      

      

      

      

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


    

    

  


--------------94A9D9705A0BC413E4C3CA6E--


From nobody Thu May 17 02:30:32 2018
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 B694F1267BB for ; Thu, 17 May 2018 02:30:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.189
X-Spam-Level: 
X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yI3Epodbq4a for ; Thu, 17 May 2018 02:30:28 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B268E1250B8 for ; Thu, 17 May 2018 02:30:27 -0700 (PDT)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 795FC821A7515 for ; Thu, 17 May 2018 10:30:21 +0100 (IST)
Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 17 May 2018 10:30:22 +0100
Received: from DGGEML510-MBS.china.huawei.com ([169.254.3.215]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0382.000; Thu, 17 May 2018 17:30:10 +0800
From: Rohit R Ranade 
To: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] NMDA System controlled resource
Thread-Index: AdPtkflME8Sn/pZvSPiqMr4/Yzk5pv//0HuA//9yM5A=
Date: Thu, 17 May 2018 09:30:10 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BBAAE98@dggeml510-mbs.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6BBAAC22@dggeml510-mbs.china.huawei.com> <4da2b372-d950-80c6-5a8e-9fa58951f6a8@cisco.com>
In-Reply-To: <4da2b372-d950-80c6-5a8e-9fa58951f6a8@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BBAAE98dggeml510mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] NMDA System controlled resource
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 May 2018 09:30:30 -0000

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

Hi Robert,

So first , we try to get to know the system configuration.
Then for the configuration leaves (based on description), check whether sys=
tem configuration trumps the intended configuration ? If yes, retain system=
 configuration, Else apply intended configuration.
If for some leaf, there is no  configuration , then apply system =
configuration .

Is my understanding correct ?

With Regards,
Rohit R Ranade

From: Robert Wilton [mailto:rwilton@cisco.com]
Sent: 17 May 2018 14:29
To: Rohit R Ranade ; netmod@ietf.org
Subject: Re: [netmod] NMDA System controlled resource


Hi Rohit,

Section 5.3.2 states that you allowed to have configuration in / for resources that could be present on the device but are not curr=
ently present.  The canonical example would be interface configuration for =
an interface on a linecard that isn't operational (either because it isn't =
present, or hasn't completely initialized).

Section 5.3.3 is saying that if the linecard becomes operational, then it m=
ay instantiate system controlled entries (in ) for those inter=
faces.  It also states that if there also happens to be configuration in / for those interfaces then that configuration will also g=
et applied as those interfaces as instantiated in .  All of th=
e configuration that has been successfully applied would also appear in .

Thanks,
Rob

On 17/05/2018 04:57, Rohit R Ranade wrote:
Hi All,

RFC 8342 has below statement in Section 5.3.3
"If a system-controlled resource has
   matching configuration in  when it appears, the system will
   try to apply the configuration; this causes the configuration to
   appear in  eventually (if application of the
   configuration was successful).
"
Why does application of configuration for system-controlled resources depen=
d on whether  has configurations for that resource ? The configur=
ation will still get applied as part of "system" configuration as shown in =
examples in Section C.1 in the same RFC given below

"In addition to filling in the default value for the auto-negotiation
   enabled leaf, a loopback interface entry is also automatically
instantiated by the system.  All of this is reflected in
   ."


With Regards,
Rohit R Ranade




_______________________________________________

netmod mailing list

netmod@ietf.org

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


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











Hi Robe=
rt,


&n=
bsp;


So firs=
t , we try to get to know the system configuration.


Then fo=
r the configuration leaves (based on description), check whether system con=
figuration trumps the intended configuration ? If yes, retain system config=
uration, Else apply intended configuration.


If for =
some leaf, there is no <intended> configuration , then apply system c=
onfiguration .


&n=
bsp;


Is my u=
nderstanding correct ?


&n=
bsp;


With Re=
gards,




Rohit R=
 Ranade




&n=
bsp;






From: Robert Wilt=
on [mailto:rwilton@cisco.com]


Sent: 17 May 2018 14:29

To: Rohit R Ranade <rohitrranade@huawei.com>; netmod@ietf.org<=
br>
Subject: Re: [netmod] NMDA System controlled resource






 


Hi Rohit,


Section 5.3.2 states that you allowed to have confi=
guration in <running>/<intended> for resources that could be pr=
esent on the device but are not currently present.  The canonical exam=
ple would be interface configuration for an interface
 on a linecard that isn't operational (either because it isn't present, or =
hasn't completely initialized).


Section 5.3.3 is saying that if the linecard become=
s operational, then it may instantiate system controlled entries (in <op=
erational>) for those interfaces.  It also states that if there als=
o happens to be configuration in <running>/<intended>
 for those interfaces then that configuration will also get applied as thos=
e interfaces as instantiated in <operational>.  All of the confi=
guration that has been successfully applied would also appear in <operat=
ional>.


Thanks,

Rob


 




On 17/05/2018 04:57, Rohit R Ra=
nade wrote:






Hi All,


 


RFC 8342 has below statement in=
 Section 5.3.3


“If =
a system-controlled resource has


   matching configuration in=
 <intended> when it appears, the system will


   try to apply the configur=
ation; this causes the configuration to


   appear in <operational=
> eventually (if application of the


   configuration was success=
ful).


“


Why does application of configu=
ration for system-controlled resources depend on whether <intended> h=
as configurations for that resource ? The configuration will still get appl=
ied as part of “system” configuration as shown
 in examples in Section C.1 in the same RFC given below

 


“In =
addition to filling in the default value for the auto-negotiation


   enabled leaf, a loopback =
interface entry is also automatically


instantiated by the system.  All =
of this is reflected in


   <operati=
onal>.”


 


 


With Regards,=



Rohit R Ranade











_______________________________________________


netmod mailing list


netmod@ietf.or=
g


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



 






--_000_991B70D8B4112A4699D5C00DDBBF878A6BBAAE98dggeml510mbschi_--


From nobody Thu May 17 03:12:25 2018
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 BAECE126E64 for ; Thu, 17 May 2018 03:12:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mh2niSwDrRaY for ; Thu, 17 May 2018 03:12:20 -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 25FFB1200E5 for ; Thu, 17 May 2018 03:12:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20323; q=dns/txt; s=iport; t=1526551940; x=1527761540; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=db4L9pEJJxiNfDUbKYXAvlmdqusP/8o1VXiR/D6xTcw=; b=Zlqg8zX3/HeXWXL4WM6qLW7HOeJPEuj/A4cUdRG92cPtKETSIwJG6J/K lQryRFd5u+tzpgLutDoAzY2OerXxAxHJaLwlVqLR3IA0wfI/phLkv/UZr zdqNj5FJTESGo7hM8rNq3r7u8wRaIjlt4glgwDHEnkmIkHBfbUMhX75tp g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AABrWvZa/xbLJq1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJNR4EQeyiLdl6NYgghgQ+TNYF4CxgBCoQDRgKDKjQYAQI?= =?us-ascii?q?BAQEBAQECbBwMhSgBAQEDAQEBK0EQCwsRAQMBAQEnBycfAwYIBgEMBgIBAYM?= =?us-ascii?q?fAoF3CA+tWB+EOYN/giIFiXk/gQ8jDIJcgxEBAYIWhR4CmDIJjksGh1eFFIs?= =?us-ascii?q?2hSeBJRw4gVIzGggbFTuCQ4sQhT8+MJB8AQE?=
X-IronPort-AV: E=Sophos;i="5.49,409,1520899200"; d="scan'208,217";a="3850007"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 May 2018 10:12:18 +0000
Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w4HACHhp006606; Thu, 17 May 2018 10:12:17 GMT
To: Rohit R Ranade , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6BBAAC22@dggeml510-mbs.china.huawei.com> <4da2b372-d950-80c6-5a8e-9fa58951f6a8@cisco.com> <991B70D8B4112A4699D5C00DDBBF878A6BBAAE98@dggeml510-mbs.china.huawei.com>
From: Robert Wilton 
Message-ID: 
Date: Thu, 17 May 2018 11:12:17 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BBAAE98@dggeml510-mbs.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------67BC6E9F4436225DC7C11BF3"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] NMDA System controlled resource
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 May 2018 10:12:24 -0000

This is a multi-part message in MIME format.
--------------67BC6E9F4436225DC7C11BF3
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi Rohit,

On 17/05/2018 10:30, Rohit R Ranade wrote:
>
> Hi Robert,
>
> So first , we try to get to know the system configuration.
>
> Then for the configuration leaves (based on description), check 
> whether system configuration trumps the intended configuration ? If 
> yes, retain system configuration, Else apply intended configuration.
>
I think that this is probably an implementation choice, so my comments 
below are subjective.

E.g. I think that Junos devices always instantiate a loopback interface 
(lo0) even if not configured, but IOS XR does not. This is fine, this 
is just a difference in architecture.

However, for both types of devices, configuring an IP address on the 
loopback interface should work just fine:

In the Junos case the lo0 interface already exists in  with 
origin "system", along with an IP address underneath it with origin 
"intended".

In the XR case, both the loopback0 interface and IP address are 
configured, hence when the config is applied both data nodes appear in 
 with the origin "intended".


Hence normally it is up to the device implementation to decide whether 
a particular item of system configuration trumps the intended 
configuration. Whatever the system decides the appropriate value 
appears in  and the origin (if supported) of that value in 
 MUST indicate where it came from. So in the general case, 
I wouldn't expect YANG modules to need to refer to system 
configuration. However, there are some specific cases where it is 
useful to do so (e.g. RFC8343 describes system-controlled interfaces).


> If for some leaf, there is no  configuration , then apply 
> system configuration .
>
For the systems that I work on then I would normally expect an 
explicitly configured value to trump a system value. If the device 
does not allow values other than the system provided value then ideally 
it should deviate the data node to only allow the system assigned value 
to be configured.

If it is a container/list/etc then you may well need to merge the data 
coming from , system and other places as well (e.g. IP 
addressed learned via DHCP)

Thanks,
Rob


> Is my understanding correct ?
>
> With Regards,
>
> Rohit R Ranade
>
> *From:*Robert Wilton [mailto:rwilton@cisco.com]
> *Sent:* 17 May 2018 14:29
> *To:* Rohit R Ranade ; netmod@ietf.org
> *Subject:* Re: [netmod] NMDA System controlled resource
>
> Hi Rohit,
>
> Section 5.3.2 states that you allowed to have configuration in 
> / for resources that could be present on the device 
> but are not currently present. The canonical example would be 
> interface configuration for an interface on a linecard that isn't 
> operational (either because it isn't present, or hasn't completely 
> initialized).
>
> Section 5.3.3 is saying that if the linecard becomes operational, then 
> it may instantiate system controlled entries (in ) for 
> those interfaces. It also states that if there also happens to be 
> configuration in / for those interfaces then that 
> configuration will also get applied as those interfaces as 
> instantiated in . All of the configuration that has been 
> successfully applied would also appear in .
>
> Thanks,
> Rob
>
> On 17/05/2018 04:57, Rohit R Ranade wrote:
>
>     Hi All,
>
>     RFC 8342 has below statement in Section 5.3.3
>
>     If a system-controlled resource has
>
>      matching configuration in  when it appears, the
>     system will
>
>      try to apply the configuration; this causes the configuration to
>
>      appear in  eventually (if application of the
>
>      configuration was successful).
>
>     
>
>     Why does application of configuration for system-controlled
>     resources depend on whether  has configurations for that
>     resource ? The configuration will still get applied as part of
>     system configuration as shown in examples in Section C.1 in the
>     same RFC given below
>
>     In addition to filling in the default value for the auto-negotiation
>
>      enabled leaf, a loopback interface entry is also automatically
>
>     instantiated by the system. All of this is reflected in
>
>     .
>
>     With Regards,
>
>     Rohit R Ranade
>
>
>
>
>     _______________________________________________
>
>     netmod mailing list
>
>     netmod@ietf.org 
>
>     https://www.ietf.org/mailman/listinfo/netmod
>


--------------67BC6E9F4436225DC7C11BF3
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Rohit,

    

    
On 17/05/2018 10:30, Rohit R Ranade
      wrote:

    

    

      
      
      
      

        
Hi
            Robert,

        

        
So
            first , we try to get to know the system configuration.

        
Then
            for the configuration leaves (based on description), check
            whether system configuration trumps the intended
            configuration ? If yes, retain system configuration, Else
            apply intended configuration.

      

    

    I think that this is probably an implementation choice, so my
    comments below are subjective.

    

    E.g. I think that Junos devices always instantiate a loopback
    interface (lo0) even if not configured, but IOS XR does not. This
    is fine, this is just a difference in architecture.

    

    However, for both types of devices, configuring an IP address on the
    loopback interface should work just fine:

    

    In the Junos case the lo0 interface already exists in
    <operational> with origin "system", along with an IP address
    underneath it with origin "intended".

    

    In the XR case, both the loopback0 interface and IP address are
    configured, hence when the config is applied both data nodes appear
    in <operational> with the origin "intended".

    

    

    Hence normally it is up to the device implementation to decide
    whether a particular item of system configuration trumps the
    intended configuration. Whatever the system decides the appropriate
    value appears in <operational> and the origin (if supported)
    of that value in <operational> MUST indicate where it came
    from. So in the general case, I wouldn't expect YANG modules to
    need to refer to system configuration. However, there are some
    specific cases where it is useful to do so (e.g. RFC8343 describes
    system-controlled interfaces).

    

    

    

      

        

        
If
            for some leaf, there is no <intended> configuration ,
            then apply system configuration .

      

    

    For the systems that I work on then I would normally expect an
    explicitly configured value to trump a system value. If the device
    does not allow values other than the system provided value then
    ideally it should deviate the data node to only allow the system
    assigned value to be configured.

    

    If it is a container/list/etc then you may well need to merge the
    data coming from <intended>, system and other places as well
    (e.g. IP addressed learned via DHCP)

    

    Thanks,

    Rob

    

    

    

      

        

        

        
Is
            my understanding correct ?

        

        
With
            Regards,

        

          
Rohit
              R Ranade

        

        

        

          

            
From:
                Robert Wilton [mailto:rwilton@cisco.com]
                

                Sent: 17 May 2018 14:29

                To: Rohit R Ranade
                <rohitrranade@huawei.com>; netmod@ietf.org

                Subject: Re: [netmod] NMDA System controlled
                resource

          

        

        

        
Hi Rohit,

        
Section 5.3.2 states that you allowed to
            have configuration in <running>/<intended> for
            resources that could be present on the device but are not
            currently present. The canonical example would be interface
            configuration for an interface on a linecard that isn't
            operational (either because it isn't present, or hasn't
            completely initialized).

        
Section 5.3.3 is saying that if the
            linecard becomes operational, then it may instantiate system
            controlled entries (in <operational>) for those
            interfaces. It also states that if there also happens to be
            configuration in <running>/<intended> for those
            interfaces then that configuration will also get applied as
            those interfaces as instantiated in <operational>.
            All of the configuration that has been successfully applied
            would also appear in <operational>.

        
Thanks,

            Rob

        

        

          
On 17/05/2018 04:57,
              Rohit R Ranade wrote:

        

        

          
Hi All,

          

          
RFC 8342 has below
              statement in Section 5.3.3

          
If a
              system-controlled resource has

          
 matching
              configuration in <intended> when it appears, the
              system will

          
 try to apply the
              configuration; this causes the configuration to

          
 appear in
              <operational> eventually (if application of the

          
 configuration
              was successful).

          

          
Why does application
              of configuration for system-controlled resources depend on
              whether <intended> has configurations for that
              resource ? The configuration will still get applied as
              part of system configuration as shown in examples in
              Section C.1 in the same RFC given below

          

          
In addition to
              filling in the default value for the auto-negotiation

          
 enabled leaf, a
              loopback interface entry is also automatically

          
instantiated by the
              system. All of this is reflected in

          

              <operational>.

          

          

          
With Regards,

          
Rohit R Ranade

          


              

              

              

          
_______________________________________________

          
netmod mailing list

          
netmod@ietf.org

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

        

        

      

    

    

  


--------------67BC6E9F4436225DC7C11BF3--


From nobody Thu May 17 04:44:23 2018
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 30D7D12EAEF for ; Thu, 17 May 2018 04:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.189
X-Spam-Level: 
X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLnrFUhhvonT for ; Thu, 17 May 2018 04:44:19 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D38B12D881 for ; Thu, 17 May 2018 04:44:19 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id D51DBE47B71D7 for ; Thu, 17 May 2018 12:44:15 +0100 (IST)
Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 17 May 2018 12:44:16 +0100
Received: from DGGEML510-MBS.china.huawei.com ([169.254.3.215]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0382.000; Thu, 17 May 2018 19:44:04 +0800
From: Rohit R Ranade 
To: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] NMDA System controlled resource
Thread-Index: AdPtkflME8Sn/pZvSPiqMr4/Yzk5pv//0HuA//9yM5CAAKJUgP//YUAg
Date: Thu, 17 May 2018 11:44:03 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BBAAF98@dggeml510-mbs.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6BBAAC22@dggeml510-mbs.china.huawei.com> <4da2b372-d950-80c6-5a8e-9fa58951f6a8@cisco.com> <991B70D8B4112A4699D5C00DDBBF878A6BBAAE98@dggeml510-mbs.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BBAAF98dggeml510mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] NMDA System controlled resource
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 May 2018 11:44:22 -0000

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

From: Robert Wilton [mailto:rwilton@cisco.com]
Sent: 17 May 2018 15:42
To: Rohit R Ranade ; netmod@ietf.org
Subject: Re: [netmod] NMDA System controlled resource

Hi Rohit,
On 17/05/2018 10:30, Rohit R Ranade wrote:
Hi Robert,

So first , we try to get to know the system configuration.
Then for the configuration leaves (based on description), check whether sys=
tem configuration trumps the intended configuration ? If yes, retain system=
 configuration, Else apply intended configuration.
I think that this is probably an implementation choice, so my comments belo=
w are subjective.

E.g. I think that Junos devices always instantiate a loopback interface (lo=
0) even if not configured, but IOS XR does not.  This is fine, this is just=
 a difference in architecture.

However, for both types of devices, configuring an IP address on the loopba=
ck interface should work just fine:

In the Junos case the lo0 interface already exists in  with or=
igin "system", along with an IP address underneath it with origin "intended=
".
[Rohit R Ranade] In this case, I think the lo0  interface will be part of s=
tartup DB / running DB. Because if the parent (interface) is part of "inten=
ded" only then a child (IP address) can be part of "intended". Right ?


In the XR case, both the loopback0 interface and IP address are configured,=
 hence when the config is applied both data nodes appear in  w=
ith the origin "intended".


Hence normally  it is up to the device implementation to decide whether a p=
articular item of system configuration trumps the intended configuration.  =
Whatever the system decides the appropriate value appears in  =
and the origin (if supported) of that value in  MUST indicate =
where it came from.  So in the general case, I wouldn't expect YANG modules=
 to need to refer to system configuration.  However, there are some specifi=
c cases where it is useful to do so (e.g. RFC8343 describes system-controll=
ed interfaces).



If for some leaf, there is no  configuration , then apply system =
configuration .
For the systems that I work on then I would normally expect an explicitly c=
onfigured value to trump a system value.   If the device does not allow val=
ues other than the system provided value then ideally it should deviate the=
 data node to only allow the system assigned value to be configured.

If it is a container/list/etc then you may well need to merge the data comi=
ng from , system and other places as well (e.g. IP addressed lear=
ned via DHCP)

Thanks,
Rob




Is my understanding correct ?

With Regards,
Rohit R Ranade

From: Robert Wilton [mailto:rwilton@cisco.com]
Sent: 17 May 2018 14:29
To: Rohit R Ranade ; netmod@ietf.org
Subject: Re: [netmod] NMDA System controlled resource


Hi Rohit,

Section 5.3.2 states that you allowed to have configuration in / for resources that could be present on the device but are not curr=
ently present.  The canonical example would be interface configuration for =
an interface on a linecard that isn't operational (either because it isn't =
present, or hasn't completely initialized).

Section 5.3.3 is saying that if the linecard becomes operational, then it m=
ay instantiate system controlled entries (in ) for those inter=
faces.  It also states that if there also happens to be configuration in / for those interfaces then that configuration will also g=
et applied as those interfaces as instantiated in .  All of th=
e configuration that has been successfully applied would also appear in .

Thanks,
Rob

On 17/05/2018 04:57, Rohit R Ranade wrote:
Hi All,

RFC 8342 has below statement in Section 5.3.3
"If a system-controlled resource has
   matching configuration in  when it appears, the system will
   try to apply the configuration; this causes the configuration to
   appear in  eventually (if application of the
   configuration was successful).
"
Why does application of configuration for system-controlled resources depen=
d on whether  has configurations for that resource ? The configur=
ation will still get applied as part of "system" configuration as shown in =
examples in Section C.1 in the same RFC given below

"In addition to filling in the default value for the auto-negotiation
   enabled leaf, a loopback interface entry is also automatically
instantiated by the system.  All of this is reflected in
   ."


With Regards,
Rohit R Ranade





_______________________________________________

netmod mailing list

netmod@ietf.org

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



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











From: Robert Wilt=
on [mailto:rwilton@cisco.com]


Sent: 17 May 2018 15:42

To: Rohit R Ranade <rohitrranade@huawei.com>; netmod@ietf.org<=
br>
Subject: Re: [netmod] NMDA System controlled resource


 


Hi Rohit,




On 17/05/2018 10:30, Rohit R Ra=
nade wrote:






Hi Robe=
rt,


 <=
/span>


So firs=
t , we try to get to know the system configuration.


Then fo=
r the configuration leaves (based on description), check whether system con=
figuration trumps the intended configuration ? If yes, retain system config=
uration, Else apply intended configuration.




I think that this is probably an implementation choice, so my comm=
ents below are subjective.



E.g. I think that Junos devices always instantiate a loopback interface (lo=
0) even if not configured, but IOS XR does not.  This is fine, this is=
 just a difference in architecture.



However, for both types of devices, configuring an IP address on the loopba=
ck interface should work just fine:



In the Junos case the lo0 interface already exists in <operational> w=
ith origin "system", along with an IP address underneath it with =
origin "intended".


[Rohit R Ranade] In this case, I th=
ink the lo0  interface will be part of startup DB / running DB. Becaus=
e if the parent (interface) is part of “intended”
 only then a child (IP address) can be part of “intended”. Righ=
t ? 






In the XR case, both the loopback0 interface and IP address are configured,=
 hence when the config is applied both data nodes appear in <operational=
> with the origin "intended".





Hence normally  it is up to the device implementation to decide whethe=
r a particular item of system configuration trumps the intended configurati=
on.  Whatever the system decides the appropriate value appears in <=
operational> and the origin (if supported) of
 that value in <operational> MUST indicate where it came from.  =
So in the general case, I wouldn't expect YANG modules to need to refer to =
system configuration.  However, there are some specific cases where it=
 is useful to do so (e.g. RFC8343 describes system-controlled
 interfaces).












If for =
some leaf, there is no <intended> configuration , then apply system c=
onfiguration .




For the systems that I work on then I would normally expect an exp=
licitly configured value to trump a system value.   If
 the device does not allow values other than the system provided value then=
 ideally it should deviate the data node to only allow the system assigned =
value to be configured.



If it is a container/list/etc then you may well need to merge the data comi=
ng from <intended>, system and other places as well (e.g. IP addresse=
d learned via DHCP)



Thanks,

Rob












 <=
/span>


Is my u=
nderstanding correct ?


 <=
/span>


With Re=
gards,




Rohit R=
 Ranade




 <=
/span>






From: Robert Wilt=
on [mailto:rwilton@cisco.com]


Sent: 17 May 2018 14:29

To: Rohit R Ranade <ro=
hitrranade@huawei.com>;
netmod@ietf.org

Subject: Re: [netmod] NMDA System controlled resource






 


Hi Rohit,


Section 5.3.2 states that you allowed to have confi=
guration in <running>/<intended> for resources that could be pr=
esent on the device but are not currently present.  The canonical exam=
ple would be interface configuration for an interface
 on a linecard that isn't operational (either because it isn't present, or =
hasn't completely initialized).


Section 5.3.3 is saying that if the linecard become=
s operational, then it may instantiate system controlled entries (in <op=
erational>) for those interfaces.  It also states that if there als=
o happens to be configuration in <running>/<intended>
 for those interfaces then that configuration will also get applied as thos=
e interfaces as instantiated in <operational>.  All of the confi=
guration that has been successfully applied would also appear in <operat=
ional>.


Thanks,

Rob


 




On 17/05/2018 04:57, Rohit R Ra=
nade wrote:






Hi All,


 


RFC 8342 has below statement in=
 Section 5.3.3


“If a system-controlled=
 resource has


   matching configuration in <intended> w=
hen it appears, the system will


   try to apply the configuration; this causes =
the configuration to


   appear in <operational> eventually (if=
 application of the


   configuration was successful).


“


Why does application of configu=
ration for system-controlled resources depend on whether <intended> h=
as configurations for that resource ? The configuration will still get appl=
ied as part of “system” configuration as shown
 in examples in Section C.1 in the same RFC given below

 


“In addition to filling=
 in the default value for the auto-negotiation<=
o:p>


   enabled leaf, a loopback interface entry is =
also automatically


instantiated by the system.  All of this is reflecte=
d in


   <operational>.”


 


 


With Regards,=



Rohit R Ranade













_______________________________________________


netmod mailing list


netmod@ietf.or=
g


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



 




 






--_000_991B70D8B4112A4699D5C00DDBBF878A6BBAAF98dggeml510mbschi_--


From nobody Thu May 17 04:45:08 2018
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 1EC4B12E8D6 for ; Wed, 16 May 2018 23:13:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXeBcTV7QUqn for ; Wed, 16 May 2018 23:13:04 -0700 (PDT)
Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C7612E8D0 for ; Wed, 16 May 2018 23:13:03 -0700 (PDT)
Received: by mail-wr0-x232.google.com with SMTP id x9-v6so1442315wrl.13 for ; Wed, 16 May 2018 23:13:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=1A7Ny6Q1FS+YiDdWNreEjZeeMJ3MH0JnRvsv9K8pcgs=; b=csTJBn4sOye2Kw6ZTT9H96So3o+j+qSlgx6jtyHXolbWYLm+61G9unqxJr3hw1o5im TXSqfxi2kLNlgE0J5l8AruB594yZ42z/zzbncEVdm8sMuGGTwR6AO8yI3mA0vkDOGyZb pRgVk11jc0CFRGvVJ03H7n1k92JyoMk8qrb3r0JCMBhrZnibaqQztTAK/LH6sD7rn2ci Z/K1aW2uGBp+iVMhPtUHbpEA0OeaHzX+XrVSavY+HdvE/L9ENOhzqNFxZPomkCZdNrqx PeUmHnOYm0L40u5MjHOgPZ69FooDQ6QmQx4ICMdaeEFyHvrq6L6WZWVw7mMw+3HcoY4M PEEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=1A7Ny6Q1FS+YiDdWNreEjZeeMJ3MH0JnRvsv9K8pcgs=; b=DEBRfxaCxE8M/aMieiQOyOIUG85gD0oipWSy/fcKtxKTJlm54EZmdX3QJzzh+J0mMd F7vvK8TN7reAdNAww2XUidS84kgN2UQQztPd01SHd16a5G5J5HzMdHCLCfP9nkQg/zb6 TYHnACgUkxEfPDS2K2h+jHNjBPGWuCY0R+aca5bKc7hTXYqaAqJqXZIdk5fLf7JfLzPs Z+HD9yujc4MFpySfVuCqJcjawSak9DZOuWBaObKo4deKceOWISaDDPpQuw8DPKkpFyux LI1tE14Q4xV8QlpeYgmGxCqO/SvVeEO2CdEugcBq8hwMSkPz0mhVjgv//6IwhsljiXLU ny3Q==
X-Gm-Message-State: ALKqPwfftx6kxqh4JdKexIAr9Bhq7FfGSTy3R3GsO7M0f4Ci3EqOnilZ h94TTfMef0xkiMT2i5xUXBgQsAGlAwM=
X-Google-Smtp-Source: AB8JxZptGUiSBvcuvELTveqsXHDOu8uZEC7PZkVrc3wTHfqMLK41CkX6VeXphk4t33YQyv8P4Y4qsw==
X-Received: by 2002:adf:9b1a:: with SMTP id b26-v6mr3079810wrc.206.1526537581969;  Wed, 16 May 2018 23:13:01 -0700 (PDT)
Received: from [10.192.5.125] (68.150.2.109.rev.sfr.net. [109.2.150.68]) by smtp.gmail.com with ESMTPSA id u35-v6sm5288300wrc.29.2018.05.16.23.13.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 May 2018 23:13:01 -0700 (PDT)
To: RFC Errata System , mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, phil@juniper.net, kwatsen@juniper.net, rwilton@cisco.com, warren@kumari.net, joelja@bogus.com, lberger@labn.net
Cc: rohitrranade@huawei.com, netmod@ietf.org
References: <20180517042534.5E4C7B813FA@rfc-editor.org>
From: Ignas Bagdonas 
Message-ID: 
Date: Thu, 17 May 2018 07:12:59 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <20180517042534.5E4C7B813FA@rfc-editor.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: 
X-Mailman-Approved-At: Thu, 17 May 2018 04:45:05 -0700
Subject: Re: [netmod] [Editorial Errata Reported] RFC8342 (5362)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 May 2018 06:13:06 -0000

Hi there,

Reading the text, this errata appears to be correct - the previous 
obsoleted versions had separate branches, not the new NMDA based ones.

Authors, would you object to this?

Thank you.

Ignas



On 17/05/2018 05:25, RFC Errata System wrote:
> The following errata report has been submitted for RFC8342,
> "Network Management Datastore Architecture (NMDA)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5362
>
> --------------------------------------
> Type: Editorial
> Reported by: Rohit R Ranade 
>
> Section: 2
>
> Original Text
> -------------
> The convention adopted by the interfaces
>     data model [RFC8343] and the IP data model [RFC8344] was to use two
>     separate branches rooted at the root of the data tree: one branch for
>     configuration data objects and one branch for operational state data
>     objects.
>
>
> Corrected Text
> --------------
> The convention adopted by the interfaces
>     data model [RFC7223] and the IP data model [RFC7277] was to use two
>     separate branches rooted at the root of the data tree: one branch for
>     configuration data objects and one branch for operational state data
>     objects.
>
>
> Notes
> -----
> The duplication of definition and separation of operational state data and configuration data happened in RFC7223 and RFC7277. RFC8343 and RFC8344 have corrected this using NMDA architecture
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC8342 (draft-ietf-netmod-revised-datastores-10)
> --------------------------------------
> Title               : Network Management Datastore Architecture (NMDA)
> Publication Date    : March 2018
> Author(s)           : M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton
> Category            : PROPOSED STANDARD
> Source              : Network Modeling
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG


From nobody Thu May 17 04:45:13 2018
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 BAE9212E8A3 for ; Wed, 16 May 2018 21:25:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4ydfdCzlxp7 for ; Wed, 16 May 2018 21:25:38 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AD4612DA4C for ; Wed, 16 May 2018 21:25:38 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 5E4C7B813FA; Wed, 16 May 2018 21:25:34 -0700 (PDT)
To: mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, phil@juniper.net, kwatsen@juniper.net, rwilton@cisco.com, ibagdona@gmail.com, warren@kumari.net,  joelja@bogus.com, kwatsen@juniper.net, lberger@labn.net
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: rohitrranade@huawei.com, netmod@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20180517042534.5E4C7B813FA@rfc-editor.org>
Date: Wed, 16 May 2018 21:25:34 -0700 (PDT)
Archived-At: 
X-Mailman-Approved-At: Thu, 17 May 2018 04:45:06 -0700
Subject: [netmod] [Editorial Errata Reported] RFC8342 (5362)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 May 2018 04:25:40 -0000

The following errata report has been submitted for RFC8342,
"Network Management Datastore Architecture (NMDA)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5362

--------------------------------------
Type: Editorial
Reported by: Rohit R Ranade 

Section: 2

Original Text
-------------
The convention adopted by the interfaces
   data model [RFC8343] and the IP data model [RFC8344] was to use two
   separate branches rooted at the root of the data tree: one branch for
   configuration data objects and one branch for operational state data
   objects.


Corrected Text
--------------
The convention adopted by the interfaces
   data model [RFC7223] and the IP data model [RFC7277] was to use two
   separate branches rooted at the root of the data tree: one branch for
   configuration data objects and one branch for operational state data
   objects.


Notes
-----
The duplication of definition and separation of operational state data and configuration data happened in RFC7223 and RFC7277. RFC8343 and RFC8344 have corrected this using NMDA architecture

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8342 (draft-ietf-netmod-revised-datastores-10)
--------------------------------------
Title               : Network Management Datastore Architecture (NMDA)
Publication Date    : March 2018
Author(s)           : M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton
Category            : PROPOSED STANDARD
Source              : Network Modeling
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG


From nobody Thu May 17 04:45:18 2018
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 CA44212DA72 for ; Wed, 16 May 2018 23:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quNE1WbPNTtC for ; Wed, 16 May 2018 23:57:02 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AF7B91275F4 for ; Wed, 16 May 2018 23:57:02 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 72FE81AE0286; Thu, 17 May 2018 08:57:01 +0200 (CEST)
Date: Thu, 17 May 2018 08:57:00 +0200 (CEST)
Message-Id: <20180517.085700.255479251368623796.mbj@tail-f.com>
To: ibagdona@gmail.com
Cc: rfc-editor@rfc-editor.org, j.schoenwaelder@jacobs-university.de, phil@juniper.net, kwatsen@juniper.net, rwilton@cisco.com, warren@kumari.net, joelja@bogus.com, lberger@labn.net, rohitrranade@huawei.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <20180517042534.5E4C7B813FA@rfc-editor.org> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
X-Mailman-Approved-At: Thu, 17 May 2018 04:45:06 -0700
Subject: Re: [netmod] [Editorial Errata Reported] RFC8342 (5362)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 May 2018 06:57:05 -0000

Ignas Bagdonas  wrote:
> Hi there,
> 
> Reading the text, this errata appears to be correct - the previous
> obsoleted versions had separate branches, not the new NMDA based ones.

I agree.

> Authors, would you object to this?

No, this errata should be accepted.

However, the Informative References section (10.2) also needs to be
updated.


/martin

> 
> Thank you.
> 
> Ignas
> 
> 
> 
> On 17/05/2018 05:25, RFC Errata System wrote:
> > The following errata report has been submitted for RFC8342,
> > "Network Management Datastore Architecture (NMDA)".
> >
> > --------------------------------------
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata/eid5362
> >
> > --------------------------------------
> > Type: Editorial
> > Reported by: Rohit R Ranade 
> >
> > Section: 2
> >
> > Original Text
> > -------------
> > The convention adopted by the interfaces
> >     data model [RFC8343] and the IP data model [RFC8344] was to use two
> >     separate branches rooted at the root of the data tree: one branch for
> >     configuration data objects and one branch for operational state data
> >     objects.
> >
> >
> > Corrected Text
> > --------------
> > The convention adopted by the interfaces
> >     data model [RFC7223] and the IP data model [RFC7277] was to use two
> >     separate branches rooted at the root of the data tree: one branch for
> >     configuration data objects and one branch for operational state data
> >     objects.
> >
> >
> > Notes
> > -----
> > The duplication of definition and separation of operational state data
> > and configuration data happened in RFC7223 and RFC7277. RFC8343 and
> > RFC8344 have corrected this using NMDA architecture
> >
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --------------------------------------
> > RFC8342 (draft-ietf-netmod-revised-datastores-10)
> > --------------------------------------
> > Title               : Network Management Datastore Architecture (NMDA)
> > Publication Date    : March 2018
> > Author(s) : M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen,
> > R. Wilton
> > Category            : PROPOSED STANDARD
> > Source              : Network Modeling
> > Area                : Operations and Management
> > Stream              : IETF
> > Verifying Party     : IESG
> 


From nobody Thu May 17 04:45:42 2018
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 1318412426E for ; Wed, 16 May 2018 23:08:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBFVJXONZqdh for ; Wed, 16 May 2018 23:08:39 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B4FD12E8D0 for ; Wed, 16 May 2018 23:08:39 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 39DCD68F; Thu, 17 May 2018 08:08:38 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Fx1ND0JOdPaS; Thu, 17 May 2018 08:08:37 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 17 May 2018 08:08:38 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E84B120035; Thu, 17 May 2018 08:08:37 +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 a-w1fwPv-mVC; Thu, 17 May 2018 08:08:37 +0200 (CEST)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D2F120031; Thu, 17 May 2018 08:08:35 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 768E142E9F78; Thu, 17 May 2018 08:08:35 +0200 (CEST)
Date: Thu, 17 May 2018 08:08:35 +0200
From: Juergen Schoenwaelder 
To: RFC Errata System 
Cc: mbj@tail-f.com, phil@juniper.net, kwatsen@juniper.net, rwilton@cisco.com, ibagdona@gmail.com, warren@kumari.net, joelja@bogus.com, lberger@labn.net, rohitrranade@huawei.com, netmod@ietf.org
Message-ID: <20180517060835.cbtlciiarfxkk6up@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: RFC Errata System , mbj@tail-f.com, phil@juniper.net, kwatsen@juniper.net, rwilton@cisco.com, ibagdona@gmail.com, warren@kumari.net, joelja@bogus.com, lberger@labn.net, rohitrranade@huawei.com, netmod@ietf.org
References: <20180517042534.5E4C7B813FA@rfc-editor.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180517042534.5E4C7B813FA@rfc-editor.org>
User-Agent: NeoMutt/20171215
Archived-At: 
X-Mailman-Approved-At: Thu, 17 May 2018 04:45:36 -0700
Subject: Re: [netmod] [Editorial Errata Reported] RFC8342 (5362)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 May 2018 06:08:42 -0000

I agree, we screwed this up. These references should have not been
updated to the new versions.

/js

On Wed, May 16, 2018 at 09:25:34PM -0700, RFC Errata System wrote:
> The following errata report has been submitted for RFC8342,
> "Network Management Datastore Architecture (NMDA)".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5362
> 
> --------------------------------------
> Type: Editorial
> Reported by: Rohit R Ranade 
> 
> Section: 2
> 
> Original Text
> -------------
> The convention adopted by the interfaces
>    data model [RFC8343] and the IP data model [RFC8344] was to use two
>    separate branches rooted at the root of the data tree: one branch for
>    configuration data objects and one branch for operational state data
>    objects.
> 
> 
> Corrected Text
> --------------
> The convention adopted by the interfaces
>    data model [RFC7223] and the IP data model [RFC7277] was to use two
>    separate branches rooted at the root of the data tree: one branch for
>    configuration data objects and one branch for operational state data
>    objects.
> 
> 
> Notes
> -----
> The duplication of definition and separation of operational state data and configuration data happened in RFC7223 and RFC7277. RFC8343 and RFC8344 have corrected this using NMDA architecture
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC8342 (draft-ietf-netmod-revised-datastores-10)
> --------------------------------------
> Title               : Network Management Datastore Architecture (NMDA)
> Publication Date    : March 2018
> Author(s)           : M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton
> Category            : PROPOSED STANDARD
> Source              : Network Modeling
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG

-- 
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 17 05:02:44 2018
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 5ABE812D881 for ; Thu, 17 May 2018 05:02:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.189
X-Spam-Level: 
X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSSJDxQDFuMp for ; Thu, 17 May 2018 05:02:39 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30EA112D87C for ; Thu, 17 May 2018 05:02:39 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id DFD449935ED14 for ; Thu, 17 May 2018 13:02:34 +0100 (IST)
Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 17 May 2018 13:02:35 +0100
Received: from DGGEML510-MBS.china.huawei.com ([169.254.3.215]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0382.000; Thu, 17 May 2018 20:02:24 +0800
From: Rohit R Ranade 
To: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] NMDA System controlled resource
Thread-Index: AdPtkflME8Sn/pZvSPiqMr4/Yzk5pv//0HuA//9yM5CAAKJUgP//XEUA
Date: Thu, 17 May 2018 12:02:24 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BBAB006@dggeml510-mbs.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6BBAAC22@dggeml510-mbs.china.huawei.com> <4da2b372-d950-80c6-5a8e-9fa58951f6a8@cisco.com> <991B70D8B4112A4699D5C00DDBBF878A6BBAAE98@dggeml510-mbs.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BBAB006dggeml510mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] NMDA System controlled resource
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 May 2018 12:02:42 -0000

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

Hi Robert,

Thank you for the detailed explanation.
On the same lines that you mentioned, maybe some vendors were showing the l=
oopback interface, as part of running. Once they implement NMDA, is it the =
intention of the authors to mandate that such configurations must be moved =
to "system" ? Currently they may have limitations on such interfaces and do=
not support deletion of such interfaces.

With Regards,
Rohit R Ranade


From: Robert Wilton [mailto:rwilton@cisco.com]
Sent: 17 May 2018 15:42
To: Rohit R Ranade ; netmod@ietf.org
Subject: Re: [netmod] NMDA System controlled resource

Hi Rohit,
On 17/05/2018 10:30, Rohit R Ranade wrote:
Hi Robert,

So first , we try to get to know the system configuration.
Then for the configuration leaves (based on description), check whether sys=
tem configuration trumps the intended configuration ? If yes, retain system=
 configuration, Else apply intended configuration.
I think that this is probably an implementation choice, so my comments belo=
w are subjective.

E.g. I think that Junos devices always instantiate a loopback interface (lo=
0) even if not configured, but IOS XR does not.  This is fine, this is just=
 a difference in architecture.

However, for both types of devices, configuring an IP address on the loopba=
ck interface should work just fine:

In the Junos case the lo0 interface already exists in  with or=
igin "system", along with an IP address underneath it with origin "intended=
".

In the XR case, both the loopback0 interface and IP address are configured,=
 hence when the config is applied both data nodes appear in  w=
ith the origin "intended".


Hence normally  it is up to the device implementation to decide whether a p=
articular item of system configuration trumps the intended configuration.  =
Whatever the system decides the appropriate value appears in  =
and the origin (if supported) of that value in  MUST indicate =
where it came from.  So in the general case, I wouldn't expect YANG modules=
 to need to refer to system configuration.  However, there are some specifi=
c cases where it is useful to do so (e.g. RFC8343 describes system-controll=
ed interfaces).



If for some leaf, there is no  configuration , then apply system =
configuration .
For the systems that I work on then I would normally expect an explicitly c=
onfigured value to trump a system value.   If the device does not allow val=
ues other than the system provided value then ideally it should deviate the=
 data node to only allow the system assigned value to be configured.

If it is a container/list/etc then you may well need to merge the data comi=
ng from , system and other places as well (e.g. IP addressed lear=
ned via DHCP)

Thanks,
Rob




Is my understanding correct ?

With Regards,
Rohit R Ranade

From: Robert Wilton [mailto:rwilton@cisco.com]
Sent: 17 May 2018 14:29
To: Rohit R Ranade ; netmod@ietf.org
Subject: Re: [netmod] NMDA System controlled resource


Hi Rohit,

Section 5.3.2 states that you allowed to have configuration in / for resources that could be present on the device but are not curr=
ently present.  The canonical example would be interface configuration for =
an interface on a linecard that isn't operational (either because it isn't =
present, or hasn't completely initialized).

Section 5.3.3 is saying that if the linecard becomes operational, then it m=
ay instantiate system controlled entries (in ) for those inter=
faces.  It also states that if there also happens to be configuration in / for those interfaces then that configuration will also g=
et applied as those interfaces as instantiated in .  All of th=
e configuration that has been successfully applied would also appear in .

Thanks,
Rob

On 17/05/2018 04:57, Rohit R Ranade wrote:
Hi All,

RFC 8342 has below statement in Section 5.3.3
"If a system-controlled resource has
   matching configuration in  when it appears, the system will
   try to apply the configuration; this causes the configuration to
   appear in  eventually (if application of the
   configuration was successful).
"
Why does application of configuration for system-controlled resources depen=
d on whether  has configurations for that resource ? The configur=
ation will still get applied as part of "system" configuration as shown in =
examples in Section C.1 in the same RFC given below

"In addition to filling in the default value for the auto-negotiation
   enabled leaf, a loopback interface entry is also automatically
instantiated by the system.  All of this is reflected in
   ."


With Regards,
Rohit R Ranade





_______________________________________________

netmod mailing list

netmod@ietf.org

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



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











Hi Robe=
rt,


&n=
bsp;


Thank y=
ou for the detailed explanation.


On the =
same lines that you mentioned, maybe some vendors were showing the loopback=
 interface, as part of running. Once they implement NMDA, is it the intenti=
on of the authors to mandate that such
 configurations must be moved to “system” ? Currently they may =
have limitations on such interfaces and donot support deletion of such inte=
rfaces.


&n=
bsp;


With Re=
gards,




Rohit R=
 Ranade


&n=
bsp;




&n=
bsp;






From: Robert Wilt=
on [mailto:rwilton@cisco.com]


Sent: 17 May 2018 15:42

To: Rohit R Ranade <rohitrranade@huawei.com>; netmod@ietf.org<=
br>
Subject: Re: [netmod] NMDA System controlled resource






 


Hi Rohit,




On 17/05/2018 10:30, Rohit R Ra=
nade wrote:






Hi Robe=
rt,


 <=
/span>


So firs=
t , we try to get to know the system configuration.


Then fo=
r the configuration leaves (based on description), check whether system con=
figuration trumps the intended configuration ? If yes, retain system config=
uration, Else apply intended configuration.




I think that this is probably an implementation choice, so my comm=
ents below are subjective.



E.g. I think that Junos devices always instantiate a loopback interface (lo=
0) even if not configured, but IOS XR does not.  This is fine, this is=
 just a difference in architecture.



However, for both types of devices, configuring an IP address on the loopba=
ck interface should work just fine:



In the Junos case the lo0 interface already exists in <operational> w=
ith origin "system", along with an IP address underneath it with =
origin "intended".



In the XR case, both the loopback0 interface and IP address are configured,=
 hence when the config is applied both data nodes appear in <operational=
> with the origin "intended".





Hence normally  it is up to the device implementation to decide whethe=
r a particular item of system configuration trumps the intended configurati=
on.  Whatever the system decides the appropriate value appears in <=
operational> and the origin (if supported) of
 that value in <operational> MUST indicate where it came from.  =
So in the general case, I wouldn't expect YANG modules to need to refer to =
system configuration.  However, there are some specific cases where it=
 is useful to do so (e.g. RFC8343 describes system-controlled
 interfaces).












If for =
some leaf, there is no <intended> configuration , then apply system c=
onfiguration .




For the systems that I work on then I would normally expect an exp=
licitly configured value to trump a system value.   If
 the device does not allow values other than the system provided value then=
 ideally it should deviate the data node to only allow the system assigned =
value to be configured.



If it is a container/list/etc then you may well need to merge the data comi=
ng from <intended>, system and other places as well (e.g. IP addresse=
d learned via DHCP)



Thanks,

Rob












 <=
/span>


Is my u=
nderstanding correct ?


 <=
/span>


With Re=
gards,




Rohit R=
 Ranade




 <=
/span>






From: Robert Wilt=
on [mailto:rwilton@cisco.com]


Sent: 17 May 2018 14:29

To: Rohit R Ranade <ro=
hitrranade@huawei.com>;
netmod@ietf.org

Subject: Re: [netmod] NMDA System controlled resource






 


Hi Rohit,


Section 5.3.2 states that you allowed to have confi=
guration in <running>/<intended> for resources that could be pr=
esent on the device but are not currently present.  The canonical exam=
ple would be interface configuration for an interface
 on a linecard that isn't operational (either because it isn't present, or =
hasn't completely initialized).


Section 5.3.3 is saying that if the linecard become=
s operational, then it may instantiate system controlled entries (in <op=
erational>) for those interfaces.  It also states that if there als=
o happens to be configuration in <running>/<intended>
 for those interfaces then that configuration will also get applied as thos=
e interfaces as instantiated in <operational>.  All of the confi=
guration that has been successfully applied would also appear in <operat=
ional>.


Thanks,

Rob


 




On 17/05/2018 04:57, Rohit R Ra=
nade wrote:






Hi All,


 


RFC 8342 has below statement in=
 Section 5.3.3


“If a system-controlled=
 resource has


   matching configuration in <intended> w=
hen it appears, the system will


   try to apply the configuration; this causes =
the configuration to


   appear in <operational> eventually (if=
 application of the


   configuration was successful).


“


Why does application of configu=
ration for system-controlled resources depend on whether <intended> h=
as configurations for that resource ? The configuration will still get appl=
ied as part of “system” configuration as shown
 in examples in Section C.1 in the same RFC given below

 


“In addition to filling=
 in the default value for the auto-negotiation<=
o:p>


   enabled leaf, a loopback interface entry is =
also automatically


instantiated by the system.  All of this is reflecte=
d in


   <operational>.”


 


 


With Regards,=



Rohit R Ranade













_______________________________________________


netmod mailing list


netmod@ietf.or=
g


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



 




 






--_000_991B70D8B4112A4699D5C00DDBBF878A6BBAB006dggeml510mbschi_--


From nobody Thu May 17 06:12:45 2018
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 A31C112DB6D for ; Thu, 17 May 2018 06:12:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgYZRthbqmEM for ; Thu, 17 May 2018 06:12:37 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31BE3128C0A for ; Thu, 17 May 2018 06:12:36 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 28829BE2; Thu, 17 May 2018 15:12:35 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id iLH782Fe00to; Thu, 17 May 2018 15:12: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 atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 17 May 2018 15:12:35 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0C22020035; Thu, 17 May 2018 15:12:35 +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 uGHC2duV04qX; Thu, 17 May 2018 15:12:34 +0200 (CEST)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B1C220031; Thu, 17 May 2018 15:12:34 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 964D542EAB8A; Thu, 17 May 2018 15:12:32 +0200 (CEST)
Date: Thu, 17 May 2018 15:12:32 +0200
From: Juergen Schoenwaelder 
To: Rohit R Ranade 
Cc: Robert Wilton , "netmod@ietf.org" 
Message-ID: <20180517131232.fdda6mkreujwnneq@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Rohit R Ranade , Robert Wilton , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6BBAAC22@dggeml510-mbs.china.huawei.com> <4da2b372-d950-80c6-5a8e-9fa58951f6a8@cisco.com> <991B70D8B4112A4699D5C00DDBBF878A6BBAAE98@dggeml510-mbs.china.huawei.com>  <991B70D8B4112A4699D5C00DDBBF878A6BBAB006@dggeml510-mbs.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BBAB006@dggeml510-mbs.china.huawei.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] NMDA System controlled resource
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 May 2018 13:12:42 -0000

Deletion of an interface != deletion of explicit configuration of an
interface. NMDA allows to make this distinction and in a way that a
client can discover what is going on.

/js

On Thu, May 17, 2018 at 12:02:24PM +0000, Rohit R Ranade wrote:
> Hi Robert,
> 
> Thank you for the detailed explanation.
> On the same lines that you mentioned, maybe some vendors were showing the loopback interface, as part of running. Once they implement NMDA, is it the intention of the authors to mandate that such configurations must be moved to "system" ? Currently they may have limitations on such interfaces and donot support deletion of such interfaces.
> 
> With Regards,
> Rohit R Ranade
> 
> 
> From: Robert Wilton [mailto:rwilton@cisco.com]
> Sent: 17 May 2018 15:42
> To: Rohit R Ranade ; netmod@ietf.org
> Subject: Re: [netmod] NMDA System controlled resource
> 
> Hi Rohit,
> On 17/05/2018 10:30, Rohit R Ranade wrote:
> Hi Robert,
> 
> So first , we try to get to know the system configuration.
> Then for the configuration leaves (based on description), check whether system configuration trumps the intended configuration ? If yes, retain system configuration, Else apply intended configuration.
> I think that this is probably an implementation choice, so my comments below are subjective.
> 
> E.g. I think that Junos devices always instantiate a loopback interface (lo0) even if not configured, but IOS XR does not.  This is fine, this is just a difference in architecture.
> 
> However, for both types of devices, configuring an IP address on the loopback interface should work just fine:
> 
> In the Junos case the lo0 interface already exists in  with origin "system", along with an IP address underneath it with origin "intended".
> 
> In the XR case, both the loopback0 interface and IP address are configured, hence when the config is applied both data nodes appear in  with the origin "intended".
> 
> 
> Hence normally  it is up to the device implementation to decide whether a particular item of system configuration trumps the intended configuration.  Whatever the system decides the appropriate value appears in  and the origin (if supported) of that value in  MUST indicate where it came from.  So in the general case, I wouldn't expect YANG modules to need to refer to system configuration.  However, there are some specific cases where it is useful to do so (e.g. RFC8343 describes system-controlled interfaces).
> 
> 
> 
> If for some leaf, there is no  configuration , then apply system configuration .
> For the systems that I work on then I would normally expect an explicitly configured value to trump a system value.   If the device does not allow values other than the system provided value then ideally it should deviate the data node to only allow the system assigned value to be configured.
> 
> If it is a container/list/etc then you may well need to merge the data coming from , system and other places as well (e.g. IP addressed learned via DHCP)
> 
> Thanks,
> Rob
> 
> 
> 
> 
> Is my understanding correct ?
> 
> With Regards,
> Rohit R Ranade
> 
> From: Robert Wilton [mailto:rwilton@cisco.com]
> Sent: 17 May 2018 14:29
> To: Rohit R Ranade ; netmod@ietf.org
> Subject: Re: [netmod] NMDA System controlled resource
> 
> 
> Hi Rohit,
> 
> Section 5.3.2 states that you allowed to have configuration in / for resources that could be present on the device but are not currently present.  The canonical example would be interface configuration for an interface on a linecard that isn't operational (either because it isn't present, or hasn't completely initialized).
> 
> Section 5.3.3 is saying that if the linecard becomes operational, then it may instantiate system controlled entries (in ) for those interfaces.  It also states that if there also happens to be configuration in / for those interfaces then that configuration will also get applied as those interfaces as instantiated in .  All of the configuration that has been successfully applied would also appear in .
> 
> Thanks,
> Rob
> 
> On 17/05/2018 04:57, Rohit R Ranade wrote:
> Hi All,
> 
> RFC 8342 has below statement in Section 5.3.3
> "If a system-controlled resource has
>    matching configuration in  when it appears, the system will
>    try to apply the configuration; this causes the configuration to
>    appear in  eventually (if application of the
>    configuration was successful).
> "
> Why does application of configuration for system-controlled resources depend on whether  has configurations for that resource ? The configuration will still get applied as part of "system" configuration as shown in examples in Section C.1 in the same RFC given below
> 
> "In addition to filling in the default value for the auto-negotiation
>    enabled leaf, a loopback interface entry is also automatically
> instantiated by the system.  All of this is reflected in
>    ."
> 
> 
> With Regards,
> Rohit R Ranade
> 
> 
> 
> 
> 
> _______________________________________________
> 
> 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


-- 
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 17 07:03:23 2018
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 D8F6E12EB25 for ; Thu, 17 May 2018 07:03:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hn0G2U_jTRz6 for ; Thu, 17 May 2018 07:03:16 -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 DE6C312EAB3 for ; Thu, 17 May 2018 07:03:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7118; q=dns/txt; s=iport; t=1526565796; x=1527775396; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=kZYpXYk//NJznrtKhIjKNKzNwsUWgWu55nxtQwo8rFE=; b=NmBR7h/6U7vRUHvFCnMQQD9sVNZfoZQ1f5KDivdsO95HtyiLrHMycL1h J2SNSzwpOMLoNHINXaxlnN3eff5h+udVX74c0XNLdKzwm/M6p3ijNEsKS eG+oGlb1ujVL8RdCVOvPPw1fK0ISy8+bBorhpXPfWfsvdo/X32pQwXAhi 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DvAQB8g/1a/xbLJq1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYMUgRB9KIN0iGKNcSGBD5NKgWQLGAuEA0YCgjA3FQECAQEBAQE?= =?us-ascii?q?BAmwcDIUoAQEBAQMBASEPAQU2GwsRAQMBAQECAiMDAgInHwMGCAYBDAYCAQE?= =?us-ascii?q?XgwgCgX8PpnqCHIRYg3OCIgWBCYh5P4EPIwyCXYMRAQGBKR+DGIJUAphICY5?= =?us-ascii?q?OBodehRqLRoUsgSUyIoFSMxoIGxU7gkOLEIU/PjCNWwIkB4IZAQE?=
X-IronPort-AV: E=Sophos;i="5.49,410,1520899200";  d="scan'208";a="3913971"
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; 17 May 2018 14:03:13 +0000
Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w4HE3Deq010812; Thu, 17 May 2018 14:03:13 GMT
To: Rohit R Ranade , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6BBAAC22@dggeml510-mbs.china.huawei.com> <4da2b372-d950-80c6-5a8e-9fa58951f6a8@cisco.com> <991B70D8B4112A4699D5C00DDBBF878A6BBAAE98@dggeml510-mbs.china.huawei.com>  <991B70D8B4112A4699D5C00DDBBF878A6BBAB006@dggeml510-mbs.china.huawei.com> <20180517131232.fdda6mkreujwnneq@elstar.local>
From: Robert Wilton 
Message-ID: <4ca72aae-8755-21fd-1454-4e681dd4d2ee@cisco.com>
Date: Thu, 17 May 2018 15:03:13 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <20180517131232.fdda6mkreujwnneq@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] NMDA System controlled resource
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 May 2018 14:03:23 -0000

To add to Juergen's comments:

If a system writes to  then it can causes a few potential problems:

(1) A client could be surprised to see configuration appear in  
that it hasn't provided.
(2) A client could reasonably expect to be able to delete any/all of the 
configuration in , but that isn't possible if it is a system 
created data node that can't be removed.
(3) If removing a linecard is allowed to remove the associated 
configuration from  then that could easily make  
become invalid, breaking one of the invariants of the  
datastore and leaving the system in an inconsistent state.

Hence, I believe that the cleanest solution is to instantiate the system 
created data nodes only in .  However, this may require 
that customers also explicitly configure those data nodes to ensure that 
all configuration reference constraints are met for the configuration to 
validate.  Generally, I don't see this as a problem, since it is likely 
that you would have at least some configuration on an interface that is 
referenced.  Also having a referentially complete configuration is 
generally a sound principle, e.g. it also opens up a path to being able 
to validate the configuration off the box as well.

Thanks,
Rob


On 17/05/2018 14:12, Juergen Schoenwaelder wrote:
> Deletion of an interface != deletion of explicit configuration of an
> interface. NMDA allows to make this distinction and in a way that a
> client can discover what is going on.
>
> /js
>
> On Thu, May 17, 2018 at 12:02:24PM +0000, Rohit R Ranade wrote:
>> Hi Robert,
>>
>> Thank you for the detailed explanation.
>> On the same lines that you mentioned, maybe some vendors were showing the loopback interface, as part of running. Once they implement NMDA, is it the intention of the authors to mandate that such configurations must be moved to "system" ? Currently they may have limitations on such interfaces and donot support deletion of such interfaces.
>>
>> With Regards,
>> Rohit R Ranade
>>
>>
>> From: Robert Wilton [mailto:rwilton@cisco.com]
>> Sent: 17 May 2018 15:42
>> To: Rohit R Ranade ; netmod@ietf.org
>> Subject: Re: [netmod] NMDA System controlled resource
>>
>> Hi Rohit,
>> On 17/05/2018 10:30, Rohit R Ranade wrote:
>> Hi Robert,
>>
>> So first , we try to get to know the system configuration.
>> Then for the configuration leaves (based on description), check whether system configuration trumps the intended configuration ? If yes, retain system configuration, Else apply intended configuration.
>> I think that this is probably an implementation choice, so my comments below are subjective.
>>
>> E.g. I think that Junos devices always instantiate a loopback interface (lo0) even if not configured, but IOS XR does not.  This is fine, this is just a difference in architecture.
>>
>> However, for both types of devices, configuring an IP address on the loopback interface should work just fine:
>>
>> In the Junos case the lo0 interface already exists in  with origin "system", along with an IP address underneath it with origin "intended".
>>
>> In the XR case, both the loopback0 interface and IP address are configured, hence when the config is applied both data nodes appear in  with the origin "intended".
>>
>>
>> Hence normally  it is up to the device implementation to decide whether a particular item of system configuration trumps the intended configuration.  Whatever the system decides the appropriate value appears in  and the origin (if supported) of that value in  MUST indicate where it came from.  So in the general case, I wouldn't expect YANG modules to need to refer to system configuration.  However, there are some specific cases where it is useful to do so (e.g. RFC8343 describes system-controlled interfaces).
>>
>>
>>
>> If for some leaf, there is no  configuration , then apply system configuration .
>> For the systems that I work on then I would normally expect an explicitly configured value to trump a system value.   If the device does not allow values other than the system provided value then ideally it should deviate the data node to only allow the system assigned value to be configured.
>>
>> If it is a container/list/etc then you may well need to merge the data coming from , system and other places as well (e.g. IP addressed learned via DHCP)
>>
>> Thanks,
>> Rob
>>
>>
>>
>>
>> Is my understanding correct ?
>>
>> With Regards,
>> Rohit R Ranade
>>
>> From: Robert Wilton [mailto:rwilton@cisco.com]
>> Sent: 17 May 2018 14:29
>> To: Rohit R Ranade ; netmod@ietf.org
>> Subject: Re: [netmod] NMDA System controlled resource
>>
>>
>> Hi Rohit,
>>
>> Section 5.3.2 states that you allowed to have configuration in / for resources that could be present on the device but are not currently present.  The canonical example would be interface configuration for an interface on a linecard that isn't operational (either because it isn't present, or hasn't completely initialized).
>>
>> Section 5.3.3 is saying that if the linecard becomes operational, then it may instantiate system controlled entries (in ) for those interfaces.  It also states that if there also happens to be configuration in / for those interfaces then that configuration will also get applied as those interfaces as instantiated in .  All of the configuration that has been successfully applied would also appear in .
>>
>> Thanks,
>> Rob
>>
>> On 17/05/2018 04:57, Rohit R Ranade wrote:
>> Hi All,
>>
>> RFC 8342 has below statement in Section 5.3.3
>> "If a system-controlled resource has
>>     matching configuration in  when it appears, the system will
>>     try to apply the configuration; this causes the configuration to
>>     appear in  eventually (if application of the
>>     configuration was successful).
>> "
>> Why does application of configuration for system-controlled resources depend on whether  has configurations for that resource ? The configuration will still get applied as part of "system" configuration as shown in examples in Section C.1 in the same RFC given below
>>
>> "In addition to filling in the default value for the auto-negotiation
>>     enabled leaf, a loopback interface entry is also automatically
>> instantiated by the system.  All of this is reflected in
>>     ."
>>
>>
>> With Regards,
>> Rohit R Ranade
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> 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 Thu May 17 09:36:41 2018
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 F2BC712E8DF for ; Thu, 17 May 2018 09:36:38 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQ20lVOpEhas for ; Thu, 17 May 2018 09:36:36 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 4FEE4124F57 for ; Thu, 17 May 2018 09:36:36 -0700 (PDT)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4HGXsW1029059 for ; Thu, 17 May 2018 09:36:35 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=Qyjia1kOaDPPcYYQATkzAJroY9NTv8ddaeWmpftOrJg=; b=BSSI6vkAwfLWFFarZzugAajHuhZho+UzdMSZ39sbto6VBuTQfi6Jct8puhrc84Z0Hl7E lN7uXKdGIgwi2/kSz2ZBubgqUKQ6BOMnO4NpsQyOhLLuxHrLtdXCOG9oXOkeIC5u84pB Q3bRRI4j/Z9bW5H4CigJsAfUZBiv5qN9dgAPndg/K33R87Oo0uk46qpCNgAnf6mYNFbN Kk943UpX+7g3Qcn4QMJyAR0O4V5HW/5fUEjl5ySTYnFTQAyZduwAMyOz4eie30O0W3tk 98PnnKCvcTT2+SzS2oJWrvJYOFhiJhY1KU9Y4Lo1+t8eRXnlumtvJiCallIzmx0bB1yr RQ== 
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0120.outbound.protection.outlook.com [207.46.163.120]) by mx0b-00273201.pphosted.com with ESMTP id 2j1cfv856f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 17 May 2018 09:36:35 -0700
Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4038.namprd05.prod.outlook.com (52.135.199.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.776.4; Thu, 17 May 2018 16:36:33 +0000
Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::5c50:c79f:dbd0:7a9a]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::5c50:c79f:dbd0:7a9a%13]) with mapi id 15.20.0776.008; Thu, 17 May 2018 16:36:33 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] IPR call on draft-ietf-netmod-acl-model-18
Thread-Index: AQHT4YeDC6Spas57z02IfO7BNMTXtqQvTzIAgAHGcwCAAt6tAA==
Date: Thu, 17 May 2018 16:36:33 +0000
Message-ID: <3372A2D3-C784-4E63-8769-61543EA06690@juniper.net>
References: <60E03C57-6239-4C07-8ECE-4FD788B9002A@juniper.net> <3d0400df-7140-4286-563f-390d56e0c248@cisco.com> <2D6E0A78-F6C0-4013-9373-4C0A39AC3C69@blairhome.com>
In-Reply-To: <2D6E0A78-F6C0-4013-9373-4C0A39AC3C69@blairhome.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB4038; 7:x89JyyJJCIKGaHtyi2qVrFOItNNfgNAbR+QrGnCw2sjt+h4+uSqFkJ4A60kQ4VUUv+2jxJI5aZHWbK/JYgz1Y/D5v/xxp3SqwR6KvP1PpeEGdBFFWgZb/E5ZLHDY5HzYBwunM7umj46ydq+b4USGmVyhKS1XUEfUVU0pSE/AtanFwYIR67QoaJ+leJ9mrEydW/FUNeRMmr20quY61Fk1sbikrPdLQQB+FCx+Kxaw8/f8Xqjfiiblg3Ha4e29PXw9
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4038; 
x-ms-traffictypediagnostic: BYAPR05MB4038:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(95692535739014)(21748063052155); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231254)(944501410)(52105095)(93006095)(93001095)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB4038; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4038; 
x-forefront-prvs: 067553F396
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(366004)(346002)(396003)(376002)(189003)(199004)(14454004)(66066001)(53546011)(229853002)(186003)(5640700003)(7736002)(6506007)(5660300001)(3280700002)(966005)(3660700001)(2501003)(478600001)(6486002)(6306002)(54896002)(102836004)(5250100002)(2906002)(26005)(53936002)(6512007)(6436002)(2900100001)(2473003)(236005)(105586002)(316002)(575784001)(86362001)(6916009)(25786009)(99286004)(97736004)(3846002)(68736007)(106356001)(2351001)(8676002)(2616005)(8936002)(33656002)(82746002)(1730700003)(81166006)(476003)(446003)(81156014)(76176011)(58126008)(83716003)(36756003)(11346002)(6116002)(486006)(48284002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4038; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: kv06/hhpIKNL6PRzM7T6t2edih2FGrwHud198MH7H+t6I13Tf1OkJyTcR591sJ2fV8FpsD42Xyb4wTktWehxXcmOSiAGdPSLMb6DUs+tFgSL/6a/SFQUCnmd+wcUO+J9+4Oowp89WPtcDECDPkKoLxNnWKv9Z2BJuKpcyPEB1wOKP8Zp93WRdjmOBNmxOWbt
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_3372A2D3C7844E63876961543EA06690junipernet_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 85032fa5-4266-4afa-59cc-08d5bc1459c0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 85032fa5-4266-4afa-59cc-08d5bc1459c0
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2018 16:36:33.3314 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4038
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-17_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805170154
Archived-At: 
Subject: [netmod] FW:  IPR call on draft-ietf-netmod-acl-model-18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 May 2018 16:36:39 -0000

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

Rm9yd2FyZGluZyB0byB0aGUgbmV0bW9kIGxpc3QsIGZvciBnZW5lcmFsIGF3YXJlbmVzcyBhbmQg
cG9zdGVyaXR5Lg0KDQoNCk9uIDUvMTUvMTgsIDEyOjQ3IFBNLCAiRGFuYSBCbGFpciIgPGRhbmFA
YmxhaXJob21lLmNvbTxtYWlsdG86ZGFuYUBibGFpcmhvbWUuY29tPj4gd3JvdGU6DQoNCk5vLCBJ
4oCZbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4NCg0K
dGhhbmtzLA0KRGFuYQ0KDQoNCk9uIE1heSAxNCwgMjAxOCwgYXQgOTo0MCBBTSwgQmVub2l0IENs
YWlzZSA8YmNsYWlzZUBjaXNjby5jb20+IHdyb3RlOg0KDQpJbmNsdWRpbmcgRGFuYSdzIGVtYWls
IGFkZHJlc3MuDQoNClJlZ2FyZHMsIEIuDQoNClRoYW5rIHlvdSwgTWFoZXNoIGFuZCBTb25hbC4N
Cg0KSSdtIHN0aWxsIHdhaXRpbmcgdG8gaGVhciBmcm9tIExpc2EgYW5kIERhbmEuICBOZWl0aGVy
IGhhdmUgYmVlbiBoZWFyZCBmcm9tIHNpbmNlIHRoZSBwZW4gbW92ZWQgYSBjb3VwbGUgeWVhcnMg
YWdvLiAgSXMgYW55b25lIGF3YXJlIG9mIExpc2Egb3IgRGFuYSdzIGN1cnJlbnQgZW1haWw/DQoN
CkxldCdzIGdpdmUgaXQgYSBmZXcgZGF5cyBidXQsIGlmIHdlIGRvbid0IGhlYXIgYmFjayBmcm9t
IHRoZW0gc2hvcnRseSwgSSByZWNvbW1lbmQgbW92aW5nIHRoZWlyIG5hbWVzIGZyb20gYXV0aG9y
cyB0byBjb250cmlidXRvcnMgc28gd2UgY2FuIHVuYmxvY2sgdGhlIHB1Ymxpc2hpbmcgcHJvY2Vz
cy4NCg0KVGhhbmtzLA0KS2VudCAvLyBzaGVwaGVyZA0KDQoNCj09PT09IG9yaWdpbmFsIG1lc3Nh
Z2UgPT09PT0NCg0KQXV0aG9ycywgQ29udHJpYnV0b3JzLCBXRywNCg0KQXMgcGFydCBvZiBTaGVw
aGVyZCB3cml0ZS11cCBmb3IgdGhlIGFjbC1tb2RlbCBkcmFmdCwgd2UgbmVlZCB0byBlbnN1cmUg
dGhhdCBhbGwgSVBSIGhhcyBiZWVuIGRlY2xhcmVkLiAgVGhlcmUgd2FzIGFuIElQUi1jYWxsIGJl
Zm9yZSwgd2hlbiB0aGVyZSB3YXMgYSBkaWZmZXJlbnQgc2V0IG9mIGF1dGhvcnMgaW52b2x2ZWQs
IGJ1dCBub3Qgc2luY2UsIHNvIGl0IHNlZW1zIHBydWRlbnQgdG8gZG8gYW5vdGhlciBjYWxsIG5v
dy4NCg0KQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdCBpZGVu
dGlmaWVkIGFib3ZlPw0KDQoNClBsZWFzZSBzdGF0ZSBlaXRoZXI6DQogICAiTm8sIEknbSBub3Qg
YXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCiBvcg0KICAgIlll
cywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCg0KDQpJZiB5
ZXMsIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJ
UFIgcnVsZXMNCihzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRl
dGFpbHMpPyBQbGVhc2Ugc3RhdGUNCmVpdGhlcjoNCiAgICJZZXMsIHRoZSBJUFIgaGFzIGJlZW4g
ZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyINCiBvcg0KICAgIk5v
LCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQiDQoNCklmIG5vLCBwbGVhc2UgcHJvdmlk
ZSBhbnkgYWRkaXRpb25hbCBkZXRhaWxzIHlvdSB0aGluayBhcHByb3ByaWF0ZS4NCg0KDQpJZiB5
b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciwgcGxlYXNl
IGFuc3dlciB0aGUNCmFib3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNz
IG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUNCmF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuIFRo
aXMgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dA0Kc3RhZ2UgdW50aWwgYSBy
ZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBsaXN0ZWQNCmNv
bnRyaWJ1dG9yLiBOT1RFOiBUSElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBMSVNURUQgSU4gVEhJ
UyBNRVNTQUdFJ1MNClRPIExJTkVTLg0KDQoNCklmIHlvdSBhcmUgb24gdGhlIFdHIGVtYWlsIGxp
c3Qgb3IgYXR0ZW5kIFdHIG1lZXRpbmdzIGJ1dCBhcmUgbm90IGxpc3RlZA0KYXMgYW4gYXV0aG9y
IG9yIGNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXIg
dGhlDQpJRVRGIElQUiBydWxlcyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElF
VEYgaWYgeW91IGFyZSBhd2FyZQ0Kb2YgSVBSIG9mIG90aGVycyBvbiBhbiBJRVRGIGNvbnRyaWJ1
dGlvbiwgb3IgdG8gcmVmcmFpbiBmcm9tIHBhcnRpY2lwYXRpbmcNCmluIGFueSBjb250cmlidXRp
b24gb3IgZGlzY3Vzc2lvbiByZWxhdGVkIHRvIHlvdXIgdW5kaXNjbG9zZWQgSVBSLiBGb3INCm1v
cmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlIGFuZA0KaHR0
cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3RyYWMudG9v
bHMuaWV0Zi5vcmdfZ3JvdXBfaWVzZ190cmFjX3dpa2lfSW50ZWxsZWN0dWFsUHJvcGVydHkmZD1E
d0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXpr
UDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPXlqMGhROVNfeHJhZUti
aVN2N01jWlkxZGlCVlZSNEVVNzhobmtsckkyNEkmcz14WC1paC1NcFoxcWtYaFlsczFVUURBSzdX
dVRKbk9jMjluN1pwNG5rX0djJmU9Lg0KDQpUaGFuayB5b3UsDQoNCktlbnQgLy8gZG9jdW1lbnQg
c2hlcGhlcmQgYW5kIGNvLWNoYWlyDQoNCg0KUFM6IFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0ZWQg
aW4gdGhlIGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXIgcmVzcG9uc2UuDQoNCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWls
aW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu
Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRt
b2QmZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJ
JnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPXlqMGhROVNf
eHJhZUtiaVN2N01jWlkxZGlCVlZSNEVVNzhobmtsckkyNEkmcz1tLXBiSW1UbE1JVk8wN0lMQzBT
cGhBLWIzRC0zdXJNU09QUjNZU1d3UVhrJmU9DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRm
Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCi4NCg0K
DQo=

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

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCglj
b2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9u
Om5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXtt
c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl
Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk
U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu
IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z
dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i
Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkZvcndhcmRp
bmcgdG8gdGhlIG5ldG1vZCBsaXN0LCBmb3IgZ2VuZXJhbCBhd2FyZW5lc3MgYW5kIHBvc3Rlcml0
eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+T24gNS8xNS8xOCwgMTI6NDcgUE0sICZxdW90O0RhbmEgQmxhaXImcXVvdDsgJmx0OzxhIGhy
ZWY9Im1haWx0bzpkYW5hQGJsYWlyaG9tZS5jb20iPmRhbmFAYmxhaXJob21lLmNvbTwvYT4mZ3Q7
IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPk5vLCBJ4oCZbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMg
dG8gdGhpcyBkcmFmdC48YnI+DQo8YnI+DQp0aGFua3MsPGJyPg0KRGFuYTxicj4NCjxicj4NCjxi
cj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNYXkgMTQsIDIw
MTgsIGF0IDk6NDAgQU0sIEJlbm9pdCBDbGFpc2UgJmx0O2JjbGFpc2VAY2lzY28uY29tJmd0OyB3
cm90ZTo8YnI+DQo8YnI+DQpJbmNsdWRpbmcgRGFuYSdzIGVtYWlsIGFkZHJlc3MuPGJyPg0KPGJy
Pg0KUmVnYXJkcywgQi48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGFuayB5b3UsIE1haGVzaCBh
bmQgU29uYWwuPGJyPg0KPGJyPg0KSSdtIHN0aWxsIHdhaXRpbmcgdG8gaGVhciBmcm9tIExpc2Eg
YW5kIERhbmEuICZuYnNwO05laXRoZXIgaGF2ZSBiZWVuIGhlYXJkIGZyb20gc2luY2UgdGhlIHBl
biBtb3ZlZCBhIGNvdXBsZSB5ZWFycyBhZ28uICZuYnNwO0lzIGFueW9uZSBhd2FyZSBvZiBMaXNh
IG9yIERhbmEncyBjdXJyZW50IGVtYWlsPzxicj4NCjxicj4NCkxldCdzIGdpdmUgaXQgYSBmZXcg
ZGF5cyBidXQsIGlmIHdlIGRvbid0IGhlYXIgYmFjayBmcm9tIHRoZW0gc2hvcnRseSwgSSByZWNv
bW1lbmQgbW92aW5nIHRoZWlyIG5hbWVzIGZyb20gYXV0aG9ycyB0byBjb250cmlidXRvcnMgc28g
d2UgY2FuIHVuYmxvY2sgdGhlIHB1Ymxpc2hpbmcgcHJvY2Vzcy48YnI+DQo8YnI+DQpUaGFua3Ms
PGJyPg0KS2VudCAvLyBzaGVwaGVyZDxicj4NCjxicj4NCjxicj4NCj09PT09IG9yaWdpbmFsIG1l
c3NhZ2UgPT09PT08YnI+DQo8YnI+DQpBdXRob3JzLCBDb250cmlidXRvcnMsIFdHLDxicj4NCjxi
cj4NCkFzIHBhcnQgb2YgU2hlcGhlcmQgd3JpdGUtdXAgZm9yIHRoZSBhY2wtbW9kZWwgZHJhZnQs
IHdlIG5lZWQgdG8gZW5zdXJlIHRoYXQgYWxsIElQUiBoYXMgYmVlbiBkZWNsYXJlZC4gJm5ic3A7
VGhlcmUgd2FzIGFuIElQUi1jYWxsIGJlZm9yZSwgd2hlbiB0aGVyZSB3YXMgYSBkaWZmZXJlbnQg
c2V0IG9mIGF1dGhvcnMgaW52b2x2ZWQsIGJ1dCBub3Qgc2luY2UsIHNvIGl0IHNlZW1zIHBydWRl
bnQgdG8gZG8gYW5vdGhlciBjYWxsIG5vdy48YnI+DQo8YnI+DQpBcmUgeW91IGF3YXJlIG9mIGFu
eSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0IGlkZW50aWZpZWQgYWJvdmU/PGJyPg0KPGJyPg0K
PGJyPg0KUGxlYXNlIHN0YXRlIGVpdGhlcjo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmcXVvdDtO
bywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0JnF1
b3Q7PGJyPg0KJm5ic3A7b3I8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmcXVvdDtZZXMsIEknbSBh
d2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQmcXVvdDs8YnI+DQo8YnI+DQo8
YnI+DQpJZiB5ZXMsIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdp
dGggSUVURiBJUFIgcnVsZXM8YnI+DQooc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3
OCBmb3IgbW9yZSBkZXRhaWxzKT8gUGxlYXNlIHN0YXRlPGJyPg0KZWl0aGVyOjxicj4NCiZuYnNw
OyZuYnNwOyZuYnNwOyZxdW90O1llcywgdGhlIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29t
cGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzJnF1b3Q7PGJyPg0KJm5ic3A7b3I8YnI+DQombmJz
cDsmbmJzcDsmbmJzcDsmcXVvdDtObywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlzY2xvc2VkJnF1
b3Q7PGJyPg0KPGJyPg0KSWYgbm8sIHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlvbmFsIGRldGFp
bHMgeW91IHRoaW5rIGFwcHJvcHJpYXRlLjxicj4NCjxicj4NCjxicj4NCklmIHlvdSBhcmUgbGlz
dGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCBwbGVhc2UgYW5zd2VyIHRo
ZTxicj4NCmFib3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdo
ZXRoZXIgb3Igbm90IHlvdSBhcmU8YnI+DQphd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLiBUaGlz
IGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQ8YnI+DQpzdGFnZSB1bnRpbCBh
IHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGxpc3RlZDxi
cj4NCmNvbnRyaWJ1dG9yLiBOT1RFOiBUSElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBMSVNURUQg
SU4gVEhJUyBNRVNTQUdFJ1M8YnI+DQpUTyBMSU5FUy48YnI+DQo8YnI+DQo8YnI+DQpJZiB5b3Ug
YXJlIG9uIHRoZSBXRyBlbWFpbCBsaXN0IG9yIGF0dGVuZCBXRyBtZWV0aW5ncyBidXQgYXJlIG5v
dCBsaXN0ZWQ8YnI+DQphcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ug
b2YgeW91ciBvYmxpZ2F0aW9ucyB1bmRlciB0aGU8YnI+DQpJRVRGIElQUiBydWxlcyB3aGljaCBl
bmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZSBhd2FyZTxicj4NCm9m
IElQUiBvZiBvdGhlcnMgb24gYW4gSUVURiBjb250cmlidXRpb24sIG9yIHRvIHJlZnJhaW4gZnJv
bSBwYXJ0aWNpcGF0aW5nPGJyPg0KaW4gYW55IGNvbnRyaWJ1dGlvbiBvciBkaXNjdXNzaW9uIHJl
bGF0ZWQgdG8geW91ciB1bmRpc2Nsb3NlZCBJUFIuIEZvcjxicj4NCm1vcmUgaW5mb3JtYXRpb24s
IHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlIGFuZDxicj4NCmh0dHBzOi8vdXJsZGVm
ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX190cmFjLnRvb2xzLmlldGYub3Jn
X2dyb3VwX2llc2dfdHJhY193aWtpX0ludGVsbGVjdHVhbFByb3BlcnR5JmFtcDtkPUR3SUNBZyZh
bXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJmFtcDtyPTl6
a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mYW1wO209eWowaFE5U194
cmFlS2JpU3Y3TWNaWTFkaUJWVlI0RVU3OGhua2xySTI0SSZhbXA7cz14WC1paC1NcFoxcWtYaFls
czFVUURBSzdXdVRKbk9jMjluN1pwNG5rX0djJmFtcDtlPS48YnI+DQo8YnI+DQpUaGFuayB5b3Us
PGJyPg0KPGJyPg0KS2VudCAvLyBkb2N1bWVudCBzaGVwaGVyZCBhbmQgY28tY2hhaXI8YnI+DQo8
YnI+DQo8YnI+DQpQUzogUGxlYXNlIGluY2x1ZGUgYWxsIGxpc3RlZCBpbiB0aGUgaGVhZGVycyBv
ZiB0aGlzIG1lc3NhZ2UgaW4geW91ciByZXNwb25zZS48YnI+DQo8YnI+DQo8YnI+DQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm5ldG1vZCBtYWls
aW5nIGxpc3Q8YnI+DQpuZXRtb2RAaWV0Zi5vcmc8YnI+DQpodHRwczovL3VybGRlZmVuc2UucHJv
b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3Rp
bmZvX25ldG1vZCZhbXA7ZD1Ed0lDQWcmYW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1L
LW5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZq
SVNsYUpkY1pvJmFtcDttPXlqMGhROVNfeHJhZUtiaVN2N01jWlkxZGlCVlZSNEVVNzhobmtsckky
NEkmYW1wO3M9bS1wYkltVGxNSVZPMDdJTEMwU3BoQS1iM0QtM3VyTVNPUFIzWVNXd1FYayZhbXA7
ZT08YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxicj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQpuZXRtb2RAaWV0Zi5vcmc8
YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDxicj4NCi48
bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_3372A2D3C7844E63876961543EA06690junipernet_--


From nobody Fri May 18 03:11:00 2018
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 435E2127873 for ; Fri, 18 May 2018 03:10:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVi7I7ygWCP6 for ; Fri, 18 May 2018 03:10:55 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0103.outbound.protection.outlook.com [104.47.1.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABF50129C70 for ; Fri, 18 May 2018 03:10:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pet+dRuJkyht92ke747fSPCaHRT7q8ZNNwVrlOBwfAw=; b=SJRgqUWirMIXRsbN1BkhuhfPcDqNoZYU16LdV6HmqI+XDs4ryR5wxTzZh2kzgxAUvuQl5K/RVp2XCfp9PFjfmdGBNcsgDFaKBYRAbYXMUtWv+t3rQtahqpYB7DwtEP/HFIq/arZMlnkcLeE5sWCeUT/lp9p1xrXUVeBEXSjgObk=
Received: from DB6PR07MB4421.eurprd07.prod.outlook.com (10.168.24.142) by DB6PR07MB3095.eurprd07.prod.outlook.com (10.170.223.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.797.5; Fri, 18 May 2018 10:10:52 +0000
Received: from DB6PR07MB4421.eurprd07.prod.outlook.com ([fe80::a53a:1f69:4c4b:dc0b]) by DB6PR07MB4421.eurprd07.prod.outlook.com ([fe80::a53a:1f69:4c4b:dc0b%13]) with mapi id 15.20.0797.005; Fri, 18 May 2018 10:10:52 +0000
From: "Bogaert, Bart (Nokia - BE/Antwerp)" 
To: "netmod@ietf.org" 
Thread-Topic: Question on when-construction involving identities not detected as an error during module compilation
Thread-Index: AdPukA/wNrVtvGb/QOCA4gfATSwNuA==
Date: Fri, 18 May 2018 10:10:52 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.245.212.207]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB6PR07MB3095; 7:QKIPksmR5Xuv7kbZ3Lf+eJ+QYU/Lt2uK2tGNlzSJMeIntH3P6CaTML8GTLECHxSOVjaeSVVBbJvoIZEGuvV3fak3mmY3wF+WwkkcRW4jNMMB5FQ2Bui+F4aXm9reTWRfRMUicyLWwNiTTjf1xYwclDPWeCARqe9rs/LCMcWLKwtrpHYn75WnztQ7xBu0UqD3qwd+ieD4Kt95gkV3xCFIDHEv9To4qOG8WCJI80hbHyZSuVEi+PZuDkmU7sxWft++
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(48565401081)(2017052603328)(7193020); SRVR:DB6PR07MB3095; 
x-ms-traffictypediagnostic: DB6PR07MB3095:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155)(79290750141951); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231254)(11241501184)(806099)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:DB6PR07MB3095; BCL:0; PCL:0; RULEID:; SRVR:DB6PR07MB3095; 
x-forefront-prvs: 0676F530A9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(39380400002)(366004)(39860400002)(189003)(199004)(26005)(53936002)(25786009)(5660300001)(14454004)(105586002)(6116002)(790700001)(478600001)(3846002)(3280700002)(3660700001)(86362001)(2501003)(2906002)(99286004)(5250100002)(66066001)(7696005)(68736007)(316002)(2900100001)(8936002)(81166006)(81156014)(1730700003)(8676002)(59450400001)(6916009)(6506007)(5630700001)(7736002)(102836004)(106356001)(55016002)(2351001)(33656002)(486006)(74316002)(6436002)(5640700003)(54896002)(6306002)(9686003)(97736004)(476003)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR07MB3095; H:DB6PR07MB4421.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: qxVy8vzhPYTk31nBIyrkS/6uPJi4bNozrlEeSLAyOAIYhWHz8/MzzMzsI1daZVWa0pXJUSvMY8eXPPUCfhHm5FIvYJAR8rlKCGV2w1P7n6zM5aY895sm5qXRcFztBVHr8AR4v3XjBm4Y2qSkaFfbSMlv07gvpvUhgzoURxMp6vonmuytSPsrlJscvgmfoitcVay6/By5jboG+Jg5plrJ33GW0RhAFVY2RElnVpV44JE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB6PR07MB4421DA0C615265DAA07CA9C294900DB6PR07MB4421eurp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: ad75416e-cfc8-4dee-e5a1-08d5bca7a2f7
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ad75416e-cfc8-4dee-e5a1-08d5bca7a2f7
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2018 10:10:52.1415 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3095
Archived-At: 
Subject: [netmod] Question on when-construction involving identities not detected as an error during module compilation
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 May 2018 10:10:58 -0000

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

Hi,

We have a question on YANG module compilation.  Assume the following model:

module test-feat-compile {
  yang-version 1.1;
  namespace "http://www.example.com/test-feat-compile";
  prefix "tfc";

  identity failure-reason {
    description
      "The reason a failure occurred.";
  }

  identity no-failure {
    description
      "No failure has occurred.";
  }

  identity general-error {
    base failure-reason;
    description
      "A general error occurred.";
  }

  container failure {
    description
      "Objects associated with a failure.";

    leaf failure-reason {
      type identityref {
        base failure-reason;
      }
      description
        "The reason the failure occurred.";
    }

    leaf failure-string {
      when "../failure-reason !=3D 'no-failure'" {
        description
          "Only valid when there is a failure.";
      }
      type string;
      description
        "A text string indicating the reason for the failure when
         either no defined reason exists or additional information
         is available beyond the definition of the reason.";
    }
  }
}

Looking at the when clause there is something obviously wrong (at least thi=
s is how I see it):

  *   The leaf 'failure-reason' is of type identityref  with 'failure-reaso=
n' as base
  *   Identity 'no-failure' does not have 'failure-reason' as base (see it =
as having been forgotten)
Question is: shouldn't this be reported at compile time?  Pyang doesn't and=
 the other compiler we use doesn't report this either.

Even when 'no-failure' is modified into some arbitrary string it is still a=
ccepted while this arbitrary string is not defined anywhere as identity.

And when it comes to the correct syntax, RFC 7950 states (section 9.1.3) th=
at identities in must and when statements should be prefixed (so tfc:no-fai=
lure in this case).  Also this "violation" passes.

So: what can we expect to be checked at compile time in this case?  Now you=
 can only detect these anomalies when using a system supporting the modules=
 and detect that things do not work as intended.  It would be better to hav=
e these erroneous constructions being detected at compile time.  If there i=
s something in the RFC that allows the compiler to behave as it does now it=
 would be good to know.

Best regards, Bart

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











Hi,


 


We have a question on YANG modu=
le compilation.  Assume the following model:


 


module test-feat-compile {


  yang-version 1.1;<=
/p>

  namespace "http://www.example.c=
om/test-feat-compile";


  prefix "tfc";


 


  identity failure-reason {=



    description


      "The re=
ason a failure occurred.";


  }


 



  identity no-failure {


    description


      "No fai=
lure has occurred.";


  }


 



  identity general-error {


    base failure-reason;


    description


      "A gene=
ral error occurred.";


  }


 



  container failure {<=
/span>


    description


      "Object=
s associated with a failure.";


   



    leaf failure-reason=
 {


      type identit=
yref {


        =
base failure-reason;


      }=



      description<=
o:p>


        =
"The reason the failure occurred.";


    }


   



    leaf failure-string=
 {


      when ".=
./failure-reason !=3D 'no-failure'" {


        =
description


       &=
nbsp;  "Only valid when there is a failure.";


      }=



      type string;=



      description<=
o:p>


        =
"A text string indicating the reason for the failure when


       &=
nbsp; either no defined reason exists or additional information<=
/span>


       &=
nbsp; is available beyond the definition of the reason.";


    }


  }


}


 


Looking at the when clause ther=
e is something obviously wrong (at least this is how I see it):<=
/span>


    

  • The leaf ‘failure-reason’ is of type=
 identityref  with ‘failure-reason’ as base
  • Identity ‘no-failure’ does n=
ot have ‘failure-reason’ as base (see it as having been forgott=
en)


Question is: shouldn’t th=
is be reported at compile time?  Pyang doesn’t and the other com=
piler we use doesn’t report this either.


 


Even when ‘no-failureR=
17; is modified into some arbitrary string it is still accepted while this =
arbitrary string is not defined anywhere as identity.


 


And when it comes to the correc=
t syntax, RFC 7950 states (section 9.1.3) that identities in must and when =
statements should be prefixed (so tfc:no-failure in this case).  Also =
this “violation” passes.


 


So: what can we expect to be ch=
ecked at compile time in this case?  Now you can only detect these ano=
malies when using a system supporting the modules and detect that things do=
 not work as intended.  It would be better
 to have these erroneous constructions being detected at compile time. =
; If there is something in the RFC that allows the compiler to behave as it=
 does now it would be good to know.


 


Best regards, Bart






--_000_DB6PR07MB4421DA0C615265DAA07CA9C294900DB6PR07MB4421eurp_--


From nobody Fri May 18 03:16:32 2018
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 CB3CC129C70 for ; Fri, 18 May 2018 03:16:30 -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 yPTg_0l0dv9E for ; Fri, 18 May 2018 03:16:29 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6D0129C6D for ; Fri, 18 May 2018 03:16:29 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 7170E1AE012C; Fri, 18 May 2018 12:16:27 +0200 (CEST)
Date: Fri, 18 May 2018 12:16:26 +0200 (CEST)
Message-Id: <20180518.121626.115730608086823938.mbj@tail-f.com>
To: bart.bogaert@nokia.com
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Question on when-construction involving identities not detected as an error during module compilation
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 May 2018 10:16:31 -0000

Hi,

"Bogaert, Bart (Nokia - BE/Antwerp)"  wrote:
> Hi,
> 
> We have a question on YANG module compilation.  Assume the following
> model:
> 
> module test-feat-compile {
>   yang-version 1.1;
>   namespace "http://www.example.com/test-feat-compile";
>   prefix "tfc";
> 
>   identity failure-reason {
>     description
>       "The reason a failure occurred.";
>   }
> 
>   identity no-failure {
>     description
>       "No failure has occurred.";
>   }
> 
>   identity general-error {
>     base failure-reason;
>     description
>       "A general error occurred.";
>   }
> 
>   container failure {
>     description
>       "Objects associated with a failure.";
> 
>     leaf failure-reason {
>       type identityref {
>         base failure-reason;
>       }
>       description
>         "The reason the failure occurred.";
>     }
> 
>     leaf failure-string {
>       when "../failure-reason != 'no-failure'" {
>         description
>           "Only valid when there is a failure.";
>       }
>       type string;
>       description
>         "A text string indicating the reason for the failure when
>          either no defined reason exists or additional information
>          is available beyond the definition of the reason.";
>     }
>   }
> }
> 
> Looking at the when clause there is something obviously wrong (at
> least this is how I see it):
> 
>   *   The leaf 'failure-reason' is of type identityref with 'failure-reason'
>       as base
>   *   Identity 'no-failure' does not have 'failure-reason' as base (see it
>       as having been forgotten)
> Question is: shouldn't this be reported at compile time?  Pyang
> doesn't and the other compiler we use doesn't report this either.
> 
> Even when 'no-failure' is modified into some arbitrary string it is
> still accepted while this arbitrary string is not defined anywhere as
> identity.
> 
> And when it comes to the correct syntax, RFC 7950 states (section
> 9.1.3) that identities in must and when statements should be prefixed
> (so tfc:no-failure in this case).  Also this "violation" passes.
> 
> So: what can we expect to be checked at compile time in this case?
> Now you can only detect these anomalies when using a system supporting
> the modules and detect that things do not work as intended.  It would
> be better to have these erroneous constructions being detected at
> compile time.  If there is something in the RFC that allows the
> compiler to behave as it does now it would be good to know.

Strictly speaking, the "when" expressions are not erroneous; they are
proper XPath expressions that happen to always return "false".

A good compiler could detect this and produce a warning, but it would
be incorrect to flag this as an error.


/martin


From nobody Fri May 18 03:23:25 2018
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 DD10412D574 for ; Fri, 18 May 2018 03:23:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level: 
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" 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 JgjT-HsPo-fq for ; Fri, 18 May 2018 03:23:21 -0700 (PDT)
Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [78.128.211.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A52712D77A for ; Fri, 18 May 2018 03:23:21 -0700 (PDT)
Received: by kalendar.cesnet.cz (Postfix, from userid 999) id EE23F604FB; Fri, 18 May 2018 12:23:18 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1526638998; bh=QFGg5bzVGAib3TCvyZC9n8Z/tAA+e+jiiy7abW+khns=; h=In-Reply-To:From:Date:Cc:To:Subject; b=0sOAO48jcDwK+kMFrHo+j59658ddmUgTaHxdFsReDVkseQC+5AtcyJZDyyPDkK5sf 6pxXqvCFUAxiEAC2210cKF9pQTAmL2lFno5dfSTmw5YTL1vlgyPHVl6xeEi2dLrLqJ nN7lEJsBsA6o+dvXJBqbC01Uu9Nxmy7CAV423rqU=
Content-Type: text/plain; charset="utf-8"
In-Reply-To: <20180518.121626.115730608086823938.mbj@tail-f.com>
From: =?utf-8?q?Michal_Va=C5=A1ko?= 
X-Forward: 2001:67c:1220:80c:f5:8e35:ef0e:146c
Date: Fri, 18 May 2018 12:23:18 +0200
Cc: bart.bogaert@nokia.com, netmod@ietf.org
To: "Martin Bjorklund" 
MIME-Version: 1.0
Message-ID: <3ee8-5afea980-1f-15b6c1c0@106157737>
User-Agent: SOGoMail 2.3.23
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod]  =?utf-8?b?Pz09P3V0Zi04P3E/ICBRdWVzdGlvbiBvbiB3aGVuLWNv?= =?utf-8?q?nstruction_involving_identities_not_detected_as_an_error_during?= =?utf-8?q?_module_compilation?=
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 May 2018 10:23:24 -0000

Hi,

On Friday, May 18, 2018 12:16 CEST, Martin Bjorklund  w=
rote: 
 
> Hi,
> 
> "Bogaert, Bart (Nokia - BE/Antwerp)"  wrote:=

> > Hi,
> > 
> > We have a question on YANG module compilation.  Assume the followin=
g
> > model:
> > 
> > module test-feat-compile {
> >   yang-version 1.1;
> >   namespace "http://www.example.com/test-feat-compile";
> >   prefix "tfc";
> > 
> >   identity failure-reason {
> >     description
> >       "The reason a failure occurred.";
> >   }
> > 
> >   identity no-failure {
> >     description
> >       "No failure has occurred.";
> >   }
> > 
> >   identity general-error {
> >     base failure-reason;
> >     description
> >       "A general error occurred.";
> >   }
> > 
> >   container failure {
> >     description
> >       "Objects associated with a failure.";
> > 
> >     leaf failure-reason {
> >       type identityref {
> >         base failure-reason;
> >       }
> >       description
> >         "The reason the failure occurred.";
> >     }
> > 
> >     leaf failure-string {
> >       when "../failure-reason !=3D 'no-failure'" {
> >         description
> >           "Only valid when there is a failure.";
> >       }
> >       type string;
> >       description
> >         "A text string indicating the reason for the failure when
> >          either no defined reason exists or additional information=

> >          is available beyond the definition of the reason.";
> >     }
> >   }
> > }
> > 
> > Looking at the when clause there is something obviously wrong (at
> > least this is how I see it):
> > 
> >   *   The leaf 'failure-reason' is of type identityref with 'failur=
e-reason'
> >       as base
> >   *   Identity 'no-failure' does not have 'failure-reason' as base =
(see it
> >       as having been forgotten)
> > Question is: shouldn't this be reported at compile time?  Pyang
> > doesn't and the other compiler we use doesn't report this either.
> > 
> > Even when 'no-failure' is modified into some arbitrary string it is=

> > still accepted while this arbitrary string is not defined anywhere =
as
> > identity.
> > 
> > And when it comes to the correct syntax, RFC 7950 states (section
> > 9.1.3) that identities in must and when statements should be prefix=
ed
> > (so tfc:no-failure in this case).  Also this "violation" passes.
> > 
> > So: what can we expect to be checked at compile time in this case?=

> > Now you can only detect these anomalies when using a system support=
ing
> > the modules and detect that things do not work as intended.  It wou=
ld
> > be better to have these erroneous constructions being detected at
> > compile time.  If there is something in the RFC that allows the
> > compiler to behave as it does now it would be good to know.
> 
> Strictly speaking, the "when" expressions are not erroneous; they are=

> proper XPath expressions that happen to always return "false".
> 
> A good compiler could detect this and produce a warning, but it would=

> be incorrect to flag this as an error.

Exactly and you can try using yanglint(1) from libyang [1], which print=
s both problems you mentioned as warnings.

Kind regards,
Michal Vasko

[1] https://github.com/cesnet/libyang


From nobody Fri May 18 03:24:46 2018
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 B68BD12D7E2 for ; Fri, 18 May 2018 03:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] 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 Bu3_kEyVb-rZ for ; Fri, 18 May 2018 03:24:42 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC50E12D77B for ; Fri, 18 May 2018 03:24:41 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:e88e:f9ff:fe2e:3070]) by mail.nic.cz (Postfix) with ESMTPSA id 20AE1601AB for ; Fri, 18 May 2018 12:24:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1526639080; bh=McQGNOPItWoX7S86SmFE+sXCDRXavGVoARqNpCfQ4xw=; h=From:To:Date; b=KO88Pc/si+JhhZYE47Ax+Df2yH1Apdps3Z5LnoRXvQBPCd4QSxWdi1Kbur3RfDGJ5 AmmvwCqUUcxv3q+mceZorGSk32k0nm6AiBF9Jcddpg3P3EPBNEVRrtB5W5UcjzEvdB PTGzhWPyTWbLmiEICwNtEjrMm9ChPAPVHKiHXfsI=
Message-ID: <97af53bab97ebbb87168735298005674d6560447.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Fri, 18 May 2018 12:24:57 +0200
In-Reply-To: <20180518.121626.115730608086823938.mbj@tail-f.com>
References:  <20180518.121626.115730608086823938.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Question on when-construction involving identities not detected as an error during module compilation
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 May 2018 10:24:45 -0000

On Fri, 2018-05-18 at 12:16 +0200, Martin Bjorklund wrote:
> Hi,
> 
> "Bogaert, Bart (Nokia - BE/Antwerp)"  wrote:
> > Hi,
> > 
> > We have a question on YANG module compilation.  Assume the following
> > model:
> > 
> > module test-feat-compile {
> >   yang-version 1.1;
> >   namespace "http://www.example.com/test-feat-compile";
> >   prefix "tfc";
> > 
> >   identity failure-reason {
> >     description
> >       "The reason a failure occurred.";
> >   }
> > 
> >   identity no-failure {
> >     description
> >       "No failure has occurred.";
> >   }
> > 
> >   identity general-error {
> >     base failure-reason;
> >     description
> >       "A general error occurred.";
> >   }
> > 
> >   container failure {
> >     description
> >       "Objects associated with a failure.";
> > 
> >     leaf failure-reason {
> >       type identityref {
> >         base failure-reason;
> >       }
> >       description
> >         "The reason the failure occurred.";
> >     }
> > 
> >     leaf failure-string {
> >       when "../failure-reason != 'no-failure'" {
> >         description
> >           "Only valid when there is a failure.";
> >       }
> >       type string;
> >       description
> >         "A text string indicating the reason for the failure when
> >          either no defined reason exists or additional information
> >          is available beyond the definition of the reason.";
> >     }
> >   }
> > }
> > 
> > Looking at the when clause there is something obviously wrong (at
> > least this is how I see it):
> > 
> >   *   The leaf 'failure-reason' is of type identityref with 'failure-reason'
> >       as base
> >   *   Identity 'no-failure' does not have 'failure-reason' as base (see it
> >       as having been forgotten)
> > Question is: shouldn't this be reported at compile time?  Pyang
> > doesn't and the other compiler we use doesn't report this either.
> > 
> > Even when 'no-failure' is modified into some arbitrary string it is
> > still accepted while this arbitrary string is not defined anywhere as
> > identity.
> > 
> > And when it comes to the correct syntax, RFC 7950 states (section
> > 9.1.3) that identities in must and when statements should be prefixed
> > (so tfc:no-failure in this case).  Also this "violation" passes.
> > 
> > So: what can we expect to be checked at compile time in this case?
> > Now you can only detect these anomalies when using a system supporting
> > the modules and detect that things do not work as intended.  It would
> > be better to have these erroneous constructions being detected at
> > compile time.  If there is something in the RFC that allows the
> > compiler to behave as it does now it would be good to know.
> 
> Strictly speaking, the "when" expressions are not erroneous; they are
> proper XPath expressions that happen to always return "false".
> 
> A good compiler could detect this and produce a warning, but it would
> be incorrect to flag this as an error.

I would also add that the XPath expression in the above module uses string
comparison which is known to be problematic. Instead, you should use the new
functions derived-from() and derived-from-or-self() introduced in YANG 1.1.

Lada

> 
> 
> /martin
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue May 22 01:38:53 2018
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 398FF126C26 for ; Tue, 22 May 2018 01:38:51 -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 PVSLV02rsGqZ for ; Tue, 22 May 2018 01:38:49 -0700 (PDT)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD257124D68 for ; Tue, 22 May 2018 01:38:48 -0700 (PDT)
Received: by mail-oi0-x22f.google.com with SMTP id n65-v6so15472603oig.6 for ; Tue, 22 May 2018 01:38:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=wSHBMvmeJ8upvQRR51Nhtkng6h/5iewW9l+XXp8UFSQ=; b=rzRtxlomBhUp6WyicfPVSF5qVeb0mDevrqDjxubxcE+6WmUIeng+J1kd3yhvG2/RCO MSI0eqjV/zzplgyjFJ3T61ounVm2BstrghhkB6X6kf7IY+2tAFDAg+Xz3IB7u+XP9xbv OKqzy9yYBU10Y8Ph04aAQYqG0Nv3cKlLmGB0fIWI0/b5bISAGWdphuOjtASfOMkWOa3H 7sVI+xIYkfSPgCeOOqfq+q9UhA5CwshDOttcGtg8kxA8HRzJwE2YPNYAlHEleR3lLX1e fIrBIvG0szkN4DLV6aOEz+RXhOazdXxcwD2zrRwaTN75HX0e8AdJAg9zVyEBLzT2BNpo FI7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=wSHBMvmeJ8upvQRR51Nhtkng6h/5iewW9l+XXp8UFSQ=; b=PtIbUUYaytukiQwL5FyFDdvzLO0AOurbfXX5Y0W8o/OTZC/y5JUewojsG6HbSTYdcB riOWpDavXo3IcXBnWETtv6SuN/KqHrP6tRyWocxVOsQTkyxOIvp7o55BSWZKkc9LlpS6 1thNmoXC0emQ95kBA/BO3ZPoca569o8LlbnK7WB+VbRR6SFSK6z80yLev39xUk+42D3t lVJ0L1v8TavHlGa2hqXBhm2ibFtOPCfLWzitEXPS/cDzoHhYUFagKHTbvjnOL/CwB3PR JKFFVMaaplq+vqIt+l8AICLbNer468Y7b1tBs3OLPQZeLt+YpZeHneFeXxCdlevgi2qT HWig==
X-Gm-Message-State: ALKqPweljFjTs21PgieKj/HnsvQCoqBi9Ev1XUNY9M2ZEL+Im+CIN/Yh tbNxi1UBM31qglnxTJ3+iVYuCNn52P4xERz0FZo=
X-Google-Smtp-Source: AB8JxZp4xDSud/WdOmffLPNpQOJ42RrUy7ZL8kFq7TgbtclP27T88r44UvAPFLdAq81O7gE14Bc2ZdxAkhGozJQRY9s=
X-Received: by 2002:aca:d594:: with SMTP id m142-v6mr12732208oig.160.1526978327870;  Tue, 22 May 2018 01:38:47 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Shiva Kumar Pathori 
Date: Tue, 22 May 2018 14:08:35 +0530
Message-ID: 
To: netmod@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d000eb056cc75899"
Archived-At: 
Subject: [netmod] Clarification about subtree filtering
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 May 2018 08:38:51 -0000

--000000000000d000eb056cc75899
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> Hi,
> Can somebody clarify what could be the response for the 
> operation provided below.
>
> Following is the user information in the datastore that is provided in th=
e
> RFC 6241 as example.
>
>> >           xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>>        
>>          
>>            
>>          
>>          
>>            
>>              
>>            
>>          
>>        
>>      
>
>
> > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>>   
>>     
>>       
>>         
>>           root
>>           superuser
>>           Charlie Root
>>           
>>             1
>>             1
>>           
>>         
>>         
>>           fred
>>           admin
>>           Fred Flintstone
>>           
>>             2
>>             2
>>           
>>         
>>         
>>           barney
>>           admin
>>           Barney Rubble
>>           
>>             2
>>             3
>>           
>>         
>>       
>>     
>>   
>> 
>
>
>
> *The  operation with content-match at parent and child nodes;=
*
>
> 
>>   
>>     
>>       
>>     
>>     
>>       
>>         
>>           
>>             admin
>>             
>>               1
>>             
>>           
>>         
>>       
>>     
>>   
>> 
>
>
> *The equivalent XPATH expression : *
>
>> 
>>   
>>     
>>       
>>     
>>     >                  type=3D"xpath"
>>
>>  select=3D"/t:top/t:users/t:user[t:type=3D'admin']/t:company-info[t:dept=
=3D=E2=80=991=E2=80=99]"/>
>>         
>>      
>
>
> For this what could be the response
>
> a) The response based on content-match nodes are AND-ed together
>
>> > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>>        
>>       
>>      
>
> OR
>
> b)  The response based on content-match nodes treated separately
>
>> > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>>   
>>     
>>       
>>         
>>           fred
>>           admin
>>           Fred Flintstone
>>         
>>         
>>           barney
>>           admin
>>           Barney Rubble
>>         
>>       
>>     
>>   
>> 
>
>
> Regards,
> Shiva
>
>
>
>

--000000000000d000eb056cc75899
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



Hi,
Can somebody clar=
ify what could be the response for the <get-config> operation provide=
d below.

Following is the user information in=
 the datastore that is provided in the RFC 6241 as example.
<rpc message-id=3D"101"=
;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:params:xml:n=
s:netconf:base:1.0">
=C2=A0 =C2=A0 =C2=A0 =C2=A0<get-config&g=
t;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<source>
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0<running/>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0</source>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<filter type=3D&=
quot;subtree">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<top =
xmlns=3D"http://example.com/schema/1.2/config">=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<users/>
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</top>
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0</filter>
=C2=A0 =C2=A0 =C2=A0 =C2=A0</get-config&=
gt;
=C2=A0 =C2=A0 =C2=A0</rpc>

<rpc-reply message-id=3D"=
101" xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">=C2=A0 <data>
=C2=A0 =C2=A0 <top xmlns=3D"htt=
p://example.com/schema/1.2/config">
=C2=A0 =C2=A0 =C2=A0 <=
;users>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <user>
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 <name>root</name>
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 <type>superuser</type>
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 <full-name>Charlie Root</full-name>
=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 <company-info>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 <dept>1</dept>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 <id>1</id>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <=
;/company-info>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </user>
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 <user>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <=
;name>fred</name>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <type&g=
t;admin</type>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <full-name>=
;Fred Flintstone</full-name>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &l=
t;company-info>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <dept>=
;2</dept>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <id>2<=
;/id>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </company-info>
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 </user>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <u=
ser>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>barney</name&g=
t;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <type>admin</type>
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <full-name>Barney Rubble</full-=
name>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <company-info>
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <dept>2</dept>
=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <id>3</id>
=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 </company-info>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
</user>
=C2=A0 =C2=A0 =C2=A0 </users>
=C2=A0 =C2=A0 </=
top>
=C2=A0 </data>
</rpc-reply>

=


The <get-config> operation with content-=
match at parent and child nodes;

<rpc message-id=3D"101" xmlns=
=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
=C2=A0 <ge=
t-config>
=C2=A0 =C2=A0 <source>
=C2=A0 =C2=A0 =C2=A0 <ru=
nning/>
=C2=A0 =C2=A0 </source>
=C2=A0 =C2=A0 <filter typ=
e=3D"subtree">
=C2=A0 =C2=A0 =C2=A0 <top xmlns=3D"<=
a href=3D"http://example.com/schema/1.2/config" target=3D"_blank" rel=3D"no=
referrer">http://example.com/schema/1.2/config">
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 <users>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <u=
ser>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <type>admin</=
name>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <company-info><=
br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <dept>1</dept&=
gt;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </company-info>
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </user>
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 </users>
=C2=A0 =C2=A0 =C2=A0 </top>
=C2=A0 =C2=A0=
 </filter>
=C2=A0 </get-config>
</rpc>
=


The equivalent XPATH expression :=C2=A0
<rpc message-id=3D"1=
01" xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">=C2=A0 <get-config>
=C2=A0 =C2=A0 <source>
=C2=A0 =C2=A0=
 =C2=A0 <running/>
=C2=A0 =C2=A0 </source>
=C2=A0 =C2=A0 =
<filter xmlns:t=3D"http://example.com/schema/1.2/config<=
/a>"=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0type=3D"xpath"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0select=3D"/t:top/t:users/t:user[t:type=3D'adm=
in']/t:company-info[t:dept=3D=E2=80=991=E2=80=99]"/>
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 </get-config>
=C2=A0 =C2=A0 =C2=A0</rpc>=
;

For this what could be the response
=


a)	The resp=
onse based on content-match nodes are AND-ed together
	<rpc-reply message-id=3D"101" xmlns=3D"urn:ietf:param=
s:xml:ns:netconf:base:1.0">
=C2=A0 =C2=A0 =C2=A0 =C2=A0<data&=
gt;
=C2=A0 =C2=A0 =C2=A0 </data>
=C2=A0 =C2=A0 =C2=A0</rpc-r=
eply>
OR=C2=A0

b)=C2=A0 The re=
sponse based on content-match nodes treated separately



<rpc-reply message-id=
=3D"101" xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0&qu=
ot;>
=C2=A0 <data>
=C2=A0 =C2=A0 <top xmlns=3D"http://example.com/schema/1.2/config">
=C2=A0 =C2=A0 =
=C2=A0 <users>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <user>
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>fred</name>
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 <type>admin</type>
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 <full-name>Fred Flintstone</full-name>
=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 </user>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <user=
>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>barney</name><=
br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <type>admin</type>
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <full-name>Barney Rubble</full-nam=
e>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </user>
=C2=A0 =C2=A0 =C2=A0 =
</users>
=C2=A0 =C2=A0 </top>
=C2=A0 </data>
<=
;/rpc-reply>

Regards,
Sh=
iva







--000000000000d000eb056cc75899--


From nobody Tue May 22 22:31:41 2018
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 99F5B124235 for ; Tue, 22 May 2018 22:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pH1Hbh0pTrKv for ; Tue, 22 May 2018 22:31:37 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 695D712025C for ; Tue, 22 May 2018 22:31:37 -0700 (PDT)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 85A6EF136E457 for ; Wed, 23 May 2018 06:31:33 +0100 (IST)
Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 23 May 2018 06:31:34 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.161]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0382.000; Wed, 23 May 2018 13:31:25 +0800
From: Rohit R Ranade 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] Operational state data in  operation
Thread-Index: AdPyVqMugw8iIPM7TG2dz6SESDGWmg==
Date: Wed, 23 May 2018 05:31:23 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BBAF534@dggeml510-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BBAF534dggeml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [netmod]  Operational state data in  operation
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 May 2018 05:31:40 -0000

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


Hi All,


RFC 6244 says below statements in Section 4.3.1

"   NETCONF does not follow the distinction formulated by the operators
   between configuration data, operational state data, and statistical
   data, since it considers state data to include both statistics and
   operational state data.
"

RFC 6241 definition for "state data":
   o  state data: The additional data on a system that is not
      configuration data such as read-only status information and
      collected statistics.

RFC 8342 definition:
   o  system state: The additional data on a system that is not
      configuration, such as read-only status information and collected
      statistics.  System state is transient and modified by
      interactions with internal components or other systems.  System
      state is modeled in YANG using "config false" nodes.

   o  operational state: The combination of applied configuration and
      system state.

According to NMDA, state-data and "system-state" are the same. So "state-da=
ta" does not include operational state data. This means that RFC 6244 under=
standing is inaccurate regarding state-data ? And hence  cannot output=
 Operational state as shown below. Please clarify.

RFC 6241 : Description for 
7.7.  

   Description:  Retrieve running configuration and device state
      information.

RFC 6241:
The  operation retrieves
   configuration data only, while the  operation retrieves
   configuration and state data.



With Regards,
Rohit R Ranade


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











 


Hi All,


 


 


RFC 6244 says below statements =
in Section 4.3.1


“   NETCONF does not follow the distincti=
on formulated by the operators


 =
  between configuration data, operational state data, and statistical<=
o:p>


 =
  data, since it
considers state data to include both statistics and


&nbs=
p;  operational state data.


”


 


RFC 6241 definition for “=
state data”:


   o  state data: The addition=
al data on a system that is not


      configuration =
data such as read-only status information and


     
collected statistics.


 


RFC 8342 definition:=



   o  system state: The additi=
onal data on a system that is not


      configuration,=
 such as read-only status information and collected


      statistics.&nb=
sp; System state is transient and modified by


      interactions w=
ith internal components or other systems.  System

      state is model=
ed in YANG using "config false" nodes.


 


   o  operational state: The c=
ombination of applied configuration and


     
system state.


 


According to NMDA, state-data a=
nd “system-state” are the same. So “state-data” doe=
s not include operational state data. This means that RFC 6244 understandin=
g is inaccurate regarding state-data ? And hence <get> cannot
 output Operational state as shown below. Please clarify.=



 


RFC 6241 : Description for <=
get>


7.7.  <get>


 


   Description:  Retrieve runn=
ing configuration and device state


     
information.


 


RFC 6241: 

The <get-config> operation retrieves


   configuration data only, while t=
he <get> operation retrieves


  
configuration and state data.


 


 


 


With Regards,=



Rohit R Ranade


 






--_000_991B70D8B4112A4699D5C00DDBBF878A6BBAF534dggeml510mbxchi_--


From nobody Wed May 23 00:00:20 2018
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 C0AEE124319 for ; Wed, 23 May 2018 00:00:17 -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 5gz6678dv1eJ for ; Wed, 23 May 2018 00:00: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 EC1D61243FE for ; Wed, 23 May 2018 00:00:15 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id A42F31AE02A7; Wed, 23 May 2018 09:00:13 +0200 (CEST)
Date: Wed, 23 May 2018 09:00:13 +0200 (CEST)
Message-Id: <20180523.090013.2000918667483073613.mbj@tail-f.com>
To: rohitrranade@huawei.com
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BBAF534@dggeml510-mbx.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6BBAF534@dggeml510-mbx.china.huawei.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Operational state data in  operation
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 May 2018 07:00:18 -0000

Hi,

It is correct that  cannot return the applied configuration
since it returns running config + state, unless the configuration and
state data are modelled in different branches (e.g., /interfaces and
/interfaces-state).  This is why we introduce  as a new
operation to retrieve all operational state, including the applied
configuration.


/martin


Rohit R Ranade  wrote:
> 
> Hi All,
> 
> 
> RFC 6244 says below statements in Section 4.3.1
> 
> "NETCONF does not follow the distinction formulated by the operators
>    between configuration data, operational state data, and statistical
>    data, since it considers state data to include both statistics and
>    operational state data.
> "
> 
> RFC 6241 definition for "state data":
>    o  state data: The additional data on a system that is not
>       configuration data such as read-only status information and
>       collected statistics.
> 
> RFC 8342 definition:
>    o  system state: The additional data on a system that is not
>       configuration, such as read-only status information and collected
>       statistics.  System state is transient and modified by
>       interactions with internal components or other systems.  System
>       state is modeled in YANG using "config false" nodes.
> 
>    o  operational state: The combination of applied configuration and
>       system state.
> 
> According to NMDA, state-data and "system-state" are the same. So
> "state-data" does not include operational state data. This means that
> RFC 6244 understanding is inaccurate regarding state-data ? And hence
>  cannot output Operational state as shown below. Please clarify.
> 
> RFC 6241 : Description for 
> 7.7.  
> 
>    Description:  Retrieve running configuration and device state
>       information.
> 
> RFC 6241:
> The  operation retrieves
>    configuration data only, while the  operation retrieves
>    configuration and state data.
> 
> 
> 
> With Regards,
> Rohit R Ranade
> 


From nobody Wed May 23 17:26:06 2018
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 1816512D7EC for ; Wed, 23 May 2018 17:26:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REll0ozdU9YB for ; Wed, 23 May 2018 17:26:03 -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 DDBF1126C2F for ; Wed, 23 May 2018 17:26:02 -0700 (PDT)
From: Alex Campbell 
To: Shiva Kumar Pathori , "netmod@ietf.org" 
Thread-Topic: [netmod] Clarification about subtree filtering
Thread-Index: AQHT8ahUCbWE6C526UqWXZHs7TFZ/aQ+BoqT
Date: Thu, 24 May 2018 00:26:01 +0000
Message-ID: <1527121561343.62896@Aviatnet.com>
References: ,  
In-Reply-To: 
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.10]
Content-Type: multipart/alternative; boundary="_000_152712156134362896Aviatnetcom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] Clarification about subtree filtering
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 May 2018 00:26:05 -0000

--_000_152712156134362896Aviatnetcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,


Since nobody else has answered I'll have a go.

I'm not familiar with subtree filtering, but I am with XPath. Assuming your=
 XPath translation is accurate, it will return no data (response A).


________________________________
From: netmod  on behalf of Shiva Kumar Pathori 
Sent: Tuesday, 22 May 2018 8:38 p.m.
To: netmod@ietf.org
Subject: [netmod] Clarification about subtree filtering


Hi,
Can somebody clarify what could be the response for the  operat=
ion provided below.

Following is the user information in the datastore that is provided in the =
RFC 6241 as example.

       
         
           
         
         
           
             
           
         
       
     


  
    
      
        
          root
          superuser
          Charlie Root
          
            1
            1
          
        
        
          fred
          admin
          Fred Flintstone
          
            2
            2
          
        
        
          barney
          admin
          Barney Rubble
          
            2
            3
          
        
      
    
  



The  operation with content-match at parent and child nodes;


  
    
      
    
    
      
        
          
            admin
            
              1
            
          
        
      
    
  


The equivalent XPATH expression :

  
    
      
    
    
        
     

For this what could be the response

a) The response based on content-match nodes are AND-ed together

       
      
     
OR

b)  The response based on content-match nodes treated separately

  
    
      
        
          fred
          admin
          Fred Flintstone
        
        
          barney
          admin
          Barney Rubble
        
      
    
  


Regards,
Shiva




--_000_152712156134362896Aviatnetcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








Hi,







Since nobody else has answered I'll have a go.




I'm not familiar with subtree filtering, but I am with XPath. Assumi=
ng your XPath translation is accurate, it will return no data (respons=
e A).













From: netmod <netmod-b=
ounces@ietf.org> on behalf of Shiva Kumar Pathori <pathori@gmail.com&=
gt;

Sent: Tuesday, 22 May 2018 8:38 p.m.

To: netmod@ietf.org

Subject: [netmod] Clarification about subtree filtering

 



















Hi,

Can somebody clarify what could be the response for the <get-config=
> operation provided below.









Following is the user information in the datastore that is provided in=
 the RFC 6241 as example.



<rpc message-id=3D"101"

          xmlns=3D"urn:ietf:params:xml:ns:net=
conf:base:1.0">

       <get-config>

         <source>

           <running/>

         </source>

         <filter type=3D"subtree">=


           <top xmlns=3D"h=
ttp://example.com/schema/1.2/config">

             <users/>

           </top>

         </filter>

       </get-config>

     </rpc>








<rpc-reply message-id=3D"101" xmlns=3D"urn:ietf:params:xm=
l:ns:netconf:base:1.0">

  <data>

    <top xmlns=3D"http://example.com/schema/1.=
2/config">

      <users>

        <user>

          <name>root</name>

          <type>superuser</type>

          <full-name>Charlie Root</full-n=
ame>

          <company-info>

            <dept>1</dept>

            <id>1</id>

          </company-info>

        </user>

        <user>

          <name>fred</name>

          <type>admin</type>

          <full-name>Fred Flintstone</ful=
l-name>

          <company-info>

            <dept>2</dept>

            <id>2</id>

          </company-info>

        </user>

        <user>

          <name>barney</name>

          <type>admin</type>

          <full-name>Barney Rubble</full-=
name>

          <company-info>

            <dept>2</dept>

            <id>3</id>

          </company-info>

        </user>

      </users>

    </top>

  </data>

</rpc-reply>












The <get-config> operation with content-match at parent and c=
hild nodes;








<rpc message-id=3D"101" xmlns=3D"urn:ietf:params:xml:ns:n=
etconf:base:1.0">

  <get-config>

    <source>

      <running/>

    </source>

    <filter type=3D"subtree">

      <top xmlns=3D"http://example.com/sc=
hema/1.2/config">

        <users>

          <user>

            <type>admin</name>
            <company-info>

              <dept>1</dept>=


            </company-info>

          </user>

        </users>

      </top>

    </filter>

  </get-config>

</rpc>







The equivalent XPATH expression : 



<rpc message-id=3D"101" xmlns=3D"urn:ietf:params:xml:ns:n=
etconf:base:1.0">

  <get-config>

    <source>

      <running/>

    </source>

    <filter xmlns:t=3D"http://example.com/sche=
ma/1.2/config" 

                 type=3D"=
xpath"

                 select=3D&quo=
t;/t:top/t:users/t:user[t:type=3D'admin']/t:company-info[t:dept=3D’1&=
#8217;]"/>

        </get-config>

     </rpc>







For this what could be the response







a) The response based on c=
ontent-match nodes are AND-ed together



<rpc-reply message-id=3D&quo=
t;101" xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">=


       <data>

      </data>

     </rpc-reply>


OR 







b)  The response based on content-match nodes treated separately<=
/div>




<rpc-reply message-id=3D"101" xmlns=3D"urn:ietf:params:xm=
l:ns:netconf:base:1.0">

  <data>

    <top xmlns=3D"http://example.com/schema/1.=
2/config">

      <users>

        <user>

          <name>fred</name>

          <type>admin</type>

          <full-name>Fred Flintstone</ful=
l-name>

        </user>

        <user>

          <name>barney</name>

          <type>admin</type>

          <full-name>Barney Rubble</full-=
name>

        </user>

      </users>

    </top>

  </data>

</rpc-reply>









Regards,


Shiva



































--_000_152712156134362896Aviatnetcom_--


From nobody Mon May 28 02:27:35 2018
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 7D4FC126579 for ; Mon, 28 May 2018 02:27:34 -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 iMFfUnAsP0ew for ; Mon, 28 May 2018 02:27:32 -0700 (PDT)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ECDD124BAC for ; Mon, 28 May 2018 02:27:32 -0700 (PDT)
Received: by mail-oi0-x233.google.com with SMTP id l1-v6so9840706oii.1 for ; Mon, 28 May 2018 02:27:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AbD96Jp6KVfTzPbEnVXlxm0xVNkwzGWdCCfmjbuf43w=; b=EVAfNtjFdD/5rNe+72hpyFYMVv7oaa+S5rbzcFtoy2yywDt92X1/B5xQ+gkgNEMObK D27cQoMA3ILy/hmTFBfleCEeHmpAy34cUpppYTKoOGV8Elsh19V1ho+M6k30mzYn8KbP 2QyqF3aiWXzhHYcb2HIGISLxLqduwwt8hY49dAj7Fkh2kuzeRrWKtSDNwCddJ3B9Pfgb XfSqBx2NQVDULJfgZ1v0SauaWP6m9+MLU5JONSrn8FUxSa4yJwIBWMvub1nDuzu5fudH ODXjwx3+inIGEw7IaPaoK6UvKkEetEl/j4VXpMWzHwNos3hFhoQZik273yQQCHXz5LGH F67g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AbD96Jp6KVfTzPbEnVXlxm0xVNkwzGWdCCfmjbuf43w=; b=t/XfXW2bkqqGJiqgk+E4flBVXeCjJrPl+4YYOuQOKw2MtbjAsUkQEymLt+l8qLRx8u ioWRKCP/wUKVI007+lNh4FRAGBRGexSi6p6swAlZ7qlWzpXWyiV8Enl35kcEfnl/qXz4 hril/LSQxJ4iHbzQArqfQyuc9MrYgh5ncUWm38JSNiCmJlGTsX+cDe6n24YuSB1LaVob uMODuC4eHpOaUz9YHkFJ4KM6dhQ3MnPfoHQgPWbMNcGdgrLTdxZrKarL4mShzhdAty5N hFFoyd9qUiIgSbalzIZzBsrmQlAqx5LnWJbq5aw2wn9TCClrCJBtfHs5U/ll864muTX7 wy5g==
X-Gm-Message-State: ALKqPwc/V226guIP681JvzVbAwlEw58SAaozwFC6nboiEEQV/pwLGG4Z BEfsS6d1Co9mwN9qh+DLdiMc9k4kOJNsPwAgv88=
X-Google-Smtp-Source: AB8JxZqUlGkBfItuNGwgF+kwDPEb2eXXNQqfM2IRf6GYe+JOloeJgfi/0w7me2ovBiZMUxK/RmdvwLx2vZcPtiH6t3s=
X-Received: by 2002:aca:d594:: with SMTP id m142-v6mr6599852oig.160.1527499651701;  Mon, 28 May 2018 02:27:31 -0700 (PDT)
MIME-Version: 1.0
References:   <1527121561343.62896@Aviatnet.com>
In-Reply-To: <1527121561343.62896@Aviatnet.com>
From: Shiva Kumar Pathori 
Date: Mon, 28 May 2018 14:57:19 +0530
Message-ID: 
To: Alex Campbell 
Cc: netmod@ietf.org
Content-Type: multipart/alternative; boundary="000000000000225ff7056d40ba4a"
Archived-At: 
Subject: Re: [netmod] Clarification about subtree filtering
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 May 2018 09:27:34 -0000

--000000000000225ff7056d40ba4a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks Alex for the clarification. Can somebody please clarify about
subtree filter behaviour or provide some pointers in RFC so that I can
refer to it.

On Thu 24 May, 2018, 5:56 AM Alex Campbell, 
wrote:

> Hi,
>
>
> Since nobody else has answered I'll have a go.
>
> I'm not familiar with subtree filtering, but I am with XPath. *Assuming
> your XPath translation is accurate*, it will return no data (response A).
>
>
> ------------------------------
> *From:* netmod  on behalf of Shiva Kumar Pathori
> 
> *Sent:* Tuesday, 22 May 2018 8:38 p.m.
> *To:* netmod@ietf.org
> *Subject:* [netmod] Clarification about subtree filtering
>
>
> Hi,
>> Can somebody clarify what could be the response for the 
>> operation provided below.
>>
>> Following is the user information in the datastore that is provided in
>> the RFC 6241 as example.
>>
>>> >>           xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>>>        
>>>          
>>>            
>>>          
>>>          
>>>            
>>>              
>>>            
>>>          
>>>        
>>>      
>>
>>
>> >> xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>>>   
>>>     
>>>       
>>>         
>>>           root
>>>           superuser
>>>           Charlie Root
>>>           
>>>             1
>>>             1
>>>           
>>>         
>>>         
>>>           fred
>>>           admin
>>>           Fred Flintstone
>>>           
>>>             2
>>>             2
>>>           
>>>         
>>>         
>>>           barney
>>>           admin
>>>           Barney Rubble
>>>           
>>>             2
>>>             3
>>>           
>>>         
>>>       
>>>     
>>>   
>>> 
>>
>>
>>
>> *The  operation with content-match at parent and child nodes=
;*
>>
>> 
>>>   
>>>     
>>>       
>>>     
>>>     
>>>       
>>>         
>>>           
>>>             admin
>>>             
>>>               1
>>>             
>>>           
>>>         
>>>       
>>>     
>>>   
>>> 
>>
>>
>> *The equivalent XPATH expression : *
>>
>>> 
>>>   
>>>     
>>>       
>>>     
>>>     >>                  type=3D"xpath"
>>>
>>>  select=3D"/t:top/t:users/t:user[t:type=3D'admin']/t:company-info[t:dep=
t=3D=E2=80=991=E2=80=99]"/>
>>>         
>>>      
>>
>>
>> For this what could be the response
>>
>> a) The response based on content-match nodes are AND-ed together
>>
>>> >> xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>>>        
>>>       
>>>      
>>
>> OR
>>
>> b)  The response based on content-match nodes treated separately
>>
>>> >> xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>>>   
>>>     
>>>       
>>>         
>>>           fred
>>>           admin
>>>           Fred Flintstone
>>>         
>>>         
>>>           barney
>>>           admin
>>>           Barney Rubble
>>>         
>>>       
>>>     
>>>   
>>> 
>>
>>
>> Regards,
>> Shiva
>>
>>
>>
>>

--000000000000225ff7056d40ba4a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks Alex for the clarification. Can somebody plea=
se clarify about subtree filter behaviour or provide some pointers in RFC s=
o that I can refer to it.

On Thu 24 May, 2018, 5:56 AM Alex Campbell, <Alex.Campbell@aviatnet.com> wrote:








Hi,







Since nobody else has answered I'll have a go.




I'm not familiar with subtree filtering, but I am with XPath. As=
suming your XPath translation is accurate, it will return no data (res=
ponse A).













From: =
netmod <netmod-bounces@ietf.org> on behalf of Shiva Kumar Pa=
thori <pathori@gmail.com>

Sent: Tuesday, 22 May 2018 8:38 p.m.

To: netmod@ietf.org

Subject: [netmod] Clarification about subtree filtering

=C2=A0



















Hi,

Can somebody clarify what could be the response for the <get-config=
> operation provided below.









Following is the user information in the datastore that is provided in=
 the RFC 6241 as example.



<rpc message-id=3D"101"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:params:xml:ns:net=
conf:base:1.0">

=C2=A0 =C2=A0 =C2=A0 =C2=A0<get-config>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<source>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<running/>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</source>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<filter type=3D"subtree">=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<top xmlns=3D"http://example.com/schema/1.2/config">

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<users/>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</top>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</filter>

=C2=A0 =C2=A0 =C2=A0 =C2=A0</get-config>

=C2=A0 =C2=A0 =C2=A0</rpc>








<rpc-reply message-id=3D"101" xmlns=3D"urn:ietf:params:xm=
l:ns:netconf:base:1.0">

=C2=A0 <data>

=C2=A0 =C2=A0 <top xmlns=3D"http://example.co=
m/schema/1.2/config">

=C2=A0 =C2=A0 =C2=A0 <users>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <user>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>root</name>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <type>superuser</type>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <full-name>Charlie Root</full-n=
ame>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <company-info>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <dept>1</dept>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <id>1</id>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </company-info>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 </user>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <user>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>fred</name>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <type>admin</type>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <full-name>Fred Flintstone</ful=
l-name>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <company-info>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <dept>2</dept>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <id>2</id>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </company-info>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 </user>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <user>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>barney</name>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <type>admin</type>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <full-name>Barney Rubble</full-=
name>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <company-info>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <dept>2</dept>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <id>3</id>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </company-info>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 </user>

=C2=A0 =C2=A0 =C2=A0 </users>

=C2=A0 =C2=A0 </top>

=C2=A0 </data>

</rpc-reply>












The <get-config> operation with content-match at parent and c=
hild nodes;








<rpc message-id=3D"101" xmlns=3D"urn:ietf:params:xml:ns:n=
etconf:base:1.0">

=C2=A0 <get-config>

=C2=A0 =C2=A0 <source>

=C2=A0 =C2=A0 =C2=A0 <running/>

=C2=A0 =C2=A0 </source>

=C2=A0 =C2=A0 <filter type=3D"subtree">

=C2=A0 =C2=A0 =C2=A0 <top xmlns=3D"http://exa=
mple.com/schema/1.2/config">

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <users>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <user>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <type>admin</name>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <company-info>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <dept>1</dept>=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </company-info>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </user>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 </users>

=C2=A0 =C2=A0 =C2=A0 </top>

=C2=A0 =C2=A0 </filter>

=C2=A0 </get-config>

</rpc>







The equivalent XPATH expression :=C2=A0



<rpc message-id=3D"101" xmlns=3D"urn:ietf:params:xml:ns:n=
etconf:base:1.0">

=C2=A0 <get-config>

=C2=A0 =C2=A0 <source>

=C2=A0 =C2=A0 =C2=A0 <running/>

=C2=A0 =C2=A0 </source>

=C2=A0 =C2=A0 <filter xmlns:t=3D"http://examp=
le.com/schema/1.2/config"=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type=3D"=
xpath"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0select=3D&quo=
t;/t:top/t:users/t:user[t:type=3D'admin']/t:company-info[t:dept=3D=
=E2=80=991=E2=80=99]"/>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 </get-config>

=C2=A0 =C2=A0 =C2=A0</rpc>







For this what could be the response







a) The response based on c=
ontent-match nodes are AND-ed together



<rpc-reply message-id=3D&quo=
t;101" xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">=


=C2=A0 =C2=A0 =C2=A0 =C2=A0<data>

=C2=A0 =C2=A0 =C2=A0 </data>

=C2=A0 =C2=A0 =C2=A0</rpc-reply>


OR=C2=A0







b)=C2=A0 The response based on content-match nodes treated separately<=
/div>




<rpc-reply message-id=3D"101" xmlns=3D"urn:ietf:params:xm=
l:ns:netconf:base:1.0">

=C2=A0 <data>

=C2=A0 =C2=A0 <top xmlns=3D"http://example.co=
m/schema/1.2/config">

=C2=A0 =C2=A0 =C2=A0 <users>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <user>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>fred</name>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <type>admin</type>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <full-name>Fred Flintstone</ful=
l-name>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 </user>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <user>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>barney</name>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <type>admin</type>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <full-name>Barney Rubble</full-=
name>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 </user>

=C2=A0 =C2=A0 =C2=A0 </users>

=C2=A0 =C2=A0 </top>

=C2=A0 </data>

</rpc-reply>









Regards,


Shiva






































--000000000000225ff7056d40ba4a--


From nobody Mon May 28 02:48:22 2018
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 0343C126BF6 for ; Mon, 28 May 2018 02:48:20 -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 mWJOe2RkExJC for ; Mon, 28 May 2018 02:48:17 -0700 (PDT)
Received: from anna.localdomain (firewallix.jacobs-university.de [212.201.44.247]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEBF12420B for ; Mon, 28 May 2018 02:48:16 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id 79D002188052; Mon, 28 May 2018 11:48:14 +0200 (CEST)
Date: Mon, 28 May 2018 11:48:14 +0200
From: Juergen Schoenwaelder 
To: Shiva Kumar Pathori 
Cc: Alex Campbell , netmod@ietf.org
Message-ID: <20180528094814.rzovxin7q4hgshff@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Shiva Kumar Pathori , Alex Campbell , netmod@ietf.org
References:   <1527121561343.62896@Aviatnet.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20180512
Archived-At: 
Subject: Re: [netmod] Clarification about subtree filtering
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 May 2018 09:48:20 -0000

Hi,

this is a netconf question and not a netmod question.

/js

On Mon, May 28, 2018 at 02:57:19PM +0530, Shiva Kumar Pathori wrote:
> Thanks Alex for the clarification. Can somebody please clarify about
> subtree filter behaviour or provide some pointers in RFC so that I can
> refer to it.
> 
> On Thu 24 May, 2018, 5:56 AM Alex Campbell, 
> wrote:
> 
> > Hi,
> >
> >
> > Since nobody else has answered I'll have a go.
> >
> > I'm not familiar with subtree filtering, but I am with XPath. *Assuming
> > your XPath translation is accurate*, it will return no data (response A).
> >
> >
> > ------------------------------
> > *From:* netmod  on behalf of Shiva Kumar Pathori
> > 
> > *Sent:* Tuesday, 22 May 2018 8:38 p.m.
> > *To:* netmod@ietf.org
> > *Subject:* [netmod] Clarification about subtree filtering
> >
> >
> > Hi,
> >> Can somebody clarify what could be the response for the 
> >> operation provided below.
> >>
> >> Following is the user information in the datastore that is provided in
> >> the RFC 6241 as example.
> >>
> >>>  >>>           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >>>        
> >>>          
> >>>            
> >>>          
> >>>          
> >>>            
> >>>              
> >>>            
> >>>          
> >>>        
> >>>      
> >>
> >>
> >>  >>> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >>>   
> >>>     
> >>>       
> >>>         
> >>>           root
> >>>           superuser
> >>>           Charlie Root
> >>>           
> >>>             1
> >>>             1
> >>>           
> >>>         
> >>>         
> >>>           fred
> >>>           admin
> >>>           Fred Flintstone
> >>>           
> >>>             2
> >>>             2
> >>>           
> >>>         
> >>>         
> >>>           barney
> >>>           admin
> >>>           Barney Rubble
> >>>           
> >>>             2
> >>>             3
> >>>           
> >>>         
> >>>       
> >>>     
> >>>   
> >>> 
> >>
> >>
> >>
> >> *The  operation with content-match at parent and child nodes;*
> >>
> >> 
> >>>   
> >>>     
> >>>       
> >>>     
> >>>     
> >>>       
> >>>         
> >>>           
> >>>             admin
> >>>             
> >>>               1
> >>>             
> >>>           
> >>>         
> >>>       
> >>>     
> >>>   
> >>> 
> >>
> >>
> >> *The equivalent XPATH expression : *
> >>
> >>> 
> >>>   
> >>>     
> >>>       
> >>>     
> >>>      >>>                  type="xpath"
> >>>
> >>>  select="/t:top/t:users/t:user[t:type='admin']/t:company-info[t:dept=???1???]"/>
> >>>         
> >>>      
> >>
> >>
> >> For this what could be the response
> >>
> >> a) The response based on content-match nodes are AND-ed together
> >>
> >>>  >>> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >>>        
> >>>       
> >>>      
> >>
> >> OR
> >>
> >> b)  The response based on content-match nodes treated separately
> >>
> >>>  >>> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >>>   
> >>>     
> >>>       
> >>>         
> >>>           fred
> >>>           admin
> >>>           Fred Flintstone
> >>>         
> >>>         
> >>>           barney
> >>>           admin
> >>>           Barney Rubble
> >>>         
> >>>       
> >>>     
> >>>   
> >>> 
> >>
> >>
> >> Regards,
> >> Shiva
> >>
> >>
> >>
> >>

> _______________________________________________
> 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 Mon May 28 11:05:08 2018
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 01A3012D964 for ; Mon, 28 May 2018 11:05:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKElM4Nuuar7 for ; Mon, 28 May 2018 11:05:04 -0700 (PDT)
Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::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 04A8912D95A for ; Mon, 28 May 2018 11:05:04 -0700 (PDT)
Received: by mail-ot0-x235.google.com with SMTP id i5-v6so14290324otf.1 for ; Mon, 28 May 2018 11:05:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to;  bh=lAHQHp8jDjzIJbQGyoQAAiLUNqkEsgnz42rV3FGomdE=; b=oMYfoOfCdoHYREpKCZlS2ozE89i4QVlV0xQChX3q6/6QAormn/rfvsFuI7SFOcTQ3d 5S+r1IUlOp6wpHa8lH4IAhkTBHsRWsbHB4mYmcm8R+uHP95dTBb46ZnVSgoKrgdf/OcZ wkEh3xnipd+Ld6VOjIbKaUrlp9K9dbb+oZq3u4dOyHFsSJ+2ogONaWL4N8SmnwRtNuOs JHZuQwaGkmcX7xhAhjlyYjVY72jvrGhqot4BjrXd1hEET2LK9zTw17LAk3/72tjvgleI y32xJtTUbmJIpAF9r9Rn3WSowGeYVCQyVyds0oD0Fgud4fCfOjBTdQjNArKLM9q0fUv7 LcgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=lAHQHp8jDjzIJbQGyoQAAiLUNqkEsgnz42rV3FGomdE=; b=aVpvvex1OwxPv73E57YRQvK0FPcBN/HJSyQUMDcl63UKHGi+LZVWsSkRub7zZ5L4Xo mo1tCEvzLlEoqDTqDsy349sN0bf7Z7RzzRc7M5+pFZftvYLIyrn7/1VS3eOnsAzzZXbm NhgXsf4JDdF8fes6+SJhxdQDjs4jNGIMMmoYVulAxeoafk30GMkyFtM/fB0dikVKWXEf EB6IX+nahRDg8uqkPzi8CmpEeiV3L9hyi4CPxzTvI/lcW4nRn7bNex0RiVo+lZTsVxMG a5Pbp/Mr9wgpdqyEaKJv/Hd+JjO39CnhvD4CIVfbJGbd53/zqrtIwS0nW2x1nqpxC6Nc gMvQ==
X-Gm-Message-State: ALKqPwe0051yU1E4LciuVpSHKCT7wAjDWXQ/vE26MzEz85oGfVaEu7wM 2pzVzX8JbHmQKyFdyLSQ/UwotnUWqekD/Q39Lg9HHA==
X-Google-Smtp-Source: ADUXVKIFGgsJVIQX6euhgUfYzUFKy+L4VWAEEKHBSppDbGY8gbw+eGPxxHFh9Qaoz2Y11KSLFqc0kMH/A/5L7COgKEQ=
X-Received: by 2002:a9d:36ed:: with SMTP id s42-v6mr8749794otd.131.1527530703372;  Mon, 28 May 2018 11:05:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:424:0:0:0:0:0 with HTTP; Mon, 28 May 2018 11:05:02 -0700 (PDT)
In-Reply-To: <20180528094814.rzovxin7q4hgshff@anna.jacobs.jacobs-university.de>
References:   <1527121561343.62896@Aviatnet.com>  <20180528094814.rzovxin7q4hgshff@anna.jacobs.jacobs-university.de>
From: Shiva Kumar Pathori 
Date: Mon, 28 May 2018 23:35:02 +0530
Message-ID: 
To: Juergen Schoenwaelder ,  Shiva Kumar Pathori , Alex Campbell , netmod@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f546f0056d47f45e"
Archived-At: 
Subject: Re: [netmod] Clarification about subtree filtering
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 May 2018 18:05:07 -0000

--000000000000f546f0056d47f45e
Content-Type: text/plain; charset="UTF-8"

Hi,  I also have put the same question in netconf group.

On 28 May 2018 at 15:18, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> Hi,
>
> this is a netconf question and not a netmod question.
>
> /js
>
> On Mon, May 28, 2018 at 02:57:19PM +0530, Shiva Kumar Pathori wrote:
> > Thanks Alex for the clarification. Can somebody please clarify about
> > subtree filter behaviour or provide some pointers in RFC so that I can
> > refer to it.
> >
> > On Thu 24 May, 2018, 5:56 AM Alex Campbell, 
> > wrote:
> >
> > > Hi,
> > >
> > >
> > > Since nobody else has answered I'll have a go.
> > >
> > > I'm not familiar with subtree filtering, but I am with XPath. *Assuming
> > > your XPath translation is accurate*, it will return no data (response
> A).
> > >
> > >
> > > ------------------------------
> > > *From:* netmod  on behalf of Shiva Kumar
> Pathori
> > > 
> > > *Sent:* Tuesday, 22 May 2018 8:38 p.m.
> > > *To:* netmod@ietf.org
> > > *Subject:* [netmod] Clarification about subtree filtering
> > >
> > >
> > > Hi,
> > >> Can somebody clarify what could be the response for the 
> > >> operation provided below.
> > >>
> > >> Following is the user information in the datastore that is provided in
> > >> the RFC 6241 as example.
> > >>
> > >>>  > >>>           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > >>>        
> > >>>          
> > >>>            
> > >>>          
> > >>>          
> > >>>            
> > >>>              
> > >>>            
> > >>>          
> > >>>        
> > >>>      
> > >>
> > >>
> > >>  > >>> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > >>>   
> > >>>     
> > >>>       
> > >>>         
> > >>>           root
> > >>>           superuser
> > >>>           Charlie Root
> > >>>           
> > >>>             1
> > >>>             1
> > >>>           
> > >>>         
> > >>>         
> > >>>           fred
> > >>>           admin
> > >>>           Fred Flintstone
> > >>>           
> > >>>             2
> > >>>             2
> > >>>           
> > >>>         
> > >>>         
> > >>>           barney
> > >>>           admin
> > >>>           Barney Rubble
> > >>>           
> > >>>             2
> > >>>             3
> > >>>           
> > >>>         
> > >>>       
> > >>>     
> > >>>   
> > >>> 
> > >>
> > >>
> > >>
> > >> *The  operation with content-match at parent and child
> nodes;*
> > >>
> > >> 
> > >>>   
> > >>>     
> > >>>       
> > >>>     
> > >>>     
> > >>>       
> > >>>         
> > >>>           
> > >>>             admin
> > >>>             
> > >>>               1
> > >>>             
> > >>>           
> > >>>         
> > >>>       
> > >>>     
> > >>>   
> > >>> 
> > >>
> > >>
> > >> *The equivalent XPATH expression : *
> > >>
> > >>> 
> > >>>   
> > >>>     
> > >>>       
> > >>>     
> > >>>      > >>>                  type="xpath"
> > >>>
> > >>>  select="/t:top/t:users/t:user[t:type='admin']/t:company-
> info[t:dept=???1???]"/>
> > >>>         
> > >>>      
> > >>
> > >>
> > >> For this what could be the response
> > >>
> > >> a) The response based on content-match nodes are AND-ed together
> > >>
> > >>>  > >>> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > >>>        
> > >>>       
> > >>>      
> > >>
> > >> OR
> > >>
> > >> b)  The response based on content-match nodes treated separately
> > >>
> > >>>  > >>> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > >>>   
> > >>>     
> > >>>       
> > >>>         
> > >>>           fred
> > >>>           admin
> > >>>           Fred Flintstone
> > >>>         
> > >>>         
> > >>>           barney
> > >>>           admin
> > >>>           Barney Rubble
> > >>>         
> > >>>       
> > >>>     
> > >>>   
> > >>> 
> > >>
> > >>
> > >> Regards,
> > >> Shiva
> > >>
> > >>
> > >>
> > >>
>
> > _______________________________________________
> > 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         
>

--000000000000f546f0056d47f45e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,=C2=A0=C2=A0I also have put the same question in=
 netconf group.

On 28 May 2018 at 15:18, Juergen Schoenwaelder <j.s=
choenwaelder@jacobs-university.de> wrote:
Hi,



this is a netconf question and not a netmod question.



/js



On Mon, May 28, 2018 at 02:57:19PM +0530, Shiva Kumar Pathori wrote:

> Thanks Alex for the clarification. Can somebody please clarify about
> subtree filter behaviour or provide some pointers in RFC so that I can=


> refer to it.

> 

> On Thu 24 May, 2018, 5:56 AM Alex Campbell, <Alex.Campbell@aviatnet.com>

> wrote:

> 

> > Hi,

> >

> >

> > Since nobody else has answered I'll have a go.

> >

> > I'm not familiar with subtree filtering, but I am with=
 XPath. *Assuming

> > your XPath translation is accurate*, it will return no data (resp=
onse A).

> >

> >

> > ------------------------------

> > *From:* netmod <net=
mod-bounces@ietf.org> on behalf of Shiva Kumar Pathori

> > <pathori@gmail.com>=
;

> > *Sent:* Tuesday, 22 May 2018 8:38 p.m.

> > *To:* netmod@ietf.org

> > *Subject:* [netmod] Clarification about subtree filtering


> >

> >

> > Hi,

> >> Can somebody clarify what could be the response for the <g=
et-config>

> >> operation provided below.

> >>

> >> Following is the user information in the datastore that is pr=
ovided in

> >> the RFC 6241 as example.

> >>

> >>> <rpc message-id=3D"101"

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns=3D"urn=
:ietf:params:xml:ns:netconf:base:1.0">

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <get-config>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <source>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <running/>=


> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </source>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <filter type=3D"=
;subtree">

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <top xmlns=3D=
"http://example.com/schema/1.2/config">
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <users=
/>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </top>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </filter>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </get-config>

> >>>=C2=A0 =C2=A0 =C2=A0 </rpc>

> >>

> >>

> >> <rpc-reply message-id=3D"101"

> >>> xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.=
0">

> >>>=C2=A0 =C2=A0<data>

> >>>=C2=A0 =C2=A0 =C2=A0<top xmlns=3D"http:=
//example.com/schema/1.2/config">

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0<users>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<user>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>root&=
lt;/name>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<type>super=
user</type>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<full-name>=
Charlie Root</full-name>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<company-info&=
gt;

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<dept&g=
t;1</dept>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<id>=
1</id>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</company-info=
>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</user>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<user>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>fred&=
lt;/name>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<type>admin=
</type>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<full-name>=
Fred Flintstone</full-name>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<company-info&=
gt;

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<dept&g=
t;2</dept>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<id>=
2</id>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</company-info=
>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</user>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<user>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>barne=
y</name>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<type>admin=
</type>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<full-name>=
Barney Rubble</full-name>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<company-info&=
gt;

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<dept&g=
t;2</dept>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<id>=
3</id>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</company-info=
>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</user>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0</users>

> >>>=C2=A0 =C2=A0 =C2=A0</top>

> >>>=C2=A0 =C2=A0</data>

> >>> </rpc-reply>

> >>

> >>

> >>


> >> *The <get-config> operation with content-ma=
tch at parent and child nodes;*

> >>

> >> <rpc message-id=3D"101" xmlns=3D"urn:ietf:p=
arams:xml:ns:netconf:base:1.0">

> >>>=C2=A0 =C2=A0<get-config>

> >>>=C2=A0 =C2=A0 =C2=A0<source>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0<running/>

> >>>=C2=A0 =C2=A0 =C2=A0</source>

> >>>=C2=A0 =C2=A0 =C2=A0<filter type=3D"subtree"&=
gt;

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0<top xmlns=3D"http://example.com/schema/1.2/config">

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<users>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<user>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<type&g=
t;admin</name>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<compan=
y-info>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<=
;dept>1</dept>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</compa=
ny-info>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</user>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</users>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0</top>

> >>>=C2=A0 =C2=A0 =C2=A0</filter>

> >>>=C2=A0 =C2=A0</get-config>

> >>> </rpc>

> >>

> >>

> >> *The equivalent XPATH expression : *

> >>

> >>> <rpc message-id=3D"101" xmlns=3D"urn:ie=
tf:params:xml:ns:netconf:base:1.0">

> >>>=C2=A0 =C2=A0<get-config>

> >>>=C2=A0 =C2=A0 =C2=A0<source>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0<running/>

> >>>=C2=A0 =C2=A0 =C2=A0</source>

> >>>=C2=A0 =C2=A0 =C2=A0<filter xmlns:t=3D"=
http://example.com/schema/1.2/config"

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 type=3D"xpath"

> >>>

> >>>=C2=A0 select=3D"/t:top/t:users/t:user[t:=
type=3D'admin']/t:company-info[t:dept=3D???1???]"/>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&=
lt;/get-config>

> >>>=C2=A0 =C2=A0 =C2=A0 </rpc>

> >>

> >>

> >> For this what could be the response

> >>

> >> a) The response based on content-match nodes are AND-ed toget=
her

> >>

> >>> <rpc-reply message-id=3D"101"

> >>> xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.=
0">

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <data>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0</data>

> >>>=C2=A0 =C2=A0 =C2=A0 </rpc-reply>

> >>

> >> OR

> >>

> >> b)=C2=A0 The response based on content-match nodes treated se=
parately

> >>

> >>> <rpc-reply message-id=3D"101"

> >>> xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.=
0">

> >>>=C2=A0 =C2=A0<data>

> >>>=C2=A0 =C2=A0 =C2=A0<top xmlns=3D"http:=
//example.com/schema/1.2/config">

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0<users>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<user>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>fred&=
lt;/name>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<type>admin=
</type>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<full-name>=
Fred Flintstone</full-name>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</user>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<user>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>barne=
y</name>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<type>admin=
</type>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<full-name>=
Barney Rubble</full-name>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</user>

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0</users>

> >>>=C2=A0 =C2=A0 =C2=A0</top>

> >>>=C2=A0 =C2=A0</data>

> >>> </rpc-reply>

> >>

> >>

> >> Regards,

> >> Shiva

> >>

> >>

> >>

> >>




> _______________________________________________

> netmod mailing list

> netmod@ietf.org

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





-- 

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

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





--000000000000f546f0056d47f45e--


From nobody Mon May 28 17:56:37 2018
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 93D9912E86C for ; Mon, 28 May 2018 17:56:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDYqmQUhFVpE for ; Mon, 28 May 2018 17:56:33 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0725.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::725]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B34DD12E05D for ; Mon, 28 May 2018 17:56:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gl24sRecGGv4004kylFkvE/Md6gNLkddfhOW3U8XMSY=; b=bImiVodGKPgR7wzf7M4igcSa3KJfV0fG7CQCyNrZkQFwrvCUynPtt7g5qFL2gWPVZCldovp8U95CW+C4qJ5/m5bf1RDVnDk3b8HFTZQCMZ+rS8YAeQkwSrVtVEprf9k+xyfht9PDcCRGY7vKBEzeAZ0lhzeDr0Y1aTAHrOtcY6Y=
Received: from DB6PR07MB4421.eurprd07.prod.outlook.com (10.168.24.142) by DB6PR07MB3384.eurprd07.prod.outlook.com (10.175.234.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.5; Tue, 29 May 2018 00:56:30 +0000
Received: from DB6PR07MB4421.eurprd07.prod.outlook.com ([fe80::a8a8:56c2:3696:4be7]) by DB6PR07MB4421.eurprd07.prod.outlook.com ([fe80::a8a8:56c2:3696:4be7%2]) with mapi id 15.20.0820.005; Tue, 29 May 2018 00:56:30 +0000
From: "Bogaert, Bart (Nokia - BE/Antwerp)" 
To: "netmod@ietf.org" 
Thread-Topic: leaf-list in YANG 1.1
Thread-Index: AdP25fycB9A0DIxRRXyoayBZtavGuA==
Date: Tue, 29 May 2018 00:56:29 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com; 
x-originating-ip: [116.246.26.58]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB6PR07MB3384; 7:Qf393SqARgD54dE5/JKqVmEiazddB5G/mx33R6mpWFNJoEID9LDGqx1OCCuaE7i7RyjiITNuUGJyaGdClF2MzT7vF+4Q3ANe4YekeEQRXvPtOXEBIAThvqrcFuXBjMKHGEAoaWXMgt90vx5WyE6Lp7T7VbmFUj/F3rop6fj15Z29Y/G24pyiKPyvxylpY9PvEp1w9ZT7dIYJnGbVA3XKLjN45kBtuypa5/En1jDliYS7rQDN045eoxnxlnsAo8om
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7193020); SRVR:DB6PR07MB3384; 
x-ms-traffictypediagnostic: DB6PR07MB3384:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(3231254)(11241501184)(806099)(944501410)(52105095)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:DB6PR07MB3384; BCL:0; PCL:0; RULEID:; SRVR:DB6PR07MB3384; 
x-forefront-prvs: 0687389FB0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(396003)(39380400002)(366004)(346002)(189003)(199004)(8676002)(7696005)(476003)(59450400001)(6506007)(33656002)(3846002)(6116002)(790700001)(486006)(81166006)(81156014)(1730700003)(2501003)(97736004)(5250100002)(5660300001)(6306002)(9686003)(7736002)(6916009)(25786009)(5640700003)(99286004)(6436002)(53936002)(54896002)(2906002)(478600001)(5630700001)(316002)(106356001)(102836004)(2351001)(14454004)(105586002)(68736007)(86362001)(66066001)(26005)(8936002)(3660700001)(3280700002)(55016002)(2900100001)(74316002)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR07MB3384; H:DB6PR07MB4421.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: zsBYOZ5kGxcWFfGtpaP4ZkjWShsXo25PbRwvA8LO0ve0kJtm4KyJ9aGaLbbTblhP9JXakVMr9lYv6grIbJUjJ7zPlnGFi++8HLwH1ogRNpbkMtDz1uhS73QmUBIy4WAyMVhT1HsAqx8GybeBM930AUCZE9ACbHdHtpfZHg9npCBLov4Yh/3XdDeLdXXdy0/FCJHXEl1sifm6FH7R61B1QhBAZD+W81QZWmpLcfLO6oI=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB6PR07MB442102BCE3D8DD74BE45BB40946D0DB6PR07MB4421eurp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 3ab0ab16-7669-4947-5599-08d5c4ff03b4
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3ab0ab16-7669-4947-5599-08d5c4ff03b4
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2018 00:56:29.9710 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3384
Archived-At: 
Subject: [netmod] leaf-list in YANG 1.1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 May 2018 00:56:36 -0000

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

Hi,

We have a question about the leaf-list in config-false data.  When comparin=
g YANG 1.0 and YANG 1.1 the restriction on having unique values seems to ha=
ve been lifted for config-false data:

  *   Section 7.7 RFC 7950: "In configuration data, the values in a leaf-li=
st MUST be unique."
  *   Section 7.7 RFC 6020: "The values in a leaf-list MUST be unique.")

This means one can have multiple entries with the same value in a state lea=
f-list.  What is expected to happen when you delete an entry by specifying =
the value of the leaf-list entry and there happen to be multiple entries wi=
th the same value? Are all these entries deleted or is one expected to perf=
orm as many delete operations as there are entries matching the value speci=
fied in the delete operation?

Regards, Bart

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











Hi,


 


We have a question about the le=
af-list in config-false data.  When comparing YANG 1.0 and YANG 1.1 th=
e restriction on having unique values seems to have been lifted for config-=
false data:


    

  • Section 7.7 RFC 7950: “In configuration da=
ta, the values in a leaf-list MUST be unique.”
    • =

  • Section 7.7 RFC 6020: “The values in a lea=
f-list MUST be unique.”)


 


This means one can have multipl=
e entries with the same value in a state leaf-list.  What is expected =
to happen when you delete an entry by specifying the value of the leaf-list=
 entry and there happen to be multiple entries
 with the same value? Are all these entries deleted or is one expected to p=
erform as many delete operations as there are entries matching the value sp=
ecified in the delete operation?


 


Regards, Bart=







--_000_DB6PR07MB442102BCE3D8DD74BE45BB40946D0DB6PR07MB4421eurp_--


From nobody Mon May 28 19:14:06 2018
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 F0453127775 for ; Mon, 28 May 2018 19:14:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBCybwA_pLgf for ; Mon, 28 May 2018 19:14:03 -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 3B578126DD9 for ; Mon, 28 May 2018 19:14:03 -0700 (PDT)
From: Alex Campbell 
To: "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" 
Thread-Topic: leaf-list in YANG 1.1
Thread-Index: AdP25fycB9A0DIxRRXyoayBZtavGuAADKpdC
Date: Tue, 29 May 2018 02:14:00 +0000
Message-ID: <1527560040669.32302@Aviatnet.com>
References: 
In-Reply-To: 
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.10]
Content-Type: multipart/alternative; boundary="_000_152756004066932302Aviatnetcom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] leaf-list in YANG 1.1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 May 2018 02:14:05 -0000

--_000_152756004066932302Aviatnetcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

As far as I'm aware, state values are not writable by the client, so the qu=
estion is moot.


Regards, Alex


________________________________
From: netmod  on behalf of Bogaert, Bart (Nokia - =
BE/Antwerp) 
Sent: Tuesday, 29 May 2018 12:56 p.m.
To: netmod@ietf.org
Subject: [netmod] leaf-list in YANG 1.1

CAUTION: This email originated from outside of the organization. Do not cli=
ck links or open attachments unless you recognize the sender and know the c=
ontent is safe.

Hi,

We have a question about the leaf-list in config-false data.  When comparin=
g YANG 1.0 and YANG 1.1 the restriction on having unique values seems to ha=
ve been lifted for config-false data:

  *   Section 7.7 RFC 7950: "In configuration data, the values in a leaf-li=
st MUST be unique."
  *   Section 7.7 RFC 6020: "The values in a leaf-list MUST be unique.")

This means one can have multiple entries with the same value in a state lea=
f-list.  What is expected to happen when you delete an entry by specifying =
the value of the leaf-list entry and there happen to be multiple entries wi=
th the same value? Are all these entries deleted or is one expected to perf=
orm as many delete operations as there are entries matching the value speci=
fied in the delete operation?

Regards, Bart

--_000_152756004066932302Aviatnetcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








As far as I'm aware, state values are not writable by the client, so the=
 question is moot.







Regards, Alex











From: netmod <netmod-b=
ounces@ietf.org> on behalf of Bogaert, Bart (Nokia - BE/Antwerp) <bar=
t.bogaert@nokia.com>

Sent: Tuesday, 29 May 2018 12:56 p.m.

To: netmod@ietf.org

Subject: [netmod] leaf-list in YANG 1.1

 







CAUTION: This email =
originated from outside of the organization. Do not click links or open att=
achments unless you recognize the sender and know the content is safe.







Hi,


 


We have a question about the le=
af-list in config-false data.  When comparing YANG 1.0 and YANG 1.1 th=
e restriction on having unique values seems to have been lifted for config-=
false data:


    

  • Section 7.7 RFC 7950: “In configuration data, the values in a leaf=
-list MUST be unique.”
  • Section 7.7 RFC 6020: “The=
 values in a leaf-list MUST be unique.”)


 


This means one can have multipl=
e entries with the same value in a state leaf-list.  What is expected =
to happen when you delete an entry by specifying the value of the leaf-list=
 entry and there happen to be multiple entries
 with the same value? Are all these entries deleted or is one expected to p=
erform as many delete operations as there are entries matching the value sp=
ecified in the delete operation?


 


Regards, Bart












--_000_152756004066932302Aviatnetcom_--


From nobody Tue May 29 02:35:28 2018
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 D597D12E8CE for ; Tue, 29 May 2018 02:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXzfP-AX2zpz for ; Tue, 29 May 2018 02:35:24 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E145412E874 for ; Tue, 29 May 2018 02:35:23 -0700 (PDT)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id BC20FA6DF506C for ; Tue, 29 May 2018 10:35:18 +0100 (IST)
Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 29 May 2018 10:35:19 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.161]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0382.000; Tue, 29 May 2018 17:35:09 +0800
From: Rohit R Ranade 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
Thread-Index: AdP3LxM2Qa00BJMETVeCiSY+xVpFuw==
Date: Tue, 29 May 2018 09:35:09 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BBB23B2@dggeml510-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BBB23B2dggeml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [netmod]  draft-ietf-netconf-rfc7895bis-06 deviation query
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 May 2018 09:35:26 -0000

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

Hi All,

Consider the below YANG tree, which contains both "rw" and "ro" nodes.

module: ietf-interfaces
    +--rw interfaces
    |  +--rw interface* [name]
    |     +--rw name                        string
    |     +--rw description?                string
    |     +--rw type                        identityref
    |     +--rw enabled?                    boolean
    |     +--rw link-up-down-trap-enable?   enumeration {if-mib}?
    |     +--ro admin-status                enumeration {if-mib}?
    |     +--ro oper-status                 enumeration
    |     +--ro last-change?                yang:date-and-time
    |     +--ro if-index                    int32 {if-mib}?
    |     +--ro phys-address?               yang:phys-address
    |     +--ro higher-layer-if*            interface-ref

>From what I understand, in the new yang-library structure the schema for  data-store will have the complete YANG tree. The schema for  will need to add deviations with "not-supported" for all the "ro" no=
des for this module ?

With Regards,
Rohit R Ranade


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











Hi All,


 


Consider the below YANG tree, w=
hich contains both “rw” and “ro” nodes.<=
/span>


 


module: ietf-interfaces


    +--rw in=
terfaces


    |  +=
;--rw interface* [name]


    |  =
;   +--rw name        =
;            &n=
bsp;   string


    |  =
;   +--rw description?      &nb=
sp;         string


    |  =
;   +--rw type        =
;            &n=
bsp;   identityref


    |  =
;   +--rw enabled?       &=
nbsp;            boo=
lean


    |  =
;   +--rw link-up-down-trap-enable?   enumeration {=
if-mib}?


    |  =
;   +--ro admin-status      &nb=
sp;         enumeration {if-mib}?


    |  =
;   +--ro oper-status      &nbs=
p;          enumeration


    |  =
;   +--ro last-change?      &nb=
sp;         yang:date-and-time=



    |  =
;   +--ro if-index       &=
nbsp;            int=
32 {if-mib}?


    |  =
;   +--ro phys-address?      &n=
bsp;        yang:phys-address=



    |  =
;   +--ro higher-layer-if*      =
;      interface-ref


 


From what I understand, in the =
new yang-library structure the schema for <operational> data-store wi=
ll have the complete YANG tree. The schema for <running> will need to=
 add deviations with “not-supported” for all the
 “ro” nodes for this module ? 


 


With Regards,=



Rohit R Ranade


 






--_000_991B70D8B4112A4699D5C00DDBBF878A6BBB23B2dggeml510mbxchi_--


From nobody Tue May 29 02:57:47 2018
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 6A71A126FDC for ; Tue, 29 May 2018 02:57:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level: 
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQ4E-twd-5qy for ; Tue, 29 May 2018 02:57:43 -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 0F742126579 for ; Tue, 29 May 2018 02:57:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7985; q=dns/txt; s=iport; t=1527587863; x=1528797463; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=cxRWopPI3mbvRkVZPAEX0lTsrJeSsFWSjxUDGSWedG0=; b=HkMRJ8wWJoogtiJfgf+/twrj7zT7Bo81yDnF86jY5yk/pcCSk448bgsb gYRmA0mxXG4BHoKPbxKTSZteZAGZq6dGLhX2010dgr/kEAr6DysBS5qLh eZr3PT/Iei455QvacpN3puVyIn3GDdhbhZ+L3XycvoLauUL9QCXRx6nBQ 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CNAQCgIw1b/xbLJq1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJOgVhtEiiMWo1jIYEPjkSGbwsYAQqEA0YCgjY4FAECAQE?= =?us-ascii?q?BAQEBAmwcDIUoAQEBAwEBAStBEAsLGC4nMAYBDAYCAQGDHgKBdwgPpi4fhDm?= =?us-ascii?q?DZYFjBYoKP4EPJAyCXYMRAQGBSoVqAowqjDgJjloGh2eFH4tahTGBWCGBUjM?= =?us-ascii?q?aCBsVO4JDixCFPz4wkCQBAQ?=
X-IronPort-AV: E=Sophos;i="5.49,455,1520899200"; d="scan'208,217";a="4103827"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 May 2018 09:57:39 +0000
Received: from [10.63.23.83] (dhcp-ensft1-uk-vla370-10-63-23-83.cisco.com [10.63.23.83]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w4T9vdf1001254; Tue, 29 May 2018 09:57:39 GMT
To: Rohit R Ranade , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB23B2@dggeml510-mbx.china.huawei.com>
From: Robert Wilton 
Message-ID: <71e76c7e-4043-d80a-73ac-1759e85cc5d7@cisco.com>
Date: Tue, 29 May 2018 10:57:39 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BBB23B2@dggeml510-mbx.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------EA8ABC75FD130CE5DC3AAEA2"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 May 2018 09:57:46 -0000

This is a multi-part message in MIME format.
--------------EA8ABC75FD130CE5DC3AAEA2
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi Rohit,


On 29/05/2018 10:35, Rohit R Ranade wrote:
>
> Hi All,
>
> Consider the below YANG tree, which contains both rw and ro nodes.
>
> module: ietf-interfaces
>
>  +--rw interfaces
>
>  | +--rw interface* [name]
>
>  | +--rw name string
>
>  | +--rw description? string
>
>  | +--rw type identityref
>
>  | +--rw enabled? boolean
>
>  | +--rw link-up-down-trap-enable? enumeration {if-mib}?
>
>  | +--ro admin-status enumeration {if-mib}?
>
>  | +--ro oper-status enumeration
>
>  | +--ro last-change? yang:date-and-time
>
>  | +--ro if-index int32 {if-mib}?
>
>  | +--ro phys-address? yang:phys-address
>
>  | +--ro higher-layer-if* interface-ref
>
> From what I understand, in the new yang-library structure the schema 
> for  data-store will have the complete YANG tree. The 
> schema for  will need to add deviations with not-supported 
> for all the ro nodes for this module ?
>
No need for the deviations for .  only contains the 
"config true" parts of the schema.

So, for a normal, NMDA compliant server, the same schema can be used for 
all datastores.

Thanks,
Rob


> With Regards,
>
> Rohit R Ranade
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--------------EA8ABC75FD130CE5DC3AAEA2
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Rohit,

    

    

    
On 29/05/2018 10:35, Rohit R Ranade
      wrote:

    

    

      
      
      
      

        
Hi All,

        

        
Consider the below YANG
            tree, which contains both rw and ro nodes.

        

        
module: ietf-interfaces

        
 +--rw interfaces

        
 | +--rw interface*
            [name]

        
 | +--rw
            name string

        
 | +--rw
            description? string

        
 | +--rw
            type identityref

        
 | +--rw
            enabled? boolean

        
 | +--rw
            link-up-down-trap-enable? enumeration {if-mib}?

        
 | +--ro
            admin-status enumeration {if-mib}?

        
 | +--ro
            oper-status enumeration

        
 | +--ro
            last-change? yang:date-and-time

        
 | +--ro
            if-index int32 {if-mib}?

        
 | +--ro
            phys-address? yang:phys-address

        
 | +--ro
            higher-layer-if* interface-ref

        

        
From what I understand,
            in the new yang-library structure the schema for
            <operational> data-store will have the complete YANG
            tree. The schema for <running> will need to add
            deviations with not-supported for all the ro nodes for
            this module ? 

      

    

    No need for the deviations for <running>. <running>
    only contains the "config true" parts of the schema.

    

    So, for a normal, NMDA compliant server, the same schema can be used
    for all datastores.

    

    Thanks,

    Rob

    

    

    

      

        

        

        
With Regards,

        
Rohit R Ranade

        

      

      

      

      

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


    

    

  


--------------EA8ABC75FD130CE5DC3AAEA2--


From nobody Tue May 29 03:44:25 2018
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 8724712E88B for ; Tue, 29 May 2018 03:44:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.189
X-Spam-Level: 
X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdtdEA-F-NaE for ; Tue, 29 May 2018 03:44:21 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1961212E85B for ; Tue, 29 May 2018 03:44:21 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id DFB4EC90D708B for ; Tue, 29 May 2018 11:44:13 +0100 (IST)
Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 29 May 2018 11:44:15 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.161]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0382.000; Tue, 29 May 2018 18:44:04 +0800
From: Rohit R Ranade 
To: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
Thread-Index: AdP3LxM2Qa00BJMETVeCiSY+xVpFu///grGA//9vcjA=
Date: Tue, 29 May 2018 10:44:04 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BBB241F@dggeml510-mbx.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB23B2@dggeml510-mbx.china.huawei.com> <71e76c7e-4043-d80a-73ac-1759e85cc5d7@cisco.com>
In-Reply-To: <71e76c7e-4043-d80a-73ac-1759e85cc5d7@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BBB241Fdggeml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 May 2018 10:44:24 -0000

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

Hi Robert,

The Introduction section has :
"
Furthermore, the operational state datastore may support non-configurable Y=
ANG modules in addition to
   the YANG modules supported by conventional configuration datastores.
"
I infer that in the new Yang-library structure,  the schema for "convention=
al" data-stores should not include the non-configurable YANG module. Is my =
inference correct ?

With Regards,
Rohit R Ranade
From: Robert Wilton [mailto:rwilton@cisco.com]
Sent: 29 May 2018 15:28
To: Rohit R Ranade ; netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query


Hi Rohit,

On 29/05/2018 10:35, Rohit R Ranade wrote:
Hi All,

Consider the below YANG tree, which contains both "rw" and "ro" nodes.

module: ietf-interfaces
    +--rw interfaces
    |  +--rw interface* [name]
    |     +--rw name                        string
    |     +--rw description?                string
    |     +--rw type                        identityref
    |     +--rw enabled?                    boolean
    |     +--rw link-up-down-trap-enable?   enumeration {if-mib}?
    |     +--ro admin-status                enumeration {if-mib}?
    |     +--ro oper-status                 enumeration
    |     +--ro last-change?                yang:date-and-time
    |     +--ro if-index                    int32 {if-mib}?
    |     +--ro phys-address?               yang:phys-address
    |     +--ro higher-layer-if*            interface-ref

>From what I understand, in the new yang-library structure the schema for  data-store will have the complete YANG tree. The schema for  will need to add deviations with "not-supported" for all the "ro" no=
des for this module ?
No need for the deviations for .   only contains the "con=
fig true" parts of the schema.

So, for a normal, NMDA compliant server, the same schema can be used for al=
l datastores.

Thanks,
Rob




With Regards,
Rohit R Ranade





_______________________________________________

netmod mailing list

netmod@ietf.org

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


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











Hi Robe=
rt,


&n=
bsp;


The Int=
roduction section has :


“=



Furthermore, the operational state datastore may support =
non-configurable YANG modules in addition to


   the YANG modules supported by conventional c=
onfiguration datastores.


”=



I infer=
 that in the new Yang-library structure,  the schema for “conven=
tional” data-stores should not include the non-configurable YANG modu=
le. Is my inference correct ?



&n=
bsp;


With Re=
gards,




Rohit R=
 Ranade








From: Robert Wilt=
on [mailto:rwilton@cisco.com]


Sent: 29 May 2018 15:28

To: Rohit R Ranade <rohitrranade@huawei.com>; netmod@ietf.org<=
br>
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation que=
ry






 


Hi Rohit,


 




On 29/05/2018 10:35, Rohit R Ra=
nade wrote:






Hi All,


 


Consider the below YANG tree, w=
hich contains both “rw” and “ro” nodes.<=
/span>


 


module: ietf-interfaces


    +--rw in=
terfaces


    |  +=
;--rw interface* [name]


    |  =
;   +--rw name        =
;            &n=
bsp;   string


    |  =
;   +--rw description?      &nb=
sp;         string


    |  =
;   +--rw type        =
;            &n=
bsp;   identityref


    |  =
;   +--rw enabled?       &=
nbsp;            boo=
lean


    |  =
;   +--rw link-up-down-trap-enable?   enumeration {=
if-mib}?


    |  =
;   +--ro admin-status      &nb=
sp;         enumeration {if-mib}?


    |  =
;   +--ro oper-status      &nbs=
p;          enumeration


    |  =
;   +--ro last-change?      &nb=
sp;         yang:date-and-time=



    |  =
;   +--ro if-index       &=
nbsp;            int=
32 {if-mib}?


    |  =
;   +--ro phys-address?      &n=
bsp;        yang:phys-address=



    |  =
;   +--ro higher-layer-if*      =
;      interface-ref


 


From what I understand, in the =
new yang-library structure the schema for <operational> data-store wi=
ll have the complete YANG tree. The schema for <running> will need to=
 add deviations with “not-supported” for all the
 “ro” nodes for this module ? 




No need for the deviations for <running>.  <running&=
gt; only contains the "config true" parts of the schema.



So, for a normal, NMDA compliant server, the same schema can be used for al=
l datastores.



Thanks,

Rob












 


With Regards,=



Rohit R Ranade


 











_______________________________________________


netmod mailing list


netmod@ietf.or=
g


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



 






--_000_991B70D8B4112A4699D5C00DDBBF878A6BBB241Fdggeml510mbxchi_--


From nobody Tue May 29 03:57:38 2018
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 0BF1B126CF9 for ; Tue, 29 May 2018 03:57:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rQBG9onnlPA for ; Tue, 29 May 2018 03:57:33 -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 439E4126BF0 for ; Tue, 29 May 2018 03:57:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15401; q=dns/txt; s=iport; t=1527591453; x=1528801053; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=DltYGAMMITwZhZlWEXvRQkobCgc4ahRXvlfUJq/ya34=; b=kl5Z35uf6brsppgj7GQ7S0UtqQjH1FIKlmVlOaB9W9ZK4oO5u0+HqD10 YLae5boTDu9KutDYd14ezRqmtEFGUrfJfk4MkkNk6hr40PXaQCFxcDA2M xyOjLZSWc4HocWFvq8PJaoxHg48nw7gcLavkH9n76WYWO9UPAjk/rcC1O w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CCAQC8MA1b/xbLJq1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJOgVhtEiiMWo1kIYEPjkSEd4F4CxgBCoQDRgKCNzYWAQI?= =?us-ascii?q?BAQEBAQECbBwMhSgBAQEEAQErQRsLEQQBAQEnBycfCQgGAQwGAgEBgx4CgX8?= =?us-ascii?q?PpjwfhDmDZYFjBYoKP4EPJAyCXYMRAQGBSkyFHgKMKow4CY5aBodnhR+LWoU?= =?us-ascii?q?xgUgBMIFSMxoIGxU7gkOLEIU/PjCPZwEB?=
X-IronPort-AV: E=Sophos;i="5.49,456,1520899200"; d="scan'208,217";a="4105281"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 May 2018 10:57:31 +0000
Received: from [10.63.23.83] (dhcp-ensft1-uk-vla370-10-63-23-83.cisco.com [10.63.23.83]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w4TAvU92014943; Tue, 29 May 2018 10:57:30 GMT
To: Rohit R Ranade , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB23B2@dggeml510-mbx.china.huawei.com> <71e76c7e-4043-d80a-73ac-1759e85cc5d7@cisco.com> <991B70D8B4112A4699D5C00DDBBF878A6BBB241F@dggeml510-mbx.china.huawei.com>
From: Robert Wilton 
Message-ID: 
Date: Tue, 29 May 2018 11:57:30 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BBB241F@dggeml510-mbx.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------8A99559189F5D341CC989C88"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 May 2018 10:57:36 -0000

This is a multi-part message in MIME format.
--------------8A99559189F5D341CC989C88
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi Rohit,

If you have a module, "mod-state-only", that only contains "config 
false" nodes then either of the following approaches is valid:

(1) You include the "mod-state-only" module in the schema for both 
conventional datastores and . All config false leaves will 
be ignored anyway for the configuration datastores.

(1) You define separate schema for the conventional datastores vs 
operational. "mod-state-only" isn't present in the schema for the 
conventional datastores, but is present in .

Either approach is valid, and I don't recall the YANG library bis draft 
stating any preference.

Thanks,
Rob


On 29/05/2018 11:44, Rohit R Ranade wrote:
>
> Hi Robert,
>
> The Introduction section has :
>
> 
>
> Furthermore, the operational state datastore may support 
> non-configurable YANG modules in addition to
>
>  the YANG modules supported by conventional configuration datastores.
>
> 
>
> I infer that in the new Yang-library structure, the schema for 
> conventional data-stores should not include the non-configurable 
> YANG module. Is my inference correct ?
>
> With Regards,
>
> Rohit R Ranade
>
> *From:*Robert Wilton [mailto:rwilton@cisco.com]
> *Sent:* 29 May 2018 15:28
> *To:* Rohit R Ranade ; netmod@ietf.org
> *Subject:* Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
>
> Hi Rohit,
>
> On 29/05/2018 10:35, Rohit R Ranade wrote:
>
>     Hi All,
>
>     Consider the below YANG tree, which contains both rw and ro nodes.
>
>     module: ietf-interfaces
>
>      +--rw interfaces
>
>      | +--rw interface* [name]
>
>      | +--rw name string
>
>      | +--rw description? string
>
>      | +--rw type identityref
>
>      | +--rw enabled? boolean
>
>      | +--rw link-up-down-trap-enable? enumeration {if-mib}?
>
>      | +--ro admin-status enumeration {if-mib}?
>
>      | +--ro oper-status enumeration
>
>      | +--ro last-change? yang:date-and-time
>
>      | +--ro if-index int32 {if-mib}?
>
>      | +--ro phys-address? yang:phys-address
>
>      | +--ro higher-layer-if* interface-ref
>
>     From what I understand, in the new yang-library structure the
>     schema for  data-store will have the complete YANG
>     tree. The schema for  will need to add deviations with
>     not-supported for all the ro nodes for this module ?
>
> No need for the deviations for .  only contains the 
> "config true" parts of the schema.
>
> So, for a normal, NMDA compliant server, the same schema can be used 
> for all datastores.
>
> Thanks,
> Rob
>
>
>
>     With Regards,
>
>     Rohit R Ranade
>
>
>
>
>     _______________________________________________
>
>     netmod mailing list
>
>     netmod@ietf.org 
>
>     https://www.ietf.org/mailman/listinfo/netmod
>


--------------8A99559189F5D341CC989C88
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Rohit,

    
If you have a module, "mod-state-only", that only contains
      "config false" nodes then either of the following approaches is
      valid:

    
(1) You include the "mod-state-only" module in the schema for
      both conventional datastores and <operational>. All config
      false leaves will be ignored anyway for the configuration
      datastores.

    

    
(1) You define separate schema for the conventional datastores vs
      operational. "mod-state-only" isn't present in the schema for the
      conventional datastores, but is present in <operational>.

    
Either approach is valid, and I don't recall the YANG library bis
      draft stating any preference.

    
Thanks,

      Rob

    

    

    
On 29/05/2018 11:44, Rohit R Ranade
      wrote:

    

    

      
      
      
      

        
Hi
            Robert,

        

        
The
            Introduction section has :

        

        
Furthermore, the operational state datastore
            may support non-configurable YANG modules in addition to

        
 the YANG modules supported by conventional
            configuration datastores.

        

        
I
            infer that in the new Yang-library structure, the schema
            for conventional data-stores should not include the
            non-configurable YANG module. Is my inference correct ?
            

        

        
With
            Regards,

        

          
Rohit
              R Ranade

        

        

          

            
From:
                Robert Wilton [mailto:rwilton@cisco.com]
                

                Sent: 29 May 2018 15:28

                To: Rohit R Ranade
                <rohitrranade@huawei.com>; netmod@ietf.org

                Subject: Re: [netmod]
                draft-ietf-netconf-rfc7895bis-06 deviation query

          

        

        

        
Hi Rohit,

        

        

          
On 29/05/2018 10:35,
              Rohit R Ranade wrote:

        

        

          
Hi All,

          

          
Consider the below
              YANG tree, which contains both rw and ro nodes.

          

          
module:
              ietf-interfaces

          
 +--rw interfaces

          
 | +--rw
              interface* [name]

          
 | +--rw
              name string

          
 | +--rw
              description? string

          
 | +--rw
              type identityref

          
 | +--rw
              enabled? boolean

          
 | +--rw
              link-up-down-trap-enable? enumeration {if-mib}?

          
 | +--ro
              admin-status enumeration {if-mib}?

          
 | +--ro
              oper-status enumeration

          
 | +--ro
              last-change? yang:date-and-time

          
 | +--ro
              if-index int32 {if-mib}?

          
 | +--ro
              phys-address? yang:phys-address

          
 | +--ro
              higher-layer-if* interface-ref

          

          
From what I
              understand, in the new yang-library structure the schema
              for <operational> data-store will have the complete
              YANG tree. The schema for <running> will need to add
              deviations with not-supported for all the ro nodes for
              this module ? 

        

        
No need for the deviations
            for <running>. <running> only contains the
            "config true" parts of the schema.

            

            So, for a normal, NMDA compliant server, the same schema can
            be used for all datastores.

            

            Thanks,

            Rob

            

            

            

            

        

          

          
With Regards,

          
Rohit R Ranade

          

          


              

              

              

          
_______________________________________________

          
netmod mailing list

          
netmod@ietf.org

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

        

        

      

    

    

  


--------------8A99559189F5D341CC989C88--


From nobody Tue May 29 04:06:15 2018
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 62AA412E8C6 for ; Tue, 29 May 2018 04:06:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNh7Q4k4Pxa8 for ; Tue, 29 May 2018 04:06:12 -0700 (PDT)
Received: from anna.localdomain (firewallix.jacobs-university.de [212.201.44.247]) by ietfa.amsl.com (Postfix) with ESMTP id 2F57F12E8CA for ; Tue, 29 May 2018 04:06:12 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id 7FC8C219C879; Tue, 29 May 2018 13:06:10 +0200 (CEST)
Date: Tue, 29 May 2018 13:06:10 +0200
From: Juergen Schoenwaelder 
To: Rohit R Ranade 
Cc: Robert Wilton , "netmod@ietf.org" 
Message-ID: <20180529110610.4rcqvp7x4qpbg5hz@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Rohit R Ranade , Robert Wilton , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB23B2@dggeml510-mbx.china.huawei.com> <71e76c7e-4043-d80a-73ac-1759e85cc5d7@cisco.com> <991B70D8B4112A4699D5C00DDBBF878A6BBB241F@dggeml510-mbx.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BBB241F@dggeml510-mbx.china.huawei.com>
User-Agent: NeoMutt/20180512
Archived-At: 
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 May 2018 11:06:15 -0000

On Tue, May 29, 2018 at 10:44:04AM +0000, Rohit R Ranade wrote:
> Hi Robert,
> 
> The Introduction section has :
> "
> Furthermore, the operational state datastore may support non-configurable YANG modules in addition to
>    the YANG modules supported by conventional configuration datastores.
> "
> I infer that in the new Yang-library structure,  the schema for "conventional" data-stores should not include the non-configurable YANG module. Is my inference correct ?
>

A module that has only config false nodes will not add anything to a
conventional configuration datastore but it is not an error list such
a module. For a simple devices, it may be desirable to have just one
schema that applies to all datastores. There is no requirement to
break things apart just because there is a module that contributes
only an empty set to conventional configuration datastores.

Note that the defined term is 'conventional configuration datastore'
and not 'conventional datastore'. Oops, I see that in one place
draft-ietf-netconf-rfc7895bis-06.txt missing the 'configuration' part
of the term. That should be fixed.

OLD

   The recommended approach to populate "/modules-state" is to report
   the schema for YANG modules that are configurable via conventional
   datastores and for which config false data nodes are returned via a
   NETCONF  operation, or equivalent.

NEW

   The recommended approach to populate "/modules-state" is to report
   the schema for YANG modules that are configurable via conventional
   configuration datastores and for which config false data nodes are
   returned via a NETCONF  operation, or equivalent.

Co-authors, if you agree, how do we track this?

/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 29 04:28:04 2018
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 E1EF1126D73 for ; Tue, 29 May 2018 04:28:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMfY7oia54YA for ; Tue, 29 May 2018 04:28:00 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E47DB1242F7 for ; Tue, 29 May 2018 04:27:59 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 930F33AA31D7F; Tue, 29 May 2018 12:27:55 +0100 (IST)
Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 29 May 2018 12:27:56 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.161]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0382.000; Tue, 29 May 2018 19:27:43 +0800
From: Rohit R Ranade 
To: Juergen Schoenwaelder 
CC: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
Thread-Index: AdP3LxM2Qa00BJMETVeCiSY+xVpFu///grGA//9vcjCAAKOzAP//djxg
Date: Tue, 29 May 2018 11:27:42 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BBB2484@dggeml510-mbx.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB23B2@dggeml510-mbx.china.huawei.com> <71e76c7e-4043-d80a-73ac-1759e85cc5d7@cisco.com> <991B70D8B4112A4699D5C00DDBBF878A6BBB241F@dggeml510-mbx.china.huawei.com> <20180529110610.4rcqvp7x4qpbg5hz@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180529110610.4rcqvp7x4qpbg5hz@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 May 2018 11:28:02 -0000

Hi Juergen,

Consider a device supports a dynamic data-store called "ephemeral". Conside=
r Yang-library 1.1 is NOT implemented in device.
Consider device have 3 Modules =3D=3D> Module1 ,  Module2-state and Module3

Module1 : Supported in  and 
Module2-state : Supported only in 
Module3 : Supported only in 

So here assumption is that Client knows he cannot do  on Module2=
-state as it has only read-only nodes.
But Client does not know the modules in ephemeral and depends on yang-libra=
ry 1.1 to know whether an edit-data can be done on Module3 ?

Which modules are supported in which data-stores is not known to Client wit=
hout Yang-library 1.1 ?

With Regards,
Rohit R Ranade

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20
Sent: 29 May 2018 16:36
To: Rohit R Ranade 
Cc: Robert Wilton ; netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query

On Tue, May 29, 2018 at 10:44:04AM +0000, Rohit R Ranade wrote:
> Hi Robert,
>=20
> The Introduction section has :
> "
> Furthermore, the operational state datastore may support non-configurable=
 YANG modules in addition to
>    the YANG modules supported by conventional configuration datastores.
> "
> I infer that in the new Yang-library structure,  the schema for "conventi=
onal" data-stores should not include the non-configurable YANG module. Is m=
y inference correct ?
>

A module that has only config false nodes will not add anything to a conven=
tional configuration datastore but it is not an error list such a module. F=
or a simple devices, it may be desirable to have just one schema that appli=
es to all datastores. There is no requirement to break things apart just be=
cause there is a module that contributes only an empty set to conventional =
configuration datastores.

Note that the defined term is 'conventional configuration datastore'
and not 'conventional datastore'. Oops, I see that in one place draft-ietf-=
netconf-rfc7895bis-06.txt missing the 'configuration' part of the term. Tha=
t should be fixed.

OLD

   The recommended approach to populate "/modules-state" is to report
   the schema for YANG modules that are configurable via conventional
   datastores and for which config false data nodes are returned via a
   NETCONF  operation, or equivalent.

NEW

   The recommended approach to populate "/modules-state" is to report
   the schema for YANG modules that are configurable via conventional
   configuration datastores and for which config false data nodes are
   returned via a NETCONF  operation, or equivalent.

Co-authors, if you agree, how do we track this?

/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 29 05:06:22 2018
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 52C5512EAC3 for ; Tue, 29 May 2018 05:06:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arNbI_M1titx for ; Tue, 29 May 2018 05:06:18 -0700 (PDT)
Received: from anna.localdomain (firewallix.jacobs-university.de [212.201.44.247]) by ietfa.amsl.com (Postfix) with ESMTP id EE09812EAAF for ; Tue, 29 May 2018 05:06:17 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id 3B9BA219CBCD; Tue, 29 May 2018 14:06:16 +0200 (CEST)
Date: Tue, 29 May 2018 14:06:16 +0200
From: Juergen Schoenwaelder 
To: Rohit R Ranade 
Cc: Robert Wilton , "netmod@ietf.org" 
Message-ID: <20180529120616.bxl4xyftqsvpsbxo@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Rohit R Ranade , Robert Wilton , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB23B2@dggeml510-mbx.china.huawei.com> <71e76c7e-4043-d80a-73ac-1759e85cc5d7@cisco.com> <991B70D8B4112A4699D5C00DDBBF878A6BBB241F@dggeml510-mbx.china.huawei.com> <20180529110610.4rcqvp7x4qpbg5hz@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BBB2484@dggeml510-mbx.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BBB2484@dggeml510-mbx.china.huawei.com>
User-Agent: NeoMutt/20180512
Archived-At: 
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 May 2018 12:06:21 -0000

Yes, this is why we have draft-ietf-netconf-rfc7895bis-06.txt.

/js

On Tue, May 29, 2018 at 11:27:42AM +0000, Rohit R Ranade wrote:
> Hi Juergen,
> 
> Consider a device supports a dynamic data-store called "ephemeral". Consider Yang-library 1.1 is NOT implemented in device.
> Consider device have 3 Modules ==> Module1 ,  Module2-state and Module3
> 
> Module1 : Supported in  and 
> Module2-state : Supported only in 
> Module3 : Supported only in 
> 
> So here assumption is that Client knows he cannot do  on Module2-state as it has only read-only nodes.
> But Client does not know the modules in ephemeral and depends on yang-library 1.1 to know whether an edit-data can be done on Module3 ?
> 
> Which modules are supported in which data-stores is not known to Client without Yang-library 1.1 ?
> 
> With Regards,
> Rohit R Ranade
> 
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] 
> Sent: 29 May 2018 16:36
> To: Rohit R Ranade 
> Cc: Robert Wilton ; netmod@ietf.org
> Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
> 
> On Tue, May 29, 2018 at 10:44:04AM +0000, Rohit R Ranade wrote:
> > Hi Robert,
> > 
> > The Introduction section has :
> > "
> > Furthermore, the operational state datastore may support non-configurable YANG modules in addition to
> >    the YANG modules supported by conventional configuration datastores.
> > "
> > I infer that in the new Yang-library structure,  the schema for "conventional" data-stores should not include the non-configurable YANG module. Is my inference correct ?
> >
> 
> A module that has only config false nodes will not add anything to a conventional configuration datastore but it is not an error list such a module. For a simple devices, it may be desirable to have just one schema that applies to all datastores. There is no requirement to break things apart just because there is a module that contributes only an empty set to conventional configuration datastores.
> 
> Note that the defined term is 'conventional configuration datastore'
> and not 'conventional datastore'. Oops, I see that in one place draft-ietf-netconf-rfc7895bis-06.txt missing the 'configuration' part of the term. That should be fixed.
> 
> OLD
> 
>    The recommended approach to populate "/modules-state" is to report
>    the schema for YANG modules that are configurable via conventional
>    datastores and for which config false data nodes are returned via a
>    NETCONF  operation, or equivalent.
> 
> NEW
> 
>    The recommended approach to populate "/modules-state" is to report
>    the schema for YANG modules that are configurable via conventional
>    configuration datastores and for which config false data nodes are
>    returned via a NETCONF  operation, or equivalent.
> 
> Co-authors, if you agree, how do we track this?
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

-- 
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 29 07:47:55 2018
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 0BC86120047 for ; Tue, 29 May 2018 07:47:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALvfPgwbWaya for ; Tue, 29 May 2018 07:47:52 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 155D6126B6D for ; Tue, 29 May 2018 07:47:52 -0700 (PDT)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4TEi7bc010689; Tue, 29 May 2018 07:47:48 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=5oSh+kfYcRFOsx/CARIktARMFl/P3EfuGtchG1Xm92A=; b=ErKYheigEe8LvLht0vAQVt3bNMIyik7xHhHmHjnvB0odMw8xcqT9+m3PT1ctYj1Quwju yG1yw81Xa2mtnkUDDTD+Ucp1D5nZgeer3owE71012ozIp5m4AXijmf+H8hAAnVktSS8x meZtISJCmm9jvzRP8Wqv57jgoV/FxLs8sEdmrvydFtFoYuVtwbkN2JdawA37tzk+u4aU d99oxllSLnzDi6WMM+lGudU3TXiDF0fnAzu+pZYanEUSNi+OModldVgZuN6hghT5UTAw g5rlOiCW94+WRuIA4N00fQy645cfBmy/d530u3YGyGsj5BSj3l5Gl8h8nhWS0dPS0Cjg yQ== 
Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0180.outbound.protection.outlook.com [216.32.181.180]) by mx0a-00273201.pphosted.com with ESMTP id 2j98gug1u9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 29 May 2018 07:47:48 -0700
Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4072.namprd05.prod.outlook.com (52.135.199.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.797.8; Tue, 29 May 2018 14:47:47 +0000
Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::95f0:e564:96c8:7f1c]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::95f0:e564:96c8:7f1c%2]) with mapi id 15.20.0820.010; Tue, 29 May 2018 14:47:47 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder , Rohit R Ranade 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
Thread-Index: AQHT9zOELNzD2uXSMkyTVHxGxI0WKqRGhYUAgAAGLQD///rfgA==
Date: Tue, 29 May 2018 14:47:46 +0000
Message-ID: 
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB23B2@dggeml510-mbx.china.huawei.com> <71e76c7e-4043-d80a-73ac-1759e85cc5d7@cisco.com> <991B70D8B4112A4699D5C00DDBBF878A6BBB241F@dggeml510-mbx.china.huawei.com> <20180529110610.4rcqvp7x4qpbg5hz@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180529110610.4rcqvp7x4qpbg5hz@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB4072; 7:5yoWZmsbtP/gsjnywdHMH2Obw9wf7waRCw6fpR5i+lbUB7UQgEi7N7Fj9eyWz+KiDS6itRXOgImvKqDLelPjbYu8Aa+7DNmovTnKlrXStyft1CUtjcuruGPC26d4LVQ7GNJO0J3vwmp09eQ0xaThvNU419i9rl/14Wx3MKmU7Jdg+rFeROECoiPW7IbVuk2W1MxCeum6YBim0igHksfNcX5sSViUfLjEyUc0fqSU+OR60LnAzkoedSuPPhX/EbCL
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4072; 
x-ms-traffictypediagnostic: BYAPR05MB4072:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(10436049006162);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231254)(944501410)(52105095)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB4072; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4072; 
x-forefront-prvs: 0687389FB0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(376002)(396003)(366004)(346002)(189003)(199004)(93886005)(59450400001)(102836004)(229853002)(486006)(83716003)(68736007)(6506007)(478600001)(966005)(8936002)(82746002)(6486002)(2616005)(99286004)(26005)(6436002)(446003)(575784001)(86362001)(110136005)(76176011)(186003)(58126008)(11346002)(316002)(36756003)(97736004)(5660300001)(2900100001)(5250100002)(6246003)(6306002)(33656002)(66066001)(3280700002)(25786009)(476003)(2906002)(4326008)(14454004)(6512007)(8676002)(53936002)(3660700001)(105586002)(106356001)(7736002)(6116002)(305945005)(3846002)(81156014)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4072; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: pkBtR2fGEe4gUF8aNV7GJQ8Z/cLHYPqId0ed3sAI58mawG0H5MjT3zuyK0qogtyAxpiY1MOxhtGIITwcaReXnBup8lDb9+ErNDtuQg3gpFQQD3EsujJfIj13zMuKNTwM2EcNmnzc3Jpf4n8lqJd5uZhGJiI58okT5JjCMdvyp/mrqva7VlDZaiPNLwAFVyhF
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 00c9b1f3-0f26-4177-a271-08d5c57324b8
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 00c9b1f3-0f26-4177-a271-08d5c57324b8
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2018 14:47:47.0323 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4072
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-29_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805290166
Archived-At: 
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 May 2018 14:47:55 -0000

PiBDby1hdXRob3JzLCBpZiB5b3UgYWdyZWUsIGhvdyBkbyB3ZSB0cmFjayB0aGlzPw0KDQpBcyBj
by1hdXRob3IsIEkgYWdyZWUgYW5kIHZpZXcgaXQgYXMgYW4gZWRpdG9yaWFsIHVwZGF0ZS4gIA0K
DQpBcyBjby1jaGFpciwgSSByZWNvbW1lbmQgdGhlIGF1dGhvcnMgY29tbWl0IHRoZSBmaXggdG8g
DQpHaXRIdWIgbm93IGFuZCB3YWl0IGZvciBBRCBhbmQvb3IgSUVTRyByZXZpZXdzIHRvIHRyaWdn
ZXINCmFuIHVwZGF0ZSB0aGF0IGl0IHdpbGwgZ2V0IHN3ZXB0IGludG8uICBJIGRvbid0IHRoaW5r
IHRoYXQNCml0J3Mgd29ydGggZml4aW5nIGFueSBzb29uZXIgdGhhbiB0aGF0LCBhbmQgeWV0IGFs
c28gZmVhcg0Kcmlza2luZyBpdCB3aWxsIGJlIGZvcmdvdHRlbi4NCg0KS2VudA0KDQoNCg0KT24g
VHVlLCBNYXkgMjksIDIwMTggYXQgMTA6NDQ6MDRBTSArMDAwMCwgUm9oaXQgUiBSYW5hZGUgd3Jv
dGU6DQo+IEhpIFJvYmVydCwNCj4gDQo+IFRoZSBJbnRyb2R1Y3Rpb24gc2VjdGlvbiBoYXMgOg0K
PiAiDQo+IEZ1cnRoZXJtb3JlLCB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgZGF0YXN0b3JlIG1heSBz
dXBwb3J0IG5vbi1jb25maWd1cmFibGUgWUFORyBtb2R1bGVzIGluIGFkZGl0aW9uIHRvDQo+ICAg
IHRoZSBZQU5HIG1vZHVsZXMgc3VwcG9ydGVkIGJ5IGNvbnZlbnRpb25hbCBjb25maWd1cmF0aW9u
IGRhdGFzdG9yZXMuDQo+ICINCj4gSSBpbmZlciB0aGF0IGluIHRoZSBuZXcgWWFuZy1saWJyYXJ5
IHN0cnVjdHVyZSwgIHRoZSBzY2hlbWEgZm9yICJjb252ZW50aW9uYWwiIGRhdGEtc3RvcmVzIHNo
b3VsZCBub3QgaW5jbHVkZSB0aGUgbm9uLWNvbmZpZ3VyYWJsZSBZQU5HIG1vZHVsZS4gSXMgbXkg
aW5mZXJlbmNlIGNvcnJlY3QgPw0KPg0KDQpBIG1vZHVsZSB0aGF0IGhhcyBvbmx5IGNvbmZpZyBm
YWxzZSBub2RlcyB3aWxsIG5vdCBhZGQgYW55dGhpbmcgdG8gYQ0KY29udmVudGlvbmFsIGNvbmZp
Z3VyYXRpb24gZGF0YXN0b3JlIGJ1dCBpdCBpcyBub3QgYW4gZXJyb3IgbGlzdCBzdWNoDQphIG1v
ZHVsZS4gRm9yIGEgc2ltcGxlIGRldmljZXMsIGl0IG1heSBiZSBkZXNpcmFibGUgdG8gaGF2ZSBq
dXN0IG9uZQ0Kc2NoZW1hIHRoYXQgYXBwbGllcyB0byBhbGwgZGF0YXN0b3Jlcy4gVGhlcmUgaXMg
bm8gcmVxdWlyZW1lbnQgdG8NCmJyZWFrIHRoaW5ncyBhcGFydCBqdXN0IGJlY2F1c2UgdGhlcmUg
aXMgYSBtb2R1bGUgdGhhdCBjb250cmlidXRlcw0Kb25seSBhbiBlbXB0eSBzZXQgdG8gY29udmVu
dGlvbmFsIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3Jlcy4NCg0KTm90ZSB0aGF0IHRoZSBkZWZpbmVk
IHRlcm0gaXMgJ2NvbnZlbnRpb25hbCBjb25maWd1cmF0aW9uIGRhdGFzdG9yZScNCmFuZCBub3Qg
J2NvbnZlbnRpb25hbCBkYXRhc3RvcmUnLiBPb3BzLCBJIHNlZSB0aGF0IGluIG9uZSBwbGFjZQ0K
ZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzc4OTViaXMtMDYudHh0IG1pc3NpbmcgdGhlICdjb25maWd1
cmF0aW9uJyBwYXJ0DQpvZiB0aGUgdGVybS4gVGhhdCBzaG91bGQgYmUgZml4ZWQuDQoNCk9MRA0K
DQogICBUaGUgcmVjb21tZW5kZWQgYXBwcm9hY2ggdG8gcG9wdWxhdGUgIi9tb2R1bGVzLXN0YXRl
IiBpcyB0byByZXBvcnQNCiAgIHRoZSBzY2hlbWEgZm9yIFlBTkcgbW9kdWxlcyB0aGF0IGFyZSBj
b25maWd1cmFibGUgdmlhIGNvbnZlbnRpb25hbA0KICAgZGF0YXN0b3JlcyBhbmQgZm9yIHdoaWNo
IGNvbmZpZyBmYWxzZSBkYXRhIG5vZGVzIGFyZSByZXR1cm5lZCB2aWEgYQ0KICAgTkVUQ09ORiA8
Z2V0PiBvcGVyYXRpb24sIG9yIGVxdWl2YWxlbnQuDQoNCk5FVw0KDQogICBUaGUgcmVjb21tZW5k
ZWQgYXBwcm9hY2ggdG8gcG9wdWxhdGUgIi9tb2R1bGVzLXN0YXRlIiBpcyB0byByZXBvcnQNCiAg
IHRoZSBzY2hlbWEgZm9yIFlBTkcgbW9kdWxlcyB0aGF0IGFyZSBjb25maWd1cmFibGUgdmlhIGNv
bnZlbnRpb25hbA0KICAgY29uZmlndXJhdGlvbiBkYXRhc3RvcmVzIGFuZCBmb3Igd2hpY2ggY29u
ZmlnIGZhbHNlIGRhdGEgbm9kZXMgYXJlDQogICByZXR1cm5lZCB2aWEgYSBORVRDT05GIDxnZXQ+
IG9wZXJhdGlvbiwgb3IgZXF1aXZhbGVudC4NCg0KQ28tYXV0aG9ycywgaWYgeW91IGFncmVlLCBo
b3cgZG8gd2UgdHJhY2sgdGhpcz8NCg0KL2pzDQoNCi0tIA0KSnVlcmdlbiBTY2hvZW53YWVsZGVy
ICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNClBob25lOiArNDkgNDIx
IDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkN
CkZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v
ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmphY29icy0yRHVuaXZlcnNpdHkuZGVf
JmQ9RHdJQ0FnJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZy
PTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1mTC1pbUdBc09D
bTB2TS1SRFJNa2lSRlUtNXg0ZExrS2E1LWhCT1U5SXlzJnM9am1yMFk3bVJDZVgwNW9wNGg2QklD
eWo5VTBsMElobmJNNXlCcWh0Y0w0ayZlPT4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9y
Zw0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193
d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed0lDQWcmYz1IQWtZdWg2M3Jz
dWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZ
aHFuMmdzQllhR1R2aklTbGFKZGNabyZtPWZMLWltR0FzT0NtMHZNLVJEUk1raVJGVS01eDRkTGtL
YTUtaEJPVTlJeXMmcz1pNC1sd01jdGp1akNfVWlabUdPNHM4My1qeUttdzdqYkdzUzBjTGZGWlQ0
JmU9DQoNCg0K


From nobody Tue May 29 08:58:52 2018
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 7926812D7F7 for ; Tue, 29 May 2018 08:58:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yN3aSK_zDclW for ; Tue, 29 May 2018 08:58:48 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 90432129C56 for ; Tue, 29 May 2018 08:58:48 -0700 (PDT)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4TFwkpC025027; Tue, 29 May 2018 08:58:46 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=0No2oc3ySSFziHCHtCzKXC/eVJHQDYHsUMLUHjBpE7E=; b=ZdOkrzTmITJBYucysl1OBvvNTblOTGDMxghVDXBJDn8zC/et7+updYpkXNiRFOOk6UAz k+Op/pd/nbhzv7CZcLB0WIiXZnGjhbcof5j5x/yCiZI+tRSd4EOt6eLjpWJlnopmzCeT NX++g/YP7CFvI+26jdCg5hpdlfAL7hT68DmgwGLdSx/d8D5dS9ay42hErxXHo26jHnss g3aVJM3VCoqiFRhXgfqqFJCLsXfIrdKgOISZ9NmOxUCWIxCfjVzWgB1LwNdIup7LWvSD 9GpBEpVVbHbLfNiUBSbqZ2OypXuv/TqHqy3iooPo7IaJoyRBpOvbceKZTEaCT878h5Su 3A== 
Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0175.outbound.protection.outlook.com [216.32.180.175]) by mx0b-00273201.pphosted.com with ESMTP id 2j964s0gf3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 29 May 2018 08:58:46 -0700
Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4389.namprd05.prod.outlook.com (52.135.202.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.5; Tue, 29 May 2018 15:58:33 +0000
Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::95f0:e564:96c8:7f1c]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::95f0:e564:96c8:7f1c%2]) with mapi id 15.20.0820.010; Tue, 29 May 2018 15:58:33 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder , Martin Bjorklund 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] yang-data-ext issues
Thread-Index: AQHT1YJYRSnZmZlnhU6JIK4LoPfNTqQEcM6AgAYAzwCAAlYhgIAB08UAgAAyUgCAATikgIAAAaSAgAGHGgCAAAK9AIAAEH6AgAACpYCAAPWtAIABPh0AgACT0YCAAAY/gIAABasAgAALQACAAARkgIAANngAgAADfgCAAAdSAIAADKEAgASYmICAAD0hgIACdpWAgAAbLACAAAZCAIAAAyoAgCqWpwA=
Date: Tue, 29 May 2018 15:58:33 +0000
Message-ID: <64990DFB-CF50-401A-A4EF-B6161C8D227B@juniper.net>
References:  <20180502.092527.2305319833268262996.mbj@tail-f.com> <9fca04b0-fb29-36b3-67aa-2f2c4fb98748@cisco.com> <20180502.112506.845305331945500257.mbj@tail-f.com> <20180502093626.ugsg6nq24a6vjtdn@elstar.local>
In-Reply-To: <20180502093626.ugsg6nq24a6vjtdn@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB4389; 7:Nz+bfbtg6spX/QZ2d3LjOYyeXql9jkfM+OCe7bdXQ+URj/cyT7rfpAE7Da/o8qDMJMCeT5wb7y+92Lc6MWdG2E8EmA6EC6ZKiH+T8lU7NBUsdwh1gCFVhSwJdpDA1BkCecjegdMjQ7yPLS6/lJkR9+klvpT7tCLv1dQikx6U2jwYh+MpQ4qMcMcOeps3ZnUFPvoZ2Fy9wMQ3Zok98PEm9xQrBfvoq2WIzZFctHsQhjHEpNLia2dr/d/g8HM2MR2N
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4389; 
x-ms-traffictypediagnostic: BYAPR05MB4389:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231254)(944501410)(52105095)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB4389; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4389; 
x-forefront-prvs: 0687389FB0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(346002)(396003)(366004)(376002)(199004)(189003)(377424004)(3660700001)(7736002)(4326008)(86362001)(2906002)(186003)(93886005)(25786009)(26005)(58126008)(59450400001)(6506007)(83716003)(229853002)(36756003)(6486002)(478600001)(76176011)(110136005)(97736004)(102836004)(3280700002)(6436002)(316002)(99286004)(14454004)(2900100001)(106356001)(6246003)(82746002)(8936002)(486006)(68736007)(81156014)(81166006)(8676002)(5660300001)(33656002)(6512007)(446003)(6116002)(5250100002)(3846002)(66066001)(53936002)(2616005)(105586002)(11346002)(476003)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4389; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 1JadnDgzH8+Jfkb3uzBhDXI0Dgs9zcfZj1EAO0JKu2zzPfgHf0sBZmwLNF10iBB7xE2PDdXIVVl04acsSaAc8fCIkzh/NK+7Glu7DTEhcrtfKdJ61Gl1uUXC13Dy+WupphLtlVYpIseVNoBkgHIsu4mR6SgPTDtRYS5iUA/tEX53SjhzN9ySQvsJFZC9gij4
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <6F57DB776DB51D4C96C84978FA6FEAE4@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 690c4e7b-5b27-4bf0-d143-08d5c57d07d1
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 690c4e7b-5b27-4bf0-d143-08d5c57d07d1
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2018 15:58:33.5037 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4389
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-29_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805290177
Archived-At: 
Subject: Re: [netmod] yang-data-ext issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 May 2018 15:58:50 -0000

W3Jlc3VycmVjdGluZyB0aGlzIHRocmVhZF0NCg0KQ3VycmVudGx5IHRoZSB6ZXJvdG91Y2ggZHJh
ZnQgaGFzIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byB0aGlzIGRyYWZ0Lg0KSSB3aWxsIHRoaXMg
d2VlayBwb3N0IGFuIHVwZGF0ZSB0byB0aGUgemVyb3RvdWNoIGRyYWZ0IHRvIHJlc29sdmUgdGhl
DQpuZXRjb25mIGxpc3QgdGhyZWFkICJhIGNvdXBsZSB6ZXJvdG91Y2gtMjEgaXNzdWVzIi4gICBJ
dCB3b3VsZCBiZSBlYXN5DQpmb3IgbWUgdG8gYWxzbyBzd2l0Y2ggYmFjayB0byB1c2luZyByYzp5
YW5nLWRhdGEsIGJ1dCBJIHdvbid0IGRvIHNvIGlmDQp0aGlzIGRyYWZ0IHJlbWFpbnMgYW4gYWN0
aXZlIHdvcmstaW4tcHJvZ3Jlc3MuDQoNClBsZWFzZSBzZWUgYmVsb3cgZm9yIG1vcmUuDQoNCg0K
T24gV2VkLCAyMDE4LTA1LTAyIGF0IDExOjM2ICswMjAwLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIg
d3JvdGU6DQo+T24gV2VkLCBNYXkgMDIsIDIwMTggYXQgMTE6MjU6MDZBTSArMDIwMCwgTWFydGlu
IEJqb3JrbHVuZCB3cm90ZToNCj4+IA0KPj4gVGhlIHByaW1hcnkgdXNlIGNhc2UgaXMgbm90ICJn
ZW5lcmljIFJQQyBtZXNzYWdlcyIsIGJ1dCBzdGFuZGFsb25lDQo+PiBpbnN0YW5jZSBkb2N1bWVu
dHMsIGVycm9yLWluZm8gc3RydWN0dXJlcywgZXRjLg0KPg0KPiBUaGUgcHJvcGVyIHNvbHV0aW9u
IGZvciBycGNzIGFuZCBhY3Rpb25zIGlzIHRvIGRlZmluZSBlcnJvcg0KPiBpbmZvcm1hdGlvbiBh
cyBwYXJ0IG9mIHRoZSBycGMvYWN0aW9uLiBZQU5HIDEuMSBkb2VzIG5vdCBzdXBwb3J0DQo+IHRo
aXMgYnV0IHRoaXMgaXMgd2hlcmUgaXQgc2hvdWxkIGJlIGZpeGVkLg0KDQpBZ3JlZWQsIGJ1dCBu
b3RlIHRoYXQgdGhlIHN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyBkcmFmdCAoYm90aCB0aGUNCnB1
Ymxpc2hlZCAtMTIgYW5kIHVucHVibGlzaGVkIC0xMykgYXJlIHJlbHlpbmcgb24gYmVpbmcgYWJs
ZSB0byBkbw0KanVzdCB0aGlzLCBhbmQgWUFORy1uZXh0IGlzIHllYXJzIGF3YXkuLi4NCg0KDQo+
IFN0YW5kYWxvbmUgaW5zdGFuY2UgZG9jdW1lbnRzIChub3QgdGllZCB0byBkYXRhc3RvcmVzKSBt
YXkgaGF2ZSB0aGVpcg0KPiB1c2UgY2FzZXMgYXMgd2VsbCBidXQgaXQgZmVlbHMgb2RkIHRvIGNy
ZWF0ZSBzdXBwb3J0IGZvciBzdGFuZGFsb25lDQo+IGluc3RhbmNlIGRvY3VtZW50cyBhcyBleHRl
bnNpb25zIGFuZCB0aGVuIHRvIGNyZWF0ZSBldmVuIG1vcmUNCj4gZXh0ZW5zaW9ucyB0byBzdXBw
b3J0IGF1Z21lbnRhdGlvbiBvZiB0aGVzZSBpbnN0YW5jZSBkb2N1bWVudHMgYW5kDQo+IHdob2V2
ZXIga25vd3Mgd2hhdCBjb21lcyBuZXh0Lg0KDQpXaGF0IGZlZWxzICJvZGQiIGFib3V0IHRoaXM/
ICBJcyBpdCBub3QgdXNpbmcgdGhlIGV4dGVuc2lvbiBzdGF0ZW1lbnQNCmFzIGl0IHdhcyBpbnRl
bmRlZD8NCg0KDQo+IEZvciBzaG9ydC10ZXJtIG5lZWRzLCB0aGVyZSBpcyB5YW5nLWRhdGEgZGVm
aW5lZCBpbiBSRkMgODA0MC4NCg0KVG8gYmUgY2xlYXIsIHRoZSAic2hvcnQtdGVybSBuZWVkcyIg
YXJlOg0KDQogIGEpIHplcm90b3VjaDogdG8gZGVmaW5lIGEgc3RhbmRhbG9uZSBpbnN0YW5jZSBk
b2N1bWVudA0KICBiKSBub3RpZmljYXRpb24tbWVzc2FnZXM6IHRvIGRlZmluZSBhIG5ldyBub3Rp
ZmljYXRpb24gbWVzc2FnZQ0KICBjKSBzdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnM6IHRvIGRlZmlu
ZSBlcnJvci1pbmZvIHN0cnVjdHVyZXMNCg0KDQpBcyBJIHJlY2FsbCwgdGhpcyBkcmFmdCAobm90
IFJGQyA4MDQwKSBpcyBuZWVkZWQ6DQoNCiAgLSBmb3IgKGEpLCBiZWNhdXNlIHJjOnlhbmctZGF0
YSBkb2Vzbid0IHN1cHBvcnQgYSB0b3AtbGV2ZWwNCiAgICAiY2hvaWNlIiBzdGF0ZW1lbnQgc3Bh
bm5pbmcgImNvbnRhaW5lciIgc3RhdGVtZW50cy4NCg0KICAtIGZvciAoYiksIGluIG9yZGVyIHRv
IGF1Z21lbnQgYSBiYXNlIHlhbmctZGF0YSAibWVzc2FnZSIgDQogICAgc3RydWN0dXJlIHdpdGgg
YWRkaXRpb25hbCBub2Rlcy4NCg0KICAtIEFGQUlBQSwgUkZDIDgwNDAgaXMgc3VmZmljaWVudCBm
b3IgKGMpDQoNCg0KSGFzIGFueXRoaW5nIGNoYW5nZWQ/ICAgSSBkb24ndCB0aGluayB0aGF0IHdl
IGNhbiB1bi1hZG9wdCB0aGlzDQpkcmFmdCB3aXRoIHNhaWQgZGVwZW5kZW5jaWVzLCByaWdodD8N
Cg0KDQpLZW50DQoNCg0KDQo=


From nobody Tue May 29 10:09:08 2018
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 7944C12EB45 for ; Tue, 29 May 2018 10:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obYjuUPIxHtt for ; Tue, 29 May 2018 10:09:04 -0700 (PDT)
Received: from anna.localdomain (anna.eecs.jacobs-university.de [IPv6:2001:638:709:5::7]) by ietfa.amsl.com (Postfix) with ESMTP id A97ED12EB20 for ; Tue, 29 May 2018 10:09:03 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id 7A415219D7EC; Tue, 29 May 2018 19:09:00 +0200 (CEST)
Date: Tue, 29 May 2018 19:09:00 +0200
From: Juergen Schoenwaelder 
To: Kent Watsen 
Cc: Martin Bjorklund , "netmod@ietf.org" 
Message-ID: <20180529170900.qboedr2rmefsmblc@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Kent Watsen , Martin Bjorklund , "netmod@ietf.org" 
References:  <20180502.092527.2305319833268262996.mbj@tail-f.com> <9fca04b0-fb29-36b3-67aa-2f2c4fb98748@cisco.com> <20180502.112506.845305331945500257.mbj@tail-f.com> <20180502093626.ugsg6nq24a6vjtdn@elstar.local> <64990DFB-CF50-401A-A4EF-B6161C8D227B@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <64990DFB-CF50-401A-A4EF-B6161C8D227B@juniper.net>
User-Agent: NeoMutt/20180512
Archived-At: 
Subject: Re: [netmod] yang-data-ext issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 May 2018 17:09:07 -0000

On Tue, May 29, 2018 at 03:58:33PM +0000, Kent Watsen wrote:
> [resurrecting this thread]
> 
> Currently the zerotouch draft has a normative reference to this draft.
> I will this week post an update to the zerotouch draft to resolve the
> netconf list thread "a couple zerotouch-21 issues".   It would be easy
> for me to also switch back to using rc:yang-data, but I won't do so if
> this draft remains an active work-in-progress.
> 
> Please see below for more.
> 
> 
> On Wed, 2018-05-02 at 11:36 +0200, Juergen Schoenwaelder wrote:
> >On Wed, May 02, 2018 at 11:25:06AM +0200, Martin Bjorklund wrote:
> >> 
> >> The primary use case is not "generic RPC messages", but standalone
> >> instance documents, error-info structures, etc.
> >
> > The proper solution for rpcs and actions is to define error
> > information as part of the rpc/action. YANG 1.1 does not support
> > this but this is where it should be fixed.
> 
> Agreed, but note that the subscribed-notifications draft (both the
> published -12 and unpublished -13) are relying on being able to do
> just this, and YANG-next is years away...

There is a description statement.

> > Standalone instance documents (not tied to datastores) may have their
> > use cases as well but it feels odd to create support for standalone
> > instance documents as extensions and then to create even more
> > extensions to support augmentation of these instance documents and
> > whoever knows what comes next.
> 
> What feels "odd" about this?  Is it not using the extension statement
> as it was intended?

For me, extensions that define new data definition statements are
borderline. RFC 7950 has this nice statement:

   o  extension: An extension attaches non-YANG semantics to statements.
      The "extension" statement defines new statements to express these
      semantics.

This does not help since we lack a definition for 'non-YANG semantics'
and yes I know that yang-data is today defined as an extension. But
for me, this is a hack and instead of creating a slightly more
generalized version of this hack, I prefer to stick to yang-data in
favor of a proper solution as part of YANG.
 
> > For short-term needs, there is yang-data defined in RFC 8040.
> 
> To be clear, the "short-term needs" are:
> 
>   a) zerotouch: to define a standalone instance document
>   b) notification-messages: to define a new notification message
>   c) subscribed-notifications: to define error-info structures
> 
> As I recall, this draft (not RFC 8040) is needed:
> 
>   - for (a), because rc:yang-data doesn't support a top-level
>     "choice" statement spanning "container" statements.

So create a container.
 
>   - for (b), in order to augment a base yang-data "message" 
>     structure with additional nodes.

So you are creating another augmentation mechanism. I am concerned
about ending up with a zoo of different mechanisms if we go down this
path, we may end up with every project or vendor creating their own
variants.

With NMDA in place, YANG 1.1 is decribing schemas for datastores plus
operations and notifications. It is not a protocol message description
language or a standalone file format description language. If this is
needed, I prefer to create YANG X.Y - and if we manage the complexity
we have something that is ideally integrated and consistent.

>   - AFAIAA, RFC 8040 is sufficient for (c)
> 
> Has anything changed?   I don't think that we can un-adopt this
> draft with said dependencies, right?

I am just voicing my opinion. It may very well be that the WG prefers
to go the route of not touching YANG 1.1 and instead patching around
its limitations with extensions.

My concern is simply driven that some want to patch in via extensions
support for describing protocol messages and standalone documents,
others want to patch via extensions and updates a different versioning
system, and who knows what comes next. In the long run, I am afraid
this will become a mess. And yes, it is always difficult to predict
the future - we need crystal balls. Perhaps as an extension. ;-)

/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 29 12:21:32 2018
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 E8AA612F29F for ; Tue, 29 May 2018 12:21:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level: 
X-Spam-Status: No, score=-2.609 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYrAsCiCpM1n for ; Tue, 29 May 2018 12:21:27 -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 742F812EE8D for ; Tue, 29 May 2018 12:21:26 -0700 (PDT)
Received: by mail-lf0-x234.google.com with SMTP id n18-v6so481729lfh.10 for ; Tue, 29 May 2018 12:21:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=XAMAFtRV++H6W9LdBCnEQ/DDFttrVjTMb3JClV3rJm0=; b=LDqhn6v6UoJ+WwSOqh0AS/RrPiKFrsevuK1iqwI0jXrtS88of0bnrpcGDVS4XJf+BN wKnCCE36GWcoU9PsPnHaBq66Rx0s8a4Uty0U9DIWy+7xM3k0bNhlB6VRmiTRrJOV6WU/ gw09UkhIBrESJB4hFiAiabt+dE6s/JaQfH/iesldscEFCBdSG2EtFMT6pGsmN7rlDrRK M4mQfEBtp3y190L0Z/9IFCrFekXkScJmvKCUMo1Q4c8Cocw8sl7DadImLAX0PneG0mj7 YtJddLYBALcqRKLYkmlzslcucrIBipMakjn60mKQyJO4nfOMYMXAGnDhRjTGPW5HxmMD P8RQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=XAMAFtRV++H6W9LdBCnEQ/DDFttrVjTMb3JClV3rJm0=; b=mkErvfi1HBUQD3bWyzDRLAgupvYjs9qDh0TRVOTs7Ul6s+qfPbC0F0LBmJOpt+sWb8 HMse+cB02WfTaAQSOu74UbHj/bL82pATC3k0zZ3rg2sq2W0XqqRlg8pAN6oa39EFgeGO T9f6AjRprsNwGhvtTtmC8zeYqfeMHtjVI/WDtwFiK/gHFwQSnGm+v1fUm7CpVyiAwQq6 ynm+rkk6Y2RAQjvsDipznxFafWiSjJKlOUKST6Or/TVmdeeK6hoDsiBPR4Y9N3lffu5T iE3WN026hNK/AhpK6rvPICsrAxmF0GwQuNIRY41UiTz88hb8iZgD8h3fHnMAqNwNhmiw Ujfw==
X-Gm-Message-State: ALKqPwc8svd4XzdhRypTarq0Fls9aqdp2rRn/K9RwgqeKCNMwVWqnpS0 spOp4v9kNx7/RDnOO92KWt4A+ifPrLKRO2UZSEpLGQ==
X-Google-Smtp-Source: ADUXVKLCkITEJ438jyNmT09gV5HwZxqpQpo2pLSUWPyJqiz4opdS+bitOMFJHLw0b5UYQpfwWF6lsCjERAoUt7M+NVw=
X-Received: by 2002:a2e:90d4:: with SMTP id o20-v6mr10160377ljg.15.1527621684535;  Tue, 29 May 2018 12:21:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Tue, 29 May 2018 12:21:23 -0700 (PDT)
In-Reply-To: <20180529170900.qboedr2rmefsmblc@anna.jacobs.jacobs-university.de>
References:  <20180502.092527.2305319833268262996.mbj@tail-f.com> <9fca04b0-fb29-36b3-67aa-2f2c4fb98748@cisco.com> <20180502.112506.845305331945500257.mbj@tail-f.com> <20180502093626.ugsg6nq24a6vjtdn@elstar.local> <64990DFB-CF50-401A-A4EF-B6161C8D227B@juniper.net> <20180529170900.qboedr2rmefsmblc@anna.jacobs.jacobs-university.de>
From: Andy Bierman 
Date: Tue, 29 May 2018 12:21:23 -0700
Message-ID: 
To: Juergen Schoenwaelder , Kent Watsen ,  Martin Bjorklund , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000dbb28a056d5d23d1"
Archived-At: 
Subject: Re: [netmod] yang-data-ext issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 May 2018 19:21:30 -0000

--000000000000dbb28a056d5d23d1
Content-Type: text/plain; charset="UTF-8"

On Tue, May 29, 2018 at 10:09 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Tue, May 29, 2018 at 03:58:33PM +0000, Kent Watsen wrote:
> > [resurrecting this thread]
> >
> > Currently the zerotouch draft has a normative reference to this draft.
> > I will this week post an update to the zerotouch draft to resolve the
> > netconf list thread "a couple zerotouch-21 issues".   It would be easy
> > for me to also switch back to using rc:yang-data, but I won't do so if
> > this draft remains an active work-in-progress.
> >
> > Please see below for more.
> >
> >
> > On Wed, 2018-05-02 at 11:36 +0200, Juergen Schoenwaelder wrote:
> > >On Wed, May 02, 2018 at 11:25:06AM +0200, Martin Bjorklund wrote:
> > >>
> > >> The primary use case is not "generic RPC messages", but standalone
> > >> instance documents, error-info structures, etc.
> > >
> > > The proper solution for rpcs and actions is to define error
> > > information as part of the rpc/action. YANG 1.1 does not support
> > > this but this is where it should be fixed.
> >
> > Agreed, but note that the subscribed-notifications draft (both the
> > published -12 and unpublished -13) are relying on being able to do
> > just this, and YANG-next is years away...
>
> There is a description statement.
>


Automation tools generally use machine-readable statements, and avoid using
description-stmts.

The yang-data extensions do not solve this "rpc/action to error-info"
mapping
problem, so this problem is not a real factor here.



> > > Standalone instance documents (not tied to datastores) may have their
> > > use cases as well but it feels odd to create support for standalone
> > > instance documents as extensions and then to create even more
> > > extensions to support augmentation of these instance documents and
> > > whoever knows what comes next.
> >
> > What feels "odd" about this?  Is it not using the extension statement
> > as it was intended?
>
> For me, extensions that define new data definition statements are
> borderline. RFC 7950 has this nice statement:
>
>    o  extension: An extension attaches non-YANG semantics to statements.
>       The "extension" statement defines new statements to express these
>       semantics.
>
> This does not help since we lack a definition for 'non-YANG semantics'
> and yes I know that yang-data is today defined as an extension. But
> for me, this is a hack and instead of creating a slightly more
> generalized version of this hack, I prefer to stick to yang-data in
> favor of a proper solution as part of YANG.
>
>

The yang-data and augment-yang-data extensions do not re-define YANG data
nodes.
They define a new context for data nodes and prevent plain YANG tools from
confusing this new context with data for configuration or operational
datastores.



> > > For short-term needs, there is yang-data defined in RFC 8040.
> >
> > To be clear, the "short-term needs" are:
> >
> >   a) zerotouch: to define a standalone instance document
> >   b) notification-messages: to define a new notification message
> >   c) subscribed-notifications: to define error-info structures
> >
> > As I recall, this draft (not RFC 8040) is needed:
> >
> >   - for (a), because rc:yang-data doesn't support a top-level
> >     "choice" statement spanning "container" statements.
>
> So create a container.
>


I tend to agree that a top-level choice could be avoided.
This is not a really compelling use-case.



>
> >   - for (b), in order to augment a base yang-data "message"
> >     structure with additional nodes.
>
> So you are creating another augmentation mechanism. I am concerned
> about ending up with a zoo of different mechanisms if we go down this
> path, we may end up with every project or vendor creating their own
> variants.
>
> With NMDA in place, YANG 1.1 is decribing schemas for datastores plus
> operations and notifications. It is not a protocol message description
> language or a standalone file format description language. If this is
> needed, I prefer to create YANG X.Y - and if we manage the complexity
> we have something that is ideally integrated and consistent.
>



Yes it is a protocol message description language, but only
in an incomplete, hacky way.  Specific subtrees within protocol messages
are defined as special YANG data-defined portions and the rest is somehow
out of scope for YANG. The way nested roots (e.g.,  or )
are handled is the worst hack of all.  But IMO a new version of YANG is
needed
to really fix these problems.



> >   - AFAIAA, RFC 8040 is sufficient for (c)
> >
> > Has anything changed?   I don't think that we can un-adopt this
> > draft with said dependencies, right?
>
> I am just voicing my opinion. It may very well be that the WG prefers
> to go the route of not touching YANG 1.1 and instead patching around
> its limitations with extensions.
>
> My concern is simply driven that some want to patch in via extensions
> support for describing protocol messages and standalone documents,
> others want to patch via extensions and updates a different versioning
> system, and who knows what comes next. In the long run, I am afraid
> this will become a mess. And yes, it is always difficult to predict
> the future - we need crystal balls. Perhaps as an extension. ;-)
>

This is a separate (but important) topic -- YANG 1.1 + a vendor-selected
set of
optional extensions is not the same as a new version of YANG (with
mandatory-to-implement statements).

YANG designers cannot really rely on optional extensions across tool-chains.


>
> /js
>

Andy


>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--000000000000dbb28a056d5d23d1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, May 29, 2018 at 10:09 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, May 29, 2018 at 03:58:33PM +0000, Kent Wats=
en wrote:

> [resurrecting this thread]

> 

> Currently the zerotouch draft has a normative reference to this draft.=


> I will this week post an update to the zerotouch draft to resolve the<=
br>
> netconf list thread "a couple zerotouch-21 issues".=C2=A0 =
=C2=A0It would be easy

> for me to also switch back to using rc:yang-data, but I won't do s=
o if

> this draft remains an active work-in-progress.

> 

> Please see below for more.

> 

> 

> On Wed, 2018-05-02 at 11:36 +0200, Juergen Schoenwaelder wrote:

> >On Wed, May 02, 2018 at 11:25:06AM +0200, Martin Bjorklund wrote:<=
br>
> >> 

> >> The primary use case is not "generic RPC messages",=
 but standalone

> >> instance documents, error-info structures, etc.

> >

> > The proper solution for rpcs and actions is to define error

> > information as part of the rpc/action. YANG 1.1 does not support<=
br>
> > this but this is where it should be fixed.

> 

> Agreed, but note that the subscribed-notifications draft (both the

> published -12 and unpublished -13) are relying on being able to do

> just this, and YANG-next is years away...



There is a description statement.


<=
/div>
Automation tools generally use machine-readable statements, and a=
void using
description-stmts.

The yang-d=
ata extensions do not solve this "rpc/action to error-info" mappi=
ng
problem, so this problem is not a real factor here.
=





> > Standalone instance documents (not tied to datastores) may have t=
heir

> > use cases as well but it feels odd to create support for standalo=
ne

> > instance documents as extensions and then to create even more

> > extensions to support augmentation of these instance documents an=
d

> > whoever knows what comes next.

> 

> What feels "odd" about this?=C2=A0 Is it not using the exten=
sion statement

> as it was intended?



For me, extensions that define new data definition statements are

borderline. RFC 7950 has this nice statement:



=C2=A0 =C2=A0o=C2=A0 extension: An extension attaches non-YANG semantics to=
 statements.

=C2=A0 =C2=A0 =C2=A0 The "extension" statement defines new statem=
ents to express these

=C2=A0 =C2=A0 =C2=A0 semantics.



This does not help since we lack a definition for 'non-YANG semantics&#=
39;

and yes I know that yang-data is today defined as an extension. But

for me, this is a hack and instead of creating a slightly more

generalized version of this hack, I prefer to stick to yang-data in

favor of a proper solution as part of YANG.




The yang-data and augme=
nt-yang-data extensions do not re-define YANG data nodes.
They de=
fine a new context for data nodes and prevent plain YANG tools from
confusing this new context with data for configuration or operational da=
tastores.

=C2=A0

> > For short-term needs, there is yang-data defined in RFC 8040.

> 

> To be clear, the "short-term needs" are:

> 

>=C2=A0 =C2=A0a) zerotouch: to define a standalone instance document

>=C2=A0 =C2=A0b) notification-messages: to define a new notification mes=
sage

>=C2=A0 =C2=A0c) subscribed-notifications: to define error-info structur=
es

> 

> As I recall, this draft (not RFC 8040) is needed:

> 

>=C2=A0 =C2=A0- for (a), because rc:yang-data doesn't support a top-=
level

>=C2=A0 =C2=A0 =C2=A0"choice" statement spanning "contain=
er" statements.



So create a container.


I=
 tend to agree that a top-level choice could be avoided.
This is =
not a really compelling use-case.

=C2=A0



>=C2=A0 =C2=A0- for (b), in order to augment a base yang-data "mess=
age" 

>=C2=A0 =C2=A0 =C2=A0structure with additional nodes.



So you are creating another augmentation mechanism. I am concerned

about ending up with a zoo of different mechanisms if we go down this

path, we may end up with every project or vendor creating their own

variants.



With NMDA in place, YANG 1.1 is decribing schemas for datastores plus

operations and notifications. It is not a protocol message description

language or a standalone file format description language. If this is

needed, I prefer to create YANG X.Y - and if we manage the complexity

we have something that is ideally integrated and consistent.



Yes it is a protocol me=
ssage description language, but only
in an incomplete, hacky way.=
=C2=A0 Specific subtrees within protocol messages
are defined as =
special YANG data-defined portions and the rest is somehow
out of=
 scope for YANG. The way nested roots (e.g., <config> or <data>=
)
are handled is the worst hack of all.=C2=A0 But IMO a new versi=
on of YANG is needed
to really fix these problems.

=





>=C2=A0 =C2=A0- AFAIAA, RFC 8040 is sufficient for (c)

> 

> Has anything changed?=C2=A0 =C2=A0I don't think that we can un-ado=
pt this

> draft with said dependencies, right?



I am just voicing my opinion. It may very well be that the WG prefers

to go the route of not touching YANG 1.1 and instead patching around

its limitations with extensions.



My concern is simply driven that some want to patch in via extensions

support for describing protocol messages and standalone documents,

others want to patch via extensions and updates a different versioning

system, and who knows what comes next. In the long run, I am afraid

this will become a mess. And yes, it is always difficult to predict

the future - we need crystal balls. Perhaps as an extension. ;-)

This is a separate (but important) topic -- YANG =
1.1 + a vendor-selected set of
optional extensions is not the sam=
e as a new version of YANG (with
mandatory-to-implement statement=
s).

YANG designers cannot really rely on optional =
extensions across tool-chains.
=C2=A0



/js

Andy
=C2=A0=




-- 

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<https://www.jacobs-university.de/>



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--000000000000dbb28a056d5d23d1--


From nobody Tue May 29 14:20:46 2018
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 EE94212EB92 for ; Tue, 29 May 2018 14:20:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SN2SNdK-zCyr for ; Tue, 29 May 2018 14:20:39 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 D5F1312EB19 for ; Tue, 29 May 2018 14:20:39 -0700 (PDT)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4TKxbZ7028225; Tue, 29 May 2018 14:02:23 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=JUPJUobgXW51z8j3qHsBLtdLC1gnGM1wxv+qKn1QpMY=; b=GKAWNRhAiMLPU0ZnJpEj8cDzxP1rScRi8lEFlC0adLW9wqng4lZa+EFkUNK+6zRh/h/M BAdrbOoEEOAi24iDvKyB1HWQe4qIrA6sAry/Mohn0hw6U43W3Th6AZYe12o/+UORArgO opfA9ovA94CLw/0d6QhrP4LakO8+M4OjBb5o7O8CV2kLLdwACLSXSMNHRYJeEi57ajEr Y/k5GaOfJxQ4XW637nmd7cu5WhL6AzbVKlcVdJcNPJ0mvm55hsGD7d+h/Ltq2dWCwyK7 loKP4b3FvRbpLYjNMRmi5OQU5GNDDLPKOstB1NxcISaBQs5m8qg2SpAZM72CfDoqSbgW /g== 
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0113.outbound.protection.outlook.com [207.46.163.113]) by mx0a-00273201.pphosted.com with ESMTP id 2j9cx38dk9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 29 May 2018 14:02:23 -0700
Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB3959.namprd05.prod.outlook.com (52.135.196.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.5; Tue, 29 May 2018 21:02:21 +0000
Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::95f0:e564:96c8:7f1c]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::95f0:e564:96c8:7f1c%2]) with mapi id 15.20.0820.010; Tue, 29 May 2018 21:02:21 +0000
From: Kent Watsen 
To: Andy Bierman , Juergen Schoenwaelder , Martin Bjorklund , "netmod@ietf.org" 
Thread-Topic: [netmod] yang-data-ext issues
Thread-Index: AQHT1YJYRSnZmZlnhU6JIK4LoPfNTqQEcM6AgAYAzwCAAlYhgIAB08UAgAAyUgCAATikgIAAAaSAgAGHGgCAAAK9AIAAEH6AgAACpYCAAPWtAIABPh0AgACT0YCAAAY/gIAABasAgAALQACAAARkgIAANngAgAADfgCAAAdSAIAADKEAgASYmICAAD0hgIACdpWAgAAbLACAAAZCAIAAAyoAgCqWpwCAAFa+AIAAJP2A///ZJgA=
Date: Tue, 29 May 2018 21:02:21 +0000
Message-ID: <21C39230-92EC-4BB5-82D0-2598300B362C@juniper.net>
References:  <20180502.092527.2305319833268262996.mbj@tail-f.com> <9fca04b0-fb29-36b3-67aa-2f2c4fb98748@cisco.com> <20180502.112506.845305331945500257.mbj@tail-f.com> <20180502093626.ugsg6nq24a6vjtdn@elstar.local> <64990DFB-CF50-401A-A4EF-B6161C8D227B@juniper.net> <20180529170900.qboedr2rmefsmblc@anna.jacobs.jacobs-university.de> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB3959; 7:eH9Y1vzubY6oMF3waKU8afMq0UtuPPYs8bXOY+xhtXYeSGKjtbq3R/bjmY74mT3dcQIfMMLp+J+tmv6oUKfEmx0/HEzJ6CkCMX4Oo3M1f4B560hZn7TDtElo16mtYqSgJXenxgdb0afEE1VXFAeI8HRUIS5P64ko8PmxB48jzep0OITmxaNkmiJm+BPNUwWdm/OVCVzqYwYq/evWVzI7r2iOH10wzQbQK90km5p05LsztxxozWWC7sdt7G+WkiiH
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB3959; 
x-ms-traffictypediagnostic: BYAPR05MB3959:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB3959; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB3959; 
x-forefront-prvs: 0687389FB0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(366004)(39380400002)(396003)(346002)(199004)(189003)(99286004)(102836004)(6506007)(59450400001)(83716003)(478600001)(82746002)(8936002)(68736007)(966005)(36756003)(316002)(26005)(93886005)(186003)(446003)(476003)(86362001)(6486002)(76176011)(2616005)(6436002)(11346002)(110136005)(58126008)(486006)(229853002)(97736004)(5660300001)(5250100002)(2501003)(66066001)(33656002)(6306002)(2900100001)(3280700002)(25786009)(2906002)(5890100001)(6246003)(14454004)(53936002)(3660700001)(105586002)(106356001)(3846002)(305945005)(6116002)(6512007)(7736002)(81166006)(8676002)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB3959; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: xIZS2U4dzJEFg9rPkDQkh/l8/0w3JFll5hpKsDNqwayUcTHgIxfteGkJeSADmtK0B4XyosXIp6VHOSO/D8r+rMqNcH1Y3NgUmmeh+yWJS8w8fOOSp0XsQGYHk7hj/VMBShEcnYjkH2/9uRiCaXmapK+N5Y3dNMTEUkpJ6X3Foz0flwwJ5CkmkuagjPrDahtQ
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: fe8b8bf6-aa10-4617-dbfa-08d5c5a7785f
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: fe8b8bf6-aa10-4617-dbfa-08d5c5a7785f
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2018 21:02:21.1460 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB3959
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-29_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1805290222
Archived-At: 
Subject: Re: [netmod] yang-data-ext issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 May 2018 21:20:43 -0000

Pj4+ID4+IFRoZSBwcmltYXJ5IHVzZSBjYXNlIGlzIG5vdCAiZ2VuZXJpYyBSUEMgbWVzc2FnZXMi
LCBidXQgc3RhbmRhbG9uZQ0KPj4+ID4+IGluc3RhbmNlIGRvY3VtZW50cywgZXJyb3ItaW5mbyBz
dHJ1Y3R1cmVzLCBldGMuDQo+Pj4gPg0KPj4+ID4gVGhlIHByb3BlciBzb2x1dGlvbiBmb3IgcnBj
cyBhbmQgYWN0aW9ucyBpcyB0byBkZWZpbmUgZXJyb3INCj4+PiA+IGluZm9ybWF0aW9uIGFzIHBh
cnQgb2YgdGhlIHJwYy9hY3Rpb24uIFlBTkcgMS4xIGRvZXMgbm90IHN1cHBvcnQNCj4+PiA+IHRo
aXMgYnV0IHRoaXMgaXMgd2hlcmUgaXQgc2hvdWxkIGJlIGZpeGVkLg0KPj4+IA0KPj4+IEFncmVl
ZCwgYnV0IG5vdGUgdGhhdCB0aGUgc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIGRyYWZ0IChib3Ro
IHRoZQ0KPj4+IHB1Ymxpc2hlZCAtMTIgYW5kIHVucHVibGlzaGVkIC0xMykgYXJlIHJlbHlpbmcg
b24gYmVpbmcgYWJsZSB0byBkbw0KPj4+IGp1c3QgdGhpcywgYW5kIFlBTkctbmV4dCBpcyB5ZWFy
cyBhd2F5Li4uDQo+Pg0KPj5UaGVyZSBpcyBhIGRlc2NyaXB0aW9uIHN0YXRlbWVudC4NCj4+DQo+
DQo+IEF1dG9tYXRpb24gdG9vbHMgZ2VuZXJhbGx5IHVzZSBtYWNoaW5lLXJlYWRhYmxlIHN0YXRl
bWVudHMsIGFuZCBhdm9pZA0KPiB1c2luZyBkZXNjcmlwdGlvbi1zdG10cy4NCj4NCj4gVGhlIHlh
bmctZGF0YSBleHRlbnNpb25zIGRvIG5vdCBzb2x2ZSB0aGlzICJycGMvYWN0aW9uIHRvIGVycm9y
LWluZm8iDQo+IG1hcHBpbmcgcHJvYmxlbSwgc28gdGhpcyBwcm9ibGVtIGlzIG5vdCBhIHJlYWwg
ZmFjdG9yIGhlcmUuDQoNCklmIHN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyBkb2Vzbid0IHVzZSAi
eWFuZy1kYXRhIiwgdGhlbiBpdCB3b3VsZCBuZWVkDQp0byB1c2UgYW5vdGhlciBleHRlbnNpb24g
c3RhdGVtZW50LCBsZXN0IHRoZSAzICJlcnJvci1pbmZvIiBzdGF0ZW1lbnRzDQppdCBkZWZpbmVz
IGFyZSBtaXNjb25zdHJ1ZWQgYXMgY29uZmlndXJhdGlvbiBvciBvcGVyYXRpb25hbCBzdGF0ZS4N
Cg0KDQo+Pj4gPiBTdGFuZGFsb25lIGluc3RhbmNlIGRvY3VtZW50cyAobm90IHRpZWQgdG8gZGF0
YXN0b3JlcykgbWF5IGhhdmUgdGhlaXINCj4+PiA+IHVzZSBjYXNlcyBhcyB3ZWxsIGJ1dCBpdCBm
ZWVscyBvZGQgdG8gY3JlYXRlIHN1cHBvcnQgZm9yIHN0YW5kYWxvbmUNCj4+PiA+IGluc3RhbmNl
IGRvY3VtZW50cyBhcyBleHRlbnNpb25zIGFuZCB0aGVuIHRvIGNyZWF0ZSBldmVuIG1vcmUNCj4+
PiA+IGV4dGVuc2lvbnMgdG8gc3VwcG9ydCBhdWdtZW50YXRpb24gb2YgdGhlc2UgaW5zdGFuY2Ug
ZG9jdW1lbnRzIGFuZA0KPj4+ID4gd2hvZXZlciBrbm93cyB3aGF0IGNvbWVzIG5leHQuDQo+Pj4g
DQo+Pj4gV2hhdCBmZWVscyAib2RkIiBhYm91dCB0aGlzP8KgIElzIGl0IG5vdCB1c2luZyB0aGUg
ZXh0ZW5zaW9uIHN0YXRlbWVudA0KPj4+IGFzIGl0IHdhcyBpbnRlbmRlZD8NCj4+DQo+PiBGb3Ig
bWUsIGV4dGVuc2lvbnMgdGhhdCBkZWZpbmUgbmV3IGRhdGEgZGVmaW5pdGlvbiBzdGF0ZW1lbnRz
IGFyZQ0KPj4gYm9yZGVybGluZS4gUkZDIDc5NTAgaGFzIHRoaXMgbmljZSBzdGF0ZW1lbnQ6DQo+
Pg0KPj7CoCDCoG/CoCBleHRlbnNpb246IEFuIGV4dGVuc2lvbiBhdHRhY2hlcyBub24tWUFORyBz
ZW1hbnRpY3MgdG8gc3RhdGVtZW50cy4NCj4+wqAgwqAgwqAgVGhlICJleHRlbnNpb24iIHN0YXRl
bWVudCBkZWZpbmVzIG5ldyBzdGF0ZW1lbnRzIHRvIGV4cHJlc3MgdGhlc2UNCj4+wqAgwqAgwqAg
c2VtYW50aWNzLg0KPj4NCj4+IFRoaXMgZG9lcyBub3QgaGVscCBzaW5jZSB3ZSBsYWNrIGEgZGVm
aW5pdGlvbiBmb3IgJ25vbi1ZQU5HIHNlbWFudGljcycNCj4+IGFuZCB5ZXMgSSBrbm93IHRoYXQg
eWFuZy1kYXRhIGlzIHRvZGF5IGRlZmluZWQgYXMgYW4gZXh0ZW5zaW9uLiBCdXQNCj4+IGZvciBt
ZSwgdGhpcyBpcyBhIGhhY2sgYW5kIGluc3RlYWQgb2YgY3JlYXRpbmcgYSBzbGlnaHRseSBtb3Jl
DQo+PiBnZW5lcmFsaXplZCB2ZXJzaW9uIG9mIHRoaXMgaGFjaywgSSBwcmVmZXIgdG8gc3RpY2sg
dG8geWFuZy1kYXRhIGluDQo+PiBmYXZvciBvZiBhIHByb3BlciBzb2x1dGlvbiBhcyBwYXJ0IG9m
IFlBTkcuDQo+DQo+IFRoZSB5YW5nLWRhdGEgYW5kIGF1Z21lbnQteWFuZy1kYXRhIGV4dGVuc2lv
bnMgZG8gbm90IHJlLWRlZmluZSBZQU5HIA0KPiBkYXRhIG5vZGVzLiBUaGV5IGRlZmluZSBhIG5l
dyBjb250ZXh0IGZvciBkYXRhIG5vZGVzIGFuZCBwcmV2ZW50IHBsYWluDQo+IFlBTkcgdG9vbHMg
ZnJvbSBjb25mdXNpbmcgdGhpcyBuZXcgY29udGV4dCB3aXRoIGRhdGEgZm9yIGNvbmZpZ3VyYXRp
b24gb3IgDQo+IG9wZXJhdGlvbmFsIGRhdGFzdG9yZXMuDQoNClllcy4NCg0KwqANCj4+PiA+IEZv
ciBzaG9ydC10ZXJtIG5lZWRzLCB0aGVyZSBpcyB5YW5nLWRhdGEgZGVmaW5lZCBpbiBSRkMgODA0
MC4NCj4+PiANCj4+PiBUbyBiZSBjbGVhciwgdGhlICJzaG9ydC10ZXJtIG5lZWRzIiBhcmU6DQo+
Pj4gDQo+Pj7CoCDCoGEpIHplcm90b3VjaDogdG8gZGVmaW5lIGEgc3RhbmRhbG9uZSBpbnN0YW5j
ZSBkb2N1bWVudA0KPj4+wqAgwqBiKSBub3RpZmljYXRpb24tbWVzc2FnZXM6IHRvIGRlZmluZSBh
IG5ldyBub3RpZmljYXRpb24gbWVzc2FnZQ0KPj4+wqAgwqBjKSBzdWJzY3JpYmVkLW5vdGlmaWNh
dGlvbnM6IHRvIGRlZmluZSBlcnJvci1pbmZvIHN0cnVjdHVyZXMNCj4+PiANCj4+PiBBcyBJIHJl
Y2FsbCwgdGhpcyBkcmFmdCAobm90IFJGQyA4MDQwKSBpcyBuZWVkZWQ6DQo+Pj4gDQo+Pj7CoCDC
oC0gZm9yIChhKSwgYmVjYXVzZSByYzp5YW5nLWRhdGEgZG9lc24ndCBzdXBwb3J0IGEgdG9wLWxl
dmVsDQo+Pj7CoCDCoCDCoCJjaG9pY2UiIHN0YXRlbWVudCBzcGFubmluZyAiY29udGFpbmVyIiBz
dGF0ZW1lbnRzLg0KPj4NCj4+IFNvIGNyZWF0ZSBhIGNvbnRhaW5lci4NCj4NCj4gSSB0ZW5kIHRv
IGFncmVlIHRoYXQgYSB0b3AtbGV2ZWwgY2hvaWNlIGNvdWxkIGJlIGF2b2lkZWQuDQo+IFRoaXMg
aXMgbm90IGEgcmVhbGx5IGNvbXBlbGxpbmcgdXNlLWNhc2UuDQoNCkZyb20gaHR0cHM6Ly9tYWls
YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9uZXRjb25mL1Q2T2dDdmJGMzBFT29VMjdiM1RfLWRP
ZGoyRToNCg0KICBUaGUgemVyb3RvdWNoIGRyYWZ0IGhhcyB3YXkgdG9vIG11Y2ggdGV4dCBpbnZl
c3RlZCBpbiB0aGUgInplcm90b3VjaC0NCiAgaW5mb3JtYXRpb24iIGFydGlmYWN0IGJlaW5nIHBv
bHltb3JwaGljIGluIG5hdHVyZSB0byBzZXJpb3VzbHkgY29uc2lkZXINCiAgaGF2aW5nIHR3byB1
bnJlbGF0ZWQgYXJ0aWZhY3RzLCB3aGVuIHRoZSBlYXNpZXIgYW5zd2VyIGlzIHRvIGFncmVlIA0K
ICB0aGF0LCBpbiB0aGlzIGNhc2UsIHRoZSB5YW5nLWRhdGEgZG9lcyBpbiBmYWN0IGNvbnRhaW4g
ImRhdGEgZGVmaW5pdGlvbiANCiAgc3RhdGVtZW50cyB0aGF0IHJlc3VsdCBpbiBleGFjdGx5IG9u
ZSBjb250YWluZXIgZGF0YSBub2RlIGRlZmluaXRpb24iLg0KICBXZSBkb24ndCBldmVuIG5lZWQg
dG8gY2hhbmdlIGFueSB0ZXh0LCBpbiB0aGlzIGRvY3VtZW50IFt6ZXJvdG91Y2hdIG9yDQogIGlu
IFJGQyA4MDQwLCBpbiBvcmRlciB0byBoYXZlIHRoaXMgYWdyZWVtZW50LiAgV2Ugd291bGQgb25s
eSBuZWVkIA0KICBgcHlhbmdgIHRvIHN0b3AgZmxhZ2dpbmcgaXQgYXMgYW4gZXJyb3IuDQoNClNv
LCB5ZXMsIHlhbmctZGF0YS1leHQgaXNuJ3QgbmVlZGVkIGZvciB6ZXJvdG91Y2gsIHRoZXJlIGFy
ZSBvcHRpb25zDQpvbiB0aGUgdGFibGUuICBCdXQsIHNvIGxvbmcgYXMgdGhpcyBkcmFmdCBpcyBh
IFdJUCwgdGhlbiBpdCBzZWVtcyB0aGF0IA0KemVyb3RvdWNoIHNob3VsZCB1c2UgaXQuDQoNCg0K
Pj4+wqAgwqAtIGZvciAoYiksIGluIG9yZGVyIHRvIGF1Z21lbnQgYSBiYXNlIHlhbmctZGF0YSAi
bWVzc2FnZSIgDQo+Pj7CoCDCoCDCoHN0cnVjdHVyZSB3aXRoIGFkZGl0aW9uYWwgbm9kZXMuDQo+
Pg0KPj4gU28geW91IGFyZSBjcmVhdGluZyBhbm90aGVyIGF1Z21lbnRhdGlvbiBtZWNoYW5pc20u
IEkgYW0gY29uY2VybmVkDQo+PiBhYm91dCBlbmRpbmcgdXAgd2l0aCBhIHpvbyBvZiBkaWZmZXJl
bnQgbWVjaGFuaXNtcyBpZiB3ZSBnbyBkb3duIHRoaXMNCj4+IHBhdGgsIHdlIG1heSBlbmQgdXAg
d2l0aCBldmVyeSBwcm9qZWN0IG9yIHZlbmRvciBjcmVhdGluZyB0aGVpciBvd24NCj4+IHZhcmlh
bnRzLg0KPj4NCj4+IFdpdGggTk1EQSBpbiBwbGFjZSwgWUFORyAxLjEgaXMgZGVjcmliaW5nIHNj
aGVtYXMgZm9yIGRhdGFzdG9yZXMgcGx1cw0KPj4gb3BlcmF0aW9ucyBhbmQgbm90aWZpY2F0aW9u
cy4gSXQgaXMgbm90IGEgcHJvdG9jb2wgbWVzc2FnZSBkZXNjcmlwdGlvbg0KPj4gbGFuZ3VhZ2Ug
b3IgYSBzdGFuZGFsb25lIGZpbGUgZm9ybWF0IGRlc2NyaXB0aW9uIGxhbmd1YWdlLiBJZiB0aGlz
IGlzDQo+PiBuZWVkZWQsIEkgcHJlZmVyIHRvIGNyZWF0ZSBZQU5HIFguWSAtIGFuZCBpZiB3ZSBt
YW5hZ2UgdGhlIGNvbXBsZXhpdHkNCj4+IHdlIGhhdmUgc29tZXRoaW5nIHRoYXQgaXMgaWRlYWxs
eSBpbnRlZ3JhdGVkIGFuZCBjb25zaXN0ZW50Lg0KPg0KPiBZZXMgaXQgaXMgYSBwcm90b2NvbCBt
ZXNzYWdlIGRlc2NyaXB0aW9uIGxhbmd1YWdlLCBidXQgb25seQ0KPiBpbiBhbiBpbmNvbXBsZXRl
LCBoYWNreSB3YXkuwqAgU3BlY2lmaWMgc3VidHJlZXMgd2l0aGluIHByb3RvY29sIG1lc3NhZ2Vz
DQo+IGFyZSBkZWZpbmVkIGFzIHNwZWNpYWwgWUFORyBkYXRhLWRlZmluZWQgcG9ydGlvbnMgYW5k
IHRoZSByZXN0IGlzIHNvbWVob3cNCj4gb3V0IG9mIHNjb3BlIGZvciBZQU5HLiBUaGUgd2F5IG5l
c3RlZCByb290cyAoZS5nLiwgPGNvbmZpZz4gb3IgPGRhdGE+KQ0KPiBhcmUgaGFuZGxlZCBpcyB0
aGUgd29yc3QgaGFjayBvZiBhbGwuwqAgQnV0IElNTyBhIG5ldyB2ZXJzaW9uIG9mIFlBTkcgaXMN
Cj4gbmVlZGVkIHRvIHJlYWxseSBmaXggdGhlc2UgcHJvYmxlbXMuDQoNClllcywgd2UgYWdyZWUg
dGhhdCBhIG5ldyB2ZXJzaW9uIG9mIFlBTkcgaXMgaWRlYWwsIGJ1dCBzdWNoIGlzIHllYXJzIGF3
YXkNCmFuZCB0aGUgTkVUQ09ORiBXRyBpcyBub3QgZ29pbmcgdG8gYmxvY2sgdGhlc2UgZHJhZnRz
IHdhaXRpbmcgZm9yIGl0LiAgRG8NCndlIHJhdGhlciB0aGUgbm90aWZpY2F0aW9uLW1lc3NhZ2Vz
IGRyYWZ0IGRlZmluZSBhIHByaXZhdGUgdmVyc2lvbiBvZiB0aGUNCiJhdWdtZW50LXlhbmctZGF0
YSIgZXh0ZW5zaW9uIHN0YXRlbWVudD8NCg0KDQo+Pj7CoCDCoC0gQUZBSUFBLCBSRkMgODA0MCBp
cyBzdWZmaWNpZW50IGZvciAoYykNCj4+PiANCj4+PiBIYXMgYW55dGhpbmcgY2hhbmdlZD/CoCDC
oEkgZG9uJ3QgdGhpbmsgdGhhdCB3ZSBjYW4gdW4tYWRvcHQgdGhpcw0KPj4+IGRyYWZ0IHdpdGgg
c2FpZCBkZXBlbmRlbmNpZXMsIHJpZ2h0Pw0KPg0KPiBJIGFtIGp1c3Qgdm9pY2luZyBteSBvcGlu
aW9uLiBJdCBtYXkgdmVyeSB3ZWxsIGJlIHRoYXQgdGhlIFdHIHByZWZlcnMNCj4gdG8gZ28gdGhl
IHJvdXRlIG9mIG5vdCB0b3VjaGluZyBZQU5HIDEuMSBhbmQgaW5zdGVhZCBwYXRjaGluZyBhcm91
bmQNCj4gaXRzIGxpbWl0YXRpb25zIHdpdGggZXh0ZW5zaW9ucy4NCj4NCj4gTXkgY29uY2VybiBp
cyBzaW1wbHkgZHJpdmVuIHRoYXQgc29tZSB3YW50IHRvIHBhdGNoIGluIHZpYSBleHRlbnNpb25z
DQo+IHN1cHBvcnQgZm9yIGRlc2NyaWJpbmcgcHJvdG9jb2wgbWVzc2FnZXMgYW5kIHN0YW5kYWxv
bmUgZG9jdW1lbnRzLA0KPiBvdGhlcnMgd2FudCB0byBwYXRjaCB2aWEgZXh0ZW5zaW9ucyBhbmQg
dXBkYXRlcyBhIGRpZmZlcmVudCB2ZXJzaW9uaW5nDQo+IHN5c3RlbSwgYW5kIHdobyBrbm93cyB3
aGF0IGNvbWVzIG5leHQuIEluIHRoZSBsb25nIHJ1biwgSSBhbSBhZnJhaWQNCj4gdGhpcyB3aWxs
IGJlY29tZSBhIG1lc3MuIEFuZCB5ZXMsIGl0IGlzIGFsd2F5cyBkaWZmaWN1bHQgdG8gcHJlZGlj
dA0KPiB0aGUgZnV0dXJlIC0gd2UgbmVlZCBjcnlzdGFsIGJhbGxzLiBQZXJoYXBzIGFzIGFuIGV4
dGVuc2lvbi4gOy0pDQo+DQo+IFRoaXMgaXMgYSBzZXBhcmF0ZSAoYnV0IGltcG9ydGFudCkgdG9w
aWMgLS0gWUFORyAxLjEgKyBhIHZlbmRvci1zZWxlY3RlZA0KPiBzZXQgb2Ygb3B0aW9uYWwgZXh0
ZW5zaW9ucyBpcyBub3QgdGhlIHNhbWUgYXMgYSBuZXcgdmVyc2lvbiBvZiBZQU5HIA0KPiAod2l0
aCBtYW5kYXRvcnktdG8taW1wbGVtZW50IHN0YXRlbWVudHMpLg0KPg0KPiBZQU5HIGRlc2lnbmVy
cyBjYW5ub3QgcmVhbGx5IHJlbHkgb24gb3B0aW9uYWwgZXh0ZW5zaW9ucyBhY3Jvc3MgdG9vbC1j
aGFpbnMuDQrCoA0KVHJ1ZSwgYnV0IGl0IHNlZW1zIHRoYXQgdGhpcyBvbmUgbWlnaHQgaGl0IGNy
aXRpY2FsIG1hc3MuIEV2ZW4gaWYgaXQgZG9lc24ndCwNCnNjcmlwdHMgY2FuIGF1dG8tY29udmVy
dCB5YW5nLWRhdGEgZGVmaW5pdGlvbnMgaW50byB0aGVpciBkZXNjZW5kZW50IG5vZGUgDQpkZWZp
bml0aW9ucyAoY29udGFpbmVyLCBvciBjaG9pY2UgaW4gemVyb3RvdWNoIGNhc2UpIHNvIGV4aXN0
aW5nIHRvb2xpbmcgY2FuDQpncm9rIHRoZW0uICBJIGhhdmUgc2NyaXB0cyBkb2luZyB0aGlzIHRv
ZGF5Lg0KDQoNCktlbnQNCg0KDQoNCg0K


From nobody Tue May 29 18:40:01 2018
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 9EF2912F092 for ; Tue, 29 May 2018 18:39:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2f3YSq8qHZV for ; Tue, 29 May 2018 18:39:57 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7DBB12ECEB for ; Tue, 29 May 2018 18:39:57 -0700 (PDT)
Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id A2EEB969DCED1 for ; Wed, 30 May 2018 02:39:53 +0100 (IST)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 30 May 2018 02:39:54 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.193]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0382.000; Wed, 30 May 2018 09:39:43 +0800
From: Qin Wu 
To: "netmod@ietf.org" 
Thread-Topic: Status update on 
Thread-Index: AQHT97P2/JSg9j4OKEuGkK1Py+kz/KRHeJEA
Date: Wed, 30 May 2018 01:39:42 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [netmod] Status update on 
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2018 01:40:00 -0000

SGksIFdHOg0KV2UgaGF2ZSBtYWRlIGFuIHVwZGF0ZSBEb2N1bWVudGF0aW9uIENvbnZlbnRpb25z
IGZvciBFeHByZXNzaW5nIFlBTkcgaW4gWE1MIEktRCBiYXNlZCBvbiBsYXN0IG1lZXRpbmcgZGlz
Y3Vzc2lvbi4NClRoZSBjaGFuZ2VzIGluY2x1ZGU6DQoxLiBBZGQgSlNPTiBzdXBwb3J0Lg0KMi4g
QWRkIG9iamVjdGl2ZXMgc2VjdGlvbiANCjMuIENvbnNvbGlkYXRlIE1hbmRhdG9yeSBCb2lsZXJw
bGF0ZSBmb3IgYm90aCBsZWFmIG5vZGUgYW5kIG1ldGFkYXRhIGFubm90YXRpb24uDQo0LiBNb3Zl
IGNvbXBsZXggY2FzZSB0byBBcHBlbmRpeC4NCjUuIEJldHRlciBBbGlnbiBhYnN0cmFjdCBhbmQg
aW50cm9kdWN0aW9uIHNlY3Rpb24gd2l0aCBvYmplY3RpdmVzIHNlY3Rpb25zLg0KVGhlIGRpZmYg
aXM6DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtd3UtbmV0bW9kLXlh
bmcteG1sLWRvYy1jb252ZW50aW9ucy0wMQ0KV2UgYmVsaWV2ZSB0aGUgdi0oMDEpIGFkZHJlc3Mg
YWxsIHRoZSBjb21tZW50cyBpbiBsYXN0IG1lZXRpbmcgYW5kIGNhbiBzZXJ2ZSBhIGdvb2QgYmFz
aXMgdG8gbW92ZSB0byB0aGUgbmV4dCBzdGVwLg0KVGhhbmtzLiBGdXJ0aGVyIENvbW1lbnRzIGFu
ZCBzdWdnZXN0aW9ucyBhcmUgd2VsY29tZS4NCg0KLVFpbg0KLS0tLS3pgq7ku7bljp/ku7YtLS0t
LQ0K5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1k
cmFmdHNAaWV0Zi5vcmddIA0K5Y+R6YCB5pe26Ze0OiAyMDE45bm0NeaciDMw5pelIDk6MTcNCuaU
tuS7tuS6ujogQmVub2l0IENsYWlzZTsgUWluIFd1OyBBZHJpYW4gRmFycmVsOyBCZW5vw650IENs
YWlzZQ0K5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXd1LW5ldG1v
ZC15YW5nLXhtbC1kb2MtY29udmVudGlvbnMtMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJ
LUQsIGRyYWZ0LXd1LW5ldG1vZC15YW5nLXhtbC1kb2MtY29udmVudGlvbnMtMDEudHh0DQpoYXMg
YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFFpbiBXdSBhbmQgcG9zdGVkIHRvIHRoZSBJ
RVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC13dS1uZXRtb2QteWFuZy14bWwtZG9jLWNv
bnZlbnRpb25zDQpSZXZpc2lvbjoJMDENClRpdGxlOgkJRG9jdW1lbnRhdGlvbiBDb252ZW50aW9u
cyBmb3IgRXhwcmVzc2luZyBZQU5HIGluIFhNTA0KRG9jdW1lbnQgZGF0ZToJMjAxOC0wNS0yOQ0K
R3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTANClVSTDogICAgICAgICAg
ICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd3UtbmV0bW9kLXlh
bmcteG1sLWRvYy1jb252ZW50aW9ucy0wMS50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2Rh
dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13dS1uZXRtb2QteWFuZy14bWwtZG9jLWNvbnZl
bnRpb25zLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm
dC13dS1uZXRtb2QteWFuZy14bWwtZG9jLWNvbnZlbnRpb25zLTAxDQpIdG1saXplZDogICAgICAg
aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC13dS1uZXRtb2QteWFu
Zy14bWwtZG9jLWNvbnZlbnRpb25zDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvcmZjZGlmZj91cmwyPWRyYWZ0LXd1LW5ldG1vZC15YW5nLXhtbC1kb2MtY29udmVudGlvbnMt
MDENCg0KQWJzdHJhY3Q6DQogICBNYW55IGRvY3VtZW50cyB0aGF0IGRlZmluZSBZQU5HIG1vZHVs
ZXMgYWxzbyBpbmNsdWRlIGFydHdvcmsgZXhhbXBsZXMNCiAgIHByZXNlbnRlZCBpbiBYTUwvSlNP
Ti4NCg0KICAgSUVURiBkb2N1bWVudGF0aW9uIGhhcyBzcGVjaWZpYyBsaW1pdHMgb24gbGluZSBs
ZW5ndGggYW5kIHNvbWUNCiAgIGFydHdvcmsgZXhhbXBsZXMgc3VjaCBhcyBYTUwgZXhhbXBsZXMg
aGF2ZSB0byBpbmNsdWRlIGxpbmUgd3JhcHMgdGhhdA0KICAgd291bGQgbm90IG5vcm1hbGx5IGJl
IGFsbG93ZWQgYWNjb3JkaW5nIHRvIHRoZSBYTUwgcmVwcmVzZW50YXRpb24NCiAgIHJ1bGVzIG9m
IFJGQzc5NTAgYW5kIFJGQzc5NTIuVGhlIHNhbWUgYXBwbGllcyB0byBKU09OLg0KDQogICBUaGlz
IGRvY3VtZW50IGxheXMgb3V0IGRvY3VtZW50YXRpb24gY29udmVudGlvbnMgdGhhdCBhbGxvdyBZ
QU5HDQogICBleGFtcGxlcyB0byBiZSBwcmVzZW50ZWQgaW4gSUVURiBkb2N1bWVudGF0aW9uIHdo
ZW4gWE1ML0pTT04gZW5jb2RlZA0KICAgWUFORyBkYXRhIGluc3RhbmNlIHdvdWxkIG90aGVyd2lz
ZSBleGNlZWQgdGhlIG1heGltdW0gbGluZSBsZW5ndGggYW5kDQogICBwcm92aWRlIGNvbnNpc3Rl
bnQgWE1ML0pTT04gZW5jb2RlZCBZQU5HIGRhdGEgbm9kZSBpbnN0YW5jZSBleGFtcGxlDQogICB3
aXRoaW4gYW4gSW50ZXJuZXQtRHJhZnQgb3IgUkZDLiAgVGhlcmUgYXJlIG5vIGltcGxpY2F0aW9u
cyBpbiB0aGlzDQogICBkb2N1bWVudCBmb3IgWUFORyBwYXJzZXJzOiB0aGlzIGRvY3VtZW50IGRv
ZXMgbm90IGNoYW5nZSB0aGUgcnVsZXMNCiAgIGZvciBwcmVzZW50aW5nIFlBTkcgbW9kZWxzIG9y
IGZvciBlbmNvZGluZyBZQU5HIGluIGRhdGEgZmlsZXMgb3IgaW4NCiAgIHRoZSB3aXJlLg0KDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr
ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0
aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu
b3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo=


From nobody Tue May 29 18:56:32 2018
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 6A2E812ECB9 for ; Tue, 29 May 2018 18:56:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8wKgYFyEL70 for ; Tue, 29 May 2018 18:56:29 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1CC212EC05 for ; Tue, 29 May 2018 18:56:28 -0700 (PDT)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id DC82718C16333; Wed, 30 May 2018 02:56:25 +0100 (IST)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 30 May 2018 02:56:26 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.193]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0382.000; Wed, 30 May 2018 09:56:15 +0800
From: Qin Wu 
To: Juergen Schoenwaelder , "Rohit R Ranade" 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
Thread-Index: AQHT9zOXH0Q7uD0JNkiP7Q3mI4ni1KRF/2gAgAAGLQCAAAYEAIAACscAgAFsZWA=
Date: Wed, 30 May 2018 01:56:14 +0000
Message-ID: 
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB23B2@dggeml510-mbx.china.huawei.com> <71e76c7e-4043-d80a-73ac-1759e85cc5d7@cisco.com> <991B70D8B4112A4699D5C00DDBBF878A6BBB241F@dggeml510-mbx.china.huawei.com> <20180529110610.4rcqvp7x4qpbg5hz@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BBB2484@dggeml510-mbx.china.huawei.com> <20180529120616.bxl4xyftqsvpsbxo@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180529120616.bxl4xyftqsvpsbxo@anna.jacobs.jacobs-university.de>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2018 01:56:32 -0000

SnVlcmdlbjoNCk9uZSBzdHVwaWQgcXVlc3Rpb24gSSBoYXZlIGlzLCBXaGF0IGFib3V0IHRoZSBv
bGQgY2xpZW50IGFuZCBzZXJ2ZXIgc3RpbGwgc3VwcG9ydCBZQU5HIDEuMCBzaW5jZSBSRkM3ODk1
YmlzIGlzIGRlc2lnbmVkIHRvIHJlcGxhY2VzIFJGQzc4OTU/DQpEbyB3ZSBoYXZlIHRyYW5zaXRp
b24gc3RhZ2UgYmVmb3JlIFJGQzc4OTViaXMgdGFrZXMgZWZmZWN0Pw0KDQotUWluDQotLS0tLdPK
vP7Urbz+LS0tLS0NCreivP7IyzogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5v
cmddILT6se0gSnVlcmdlbiBTY2hvZW53YWVsZGVyDQq3osvNyrG85DogMjAxOMTqNdTCMjnI1SAy
MDowNg0KytW8/sjLOiBSb2hpdCBSIFJhbmFkZQ0Ks63LzTogbmV0bW9kQGlldGYub3JnDQrW98zi
OiBSZTogW25ldG1vZF0gZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzc4OTViaXMtMDYgZGV2aWF0aW9u
IHF1ZXJ5DQoNClllcywgdGhpcyBpcyB3aHkgd2UgaGF2ZSBkcmFmdC1pZXRmLW5ldGNvbmYtcmZj
Nzg5NWJpcy0wNi50eHQuDQoNCi9qcw0KDQpPbiBUdWUsIE1heSAyOSwgMjAxOCBhdCAxMToyNzo0
MkFNICswMDAwLCBSb2hpdCBSIFJhbmFkZSB3cm90ZToNCj4gSGkgSnVlcmdlbiwNCj4gDQo+IENv
bnNpZGVyIGEgZGV2aWNlIHN1cHBvcnRzIGEgZHluYW1pYyBkYXRhLXN0b3JlIGNhbGxlZCAiZXBo
ZW1lcmFsIi4gQ29uc2lkZXIgWWFuZy1saWJyYXJ5IDEuMSBpcyBOT1QgaW1wbGVtZW50ZWQgaW4g
ZGV2aWNlLg0KPiBDb25zaWRlciBkZXZpY2UgaGF2ZSAzIE1vZHVsZXMgPT0+IE1vZHVsZTEgLCAg
TW9kdWxlMi1zdGF0ZSBhbmQgDQo+IE1vZHVsZTMNCj4gDQo+IE1vZHVsZTEgOiBTdXBwb3J0ZWQg
aW4gPHJ1bm5pbmc+IGFuZCA8b3BlcmF0aW9uYWw+IE1vZHVsZTItc3RhdGUgOiANCj4gU3VwcG9y
dGVkIG9ubHkgaW4gPG9wZXJhdGlvbmFsPg0KPiBNb2R1bGUzIDogU3VwcG9ydGVkIG9ubHkgaW4g
PGVwaGVtZXJhbD4NCj4gDQo+IFNvIGhlcmUgYXNzdW1wdGlvbiBpcyB0aGF0IENsaWVudCBrbm93
cyBoZSBjYW5ub3QgZG8gPGVkaXQtZGF0YT4gb24gTW9kdWxlMi1zdGF0ZSBhcyBpdCBoYXMgb25s
eSByZWFkLW9ubHkgbm9kZXMuDQo+IEJ1dCBDbGllbnQgZG9lcyBub3Qga25vdyB0aGUgbW9kdWxl
cyBpbiBlcGhlbWVyYWwgYW5kIGRlcGVuZHMgb24geWFuZy1saWJyYXJ5IDEuMSB0byBrbm93IHdo
ZXRoZXIgYW4gZWRpdC1kYXRhIGNhbiBiZSBkb25lIG9uIE1vZHVsZTMgPw0KPiANCj4gV2hpY2gg
bW9kdWxlcyBhcmUgc3VwcG9ydGVkIGluIHdoaWNoIGRhdGEtc3RvcmVzIGlzIG5vdCBrbm93biB0
byBDbGllbnQgd2l0aG91dCBZYW5nLWxpYnJhcnkgMS4xID8NCj4gDQo+IFdpdGggUmVnYXJkcywN
Cj4gUm9oaXQgUiBSYW5hZGUNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy
b206IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciANCj4gW21haWx0bzpqLnNjaG9lbndhZWxkZXJAamFj
b2JzLXVuaXZlcnNpdHkuZGVdDQo+IFNlbnQ6IDI5IE1heSAyMDE4IDE2OjM2DQo+IFRvOiBSb2hp
dCBSIFJhbmFkZSA8cm9oaXRycmFuYWRlQGh1YXdlaS5jb20+DQo+IENjOiBSb2JlcnQgV2lsdG9u
IDxyd2lsdG9uQGNpc2NvLmNvbT47IG5ldG1vZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW25l
dG1vZF0gZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzc4OTViaXMtMDYgZGV2aWF0aW9uIHF1ZXJ5DQo+
IA0KPiBPbiBUdWUsIE1heSAyOSwgMjAxOCBhdCAxMDo0NDowNEFNICswMDAwLCBSb2hpdCBSIFJh
bmFkZSB3cm90ZToNCj4gPiBIaSBSb2JlcnQsDQo+ID4gDQo+ID4gVGhlIEludHJvZHVjdGlvbiBz
ZWN0aW9uIGhhcyA6DQo+ID4gIg0KPiA+IEZ1cnRoZXJtb3JlLCB0aGUgb3BlcmF0aW9uYWwgc3Rh
dGUgZGF0YXN0b3JlIG1heSBzdXBwb3J0IG5vbi1jb25maWd1cmFibGUgWUFORyBtb2R1bGVzIGlu
IGFkZGl0aW9uIHRvDQo+ID4gICAgdGhlIFlBTkcgbW9kdWxlcyBzdXBwb3J0ZWQgYnkgY29udmVu
dGlvbmFsIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3Jlcy4NCj4gPiAiDQo+ID4gSSBpbmZlciB0aGF0
IGluIHRoZSBuZXcgWWFuZy1saWJyYXJ5IHN0cnVjdHVyZSwgIHRoZSBzY2hlbWEgZm9yICJjb252
ZW50aW9uYWwiIGRhdGEtc3RvcmVzIHNob3VsZCBub3QgaW5jbHVkZSB0aGUgbm9uLWNvbmZpZ3Vy
YWJsZSBZQU5HIG1vZHVsZS4gSXMgbXkgaW5mZXJlbmNlIGNvcnJlY3QgPw0KPiA+DQo+IA0KPiBB
IG1vZHVsZSB0aGF0IGhhcyBvbmx5IGNvbmZpZyBmYWxzZSBub2RlcyB3aWxsIG5vdCBhZGQgYW55
dGhpbmcgdG8gYSBjb252ZW50aW9uYWwgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUgYnV0IGl0IGlz
IG5vdCBhbiBlcnJvciBsaXN0IHN1Y2ggYSBtb2R1bGUuIEZvciBhIHNpbXBsZSBkZXZpY2VzLCBp
dCBtYXkgYmUgZGVzaXJhYmxlIHRvIGhhdmUganVzdCBvbmUgc2NoZW1hIHRoYXQgYXBwbGllcyB0
byBhbGwgZGF0YXN0b3Jlcy4gVGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgdG8gYnJlYWsgdGhpbmdz
IGFwYXJ0IGp1c3QgYmVjYXVzZSB0aGVyZSBpcyBhIG1vZHVsZSB0aGF0IGNvbnRyaWJ1dGVzIG9u
bHkgYW4gZW1wdHkgc2V0IHRvIGNvbnZlbnRpb25hbCBjb25maWd1cmF0aW9uIGRhdGFzdG9yZXMu
DQo+IA0KPiBOb3RlIHRoYXQgdGhlIGRlZmluZWQgdGVybSBpcyAnY29udmVudGlvbmFsIGNvbmZp
Z3VyYXRpb24gZGF0YXN0b3JlJw0KPiBhbmQgbm90ICdjb252ZW50aW9uYWwgZGF0YXN0b3JlJy4g
T29wcywgSSBzZWUgdGhhdCBpbiBvbmUgcGxhY2UgZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzc4OTVi
aXMtMDYudHh0IG1pc3NpbmcgdGhlICdjb25maWd1cmF0aW9uJyBwYXJ0IG9mIHRoZSB0ZXJtLiBU
aGF0IHNob3VsZCBiZSBmaXhlZC4NCj4gDQo+IE9MRA0KPiANCj4gICAgVGhlIHJlY29tbWVuZGVk
IGFwcHJvYWNoIHRvIHBvcHVsYXRlICIvbW9kdWxlcy1zdGF0ZSIgaXMgdG8gcmVwb3J0DQo+ICAg
IHRoZSBzY2hlbWEgZm9yIFlBTkcgbW9kdWxlcyB0aGF0IGFyZSBjb25maWd1cmFibGUgdmlhIGNv
bnZlbnRpb25hbA0KPiAgICBkYXRhc3RvcmVzIGFuZCBmb3Igd2hpY2ggY29uZmlnIGZhbHNlIGRh
dGEgbm9kZXMgYXJlIHJldHVybmVkIHZpYSBhDQo+ICAgIE5FVENPTkYgPGdldD4gb3BlcmF0aW9u
LCBvciBlcXVpdmFsZW50Lg0KPiANCj4gTkVXDQo+IA0KPiAgICBUaGUgcmVjb21tZW5kZWQgYXBw
cm9hY2ggdG8gcG9wdWxhdGUgIi9tb2R1bGVzLXN0YXRlIiBpcyB0byByZXBvcnQNCj4gICAgdGhl
IHNjaGVtYSBmb3IgWUFORyBtb2R1bGVzIHRoYXQgYXJlIGNvbmZpZ3VyYWJsZSB2aWEgY29udmVu
dGlvbmFsDQo+ICAgIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlcyBhbmQgZm9yIHdoaWNoIGNvbmZp
ZyBmYWxzZSBkYXRhIG5vZGVzIGFyZQ0KPiAgICByZXR1cm5lZCB2aWEgYSBORVRDT05GIDxnZXQ+
IG9wZXJhdGlvbiwgb3IgZXF1aXZhbGVudC4NCj4gDQo+IENvLWF1dGhvcnMsIGlmIHlvdSBhZ3Jl
ZSwgaG93IGRvIHdlIHRyYWNrIHRoaXM/DQo+IA0KPiAvanMNCj4gDQo+IC0tIA0KPiBKdWVyZ2Vu
IFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0K
PiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBC
cmVtZW4gfCBHZXJtYW55DQo+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBz
Oi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg0KLS0gDQpKdWVyZ2VuIFNjaG9lbndhZWxk
ZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KUGhvbmU6ICs0OSA0
MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFu
eQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVu
aXZlcnNpdHkuZGUvPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K


From nobody Tue May 29 22:21:48 2018
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 6B28612FA7C for ; Tue, 29 May 2018 22:21:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.19
X-Spam-Level: 
X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ej8kvdj8pC04 for ; Tue, 29 May 2018 22:21:44 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A6512F4CA for ; Tue, 29 May 2018 22:21:43 -0700 (PDT)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 7C3CD74A320A4 for ; Wed, 30 May 2018 06:21:37 +0100 (IST)
Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 30 May 2018 06:21:38 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.161]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0382.000; Wed, 30 May 2018 13:21:29 +0800
From: Rohit R Ranade 
To: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
Thread-Index: AdP3LxM2Qa00BJMETVeCiSY+xVpFu///grGA//9vcjCAAKFHAP/+R98Q
Date: Wed, 30 May 2018 05:21:29 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BBB2C11@dggeml510-mbx.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB23B2@dggeml510-mbx.china.huawei.com> <71e76c7e-4043-d80a-73ac-1759e85cc5d7@cisco.com> <991B70D8B4112A4699D5C00DDBBF878A6BBB241F@dggeml510-mbx.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BBB2C11dggeml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2018 05:21:47 -0000

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

Hi Robert,

An example has been shown in the "Appendix B.  Example YANG Library Instanc=
e for a Basic Server"

     
       config-schema
       config-modules
     
     
       state-schema
       config-modules
       state-modules
     

     
       ds:startup
       config-schema
     
     
       ds:running
       config-schema
     
     
       ds:operational
       state-schema
     

This example shows  having state-modules, but  has on=
ly configuration modules. This and introduction statement, convinced me the=
  and  will have different schema in a Basic server.

Also what does it mean that state-modules have been "implemented" in the  data-store ?

With Regards,
Rohit R Ranade

From: Robert Wilton [mailto:rwilton@cisco.com]
Sent: 29 May 2018 16:28
To: Rohit R Ranade ; netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query


Hi Rohit,

If you have a module, "mod-state-only", that only contains "config false" n=
odes then either of the following approaches is valid:

(1) You include the "mod-state-only" module in the schema for both conventi=
onal datastores and .  All config false leaves will be ignored=
 anyway for the configuration datastores.

(1) You define separate schema for the conventional datastores vs operation=
al.  "mod-state-only" isn't present in the schema for the conventional data=
stores, but is present in .

Either approach is valid, and I don't recall the YANG library bis draft sta=
ting any preference.

Thanks,
Rob

On 29/05/2018 11:44, Rohit R Ranade wrote:
Hi Robert,

The Introduction section has :
"
Furthermore, the operational state datastore may support non-configurable Y=
ANG modules in addition to
   the YANG modules supported by conventional configuration datastores.
"
I infer that in the new Yang-library structure,  the schema for "convention=
al" data-stores should not include the non-configurable YANG module. Is my =
inference correct ?

With Regards,
Rohit R Ranade
From: Robert Wilton [mailto:rwilton@cisco.com]
Sent: 29 May 2018 15:28
To: Rohit R Ranade ; netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query


Hi Rohit,

On 29/05/2018 10:35, Rohit R Ranade wrote:
Hi All,

Consider the below YANG tree, which contains both "rw" and "ro" nodes.

module: ietf-interfaces
    +--rw interfaces
    |  +--rw interface* [name]
    |     +--rw name                        string
    |     +--rw description?                string
    |     +--rw type                        identityref
    |     +--rw enabled?                    boolean
    |     +--rw link-up-down-trap-enable?   enumeration {if-mib}?
    |     +--ro admin-status                enumeration {if-mib}?
    |     +--ro oper-status                 enumeration
    |     +--ro last-change?                yang:date-and-time
    |     +--ro if-index                    int32 {if-mib}?
    |     +--ro phys-address?               yang:phys-address
    |     +--ro higher-layer-if*            interface-ref

>From what I understand, in the new yang-library structure the schema for  data-store will have the complete YANG tree. The schema for  will need to add deviations with "not-supported" for all the "ro" no=
des for this module ?
No need for the deviations for .   only contains the "con=
fig true" parts of the schema.

So, for a normal, NMDA compliant server, the same schema can be used for al=
l datastores.

Thanks,
Rob





With Regards,
Rohit R Ranade






_______________________________________________

netmod mailing list

netmod@ietf.org

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



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











Hi Robe=
rt,


&n=
bsp;


An exam=
ple has been shown in the “Appendix B.  Example =
YANG Library Instance for a Basic Server”


&n=
bsp;


     <schema>=



       <name>config-s=
chema</name>


       <module-set>co=
nfig-modules</module-set>


     </schema>


     <schema>=



       <name>state-sc=
hema</name>


       <module-set>co=
nfig-modules</module-set>


       <module-set>st=
ate-modules</module-set>


     </schema>


 


     <datastore>


       <name>ds:start=
up</name>


       <schema>config=
-schema</schema>


     </datastore>


     <datastore>


       <name>ds:runni=
ng</name>


       <schema>config=
-schema</schema>


     </datastore>


     <datastore>


       <name>ds:opera=
tional</name>


      
<schema>state-schema</schema>


     </datastore>


&n=
bsp;


This ex=
ample shows <operational> having state-modules, but <running> h=
as only configuration modules. This and introduction statement, convinced m=
e the <operational> and <running> will have different
 schema in a Basic server.


&n=
bsp;


Also wh=
at does it mean that state-modules have been “implemented” in t=
he <running> data-store ?



&n=
bsp;


With Re=
gards,




Rohit R=
 Ranade




&n=
bsp;






From: Robert Wilt=
on [mailto:rwilton@cisco.com]


Sent: 29 May 2018 16:28

To: Rohit R Ranade <rohitrranade@huawei.com>; netmod@ietf.org<=
br>
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation que=
ry






 


Hi Rohit,


If you have a module, "mod-state-only", t=
hat only contains "config false" nodes then either of the followi=
ng approaches is valid:


(1) You include the "mod-state-only" modu=
le in the schema for both conventional datastores and <operational>.&=
nbsp; All config false leaves will be ignored anyway for the configuration =
datastores.


(1) You define separate schema for the conventional=
 datastores vs operational.  "mod-state-only" isn't present =
in the schema for the conventional datastores, but is present in <operat=
ional>.


Either approach is valid, and I don't recall the YA=
NG library bis draft stating any preference.


Thanks,

Rob


 




On 29/05/2018 11:44, Rohit R Ra=
nade wrote:






Hi Robe=
rt,


 <=
/span>


The Int=
roduction section has :


“=



Furthermore, the operational state datastore may support =
non-configurable YANG modules in addition to


   the YANG modules supported by conventional c=
onfiguration datastores.


”=



I infer=
 that in the new Yang-library structure,  the schema for “conven=
tional” data-stores should not include the non-configurable YANG modu=
le. Is my inference correct ?



 <=
/span>


With Re=
gards,




Rohit R=
 Ranade








From: Robert Wilt=
on [mailto:rwilton@cisco.com]


Sent: 29 May 2018 15:28

To: Rohit R Ranade <ro=
hitrranade@huawei.com>;
netmod@ietf.org

Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation que=
ry






 


Hi Rohit,


 




On 29/05/2018 10:35, Rohit R Ra=
nade wrote:






Hi All,


 


Consider the below YANG tree, w=
hich contains both “rw” and “ro” nodes.<=
/span>


 


module: ietf-interfaces


    +--rw in=
terfaces


    |  +=
;--rw interface* [name]


    |  =
;   +--rw name        =
;            &n=
bsp;   string


    |  =
;   +--rw description?      &nb=
sp;         string


    |  =
;   +--rw type        =
;            &n=
bsp;   identityref


    |  =
;   +--rw enabled?       &=
nbsp;            boo=
lean


    |  =
;   +--rw link-up-down-trap-enable?   enumeration {=
if-mib}?


    |  =
;   +--ro admin-status      &nb=
sp;         enumeration {if-mib}?


    |  =
;   +--ro oper-status      &nbs=
p;          enumeration


    |  =
;   +--ro last-change?      &nb=
sp;         yang:date-and-time=



    |  =
;   +--ro if-index       &=
nbsp;            int=
32 {if-mib}?


    |  =
;   +--ro phys-address?      &n=
bsp;        yang:phys-address=



    |  =
;   +--ro higher-layer-if*      =
;      interface-ref


 


From what I understand, in the =
new yang-library structure the schema for <operational> data-store wi=
ll have the complete YANG tree. The schema for <running> will need to=
 add deviations with “not-supported” for all the
 “ro” nodes for this module ? 




No need for the deviations for <running>.  <r=
unning> only contains the "config true" parts of the schema.


So, for a normal, NMDA compliant server, the same schema can be used for al=
l datastores.



Thanks,

Rob














 


With Regards,=



Rohit R Ranade


 













_______________________________________________


netmod mailing list


netmod@ietf.or=
g


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



 




 






--_000_991B70D8B4112A4699D5C00DDBBF878A6BBB2C11dggeml510mbxchi_--


From nobody Tue May 29 22:34:17 2018
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 8C8C612EC3C for ; Tue, 29 May 2018 22:34:16 -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 NJdYnvLDuKug for ; Tue, 29 May 2018 22:34:14 -0700 (PDT)
Received: from anna.localdomain (firewallix.jacobs-university.de [212.201.44.247]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9D812EB7E for ; Tue, 29 May 2018 22:34:14 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id 2087921A09FD; Wed, 30 May 2018 07:34:11 +0200 (CEST)
Date: Wed, 30 May 2018 07:34:11 +0200
From: Juergen Schoenwaelder 
To: Qin Wu 
Cc: "netmod@ietf.org" 
Message-ID: <20180530053411.7scy2khghg75wlbz@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Qin Wu , "netmod@ietf.org" 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: NeoMutt/20180512
Archived-At: 
Subject: Re: [netmod] Status update on 
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2018 05:34:17 -0000

I think the title of the document is misleading. The convention for
expressing YANG in XML is called YIN, defined in RFC 7950. There are
other phrases that I find misleading, for example, Automatic
Generation of Valid XML From Examples. For me, the example is the XML
(or JSON) and what you call an example is the encoding of an XML in
the RFC format and what you define is an RFC format qencoding and a
decoding function. Perhaps it helps to properly define the terminology
you use and then to go through the document to make sure terms are
used consistently.

/js

On Wed, May 30, 2018 at 01:39:42AM +0000, Qin Wu wrote:
> Hi, WG:
> We have made an update Documentation Conventions for Expressing YANG in XML I-D based on last meeting discussion.
> The changes include:
> 1. Add JSON support.
> 2. Add objectives section 
> 3. Consolidate Mandatory Boilerplate for both leaf node and metadata annotation.
> 4. Move complex case to Appendix.
> 5. Better Align abstract and introduction section with objectives sections.
> The diff is:
> https://www.ietf.org/rfcdiff?url2=draft-wu-netmod-yang-xml-doc-conventions-01
> We believe the v-(01) address all the comments in last meeting and can serve a good basis to move to the next step.
> Thanks. Further Comments and suggestions are welcome.
> 
> -Qin
> -----邮件原件-----
> 发件人: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
> 发送时间: 2018年5月30日 9:17
> 收件人: Benoit Claise; Qin Wu; Adrian Farrel; Benoît Claise
> 主题: New Version Notification for draft-wu-netmod-yang-xml-doc-conventions-01.txt
> 
> 
> A new version of I-D, draft-wu-netmod-yang-xml-doc-conventions-01.txt
> has been successfully submitted by Qin Wu and posted to the IETF repository.
> 
> Name:		draft-wu-netmod-yang-xml-doc-conventions
> Revision:	01
> Title:		Documentation Conventions for Expressing YANG in XML
> Document date:	2018-05-29
> Group:		Individual Submission
> Pages:		10
> URL:            https://www.ietf.org/internet-drafts/draft-wu-netmod-yang-xml-doc-conventions-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-wu-netmod-yang-xml-doc-conventions/
> Htmlized:       https://tools.ietf.org/html/draft-wu-netmod-yang-xml-doc-conventions-01
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-wu-netmod-yang-xml-doc-conventions
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-wu-netmod-yang-xml-doc-conventions-01
> 
> Abstract:
>    Many documents that define YANG modules also include artwork examples
>    presented in XML/JSON.
> 
>    IETF documentation has specific limits on line length and some
>    artwork examples such as XML examples have to include line wraps that
>    would not normally be allowed according to the XML representation
>    rules of RFC7950 and RFC7952.The same applies to JSON.
> 
>    This document lays out documentation conventions that allow YANG
>    examples to be presented in IETF documentation when XML/JSON encoded
>    YANG data instance would otherwise exceed the maximum line length and
>    provide consistent XML/JSON encoded YANG data node instance example
>    within an Internet-Draft or RFC.  There are no implications in this
>    document for YANG parsers: this document does not change the rules
>    for presenting YANG models or for encoding YANG in data files or in
>    the wire.
> 
>                                                                                   
> 
> 
> 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.
> 
> The IETF Secretariat
> 
> _______________________________________________
> 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 Tue May 29 22:39:38 2018
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 CEB4C12EB51 for ; Tue, 29 May 2018 22:39:36 -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 NBYooaq6x8pn for ; Tue, 29 May 2018 22:39:35 -0700 (PDT)
Received: from anna.localdomain (anna.eecs.jacobs-university.de [IPv6:2001:638:709:5::7]) by ietfa.amsl.com (Postfix) with ESMTP id B0EBD12E8DF for ; Tue, 29 May 2018 22:39:34 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id 911F421A0A81; Wed, 30 May 2018 07:39:33 +0200 (CEST)
Date: Wed, 30 May 2018 07:39:33 +0200
From: Juergen Schoenwaelder 
To: Rohit R Ranade 
Cc: Robert Wilton , "netmod@ietf.org" 
Message-ID: <20180530053933.jvzkjgfnhxvhdmak@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Rohit R Ranade , Robert Wilton , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB23B2@dggeml510-mbx.china.huawei.com> <71e76c7e-4043-d80a-73ac-1759e85cc5d7@cisco.com> <991B70D8B4112A4699D5C00DDBBF878A6BBB241F@dggeml510-mbx.china.huawei.com>  <991B70D8B4112A4699D5C00DDBBF878A6BBB2C11@dggeml510-mbx.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BBB2C11@dggeml510-mbx.china.huawei.com>
User-Agent: NeoMutt/20180512
Archived-At: 
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2018 05:39:37 -0000

On Wed, May 30, 2018 at 05:21:29AM +0000, Rohit R Ranade wrote:
> 
> Also what does it mean that state-modules have been "implemented" in the  data-store ?
>

The server implemented an empty set of objects. No client should have
an issue with that and a server may choose to report this (for example
if the server wants to have a single schema for all datastores).

I do not see why making this illegal would simplify anything. It seems
making this illegal just adds complexity for no value.

/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 29 22:41:42 2018
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 9B79512ECBE for ; Tue, 29 May 2018 22:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1us7UbLuOsC4 for ; Tue, 29 May 2018 22:41:38 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0531D12F27D for ; Tue, 29 May 2018 22:41:38 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 25D1A20764F11; Wed, 30 May 2018 06:41:35 +0100 (IST)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 30 May 2018 06:41:35 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.193]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0382.000; Wed, 30 May 2018 13:41:31 +0800
From: Qin Wu 
To: Juergen Schoenwaelder 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] Status update on 
Thread-Index: AQHT97P2/JSg9j4OKEuGkK1Py+kz/KRHeJEA///Bl4CAAIeWAA==
Date: Wed, 30 May 2018 05:41:31 +0000
Message-ID: 
References:  <20180530053411.7scy2khghg75wlbz@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180530053411.7scy2khghg75wlbz@anna.jacobs.jacobs-university.de>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] Status update on 
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2018 05:41:41 -0000

R29vZCBwb2ludCwgd2Ugd2lsbCBmaXggdGVybWlub2xvZ2llcyBpc3N1ZXMgaW4gdGhlIG5leHQg
dXBkYXRlLiANClRoYW5rcywgSnVlcmdlbi4NCg0KLVFpbg0KLS0tLS3pgq7ku7bljp/ku7YtLS0t
LQ0K5Y+R5Lu25Lq6OiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgW21haWx0bzpqLnNjaG9lbndhZWxk
ZXJAamFjb2JzLXVuaXZlcnNpdHkuZGVdIA0K5Y+R6YCB5pe26Ze0OiAyMDE45bm0NeaciDMw5pel
IDEzOjM0DQrmlLbku7bkuro6IFFpbiBXdQ0K5oqE6YCBOiBuZXRtb2RAaWV0Zi5vcmcNCuS4u+mi
mDogUmU6IFtuZXRtb2RdIFN0YXR1cyB1cGRhdGUgb24gPGRyYWZ0LXd1LW5ldG1vZC15YW5nLXht
bC1kb2MtY29udmVudGlvbnMtMDE+DQoNCkkgdGhpbmsgdGhlIHRpdGxlIG9mIHRoZSBkb2N1bWVu
dCBpcyBtaXNsZWFkaW5nLiBUaGUgY29udmVudGlvbiBmb3IgZXhwcmVzc2luZyBZQU5HIGluIFhN
TCBpcyBjYWxsZWQgWUlOLCBkZWZpbmVkIGluIFJGQyA3OTUwLiBUaGVyZSBhcmUgb3RoZXIgcGhy
YXNlcyB0aGF0IEkgZmluZCBtaXNsZWFkaW5nLCBmb3IgZXhhbXBsZSwgQXV0b21hdGljIEdlbmVy
YXRpb24gb2YgVmFsaWQgWE1MIEZyb20gRXhhbXBsZXMuIEZvciBtZSwgdGhlIGV4YW1wbGUgaXMg
dGhlIFhNTCAob3IgSlNPTikgYW5kIHdoYXQgeW91IGNhbGwgYW4gZXhhbXBsZSBpcyB0aGUgZW5j
b2Rpbmcgb2YgYW4gWE1MIGluIHRoZSBSRkMgZm9ybWF0IGFuZCB3aGF0IHlvdSBkZWZpbmUgaXMg
YW4gUkZDIGZvcm1hdCBxZW5jb2RpbmcgYW5kIGEgZGVjb2RpbmcgZnVuY3Rpb24uIFBlcmhhcHMg
aXQgaGVscHMgdG8gcHJvcGVybHkgZGVmaW5lIHRoZSB0ZXJtaW5vbG9neSB5b3UgdXNlIGFuZCB0
aGVuIHRvIGdvIHRocm91Z2ggdGhlIGRvY3VtZW50IHRvIG1ha2Ugc3VyZSB0ZXJtcyBhcmUgdXNl
ZCBjb25zaXN0ZW50bHkuDQoNCi9qcw0KDQpPbiBXZWQsIE1heSAzMCwgMjAxOCBhdCAwMTozOTo0
MkFNICswMDAwLCBRaW4gV3Ugd3JvdGU6DQo+IEhpLCBXRzoNCj4gV2UgaGF2ZSBtYWRlIGFuIHVw
ZGF0ZSBEb2N1bWVudGF0aW9uIENvbnZlbnRpb25zIGZvciBFeHByZXNzaW5nIFlBTkcgaW4gWE1M
IEktRCBiYXNlZCBvbiBsYXN0IG1lZXRpbmcgZGlzY3Vzc2lvbi4NCj4gVGhlIGNoYW5nZXMgaW5j
bHVkZToNCj4gMS4gQWRkIEpTT04gc3VwcG9ydC4NCj4gMi4gQWRkIG9iamVjdGl2ZXMgc2VjdGlv
bg0KPiAzLiBDb25zb2xpZGF0ZSBNYW5kYXRvcnkgQm9pbGVycGxhdGUgZm9yIGJvdGggbGVhZiBu
b2RlIGFuZCBtZXRhZGF0YSBhbm5vdGF0aW9uLg0KPiA0LiBNb3ZlIGNvbXBsZXggY2FzZSB0byBB
cHBlbmRpeC4NCj4gNS4gQmV0dGVyIEFsaWduIGFic3RyYWN0IGFuZCBpbnRyb2R1Y3Rpb24gc2Vj
dGlvbiB3aXRoIG9iamVjdGl2ZXMgc2VjdGlvbnMuDQo+IFRoZSBkaWZmIGlzOg0KPiBodHRwczov
L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtd3UtbmV0bW9kLXlhbmcteG1sLWRvYy1j
b252ZW50DQo+IGlvbnMtMDEgV2UgYmVsaWV2ZSB0aGUgdi0oMDEpIGFkZHJlc3MgYWxsIHRoZSBj
b21tZW50cyBpbiBsYXN0IG1lZXRpbmcgDQo+IGFuZCBjYW4gc2VydmUgYSBnb29kIGJhc2lzIHRv
IG1vdmUgdG8gdGhlIG5leHQgc3RlcC4NCj4gVGhhbmtzLiBGdXJ0aGVyIENvbW1lbnRzIGFuZCBz
dWdnZXN0aW9ucyBhcmUgd2VsY29tZS4NCj4gDQo+IC1RaW4NCj4gLS0tLS3pgq7ku7bljp/ku7Yt
LS0tLQ0KPiDlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVy
bmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4g5Y+R6YCB5pe26Ze0OiAyMDE45bm0NeaciDMw5pelIDk6
MTcNCj4g5pS25Lu25Lq6OiBCZW5vaXQgQ2xhaXNlOyBRaW4gV3U7IEFkcmlhbiBGYXJyZWw7IEJl
bm/DrnQgQ2xhaXNlDQo+IOS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciANCj4g
ZHJhZnQtd3UtbmV0bW9kLXlhbmcteG1sLWRvYy1jb252ZW50aW9ucy0wMS50eHQNCj4gDQo+IA0K
PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd3UtbmV0bW9kLXlhbmcteG1sLWRvYy1jb252
ZW50aW9ucy0wMS50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBRaW4g
V3UgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KPiANCj4gTmFtZToJCWRyYWZ0
LXd1LW5ldG1vZC15YW5nLXhtbC1kb2MtY29udmVudGlvbnMNCj4gUmV2aXNpb246CTAxDQo+IFRp
dGxlOgkJRG9jdW1lbnRhdGlvbiBDb252ZW50aW9ucyBmb3IgRXhwcmVzc2luZyBZQU5HIGluIFhN
TA0KPiBEb2N1bWVudCBkYXRlOgkyMDE4LTA1LTI5DQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJt
aXNzaW9uDQo+IFBhZ2VzOgkJMTANCj4gVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYu
b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13dS1uZXRtb2QteWFuZy14bWwtZG9jLWNvbnZlbnRp
b25zLTAxLnR4dA0KPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y
Zy9kb2MvZHJhZnQtd3UtbmV0bW9kLXlhbmcteG1sLWRvYy1jb252ZW50aW9ucy8NCj4gSHRtbGl6
ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13dS1uZXRtb2QteWFu
Zy14bWwtZG9jLWNvbnZlbnRpb25zLTAxDQo+IEh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0
cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXd1LW5ldG1vZC15YW5nLXhtbC1kb2MtY29u
dmVudGlvbnMNCj4gRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/
dXJsMj1kcmFmdC13dS1uZXRtb2QteWFuZy14bWwtZG9jLWNvbnZlbnRpb25zLTAxDQo+IA0KPiBB
YnN0cmFjdDoNCj4gICAgTWFueSBkb2N1bWVudHMgdGhhdCBkZWZpbmUgWUFORyBtb2R1bGVzIGFs
c28gaW5jbHVkZSBhcnR3b3JrIGV4YW1wbGVzDQo+ICAgIHByZXNlbnRlZCBpbiBYTUwvSlNPTi4N
Cj4gDQo+ICAgIElFVEYgZG9jdW1lbnRhdGlvbiBoYXMgc3BlY2lmaWMgbGltaXRzIG9uIGxpbmUg
bGVuZ3RoIGFuZCBzb21lDQo+ICAgIGFydHdvcmsgZXhhbXBsZXMgc3VjaCBhcyBYTUwgZXhhbXBs
ZXMgaGF2ZSB0byBpbmNsdWRlIGxpbmUgd3JhcHMgdGhhdA0KPiAgICB3b3VsZCBub3Qgbm9ybWFs
bHkgYmUgYWxsb3dlZCBhY2NvcmRpbmcgdG8gdGhlIFhNTCByZXByZXNlbnRhdGlvbg0KPiAgICBy
dWxlcyBvZiBSRkM3OTUwIGFuZCBSRkM3OTUyLlRoZSBzYW1lIGFwcGxpZXMgdG8gSlNPTi4NCj4g
DQo+ICAgIFRoaXMgZG9jdW1lbnQgbGF5cyBvdXQgZG9jdW1lbnRhdGlvbiBjb252ZW50aW9ucyB0
aGF0IGFsbG93IFlBTkcNCj4gICAgZXhhbXBsZXMgdG8gYmUgcHJlc2VudGVkIGluIElFVEYgZG9j
dW1lbnRhdGlvbiB3aGVuIFhNTC9KU09OIGVuY29kZWQNCj4gICAgWUFORyBkYXRhIGluc3RhbmNl
IHdvdWxkIG90aGVyd2lzZSBleGNlZWQgdGhlIG1heGltdW0gbGluZSBsZW5ndGggYW5kDQo+ICAg
IHByb3ZpZGUgY29uc2lzdGVudCBYTUwvSlNPTiBlbmNvZGVkIFlBTkcgZGF0YSBub2RlIGluc3Rh
bmNlIGV4YW1wbGUNCj4gICAgd2l0aGluIGFuIEludGVybmV0LURyYWZ0IG9yIFJGQy4gIFRoZXJl
IGFyZSBubyBpbXBsaWNhdGlvbnMgaW4gdGhpcw0KPiAgICBkb2N1bWVudCBmb3IgWUFORyBwYXJz
ZXJzOiB0aGlzIGRvY3VtZW50IGRvZXMgbm90IGNoYW5nZSB0aGUgcnVsZXMNCj4gICAgZm9yIHBy
ZXNlbnRpbmcgWUFORyBtb2RlbHMgb3IgZm9yIGVuY29kaW5nIFlBTkcgaW4gZGF0YSBmaWxlcyBv
ciBpbg0KPiAgICB0aGUgd2lyZS4NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4g
DQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg
ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu
ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBUaGUgSUVURiBT
ZWNyZXRhcmlhdA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KLS0gDQpKdWVyZ2Vu
IFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0K
UGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJl
bWVuIHwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93
d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K


From nobody Tue May 29 22:53:17 2018
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 25BD8127241 for ; Tue, 29 May 2018 22:53:16 -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 yrDrWllY--A5 for ; Tue, 29 May 2018 22:53:14 -0700 (PDT)
Received: from anna.localdomain (firewallix.jacobs-university.de [212.201.44.247]) by ietfa.amsl.com (Postfix) with ESMTP id CDC4612D80F for ; Tue, 29 May 2018 22:53:13 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id 2FC8021A0BE5; Wed, 30 May 2018 07:53:12 +0200 (CEST)
Date: Wed, 30 May 2018 07:53:12 +0200
From: Juergen Schoenwaelder 
To: Qin Wu 
Cc: Rohit R Ranade , "netmod@ietf.org" 
Message-ID: <20180530055312.htsncty2eyt25wzg@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Qin Wu , Rohit R Ranade , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB23B2@dggeml510-mbx.china.huawei.com> <71e76c7e-4043-d80a-73ac-1759e85cc5d7@cisco.com> <991B70D8B4112A4699D5C00DDBBF878A6BBB241F@dggeml510-mbx.china.huawei.com> <20180529110610.4rcqvp7x4qpbg5hz@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BBB2484@dggeml510-mbx.china.huawei.com> <20180529120616.bxl4xyftqsvpsbxo@anna.jacobs.jacobs-university.de> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: NeoMutt/20180512
Archived-At: 
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2018 05:53:16 -0000

This is discussed in section 1 of draft-ietf-netconf-rfc7895bis-06.txt.

/js

On Wed, May 30, 2018 at 01:56:14AM +0000, Qin Wu wrote:
> Juergen:
> One stupid question I have is, What about the old client and server still support YANG 1.0 since RFC7895bis is designed to replaces RFC7895?
> Do we have transition stage before RFC7895bis takes effect?
> 
> -Qin
> -----邮件原件-----
> 发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Juergen Schoenwaelder
> 发送时间: 2018年5月29日 20:06
> 收件人: Rohit R Ranade
> 抄送: netmod@ietf.org
> 主题: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
> 
> Yes, this is why we have draft-ietf-netconf-rfc7895bis-06.txt.
> 
> /js
> 
> On Tue, May 29, 2018 at 11:27:42AM +0000, Rohit R Ranade wrote:
> > Hi Juergen,
> > 
> > Consider a device supports a dynamic data-store called "ephemeral". Consider Yang-library 1.1 is NOT implemented in device.
> > Consider device have 3 Modules ==> Module1 ,  Module2-state and 
> > Module3
> > 
> > Module1 : Supported in  and  Module2-state : 
> > Supported only in 
> > Module3 : Supported only in 
> > 
> > So here assumption is that Client knows he cannot do  on Module2-state as it has only read-only nodes.
> > But Client does not know the modules in ephemeral and depends on yang-library 1.1 to know whether an edit-data can be done on Module3 ?
> > 
> > Which modules are supported in which data-stores is not known to Client without Yang-library 1.1 ?
> > 
> > With Regards,
> > Rohit R Ranade
> > 
> > -----Original Message-----
> > From: Juergen Schoenwaelder 
> > [mailto:j.schoenwaelder@jacobs-university.de]
> > Sent: 29 May 2018 16:36
> > To: Rohit R Ranade 
> > Cc: Robert Wilton ; netmod@ietf.org
> > Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
> > 
> > On Tue, May 29, 2018 at 10:44:04AM +0000, Rohit R Ranade wrote:
> > > Hi Robert,
> > > 
> > > The Introduction section has :
> > > "
> > > Furthermore, the operational state datastore may support non-configurable YANG modules in addition to
> > >    the YANG modules supported by conventional configuration datastores.
> > > "
> > > I infer that in the new Yang-library structure,  the schema for "conventional" data-stores should not include the non-configurable YANG module. Is my inference correct ?
> > >
> > 
> > A module that has only config false nodes will not add anything to a conventional configuration datastore but it is not an error list such a module. For a simple devices, it may be desirable to have just one schema that applies to all datastores. There is no requirement to break things apart just because there is a module that contributes only an empty set to conventional configuration datastores.
> > 
> > Note that the defined term is 'conventional configuration datastore'
> > and not 'conventional datastore'. Oops, I see that in one place draft-ietf-netconf-rfc7895bis-06.txt missing the 'configuration' part of the term. That should be fixed.
> > 
> > OLD
> > 
> >    The recommended approach to populate "/modules-state" is to report
> >    the schema for YANG modules that are configurable via conventional
> >    datastores and for which config false data nodes are returned via a
> >    NETCONF  operation, or equivalent.
> > 
> > NEW
> > 
> >    The recommended approach to populate "/modules-state" is to report
> >    the schema for YANG modules that are configurable via conventional
> >    configuration datastores and for which config false data nodes are
> >    returned via a NETCONF  operation, or equivalent.
> > 
> > Co-authors, if you agree, how do we track this?
> > 
> > /js
> > 
> > -- 
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103         
> 
> -- 
> 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

-- 
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 29 22:59:37 2018
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 3BE9F12E04B for ; Tue, 29 May 2018 22:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHeDrvflCt08 for ; Tue, 29 May 2018 22:59:33 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB5A41201FA for ; Tue, 29 May 2018 22:59:32 -0700 (PDT)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 5E76BE759BEE3; Wed, 30 May 2018 06:59:28 +0100 (IST)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 30 May 2018 06:59:29 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.193]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0382.000; Wed, 30 May 2018 13:59:19 +0800
From: Qin Wu 
To: Juergen Schoenwaelder 
CC: Rohit R Ranade , "netmod@ietf.org" 
Thread-Topic: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
Thread-Index: AQHT9zOXH0Q7uD0JNkiP7Q3mI4ni1KRF/2gAgAAGLQCAAAYEAIAACscAgAFsZWD//720AIAAh2mQ
Date: Wed, 30 May 2018 05:59:19 +0000
Message-ID: 
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB23B2@dggeml510-mbx.china.huawei.com> <71e76c7e-4043-d80a-73ac-1759e85cc5d7@cisco.com> <991B70D8B4112A4699D5C00DDBBF878A6BBB241F@dggeml510-mbx.china.huawei.com> <20180529110610.4rcqvp7x4qpbg5hz@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BBB2484@dggeml510-mbx.china.huawei.com> <20180529120616.bxl4xyftqsvpsbxo@anna.jacobs.jacobs-university.de>  <20180530055312.htsncty2eyt25wzg@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180530055312.htsncty2eyt25wzg@anna.jacobs.jacobs-university.de>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2018 05:59:35 -0000

SSBmaW5kIGFuc3dlciBpbiAzcmQgcGFyYWdyYXBoIG9mIHNlY3Rpb24gMSwgdGhhbmtzIEp1ZXJn
ZW4gZm9yIGNsYXJpZmljYXRpb24sDQoNCi1RaW4NCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWP
keS7tuS6ujogSnVlcmdlbiBTY2hvZW53YWVsZGVyIFttYWlsdG86ai5zY2hvZW53YWVsZGVyQGph
Y29icy11bml2ZXJzaXR5LmRlXSANCuWPkemAgeaXtumXtDogMjAxOOW5tDXmnIgzMOaXpSAxMzo1
Mw0K5pS25Lu25Lq6OiBRaW4gV3UNCuaKhOmAgTogUm9oaXQgUiBSYW5hZGU7IG5ldG1vZEBpZXRm
Lm9yZw0K5Li76aKYOiBSZTogW25ldG1vZF0gZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzc4OTViaXMt
MDYgZGV2aWF0aW9uIHF1ZXJ5DQoNClRoaXMgaXMgZGlzY3Vzc2VkIGluIHNlY3Rpb24gMSBvZiBk
cmFmdC1pZXRmLW5ldGNvbmYtcmZjNzg5NWJpcy0wNi50eHQuDQoNCi9qcw0KDQpPbiBXZWQsIE1h
eSAzMCwgMjAxOCBhdCAwMTo1NjoxNEFNICswMDAwLCBRaW4gV3Ugd3JvdGU6DQo+IEp1ZXJnZW46
DQo+IE9uZSBzdHVwaWQgcXVlc3Rpb24gSSBoYXZlIGlzLCBXaGF0IGFib3V0IHRoZSBvbGQgY2xp
ZW50IGFuZCBzZXJ2ZXIgc3RpbGwgc3VwcG9ydCBZQU5HIDEuMCBzaW5jZSBSRkM3ODk1YmlzIGlz
IGRlc2lnbmVkIHRvIHJlcGxhY2VzIFJGQzc4OTU/DQo+IERvIHdlIGhhdmUgdHJhbnNpdGlvbiBz
dGFnZSBiZWZvcmUgUkZDNzg5NWJpcyB0YWtlcyBlZmZlY3Q/DQo+IA0KPiAtUWluDQo+IC0tLS0t
6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91
bmNlc0BpZXRmLm9yZ10g5Luj6KGoIEp1ZXJnZW4gU2Nob2Vud2FlbGRlcg0KPiDlj5HpgIHml7bp
l7Q6IDIwMTjlubQ15pyIMjnml6UgMjA6MDYNCj4g5pS25Lu25Lq6OiBSb2hpdCBSIFJhbmFkZQ0K
PiDmioTpgIE6IG5ldG1vZEBpZXRmLm9yZw0KPiDkuLvpopg6IFJlOiBbbmV0bW9kXSBkcmFmdC1p
ZXRmLW5ldGNvbmYtcmZjNzg5NWJpcy0wNiBkZXZpYXRpb24gcXVlcnkNCj4gDQo+IFllcywgdGhp
cyBpcyB3aHkgd2UgaGF2ZSBkcmFmdC1pZXRmLW5ldGNvbmYtcmZjNzg5NWJpcy0wNi50eHQuDQo+
IA0KPiAvanMNCj4gDQo+IE9uIFR1ZSwgTWF5IDI5LCAyMDE4IGF0IDExOjI3OjQyQU0gKzAwMDAs
IFJvaGl0IFIgUmFuYWRlIHdyb3RlOg0KPiA+IEhpIEp1ZXJnZW4sDQo+ID4gDQo+ID4gQ29uc2lk
ZXIgYSBkZXZpY2Ugc3VwcG9ydHMgYSBkeW5hbWljIGRhdGEtc3RvcmUgY2FsbGVkICJlcGhlbWVy
YWwiLiBDb25zaWRlciBZYW5nLWxpYnJhcnkgMS4xIGlzIE5PVCBpbXBsZW1lbnRlZCBpbiBkZXZp
Y2UuDQo+ID4gQ29uc2lkZXIgZGV2aWNlIGhhdmUgMyBNb2R1bGVzID09PiBNb2R1bGUxICwgIE1v
ZHVsZTItc3RhdGUgYW5kIA0KPiA+IE1vZHVsZTMNCj4gPiANCj4gPiBNb2R1bGUxIDogU3VwcG9y
dGVkIGluIDxydW5uaW5nPiBhbmQgPG9wZXJhdGlvbmFsPiBNb2R1bGUyLXN0YXRlIDogDQo+ID4g
U3VwcG9ydGVkIG9ubHkgaW4gPG9wZXJhdGlvbmFsPg0KPiA+IE1vZHVsZTMgOiBTdXBwb3J0ZWQg
b25seSBpbiA8ZXBoZW1lcmFsPg0KPiA+IA0KPiA+IFNvIGhlcmUgYXNzdW1wdGlvbiBpcyB0aGF0
IENsaWVudCBrbm93cyBoZSBjYW5ub3QgZG8gPGVkaXQtZGF0YT4gb24gTW9kdWxlMi1zdGF0ZSBh
cyBpdCBoYXMgb25seSByZWFkLW9ubHkgbm9kZXMuDQo+ID4gQnV0IENsaWVudCBkb2VzIG5vdCBr
bm93IHRoZSBtb2R1bGVzIGluIGVwaGVtZXJhbCBhbmQgZGVwZW5kcyBvbiB5YW5nLWxpYnJhcnkg
MS4xIHRvIGtub3cgd2hldGhlciBhbiBlZGl0LWRhdGEgY2FuIGJlIGRvbmUgb24gTW9kdWxlMyA/
DQo+ID4gDQo+ID4gV2hpY2ggbW9kdWxlcyBhcmUgc3VwcG9ydGVkIGluIHdoaWNoIGRhdGEtc3Rv
cmVzIGlzIG5vdCBrbm93biB0byBDbGllbnQgd2l0aG91dCBZYW5nLWxpYnJhcnkgMS4xID8NCj4g
PiANCj4gPiBXaXRoIFJlZ2FyZHMsDQo+ID4gUm9oaXQgUiBSYW5hZGUNCj4gPiANCj4gPiAtLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAN
Cj4gPiBbbWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZV0NCj4gPiBT
ZW50OiAyOSBNYXkgMjAxOCAxNjozNg0KPiA+IFRvOiBSb2hpdCBSIFJhbmFkZSA8cm9oaXRycmFu
YWRlQGh1YXdlaS5jb20+DQo+ID4gQ2M6IFJvYmVydCBXaWx0b24gPHJ3aWx0b25AY2lzY28uY29t
PjsgbmV0bW9kQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtuZXRtb2RdIGRyYWZ0LWlldGYt
bmV0Y29uZi1yZmM3ODk1YmlzLTA2IGRldmlhdGlvbiBxdWVyeQ0KPiA+IA0KPiA+IE9uIFR1ZSwg
TWF5IDI5LCAyMDE4IGF0IDEwOjQ0OjA0QU0gKzAwMDAsIFJvaGl0IFIgUmFuYWRlIHdyb3RlOg0K
PiA+ID4gSGkgUm9iZXJ0LA0KPiA+ID4gDQo+ID4gPiBUaGUgSW50cm9kdWN0aW9uIHNlY3Rpb24g
aGFzIDoNCj4gPiA+ICINCj4gPiA+IEZ1cnRoZXJtb3JlLCB0aGUgb3BlcmF0aW9uYWwgc3RhdGUg
ZGF0YXN0b3JlIG1heSBzdXBwb3J0IG5vbi1jb25maWd1cmFibGUgWUFORyBtb2R1bGVzIGluIGFk
ZGl0aW9uIHRvDQo+ID4gPiAgICB0aGUgWUFORyBtb2R1bGVzIHN1cHBvcnRlZCBieSBjb252ZW50
aW9uYWwgY29uZmlndXJhdGlvbiBkYXRhc3RvcmVzLg0KPiA+ID4gIg0KPiA+ID4gSSBpbmZlciB0
aGF0IGluIHRoZSBuZXcgWWFuZy1saWJyYXJ5IHN0cnVjdHVyZSwgIHRoZSBzY2hlbWEgZm9yICJj
b252ZW50aW9uYWwiIGRhdGEtc3RvcmVzIHNob3VsZCBub3QgaW5jbHVkZSB0aGUgbm9uLWNvbmZp
Z3VyYWJsZSBZQU5HIG1vZHVsZS4gSXMgbXkgaW5mZXJlbmNlIGNvcnJlY3QgPw0KPiA+ID4NCj4g
PiANCj4gPiBBIG1vZHVsZSB0aGF0IGhhcyBvbmx5IGNvbmZpZyBmYWxzZSBub2RlcyB3aWxsIG5v
dCBhZGQgYW55dGhpbmcgdG8gYSBjb252ZW50aW9uYWwgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUg
YnV0IGl0IGlzIG5vdCBhbiBlcnJvciBsaXN0IHN1Y2ggYSBtb2R1bGUuIEZvciBhIHNpbXBsZSBk
ZXZpY2VzLCBpdCBtYXkgYmUgZGVzaXJhYmxlIHRvIGhhdmUganVzdCBvbmUgc2NoZW1hIHRoYXQg
YXBwbGllcyB0byBhbGwgZGF0YXN0b3Jlcy4gVGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgdG8gYnJl
YWsgdGhpbmdzIGFwYXJ0IGp1c3QgYmVjYXVzZSB0aGVyZSBpcyBhIG1vZHVsZSB0aGF0IGNvbnRy
aWJ1dGVzIG9ubHkgYW4gZW1wdHkgc2V0IHRvIGNvbnZlbnRpb25hbCBjb25maWd1cmF0aW9uIGRh
dGFzdG9yZXMuDQo+ID4gDQo+ID4gTm90ZSB0aGF0IHRoZSBkZWZpbmVkIHRlcm0gaXMgJ2NvbnZl
bnRpb25hbCBjb25maWd1cmF0aW9uIGRhdGFzdG9yZScNCj4gPiBhbmQgbm90ICdjb252ZW50aW9u
YWwgZGF0YXN0b3JlJy4gT29wcywgSSBzZWUgdGhhdCBpbiBvbmUgcGxhY2UgZHJhZnQtaWV0Zi1u
ZXRjb25mLXJmYzc4OTViaXMtMDYudHh0IG1pc3NpbmcgdGhlICdjb25maWd1cmF0aW9uJyBwYXJ0
IG9mIHRoZSB0ZXJtLiBUaGF0IHNob3VsZCBiZSBmaXhlZC4NCj4gPiANCj4gPiBPTEQNCj4gPiAN
Cj4gPiAgICBUaGUgcmVjb21tZW5kZWQgYXBwcm9hY2ggdG8gcG9wdWxhdGUgIi9tb2R1bGVzLXN0
YXRlIiBpcyB0byByZXBvcnQNCj4gPiAgICB0aGUgc2NoZW1hIGZvciBZQU5HIG1vZHVsZXMgdGhh
dCBhcmUgY29uZmlndXJhYmxlIHZpYSBjb252ZW50aW9uYWwNCj4gPiAgICBkYXRhc3RvcmVzIGFu
ZCBmb3Igd2hpY2ggY29uZmlnIGZhbHNlIGRhdGEgbm9kZXMgYXJlIHJldHVybmVkIHZpYSBhDQo+
ID4gICAgTkVUQ09ORiA8Z2V0PiBvcGVyYXRpb24sIG9yIGVxdWl2YWxlbnQuDQo+ID4gDQo+ID4g
TkVXDQo+ID4gDQo+ID4gICAgVGhlIHJlY29tbWVuZGVkIGFwcHJvYWNoIHRvIHBvcHVsYXRlICIv
bW9kdWxlcy1zdGF0ZSIgaXMgdG8gcmVwb3J0DQo+ID4gICAgdGhlIHNjaGVtYSBmb3IgWUFORyBt
b2R1bGVzIHRoYXQgYXJlIGNvbmZpZ3VyYWJsZSB2aWEgY29udmVudGlvbmFsDQo+ID4gICAgY29u
ZmlndXJhdGlvbiBkYXRhc3RvcmVzIGFuZCBmb3Igd2hpY2ggY29uZmlnIGZhbHNlIGRhdGEgbm9k
ZXMgYXJlDQo+ID4gICAgcmV0dXJuZWQgdmlhIGEgTkVUQ09ORiA8Z2V0PiBvcGVyYXRpb24sIG9y
IGVxdWl2YWxlbnQuDQo+ID4gDQo+ID4gQ28tYXV0aG9ycywgaWYgeW91IGFncmVlLCBob3cgZG8g
d2UgdHJhY2sgdGhpcz8NCj4gPiANCj4gPiAvanMNCj4gPiANCj4gPiAtLSANCj4gPiBKdWVyZ2Vu
IFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0K
PiA+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5
IEJyZW1lbiB8IEdlcm1hbnkNCj4gPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxo
dHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo+IA0KPiAtLSANCj4gSnVlcmdlbiBT
Y2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4g
UGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJl
bWVuIHwgR2VybWFueQ0KPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczov
L3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1v
ZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v
ZA0KDQotLSANCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNp
dHkgQnJlbWVuIGdHbWJIDQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBS
aW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAg
ICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo=


From nobody Tue May 29 23:40:17 2018
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 3C6EE12EC7C for ; Tue, 29 May 2018 23:40:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvtuuNaA5ljQ for ; Tue, 29 May 2018 23:40:14 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E1DC12EC5C for ; Tue, 29 May 2018 23:40:14 -0700 (PDT)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 2CD8CA7F52839; Wed, 30 May 2018 07:40:11 +0100 (IST)
Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 30 May 2018 07:40:12 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.161]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0382.000; Wed, 30 May 2018 14:40:03 +0800
From: Rohit R Ranade 
To: Juergen Schoenwaelder 
CC: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
Thread-Index: AdP3LxM2Qa00BJMETVeCiSY+xVpFu///grGA//9vcjCAAKFHAP/+R98QgALxoID//3TFwA==
Date: Wed, 30 May 2018 06:40:02 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BBB2F8A@dggeml510-mbx.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB23B2@dggeml510-mbx.china.huawei.com> <71e76c7e-4043-d80a-73ac-1759e85cc5d7@cisco.com> <991B70D8B4112A4699D5C00DDBBF878A6BBB241F@dggeml510-mbx.china.huawei.com>  <991B70D8B4112A4699D5C00DDBBF878A6BBB2C11@dggeml510-mbx.china.huawei.com> <20180530053933.jvzkjgfnhxvhdmak@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180530053933.jvzkjgfnhxvhdmak@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2018 06:40:16 -0000

Hi Juergen,

My intention is only to get clarity about what is the meaning of implementi=
ng a module in a data-store, as it used in below places,

" It must be possible to NOT implement a module or feature in
       , even if it is implemented in some other datastore"

"   2.  A dynamic configuration datastore must be able to implement a
       module or feature that is not implemented in the conventional
       configuration datastores."

A module having only "ro" nodes , can be considered to be implemented in an=
y data-store ? operational/ephemeral etc
A module having "rw" nodes,  what is the rules for it to be considered impl=
emented in a data-store ?

RFC 7950 is quite clear for the rules for when a module is considered imple=
mented. Please clarify implementation with respect to data-store also.

With Regards,
Rohit R Ranade

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20
Sent: 30 May 2018 11:10
To: Rohit R Ranade 
Cc: Robert Wilton ; netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query

On Wed, May 30, 2018 at 05:21:29AM +0000, Rohit R Ranade wrote:
>=20
> Also what does it mean that state-modules have been "implemented" in the =
 data-store ?
>

The server implemented an empty set of objects. No client should have an is=
sue with that and a server may choose to report this (for example if the se=
rver wants to have a single schema for all datastores).

I do not see why making this illegal would simplify anything. It seems maki=
ng this illegal just adds complexity for no value.

/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 29 23:57:44 2018
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 D294F12EB54 for ; Tue, 29 May 2018 23:57:41 -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 O1yT-vZ3oSsZ for ; Tue, 29 May 2018 23:57:40 -0700 (PDT)
Received: from anna.localdomain (anna.eecs.jacobs-university.de [IPv6:2001:638:709:5::7]) by ietfa.amsl.com (Postfix) with ESMTP id 3556712EB31 for ; Tue, 29 May 2018 23:57:40 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id 7383421A0EB0; Wed, 30 May 2018 08:57:37 +0200 (CEST)
Date: Wed, 30 May 2018 08:57:37 +0200
From: Juergen Schoenwaelder 
To: Rohit R Ranade 
Cc: Robert Wilton , "netmod@ietf.org" 
Message-ID: <20180530065737.tkntrvzc2kulk6ex@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Rohit R Ranade , Robert Wilton , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB23B2@dggeml510-mbx.china.huawei.com> <71e76c7e-4043-d80a-73ac-1759e85cc5d7@cisco.com> <991B70D8B4112A4699D5C00DDBBF878A6BBB241F@dggeml510-mbx.china.huawei.com>  <991B70D8B4112A4699D5C00DDBBF878A6BBB2C11@dggeml510-mbx.china.huawei.com> <20180530053933.jvzkjgfnhxvhdmak@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BBB2F8A@dggeml510-mbx.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BBB2F8A@dggeml510-mbx.china.huawei.com>
User-Agent: NeoMutt/20180512
Archived-At: 
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2018 06:57:42 -0000

On Wed, May 30, 2018 at 06:40:02AM +0000, Rohit R Ranade wrote:

> A module having only "ro" nodes , can be considered to be implemented in any data-store ? operational/ephemeral etc

No.

> A module having "rw" nodes,  what is the rules for it to be considered implemented in a data-store ?

You implement the set of nodes that the datastore supports. In case of
a config false module and a conventional configuration datastore, this
set is empty.
 
> RFC 7950 is quite clear for the rules for when a module is considered implemented. Please clarify implementation with respect to data-store also.

I do not understand why this is unclear.

/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 30 02:38:22 2018
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 9A35D12DA3E for ; Wed, 30 May 2018 02:38:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjNk-EqXeGyA for ; Wed, 30 May 2018 02:38:19 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1AB7127735 for ; Wed, 30 May 2018 02:38:18 -0700 (PDT)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id AAF045D87950C; Wed, 30 May 2018 10:38:13 +0100 (IST)
Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 30 May 2018 10:38:14 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.161]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0382.000; Wed, 30 May 2018 17:38:06 +0800
From: Rohit R Ranade 
To: Juergen Schoenwaelder 
CC: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
Thread-Index: AdP3LxM2Qa00BJMETVeCiSY+xVpFu///grGA//9vcjCAAKFHAP/+R98QgALxoID//3TFwAAUIXOA//9PjeA=
Date: Wed, 30 May 2018 09:38:05 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BBB30EB@dggeml510-mbx.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB23B2@dggeml510-mbx.china.huawei.com> <71e76c7e-4043-d80a-73ac-1759e85cc5d7@cisco.com> <991B70D8B4112A4699D5C00DDBBF878A6BBB241F@dggeml510-mbx.china.huawei.com>  <991B70D8B4112A4699D5C00DDBBF878A6BBB2C11@dggeml510-mbx.china.huawei.com> <20180530053933.jvzkjgfnhxvhdmak@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BBB2F8A@dggeml510-mbx.china.huawei.com> <20180530065737.tkntrvzc2kulk6ex@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180530065737.tkntrvzc2kulk6ex@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2018 09:38:21 -0000

Hi Juergen,

Modules which define only notifications(ietf-netconf-notifications) will be=
 defined in  data-store ONLY. Right ?

With Regards,
Rohit R Ranade



-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20
Sent: 30 May 2018 12:28
To: Rohit R Ranade 
Cc: Robert Wilton ; netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query

On Wed, May 30, 2018 at 06:40:02AM +0000, Rohit R Ranade wrote:

> A module having only "ro" nodes , can be considered to be implemented=20
> in any data-store ? operational/ephemeral etc

No.

> A module having "rw" nodes,  what is the rules for it to be considered im=
plemented in a data-store ?

You implement the set of nodes that the datastore supports. In case of a co=
nfig false module and a conventional configuration datastore, this set is e=
mpty.
=20
> RFC 7950 is quite clear for the rules for when a module is considered imp=
lemented. Please clarify implementation with respect to data-store also.

I do not understand why this is unclear.

/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 Wed May 30 03:56:09 2018
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 A50FF12DA14 for ; Wed, 30 May 2018 03:56:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhr64t2c7C4p for ; Wed, 30 May 2018 03:56:04 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8B6512D77C for ; Wed, 30 May 2018 03:56:04 -0700 (PDT)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 43CA8E29163A1; Wed, 30 May 2018 11:55:58 +0100 (IST)
Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 30 May 2018 11:55:59 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.161]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0382.000; Wed, 30 May 2018 18:55:51 +0800
From: Rohit R Ranade 
To: Kent Watsen , Juergen Schoenwaelder 
CC: "netmod@ietf.org" 
Thread-Topic: Editorial  update [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
Thread-Index: AdP4BDPQDmkE0+JoTc2K8DtB9QQxmw==
Date: Wed, 30 May 2018 10:55:51 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BBB3189@dggeml510-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [netmod] Editorial update draft-ietf-netconf-rfc7895bis-06 deviation query
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2018 10:56:07 -0000

DQpPTEQNCg0KICAgVGhlIHJlY29tbWVuZGVkIGFwcHJvYWNoIHRvIHBvcHVsYXRlICIvbW9kdWxl
cy1zdGF0ZSIgaXMgdG8gcmVwb3J0DQogICB0aGUgc2NoZW1hIGZvciBZQU5HIG1vZHVsZXMgdGhh
dCBhcmUgY29uZmlndXJhYmxlIHZpYSBjb252ZW50aW9uYWwNCiAgIGRhdGFzdG9yZXMgYW5kIGZv
ciB3aGljaCBjb25maWcgZmFsc2UgZGF0YSBub2RlcyBhcmUgcmV0dXJuZWQgdmlhIGENCiAgIE5F
VENPTkYgPGdldD4gb3BlcmF0aW9uLCBvciBlcXVpdmFsZW50Lg0KDQpORVcNCg0KICAgVGhlIHJl
Y29tbWVuZGVkIGFwcHJvYWNoIHRvIHBvcHVsYXRlICIvbW9kdWxlcy1zdGF0ZSIgaXMgdG8gcmVw
b3J0DQogICB0aGUgc2NoZW1hIGZvciBZQU5HIG1vZHVsZXMgdGhhdCBhcmUgY29uZmlndXJhYmxl
IHZpYSBjb252ZW50aW9uYWwNCiAgIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlcyBhbmQgZm9yIHdo
aWNoIGNvbmZpZyBmYWxzZSBkYXRhIG5vZGVzIGFyZQ0KICAgcmV0dXJuZWQgdmlhIGEgTkVUQ09O
RiA8Z2V0PiBvcGVyYXRpb24sIG9yIGVxdWl2YWxlbnQuDQoNCltSb2hpdCBSIFJhbmFkZV0gSGVy
ZSB0aGUgbW9kdWxlcyB3aGljaCBhcmUgaW1wb3J0ZWQgb25seSBhbmQgdGhvc2UgbW9kdWxlcyB3
aGljaCBkZWZpbmUgb25seSBycGMgLyBub3RpZmljYXRpb25zIGFyZSBub3QgY29uc2lkZXJlZCA/
IEZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LCB0aGUgZXhpc3RpbmcgbW9kdWxlcyBzaG91bGQg
Y29udGludWUgdG8gYmUgc2hvd24gaW4gdGhlIGRlcHJlY2F0ZWQgbW9kdWxlLXN0YXRlLg0KDQpD
by1hdXRob3JzLCBpZiB5b3UgYWdyZWUsIGhvdyBkbyB3ZSB0cmFjayB0aGlzPw0KDQovanMNCg0K
LS0gDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJy
ZW1lbiBnR21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAx
IHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAg
ICA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193
d3cuamFjb2JzLTJEdW5pdmVyc2l0eS5kZV8mZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZo
MFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllh
R1R2aklTbGFKZGNabyZtPWZMLWltR0FzT0NtMHZNLVJEUk1raVJGVS01eDRkTGtLYTUtaEJPVTlJ
eXMmcz1qbXIwWTdtUkNlWDA1b3A0aDZCSUN5ajlVMGwwSWhuYk01eUJxaHRjTDRrJmU9Pg0KDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1h
aWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu
dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25l
dG1vZCZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pv
Q0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09ZkwtaW1H
QXNPQ20wdk0tUkRSTWtpUkZVLTV4NGRMa0thNS1oQk9VOUl5cyZzPWk0LWx3TWN0anVqQ19VaVpt
R080czgzLWp5S213N2piR3NTMGNMZkZaVDQmZT0NCg0KDQo=


From nobody Wed May 30 03:56:44 2018
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 8A85C12EBD4 for ; Wed, 30 May 2018 03:56:43 -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 DK7oNynhk5TO for ; Wed, 30 May 2018 03:56:42 -0700 (PDT)
Received: from anna.localdomain (firewallix.jacobs-university.de [212.201.44.247]) by ietfa.amsl.com (Postfix) with ESMTP id B5F1612DA14 for ; Wed, 30 May 2018 03:56:41 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id 1D60321A1D50; Wed, 30 May 2018 12:56:40 +0200 (CEST)
Date: Wed, 30 May 2018 12:56:40 +0200
From: Juergen Schoenwaelder 
To: Rohit R Ranade 
Cc: Robert Wilton , "netmod@ietf.org" 
Message-ID: <20180530105640.rwjsdkghb3lvyzqo@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Rohit R Ranade , Robert Wilton , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB23B2@dggeml510-mbx.china.huawei.com> <71e76c7e-4043-d80a-73ac-1759e85cc5d7@cisco.com> <991B70D8B4112A4699D5C00DDBBF878A6BBB241F@dggeml510-mbx.china.huawei.com>  <991B70D8B4112A4699D5C00DDBBF878A6BBB2C11@dggeml510-mbx.china.huawei.com> <20180530053933.jvzkjgfnhxvhdmak@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BBB2F8A@dggeml510-mbx.china.huawei.com> <20180530065737.tkntrvzc2kulk6ex@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BBB30EB@dggeml510-mbx.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BBB30EB@dggeml510-mbx.china.huawei.com>
User-Agent: NeoMutt/20180512
Archived-At: 
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2018 10:56:44 -0000

The phrase 'will be defined' is not good. Anyway, for a notification
nested in data tree, the data tree must exist in  and
the context in which XPath expressions are evaluated is ,
see section 6.1. of RFC 8342.

/js

On Wed, May 30, 2018 at 09:38:05AM +0000, Rohit R Ranade wrote:
> Hi Juergen,
> 
> Modules which define only notifications(ietf-netconf-notifications) will be defined in  data-store ONLY. Right ?
> 
> With Regards,
> Rohit R Ranade
> 
> 
> 
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] 
> Sent: 30 May 2018 12:28
> To: Rohit R Ranade 
> Cc: Robert Wilton ; netmod@ietf.org
> Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
> 
> On Wed, May 30, 2018 at 06:40:02AM +0000, Rohit R Ranade wrote:
> 
> > A module having only "ro" nodes , can be considered to be implemented 
> > in any data-store ? operational/ephemeral etc
> 
> No.
> 
> > A module having "rw" nodes,  what is the rules for it to be considered implemented in a data-store ?
> 
> You implement the set of nodes that the datastore supports. In case of a config false module and a conventional configuration datastore, this set is empty.
>  
> > RFC 7950 is quite clear for the rules for when a module is considered implemented. Please clarify implementation with respect to data-store also.
> 
> I do not understand why this is unclear.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

-- 
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 30 08:29:46 2018
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 DED2712E885 for ; Wed, 30 May 2018 08:29:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zd7e4unZirZ9 for ; Wed, 30 May 2018 08:29:43 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 DB9BB12E88D for ; Wed, 30 May 2018 08:29:42 -0700 (PDT)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4UFNrsh012213 for ; Wed, 30 May 2018 08:23:53 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=L6I58FIGM1JMfAPurGBJ4XJ7O5nbFBJKMmQioWxS1uk=; b=K1OiNYrEmbI9/7UcNUjo029vKrrsPRhqi7PGFzgmY2jFbx0dXrInOaTcMoGmAOa/4N17 379p4rcO6Z1gaXQxiEYZTubea1/vZjwcqpC83j0zllpG9ekhlksBeCNHD/cjmojB02Ou On9WsdmN7ckE6eJ41cTnCWKISN8ZHJj2ubMPzI2c9jMOrcIUR8xe6wtwt/ACSKtEU72E aXWzp4hMx0xdfEF3J1kGoUPBdzZ+ZnQHSxgw7VMeg6WzM/ARBnSAxawx/x3oTPuJUYvn BGUnVVb4X0baEQWl+k8B4WBlh60rq7TEFX/p8kZg31XBxhluOk5KK/x7MBeiJQaLY+Z1 Ag== 
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0118.outbound.protection.outlook.com [207.46.163.118]) by mx0b-00273201.pphosted.com with ESMTP id 2j9wv786kj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 30 May 2018 08:23:53 -0700
Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4168.namprd05.prod.outlook.com (52.135.200.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.5; Wed, 30 May 2018 15:23:51 +0000
Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::95f0:e564:96c8:7f1c]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::95f0:e564:96c8:7f1c%2]) with mapi id 15.20.0820.010; Wed, 30 May 2018 15:23:51 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: handling long lines in artwork in drafts
Thread-Index: AQHT+Co2VNmM6Shj6UGOYkb54PY8Vg==
Date: Wed, 30 May 2018 15:23:51 +0000
Message-ID: <62F8033D-F132-48B9-BDE5-900D27B0955D@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB4168; 7:vi+xN4dzUIeIBIUe9gWuMpovYMFo3EIj9+eKmo0V/GJ4+q+d6JPpbzA1vFfr9OEgNP99iJxu6vHOOT/BH2XFAUb0PmgxmeayDGFmHE7tKrvApLx7GfgAjYEgOLoTWO9+W2VCOe4Ee+tjhNcKmA7haWohINGD8puGRzhFT2LOM8ld0SB10UoBs5xrZv57+u18CH0HZNpfebUWu+HDLPhEvnvE5xKgrFJvrir7IzybUcv6Iqb2OnNsGoqV6qarofKl
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4168; 
x-ms-traffictypediagnostic: BYAPR05MB4168:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB4168; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4168; 
x-forefront-prvs: 0688BF9B46
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(346002)(39860400002)(396003)(366004)(376002)(199004)(189003)(6306002)(25786009)(2351001)(558084003)(3846002)(6116002)(486006)(6512007)(2616005)(476003)(53936002)(7736002)(26005)(81156014)(82746002)(66066001)(6506007)(186003)(102836004)(33656002)(966005)(305945005)(8936002)(14454004)(81166006)(1730700003)(2900100001)(68736007)(8676002)(478600001)(5250100002)(2501003)(3660700001)(5660300001)(83716003)(36756003)(105586002)(106356001)(99286004)(6916009)(2906002)(97736004)(6486002)(58126008)(86362001)(6436002)(3280700002)(5640700003)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4168; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 2NQGMTZ6qf9/DXTS//xSyPHWydr1F2wkSCccvl7s8GfbHWiN33q9XOhHihVJFEe13yX1U3/FTmFVaE2V7ET5xt30+ojC23JxH+g93kHk53s6PWdT8dNCT5loQmh07ra6SSK8ZewgwqubQE5ZahdPfFdht3615vFFq7kgRhbbCd2UBqykobjyb8AhLmBR2phs
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <3FA9BBB0BA4FB24CA974E0D4B46716FA@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 5cb3e261-e5ba-4ce3-be73-08d5c6415962
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 5cb3e261-e5ba-4ce3-be73-08d5c6415962
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 May 2018 15:23:51.7380 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4168
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-30_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1805300171
Archived-At: 
Subject: [netmod] handling long lines in artwork in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2018 15:29:45 -0000

DQpBcyB0aG9zZSBpbiBMb25kb24gcmVjYWxsLCBJIHN1Z2dlc3RlZCBhbiBhbHRlcm5hdGl2ZSBz
b2x1dGlvbiBmb3IgaGFuZGxpbmcgbG9uZyBsaW5lcyBpbiBhcnR3b3JrIGluIGRyYWZ0cy4gIEZX
SVcsIEkgaGF2ZSBjYXB0dXJlZCB0aGlzIGlkZWEgaW4gdGhlIGZvbGxvd2luZyBJLUQ6IA0KDQoJ
aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWt3YXRzZW4tbmV0bW9kLWFydHdvcmst
Zm9sZGluZy0wMA0KDQoNCktlbnQgLy8gY29udHJpYnV0b3INCg0KDQoNCg==


From nobody Wed May 30 20:06:18 2018
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 8E0AF12ECC9 for ; Wed, 30 May 2018 20:06:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mlB8U4KmMPv for ; Wed, 30 May 2018 20:06:15 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D30612FB30 for ; Wed, 30 May 2018 20:06:15 -0700 (PDT)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id B0299634C1C71 for ; Thu, 31 May 2018 04:06:09 +0100 (IST)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 31 May 2018 04:06:11 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.193]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0382.000; Thu, 31 May 2018 11:06:08 +0800
From: Qin Wu 
To: "netmod@ietf.org" 
Thread-Topic: New Version Notification for draft-wu-netmod-yang-xml-doc-conventions-02.txt
Thread-Index: AQHT+IsvCh1MgROGGUa2L2pDTrPwfaRJJVjw
Date: Thu, 31 May 2018 03:06:07 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-wu-netmod-yang-xml-doc-conventions-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2018 03:06:18 -0000

VGhhbmtzIEp1ZXJnZW4ncyBjb21tZW50cyBvbiBkcmFmdC13dS1uZXRtb2QteWFuZy14bWwtZG9j
LWNvbnZlbnRpb25zIA0KVGhlIHYtKDAyKSBoYXMgYmVlbiBwb3N0ZWQgdG8gYWRkcmVzcyBoaXMg
Y29tbWVudHMNCkluIHYtKDAyKSwgDQphLiBUaGUgdGl0bGUgaXMgY2hhbmdlZCBpbnRvICJEb2N1
bWVudGF0aW9uIENvbnZlbnRpb25zIGZvciBFeHByZXNzaW5nIA0KYi4gWE1MIGFuZCBKU09OIGVu
Y29kZWQgWUFORyBEYXRhIE5vZGUgSW5zdGFuY2UiDQpjLiBUaGUgdGVybWlub2xvZ2llcyBhcmUg
YWRkZWQgdG8gc2VjdGlvbiAyLCB0d28gbmV3IHRlcm1zIGFyZSBpbnRyb2R1Y2VkIGJhc2VkIG9u
IEp1ZXJnZW4ncyBzdWdnZXN0aW9uLg0KZC4gVGhlIHNlY3Rpb24gOCBoYXMgYmVlbiBjbGFyaWZp
ZWQgd2l0aCBzb21lIGFkZGl0aW9uYWwgdGV4dCBhbmQgdGVybXMgZGVmaW5lZC4NClRoZSBkaWZm
IGlzOg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXd1LW5ldG1vZC15
YW5nLXhtbC1kb2MtY29udmVudGlvbnMtMDINCg0KLVFpbg0KLS0tLS3pgq7ku7bljp/ku7YtLS0t
LQ0K5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1k
cmFmdHNAaWV0Zi5vcmddIA0K5Y+R6YCB5pe26Ze0OiAyMDE45bm0NeaciDMx5pelIDEwOjU4DQrm
lLbku7bkuro6IEJlbm9pdCBDbGFpc2U7IFFpbiBXdTsgQWRyaWFuIEZhcnJlbDsgQmVub8OudCBD
bGFpc2UNCuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13dS1uZXRt
b2QteWFuZy14bWwtZG9jLWNvbnZlbnRpb25zLTAyLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2Yg
SS1ELCBkcmFmdC13dS1uZXRtb2QteWFuZy14bWwtZG9jLWNvbnZlbnRpb25zLTAyLnR4dA0KaGFz
IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBRaW4gV3UgYW5kIHBvc3RlZCB0byB0aGUg
SUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtd3UtbmV0bW9kLXlhbmcteG1sLWRvYy1j
b252ZW50aW9ucw0KUmV2aXNpb246CTAyDQpUaXRsZToJCURvY3VtZW50YXRpb24gQ29udmVudGlv
bnMgZm9yIEV4cHJlc3NpbmcgWE1MIGFuZCBKU09OIGVuY29kZWQgWUFORyBEYXRhIE5vZGUgSW5z
dGFuY2UNCkRvY3VtZW50IGRhdGU6CTIwMTgtMDUtMzANCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJt
aXNzaW9uDQpQYWdlczoJCTExDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXd1LW5ldG1vZC15YW5nLXhtbC1kb2MtY29udmVudGlvbnMt
MDIudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv
ZHJhZnQtd3UtbmV0bW9kLXlhbmcteG1sLWRvYy1jb252ZW50aW9ucy8NCkh0bWxpemVkOiAgICAg
ICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3UtbmV0bW9kLXlhbmcteG1sLWRv
Yy1jb252ZW50aW9ucy0wMg0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0
Zi5vcmcvZG9jL2h0bWwvZHJhZnQtd3UtbmV0bW9kLXlhbmcteG1sLWRvYy1jb252ZW50aW9ucw0K
RGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC13
dS1uZXRtb2QteWFuZy14bWwtZG9jLWNvbnZlbnRpb25zLTAyDQoNCkFic3RyYWN0Og0KICAgTWFu
eSBkb2N1bWVudHMgdGhhdCBkZWZpbmUgWUFORyBtb2R1bGVzIGFsc28gaW5jbHVkZSBZQU5HIGRh
dGEgbm9kZQ0KICAgSW5zdGFuY2UgZXhhbXBsZXMgcHJlc2VudGVkIGluIFhNTC9KU09OLg0KDQog
ICBJRVRGIGRvY3VtZW50YXRpb24gaGFzIHNwZWNpZmljIGxpbWl0cyBvbiBsaW5lIGxlbmd0aCBh
bmQgc29tZSBZQU5HDQogICBkYXRhIG5vZGUgSW5zdGFuY2UgZXhhbXBsZXMgc3VjaCBhcyBYTUwg
ZXhhbXBsZXMgaGF2ZSB0byBpbmNsdWRlIGxpbmUNCiAgIHdyYXBzIHRoYXQgd291bGQgbm90IG5v
cm1hbGx5IGJlIGFsbG93ZWQgYWNjb3JkaW5nIHRvIHRoZSBYTUwNCiAgIHJlcHJlc2VudGF0aW9u
IHJ1bGVzIG9mIFJGQzc5NTAgYW5kIFJGQzc5NTIuVGhlIHNhbWUgYXBwbGllcyB0byBKU09OLg0K
DQogICBUaGlzIGRvY3VtZW50IGxheXMgb3V0IGRvY3VtZW50YXRpb24gY29udmVudGlvbnMgdGhh
dCBhbGxvdyBZQU5HDQogICBleGFtcGxlcyB0byBiZSBwcmVzZW50ZWQgaW4gSUVURiBkb2N1bWVu
dGF0aW9uIHdoZW4gWE1ML0pTT04gZW5jb2RlZA0KICAgWUFORyBkYXRhIGluc3RhbmNlIHdvdWxk
IG90aGVyd2lzZSBleGNlZWQgdGhlIG1heGltdW0gbGluZSBsZW5ndGggYW5kDQogICBwcm92aWRl
IGNvbnNpc3RlbnQgWE1ML0pTT04gZW5jb2RlZCBZQU5HIGRhdGEgbm9kZSBpbnN0YW5jZSBleGFt
cGxlDQogICB3aXRoaW4gYW4gSW50ZXJuZXQtRHJhZnQgb3IgUkZDLiAgVGhlcmUgYXJlIG5vIGlt
cGxpY2F0aW9ucyBpbiB0aGlzDQogICBkb2N1bWVudCBmb3IgWUFORyBwYXJzZXJzOiB0aGlzIGRv
Y3VtZW50IGRvZXMgbm90IGNoYW5nZSB0aGUgcnVsZXMNCiAgIGZvciBwcmVzZW50aW5nIFlBTkcg
bW9kZWxzIG9yIGZvciBlbmNvZGluZyBZQU5HIGluIGRhdGEgZmlsZXMgb3IgaW4NCiAgIHRoZSB3
aXJlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBp
dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lv
biB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv
b2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo=


From nobody Wed May 30 20:15:10 2018
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 C678F131709 for ; Wed, 30 May 2018 20:15:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oaz3g31DCMBt for ; Wed, 30 May 2018 20:15:07 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6E431316F5 for ; Wed, 30 May 2018 20:15:06 -0700 (PDT)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 2C36FBC74057C; Thu, 31 May 2018 04:15:02 +0100 (IST)
Received: from DGGEMM423-HUB.china.huawei.com (10.1.198.40) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 31 May 2018 04:15:02 +0100
Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.90]) by dggemm423-hub.china.huawei.com ([10.1.198.40]) with mapi id 14.03.0382.000; Thu, 31 May 2018 11:14:51 +0800
From: "dingxiaojian (A)" 
To: Juergen Schoenwaelder , Qin Wu 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] Status update on 
Thread-Index: AQHT97P2/JSg9j4OKEuGkK1Py+kz/KRHeJEA///Bl4CAAfFJcA==
Date: Thu, 31 May 2018 03:14:51 +0000
Message-ID: <3B110B81B721B940871EC78F107D848C010C6D95@DGGEMM506-MBS.china.huawei.com>
References:  <20180530053411.7scy2khghg75wlbz@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180530053411.7scy2khghg75wlbz@anna.jacobs.jacobs-university.de>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.134.134.227]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] Status update on 
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2018 03:15:09 -0000

QWdyZWUgd2l0aCBKdXJnZW4sIEkgdGhpbmsgd2hhdCBuZWVkIHRvIGJlIGVtcGhhc2l6ZWQgaXMg
aG93IG1hY2hpbmUgcGFyc2UgdGhlIGRhdGEgc2hvdWxkIG5vdCBiZSBjaGFuZ2VkLGluIGRyYWZ0
LXd1LW5ldG1vZC15YW5nLXhtbC1kb2MtY29udmVudGlvbnMsIHdoYXQgaXMgcmVxdWlyZWQgaXMg
YWRkaXRpb25hbCBlbmNvZGluZyBhbmQgZGVjb2RpbmcgbWVjaGFuaXNtIHRvIG1ha2UgZGF0YSBi
ZXR0ZXIgZml0IGludG8gUkZDIGFuZCBJLUQuDQoNClhpYW9qaWFuDQoNCi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQpGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9y
Z10gT24gQmVoYWxmIE9mIEp1ZXJnZW4gU2Nob2Vud2FlbGRlcg0KU2VudDogV2VkbmVzZGF5LCBN
YXkgMzAsIDIwMTggMTozNCBQTQ0KVG86IFFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29tPg0KQ2M6
IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIFN0YXR1cyB1cGRhdGUgb24g
PGRyYWZ0LXd1LW5ldG1vZC15YW5nLXhtbC1kb2MtY29udmVudGlvbnMtMDE+DQoNCkkgdGhpbmsg
dGhlIHRpdGxlIG9mIHRoZSBkb2N1bWVudCBpcyBtaXNsZWFkaW5nLiBUaGUgY29udmVudGlvbiBm
b3IgZXhwcmVzc2luZyBZQU5HIGluIFhNTCBpcyBjYWxsZWQgWUlOLCBkZWZpbmVkIGluIFJGQyA3
OTUwLiBUaGVyZSBhcmUgb3RoZXIgcGhyYXNlcyB0aGF0IEkgZmluZCBtaXNsZWFkaW5nLCBmb3Ig
ZXhhbXBsZSwgQXV0b21hdGljIEdlbmVyYXRpb24gb2YgVmFsaWQgWE1MIEZyb20gRXhhbXBsZXMu
IEZvciBtZSwgdGhlIGV4YW1wbGUgaXMgdGhlIFhNTCAob3IgSlNPTikgYW5kIHdoYXQgeW91IGNh
bGwgYW4gZXhhbXBsZSBpcyB0aGUgZW5jb2Rpbmcgb2YgYW4gWE1MIGluIHRoZSBSRkMgZm9ybWF0
IGFuZCB3aGF0IHlvdSBkZWZpbmUgaXMgYW4gUkZDIGZvcm1hdCBxZW5jb2RpbmcgYW5kIGEgZGVj
b2RpbmcgZnVuY3Rpb24uIFBlcmhhcHMgaXQgaGVscHMgdG8gcHJvcGVybHkgZGVmaW5lIHRoZSB0
ZXJtaW5vbG9neSB5b3UgdXNlIGFuZCB0aGVuIHRvIGdvIHRocm91Z2ggdGhlIGRvY3VtZW50IHRv
IG1ha2Ugc3VyZSB0ZXJtcyBhcmUgdXNlZCBjb25zaXN0ZW50bHkuDQoNCi9qcw0KDQpPbiBXZWQs
IE1heSAzMCwgMjAxOCBhdCAwMTozOTo0MkFNICswMDAwLCBRaW4gV3Ugd3JvdGU6DQo+IEhpLCBX
RzoNCj4gV2UgaGF2ZSBtYWRlIGFuIHVwZGF0ZSBEb2N1bWVudGF0aW9uIENvbnZlbnRpb25zIGZv
ciBFeHByZXNzaW5nIFlBTkcgaW4gWE1MIEktRCBiYXNlZCBvbiBsYXN0IG1lZXRpbmcgZGlzY3Vz
c2lvbi4NCj4gVGhlIGNoYW5nZXMgaW5jbHVkZToNCj4gMS4gQWRkIEpTT04gc3VwcG9ydC4NCj4g
Mi4gQWRkIG9iamVjdGl2ZXMgc2VjdGlvbg0KPiAzLiBDb25zb2xpZGF0ZSBNYW5kYXRvcnkgQm9p
bGVycGxhdGUgZm9yIGJvdGggbGVhZiBub2RlIGFuZCBtZXRhZGF0YSBhbm5vdGF0aW9uLg0KPiA0
LiBNb3ZlIGNvbXBsZXggY2FzZSB0byBBcHBlbmRpeC4NCj4gNS4gQmV0dGVyIEFsaWduIGFic3Ry
YWN0IGFuZCBpbnRyb2R1Y3Rpb24gc2VjdGlvbiB3aXRoIG9iamVjdGl2ZXMgc2VjdGlvbnMuDQo+
IFRoZSBkaWZmIGlzOg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt
d3UtbmV0bW9kLXlhbmcteG1sLWRvYy1jb252ZW50DQo+IGlvbnMtMDEgV2UgYmVsaWV2ZSB0aGUg
di0oMDEpIGFkZHJlc3MgYWxsIHRoZSBjb21tZW50cyBpbiBsYXN0IG1lZXRpbmcgDQo+IGFuZCBj
YW4gc2VydmUgYSBnb29kIGJhc2lzIHRvIG1vdmUgdG8gdGhlIG5leHQgc3RlcC4NCj4gVGhhbmtz
LiBGdXJ0aGVyIENvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgd2VsY29tZS4NCj4gDQo+IC1R
aW4NCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0
c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4g5Y+R6YCB5pe2
6Ze0OiAyMDE45bm0NeaciDMw5pelIDk6MTcNCj4g5pS25Lu25Lq6OiBCZW5vaXQgQ2xhaXNlOyBR
aW4gV3U7IEFkcmlhbiBGYXJyZWw7IEJlbm/DrnQgQ2xhaXNlDQo+IOS4u+mimDogTmV3IFZlcnNp
b24gTm90aWZpY2F0aW9uIGZvciANCj4gZHJhZnQtd3UtbmV0bW9kLXlhbmcteG1sLWRvYy1jb252
ZW50aW9ucy0wMS50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd3Ut
bmV0bW9kLXlhbmcteG1sLWRvYy1jb252ZW50aW9ucy0wMS50eHQNCj4gaGFzIGJlZW4gc3VjY2Vz
c2Z1bGx5IHN1Ym1pdHRlZCBieSBRaW4gV3UgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0
b3J5Lg0KPiANCj4gTmFtZToJCWRyYWZ0LXd1LW5ldG1vZC15YW5nLXhtbC1kb2MtY29udmVudGlv
bnMNCj4gUmV2aXNpb246CTAxDQo+IFRpdGxlOgkJRG9jdW1lbnRhdGlvbiBDb252ZW50aW9ucyBm
b3IgRXhwcmVzc2luZyBZQU5HIGluIFhNTA0KPiBEb2N1bWVudCBkYXRlOgkyMDE4LTA1LTI5DQo+
IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJMTANCj4gVVJMOiAgICAg
ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13dS1uZXRt
b2QteWFuZy14bWwtZG9jLWNvbnZlbnRpb25zLTAxLnR4dA0KPiBTdGF0dXM6ICAgICAgICAgaHR0
cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd3UtbmV0bW9kLXlhbmcteG1sLWRv
Yy1jb252ZW50aW9ucy8NCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC13dS1uZXRtb2QteWFuZy14bWwtZG9jLWNvbnZlbnRpb25zLTAxDQo+IEh0bWxp
emVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXd1
LW5ldG1vZC15YW5nLXhtbC1kb2MtY29udmVudGlvbnMNCj4gRGlmZjogICAgICAgICAgIGh0dHBz
Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC13dS1uZXRtb2QteWFuZy14bWwtZG9j
LWNvbnZlbnRpb25zLTAxDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgTWFueSBkb2N1bWVudHMgdGhh
dCBkZWZpbmUgWUFORyBtb2R1bGVzIGFsc28gaW5jbHVkZSBhcnR3b3JrIGV4YW1wbGVzDQo+ICAg
IHByZXNlbnRlZCBpbiBYTUwvSlNPTi4NCj4gDQo+ICAgIElFVEYgZG9jdW1lbnRhdGlvbiBoYXMg
c3BlY2lmaWMgbGltaXRzIG9uIGxpbmUgbGVuZ3RoIGFuZCBzb21lDQo+ICAgIGFydHdvcmsgZXhh
bXBsZXMgc3VjaCBhcyBYTUwgZXhhbXBsZXMgaGF2ZSB0byBpbmNsdWRlIGxpbmUgd3JhcHMgdGhh
dA0KPiAgICB3b3VsZCBub3Qgbm9ybWFsbHkgYmUgYWxsb3dlZCBhY2NvcmRpbmcgdG8gdGhlIFhN
TCByZXByZXNlbnRhdGlvbg0KPiAgICBydWxlcyBvZiBSRkM3OTUwIGFuZCBSRkM3OTUyLlRoZSBz
YW1lIGFwcGxpZXMgdG8gSlNPTi4NCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgbGF5cyBvdXQgZG9j
dW1lbnRhdGlvbiBjb252ZW50aW9ucyB0aGF0IGFsbG93IFlBTkcNCj4gICAgZXhhbXBsZXMgdG8g
YmUgcHJlc2VudGVkIGluIElFVEYgZG9jdW1lbnRhdGlvbiB3aGVuIFhNTC9KU09OIGVuY29kZWQN
Cj4gICAgWUFORyBkYXRhIGluc3RhbmNlIHdvdWxkIG90aGVyd2lzZSBleGNlZWQgdGhlIG1heGlt
dW0gbGluZSBsZW5ndGggYW5kDQo+ICAgIHByb3ZpZGUgY29uc2lzdGVudCBYTUwvSlNPTiBlbmNv
ZGVkIFlBTkcgZGF0YSBub2RlIGluc3RhbmNlIGV4YW1wbGUNCj4gICAgd2l0aGluIGFuIEludGVy
bmV0LURyYWZ0IG9yIFJGQy4gIFRoZXJlIGFyZSBubyBpbXBsaWNhdGlvbnMgaW4gdGhpcw0KPiAg
ICBkb2N1bWVudCBmb3IgWUFORyBwYXJzZXJzOiB0aGlzIGRvY3VtZW50IGRvZXMgbm90IGNoYW5n
ZSB0aGUgcnVsZXMNCj4gICAgZm9yIHByZXNlbnRpbmcgWUFORyBtb2RlbHMgb3IgZm9yIGVuY29k
aW5nIFlBTkcgaW4gZGF0YSBmaWxlcyBvciBpbg0KPiAgICB0aGUgd2lyZS4NCj4gDQo+ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0
YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGls
IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0
Zi5vcmcuDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiANCj4gX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0K
PiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9uZXRtb2QNCg0KLS0gDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBV
bml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBD
YW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAw
IDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxp
bmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL25ldG1vZA0K


From nobody Wed May 30 20:21:47 2018
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 2724A12EC03 for ; Wed, 30 May 2018 20:21:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b27lfPkHby_r for ; Wed, 30 May 2018 20:21:43 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 453691318A6 for ; Wed, 30 May 2018 20:21:41 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id D7A3B25932DFF; Thu, 31 May 2018 04:21:37 +0100 (IST)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 31 May 2018 04:21:39 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.193]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0382.000; Thu, 31 May 2018 11:21:28 +0800
From: Qin Wu 
To: "dingxiaojian (A)" , Juergen Schoenwaelder 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] Status update on 
Thread-Index: AQHT97P2/JSg9j4OKEuGkK1Py+kz/KRHeJEA///Bl4CAAfFJcIAAAE+A
Date: Thu, 31 May 2018 03:21:27 +0000
Message-ID: 
References:  <20180530053411.7scy2khghg75wlbz@anna.jacobs.jacobs-university.de> <3B110B81B721B940871EC78F107D848C010C6D95@DGGEMM506-MBS.china.huawei.com>
In-Reply-To: <3B110B81B721B940871EC78F107D848C010C6D95@DGGEMM506-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] Status update on 
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2018 03:21:46 -0000

VGhpcyBpcyBleGFjdGx5IHdoYXQgd2UgcHJvcG9zZWQgaW4gdi0oMDIpICwgDQpodHRwczovL3d3
dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtd3UtbmV0bW9kLXlhbmcteG1sLWRvYy1jb252
ZW50aW9ucy0wMg0KDQpSZWdhcmRpbmcgbWFjaGluZSBwYXJzaW5nIGRhdGEsIHBsZWFzZSBzZWUg
bGFzdCBwYXJhZ3JhcGggb2YgYWJzdHJhY3Q6DQoiDQogICBUaGVyZSBhcmUgbm8gaW1wbGljYXRp
b25zIGluIHRoaXMNCiAgIGRvY3VtZW50IGZvciBZQU5HIHBhcnNlcnM6IHRoaXMgZG9jdW1lbnQg
ZG9lcyBub3QgY2hhbmdlIHRoZSBydWxlcw0KICAgZm9yIHByZXNlbnRpbmcgWUFORyBtb2RlbHMg
b3IgZm9yIGVuY29kaW5nIFlBTkcgaW4gZGF0YSBmaWxlcyBvciBpbg0KICAgdGhlIHdpcmUuDQoi
DQpUaGlzIGhhcyBhbHJlYWR5IGJlZW4gaGlnaGxpZ2h0ZWQgaW4gdi0oMDApLg0KDQotUWluDQot
LS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IGRpbmd4aWFvamlhbiAoQSkgDQrlj5Hp
gIHml7bpl7Q6IDIwMTjlubQ15pyIMzHml6UgMTE6MTUNCuaUtuS7tuS6ujogSnVlcmdlbiBTY2hv
ZW53YWVsZGVyOyBRaW4gV3UNCuaKhOmAgTogbmV0bW9kQGlldGYub3JnDQrkuLvpopg6IFJFOiBb
bmV0bW9kXSBTdGF0dXMgdXBkYXRlIG9uIDxkcmFmdC13dS1uZXRtb2QteWFuZy14bWwtZG9jLWNv
bnZlbnRpb25zLTAxPg0KDQpBZ3JlZSB3aXRoIEp1cmdlbiwgSSB0aGluayB3aGF0IG5lZWQgdG8g
YmUgZW1waGFzaXplZCBpcyBob3cgbWFjaGluZSBwYXJzZSB0aGUgZGF0YSBzaG91bGQgbm90IGJl
IGNoYW5nZWQsaW4gZHJhZnQtd3UtbmV0bW9kLXlhbmcteG1sLWRvYy1jb252ZW50aW9ucywgd2hh
dCBpcyByZXF1aXJlZCBpcyBhZGRpdGlvbmFsIGVuY29kaW5nIGFuZCBkZWNvZGluZyBtZWNoYW5p
c20gdG8gbWFrZSBkYXRhIGJldHRlciBmaXQgaW50byBSRkMgYW5kIEktRC4NCg0KWGlhb2ppYW4N
Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG5ldG1vZCBbbWFpbHRvOm5ldG1v
ZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVlcmdlbiBTY2hvZW53YWVsZGVyDQpT
ZW50OiBXZWRuZXNkYXksIE1heSAzMCwgMjAxOCAxOjM0IFBNDQpUbzogUWluIFd1IDxiaWxsLnd1
QGh1YXdlaS5jb20+DQpDYzogbmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25ldG1vZF0g
U3RhdHVzIHVwZGF0ZSBvbiA8ZHJhZnQtd3UtbmV0bW9kLXlhbmcteG1sLWRvYy1jb252ZW50aW9u
cy0wMT4NCg0KSSB0aGluayB0aGUgdGl0bGUgb2YgdGhlIGRvY3VtZW50IGlzIG1pc2xlYWRpbmcu
IFRoZSBjb252ZW50aW9uIGZvciBleHByZXNzaW5nIFlBTkcgaW4gWE1MIGlzIGNhbGxlZCBZSU4s
IGRlZmluZWQgaW4gUkZDIDc5NTAuIFRoZXJlIGFyZSBvdGhlciBwaHJhc2VzIHRoYXQgSSBmaW5k
IG1pc2xlYWRpbmcsIGZvciBleGFtcGxlLCBBdXRvbWF0aWMgR2VuZXJhdGlvbiBvZiBWYWxpZCBY
TUwgRnJvbSBFeGFtcGxlcy4gRm9yIG1lLCB0aGUgZXhhbXBsZSBpcyB0aGUgWE1MIChvciBKU09O
KSBhbmQgd2hhdCB5b3UgY2FsbCBhbiBleGFtcGxlIGlzIHRoZSBlbmNvZGluZyBvZiBhbiBYTUwg
aW4gdGhlIFJGQyBmb3JtYXQgYW5kIHdoYXQgeW91IGRlZmluZSBpcyBhbiBSRkMgZm9ybWF0IHFl
bmNvZGluZyBhbmQgYSBkZWNvZGluZyBmdW5jdGlvbi4gUGVyaGFwcyBpdCBoZWxwcyB0byBwcm9w
ZXJseSBkZWZpbmUgdGhlIHRlcm1pbm9sb2d5IHlvdSB1c2UgYW5kIHRoZW4gdG8gZ28gdGhyb3Vn
aCB0aGUgZG9jdW1lbnQgdG8gbWFrZSBzdXJlIHRlcm1zIGFyZSB1c2VkIGNvbnNpc3RlbnRseS4N
Cg0KL2pzDQoNCk9uIFdlZCwgTWF5IDMwLCAyMDE4IGF0IDAxOjM5OjQyQU0gKzAwMDAsIFFpbiBX
dSB3cm90ZToNCj4gSGksIFdHOg0KPiBXZSBoYXZlIG1hZGUgYW4gdXBkYXRlIERvY3VtZW50YXRp
b24gQ29udmVudGlvbnMgZm9yIEV4cHJlc3NpbmcgWUFORyBpbiBYTUwgSS1EIGJhc2VkIG9uIGxh
c3QgbWVldGluZyBkaXNjdXNzaW9uLg0KPiBUaGUgY2hhbmdlcyBpbmNsdWRlOg0KPiAxLiBBZGQg
SlNPTiBzdXBwb3J0Lg0KPiAyLiBBZGQgb2JqZWN0aXZlcyBzZWN0aW9uDQo+IDMuIENvbnNvbGlk
YXRlIE1hbmRhdG9yeSBCb2lsZXJwbGF0ZSBmb3IgYm90aCBsZWFmIG5vZGUgYW5kIG1ldGFkYXRh
IGFubm90YXRpb24uDQo+IDQuIE1vdmUgY29tcGxleCBjYXNlIHRvIEFwcGVuZGl4Lg0KPiA1LiBC
ZXR0ZXIgQWxpZ24gYWJzdHJhY3QgYW5kIGludHJvZHVjdGlvbiBzZWN0aW9uIHdpdGggb2JqZWN0
aXZlcyBzZWN0aW9ucy4NCj4gVGhlIGRpZmYgaXM6DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL3Jm
Y2RpZmY/dXJsMj1kcmFmdC13dS1uZXRtb2QteWFuZy14bWwtZG9jLWNvbnZlbnQNCj4gaW9ucy0w
MSBXZSBiZWxpZXZlIHRoZSB2LSgwMSkgYWRkcmVzcyBhbGwgdGhlIGNvbW1lbnRzIGluIGxhc3Qg
bWVldGluZyANCj4gYW5kIGNhbiBzZXJ2ZSBhIGdvb2QgYmFzaXMgdG8gbW92ZSB0byB0aGUgbmV4
dCBzdGVwLg0KPiBUaGFua3MuIEZ1cnRoZXIgQ29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3
ZWxjb21lLg0KPiANCj4gLVFpbg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6
ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu
b3JnXQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTjlubQ15pyIMzDml6UgOToxNw0KPiDmlLbku7bkuro6
IEJlbm9pdCBDbGFpc2U7IFFpbiBXdTsgQWRyaWFuIEZhcnJlbDsgQmVub8OudCBDbGFpc2UNCj4g
5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+IGRyYWZ0LXd1LW5ldG1vZC15
YW5nLXhtbC1kb2MtY29udmVudGlvbnMtMDEudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBv
ZiBJLUQsIGRyYWZ0LXd1LW5ldG1vZC15YW5nLXhtbC1kb2MtY29udmVudGlvbnMtMDEudHh0DQo+
IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUWluIFd1IGFuZCBwb3N0ZWQgdG8g
dGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC13dS1uZXRtb2QteWFuZy14
bWwtZG9jLWNvbnZlbnRpb25zDQo+IFJldmlzaW9uOgkwMQ0KPiBUaXRsZToJCURvY3VtZW50YXRp
b24gQ29udmVudGlvbnMgZm9yIEV4cHJlc3NpbmcgWUFORyBpbiBYTUwNCj4gRG9jdW1lbnQgZGF0
ZToJMjAxOC0wNS0yOQ0KPiBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBQYWdlczoJ
CTEwDQo+IFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm
dHMvZHJhZnQtd3UtbmV0bW9kLXlhbmcteG1sLWRvYy1jb252ZW50aW9ucy0wMS50eHQNCj4gU3Rh
dHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXd1LW5l
dG1vZC15YW5nLXhtbC1kb2MtY29udmVudGlvbnMvDQo+IEh0bWxpemVkOiAgICAgICBodHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3UtbmV0bW9kLXlhbmcteG1sLWRvYy1jb252ZW50
aW9ucy0wMQ0KPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k
b2MvaHRtbC9kcmFmdC13dS1uZXRtb2QteWFuZy14bWwtZG9jLWNvbnZlbnRpb25zDQo+IERpZmY6
ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtd3UtbmV0
bW9kLXlhbmcteG1sLWRvYy1jb252ZW50aW9ucy0wMQ0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIE1h
bnkgZG9jdW1lbnRzIHRoYXQgZGVmaW5lIFlBTkcgbW9kdWxlcyBhbHNvIGluY2x1ZGUgYXJ0d29y
ayBleGFtcGxlcw0KPiAgICBwcmVzZW50ZWQgaW4gWE1ML0pTT04uDQo+IA0KPiAgICBJRVRGIGRv
Y3VtZW50YXRpb24gaGFzIHNwZWNpZmljIGxpbWl0cyBvbiBsaW5lIGxlbmd0aCBhbmQgc29tZQ0K
PiAgICBhcnR3b3JrIGV4YW1wbGVzIHN1Y2ggYXMgWE1MIGV4YW1wbGVzIGhhdmUgdG8gaW5jbHVk
ZSBsaW5lIHdyYXBzIHRoYXQNCj4gICAgd291bGQgbm90IG5vcm1hbGx5IGJlIGFsbG93ZWQgYWNj
b3JkaW5nIHRvIHRoZSBYTUwgcmVwcmVzZW50YXRpb24NCj4gICAgcnVsZXMgb2YgUkZDNzk1MCBh
bmQgUkZDNzk1Mi5UaGUgc2FtZSBhcHBsaWVzIHRvIEpTT04uDQo+IA0KPiAgICBUaGlzIGRvY3Vt
ZW50IGxheXMgb3V0IGRvY3VtZW50YXRpb24gY29udmVudGlvbnMgdGhhdCBhbGxvdyBZQU5HDQo+
ICAgIGV4YW1wbGVzIHRvIGJlIHByZXNlbnRlZCBpbiBJRVRGIGRvY3VtZW50YXRpb24gd2hlbiBY
TUwvSlNPTiBlbmNvZGVkDQo+ICAgIFlBTkcgZGF0YSBpbnN0YW5jZSB3b3VsZCBvdGhlcndpc2Ug
ZXhjZWVkIHRoZSBtYXhpbXVtIGxpbmUgbGVuZ3RoIGFuZA0KPiAgICBwcm92aWRlIGNvbnNpc3Rl
bnQgWE1ML0pTT04gZW5jb2RlZCBZQU5HIGRhdGEgbm9kZSBpbnN0YW5jZSBleGFtcGxlDQo+ICAg
IHdpdGhpbiBhbiBJbnRlcm5ldC1EcmFmdCBvciBSRkMuICBUaGVyZSBhcmUgbm8gaW1wbGljYXRp
b25zIGluIHRoaXMNCj4gICAgZG9jdW1lbnQgZm9yIFlBTkcgcGFyc2VyczogdGhpcyBkb2N1bWVu
dCBkb2VzIG5vdCBjaGFuZ2UgdGhlIHJ1bGVzDQo+ICAgIGZvciBwcmVzZW50aW5nIFlBTkcgbW9k
ZWxzIG9yIGZvciBlbmNvZGluZyBZQU5HIGluIGRhdGEgZmlsZXMgb3IgaW4NCj4gICAgdGhlIHdp
cmUuDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+IA0KPiANCj4gUGxlYXNlIG5v
dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg
c3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh
YmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gDQo+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldG1v
ZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCi0tIA0KSnVlcmdlbiBTY2hvZW53YWVsZGVyICAg
ICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNClBob25lOiArNDkgNDIxIDIw
MCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCkZh
eDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vd3d3LmphY29icy11bml2ZXJz
aXR5LmRlLz4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg==


From nobody Wed May 30 21:55:35 2018
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 DD3CB12EB7C for ; Wed, 30 May 2018 21:55:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3B4aK-onF6kc for ; Wed, 30 May 2018 21:55:23 -0700 (PDT)
Received: from anna.localdomain (firewallix.jacobs-university.de [212.201.44.247]) by ietfa.amsl.com (Postfix) with ESMTP id C67DC12EB2F for ; Wed, 30 May 2018 21:55:22 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id 1ACF921C0C62; Thu, 31 May 2018 06:55:21 +0200 (CEST)
Date: Thu, 31 May 2018 06:55:21 +0200
From: Juergen Schoenwaelder 
To: Qin Wu 
Cc: "dingxiaojian (A)" , "netmod@ietf.org" 
Message-ID: <20180531045521.4qfpeqjvyteywek2@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Qin Wu , "dingxiaojian (A)" , "netmod@ietf.org" 
References:  <20180530053411.7scy2khghg75wlbz@anna.jacobs.jacobs-university.de> <3B110B81B721B940871EC78F107D848C010C6D95@DGGEMM506-MBS.china.huawei.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: NeoMutt/20180512
Archived-At: 
Subject: Re: [netmod] Status update on 
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2018 04:55:26 -0000

What is a 'YANG parser'? For me, a YANG parser is something that parses
YANG, i.e., not an XML or JSON parser.

/js

On Thu, May 31, 2018 at 03:21:27AM +0000, Qin Wu wrote:
> This is exactly what we proposed in v-(02) , 
> https://www.ietf.org/rfcdiff?url2=draft-wu-netmod-yang-xml-doc-conventions-02
> 
> Regarding machine parsing data, please see last paragraph of abstract:
> "
>    There are no implications in this
>    document for YANG parsers: this document does not change the rules
>    for presenting YANG models or for encoding YANG in data files or in
>    the wire.
> "
> This has already been highlighted in v-(00).
> 
> -Qin
> -----邮件原件-----
> 发件人: dingxiaojian (A) 
> 发送时间: 2018年5月31日 11:15
> 收件人: Juergen Schoenwaelder; Qin Wu
> 抄送: netmod@ietf.org
> 主题: RE: [netmod] Status update on 
> 
> Agree with Jurgen, I think what need to be emphasized is how machine parse the data should not be changed,in draft-wu-netmod-yang-xml-doc-conventions, what is required is additional encoding and decoding mechanism to make data better fit into RFC and I-D.
> 
> Xiaojian
> 
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder
> Sent: Wednesday, May 30, 2018 1:34 PM
> To: Qin Wu 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Status update on 
> 
> I think the title of the document is misleading. The convention for expressing YANG in XML is called YIN, defined in RFC 7950. There are other phrases that I find misleading, for example, Automatic Generation of Valid XML From Examples. For me, the example is the XML (or JSON) and what you call an example is the encoding of an XML in the RFC format and what you define is an RFC format qencoding and a decoding function. Perhaps it helps to properly define the terminology you use and then to go through the document to make sure terms are used consistently.
> 
> /js
> 
> On Wed, May 30, 2018 at 01:39:42AM +0000, Qin Wu wrote:
> > Hi, WG:
> > We have made an update Documentation Conventions for Expressing YANG in XML I-D based on last meeting discussion.
> > The changes include:
> > 1. Add JSON support.
> > 2. Add objectives section
> > 3. Consolidate Mandatory Boilerplate for both leaf node and metadata annotation.
> > 4. Move complex case to Appendix.
> > 5. Better Align abstract and introduction section with objectives sections.
> > The diff is:
> > https://www.ietf.org/rfcdiff?url2=draft-wu-netmod-yang-xml-doc-convent
> > ions-01 We believe the v-(01) address all the comments in last meeting 
> > and can serve a good basis to move to the next step.
> > Thanks. Further Comments and suggestions are welcome.
> > 
> > -Qin
> > -----邮件原件-----
> > 发件人: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > 发送时间: 2018年5月30日 9:17
> > 收件人: Benoit Claise; Qin Wu; Adrian Farrel; Benoît Claise
> > 主题: New Version Notification for
> > draft-wu-netmod-yang-xml-doc-conventions-01.txt
> > 
> > 
> > A new version of I-D, draft-wu-netmod-yang-xml-doc-conventions-01.txt
> > has been successfully submitted by Qin Wu and posted to the IETF repository.
> > 
> > Name:		draft-wu-netmod-yang-xml-doc-conventions
> > Revision:	01
> > Title:		Documentation Conventions for Expressing YANG in XML
> > Document date:	2018-05-29
> > Group:		Individual Submission
> > Pages:		10
> > URL:            https://www.ietf.org/internet-drafts/draft-wu-netmod-yang-xml-doc-conventions-01.txt
> > Status:         https://datatracker.ietf.org/doc/draft-wu-netmod-yang-xml-doc-conventions/
> > Htmlized:       https://tools.ietf.org/html/draft-wu-netmod-yang-xml-doc-conventions-01
> > Htmlized:       https://datatracker.ietf.org/doc/html/draft-wu-netmod-yang-xml-doc-conventions
> > Diff:           https://www.ietf.org/rfcdiff?url2=draft-wu-netmod-yang-xml-doc-conventions-01
> > 
> > Abstract:
> >    Many documents that define YANG modules also include artwork examples
> >    presented in XML/JSON.
> > 
> >    IETF documentation has specific limits on line length and some
> >    artwork examples such as XML examples have to include line wraps that
> >    would not normally be allowed according to the XML representation
> >    rules of RFC7950 and RFC7952.The same applies to JSON.
> > 
> >    This document lays out documentation conventions that allow YANG
> >    examples to be presented in IETF documentation when XML/JSON encoded
> >    YANG data instance would otherwise exceed the maximum line length and
> >    provide consistent XML/JSON encoded YANG data node instance example
> >    within an Internet-Draft or RFC.  There are no implications in this
> >    document for YANG parsers: this document does not change the rules
> >    for presenting YANG models or for encoding YANG in data files or in
> >    the wire.
> > 
> >                                                                                   
> > 
> > 
> > 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.
> > 
> > The IETF Secretariat
> > 
> > _______________________________________________
> > 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         
> 
> _______________________________________________
> 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 30 22:43:49 2018
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 D1DBB1273B1 for ; Wed, 30 May 2018 22:43:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2as87WyPsQN for ; Wed, 30 May 2018 22:43:44 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4369412DA6F for ; Wed, 30 May 2018 22:43:44 -0700 (PDT)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id CB53D3D790141; Thu, 31 May 2018 06:43:40 +0100 (IST)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 31 May 2018 06:43:41 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.193]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0382.000; Thu, 31 May 2018 13:43:31 +0800
From: Qin Wu 
To: Juergen Schoenwaelder 
CC: "dingxiaojian (A)" , "netmod@ietf.org" 
Thread-Topic: [netmod] Status update on 
Thread-Index: AQHT97P2/JSg9j4OKEuGkK1Py+kz/KRHeJEA///Bl4CAAfFJcIAAAE+A//+V44CAAJIVEA==
Date: Thu, 31 May 2018 05:43:31 +0000
Message-ID: 
References:  <20180530053411.7scy2khghg75wlbz@anna.jacobs.jacobs-university.de> <3B110B81B721B940871EC78F107D848C010C6D95@DGGEMM506-MBS.china.huawei.com>  <20180531045521.4qfpeqjvyteywek2@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180531045521.4qfpeqjvyteywek2@anna.jacobs.jacobs-university.de>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] Status update on 
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2018 05:43:47 -0000

WUFORyBwYXJzZXIgaW4gdGhpcyBkb2N1bWVudCBjb250ZXh0IGlzIFhNTC9KU09OIHBhcnNlciBm
b3IgWUFORyBkZWZpbmVkIGRhdGEsIGluIG15IHVuZGVyc3RhbmRpbmcuDQpOb3Qgc3VyZSB0aGlz
IGlzIHJpZ2h0IHRlcm0gb3Igd2hldGhlciB0aGVyZSBpcyBhbnkgYmV0dGVyIHRlcm0uIFdlIHdp
bGwgZmlndXJlIGl0IG91dC4gVGhhbmtzLg0KDQotUWluDQotLS0tLemCruS7tuWOn+S7ti0tLS0t
DQrlj5Hku7bkuro6IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciBbbWFpbHRvOmouc2Nob2Vud2FlbGRl
ckBqYWNvYnMtdW5pdmVyc2l0eS5kZV0gDQrlj5HpgIHml7bpl7Q6IDIwMTjlubQ15pyIMzHml6Ug
MTI6NTUNCuaUtuS7tuS6ujogUWluIFd1DQrmioTpgIE6IGRpbmd4aWFvamlhbiAoQSk7IG5ldG1v
ZEBpZXRmLm9yZw0K5Li76aKYOiBSZTogW25ldG1vZF0gU3RhdHVzIHVwZGF0ZSBvbiA8ZHJhZnQt
d3UtbmV0bW9kLXlhbmcteG1sLWRvYy1jb252ZW50aW9ucy0wMT4NCg0KV2hhdCBpcyBhICdZQU5H
IHBhcnNlcic/IEZvciBtZSwgYSBZQU5HIHBhcnNlciBpcyBzb21ldGhpbmcgdGhhdCBwYXJzZXMg
WUFORywgaS5lLiwgbm90IGFuIFhNTCBvciBKU09OIHBhcnNlci4NCg0KL2pzDQoNCk9uIFRodSwg
TWF5IDMxLCAyMDE4IGF0IDAzOjIxOjI3QU0gKzAwMDAsIFFpbiBXdSB3cm90ZToNCj4gVGhpcyBp
cyBleGFjdGx5IHdoYXQgd2UgcHJvcG9zZWQgaW4gdi0oMDIpICwNCj4gaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXd1LW5ldG1vZC15YW5nLXhtbC1kb2MtY29udmVudA0K
PiBpb25zLTAyDQo+IA0KPiBSZWdhcmRpbmcgbWFjaGluZSBwYXJzaW5nIGRhdGEsIHBsZWFzZSBz
ZWUgbGFzdCBwYXJhZ3JhcGggb2YgYWJzdHJhY3Q6DQo+ICINCj4gICAgVGhlcmUgYXJlIG5vIGlt
cGxpY2F0aW9ucyBpbiB0aGlzDQo+ICAgIGRvY3VtZW50IGZvciBZQU5HIHBhcnNlcnM6IHRoaXMg
ZG9jdW1lbnQgZG9lcyBub3QgY2hhbmdlIHRoZSBydWxlcw0KPiAgICBmb3IgcHJlc2VudGluZyBZ
QU5HIG1vZGVscyBvciBmb3IgZW5jb2RpbmcgWUFORyBpbiBkYXRhIGZpbGVzIG9yIGluDQo+ICAg
IHRoZSB3aXJlLg0KPiAiDQo+IFRoaXMgaGFzIGFscmVhZHkgYmVlbiBoaWdobGlnaHRlZCBpbiB2
LSgwMCkuDQo+IA0KPiAtUWluDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6
OiBkaW5neGlhb2ppYW4gKEEpDQo+IOWPkemAgeaXtumXtDogMjAxOOW5tDXmnIgzMeaXpSAxMTox
NQ0KPiDmlLbku7bkuro6IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjsgUWluIFd1DQo+IOaKhOmAgTog
bmV0bW9kQGlldGYub3JnDQo+IOS4u+mimDogUkU6IFtuZXRtb2RdIFN0YXR1cyB1cGRhdGUgb24g
DQo+IDxkcmFmdC13dS1uZXRtb2QteWFuZy14bWwtZG9jLWNvbnZlbnRpb25zLTAxPg0KPiANCj4g
QWdyZWUgd2l0aCBKdXJnZW4sIEkgdGhpbmsgd2hhdCBuZWVkIHRvIGJlIGVtcGhhc2l6ZWQgaXMg
aG93IG1hY2hpbmUgcGFyc2UgdGhlIGRhdGEgc2hvdWxkIG5vdCBiZSBjaGFuZ2VkLGluIGRyYWZ0
LXd1LW5ldG1vZC15YW5nLXhtbC1kb2MtY29udmVudGlvbnMsIHdoYXQgaXMgcmVxdWlyZWQgaXMg
YWRkaXRpb25hbCBlbmNvZGluZyBhbmQgZGVjb2RpbmcgbWVjaGFuaXNtIHRvIG1ha2UgZGF0YSBi
ZXR0ZXIgZml0IGludG8gUkZDIGFuZCBJLUQuDQo+IA0KPiBYaWFvamlhbg0KPiANCj4gLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5j
ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdWVyZ2VuIA0KPiBTY2hvZW53YWVsZGVyDQo+IFNl
bnQ6IFdlZG5lc2RheSwgTWF5IDMwLCAyMDE4IDE6MzQgUE0NCj4gVG86IFFpbiBXdSA8YmlsbC53
dUBodWF3ZWkuY29tPg0KPiBDYzogbmV0bW9kQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbmV0
bW9kXSBTdGF0dXMgdXBkYXRlIG9uIA0KPiA8ZHJhZnQtd3UtbmV0bW9kLXlhbmcteG1sLWRvYy1j
b252ZW50aW9ucy0wMT4NCj4gDQo+IEkgdGhpbmsgdGhlIHRpdGxlIG9mIHRoZSBkb2N1bWVudCBp
cyBtaXNsZWFkaW5nLiBUaGUgY29udmVudGlvbiBmb3IgZXhwcmVzc2luZyBZQU5HIGluIFhNTCBp
cyBjYWxsZWQgWUlOLCBkZWZpbmVkIGluIFJGQyA3OTUwLiBUaGVyZSBhcmUgb3RoZXIgcGhyYXNl
cyB0aGF0IEkgZmluZCBtaXNsZWFkaW5nLCBmb3IgZXhhbXBsZSwgQXV0b21hdGljIEdlbmVyYXRp
b24gb2YgVmFsaWQgWE1MIEZyb20gRXhhbXBsZXMuIEZvciBtZSwgdGhlIGV4YW1wbGUgaXMgdGhl
IFhNTCAob3IgSlNPTikgYW5kIHdoYXQgeW91IGNhbGwgYW4gZXhhbXBsZSBpcyB0aGUgZW5jb2Rp
bmcgb2YgYW4gWE1MIGluIHRoZSBSRkMgZm9ybWF0IGFuZCB3aGF0IHlvdSBkZWZpbmUgaXMgYW4g
UkZDIGZvcm1hdCBxZW5jb2RpbmcgYW5kIGEgZGVjb2RpbmcgZnVuY3Rpb24uIFBlcmhhcHMgaXQg
aGVscHMgdG8gcHJvcGVybHkgZGVmaW5lIHRoZSB0ZXJtaW5vbG9neSB5b3UgdXNlIGFuZCB0aGVu
IHRvIGdvIHRocm91Z2ggdGhlIGRvY3VtZW50IHRvIG1ha2Ugc3VyZSB0ZXJtcyBhcmUgdXNlZCBj
b25zaXN0ZW50bHkuDQo+IA0KPiAvanMNCj4gDQo+IE9uIFdlZCwgTWF5IDMwLCAyMDE4IGF0IDAx
OjM5OjQyQU0gKzAwMDAsIFFpbiBXdSB3cm90ZToNCj4gPiBIaSwgV0c6DQo+ID4gV2UgaGF2ZSBt
YWRlIGFuIHVwZGF0ZSBEb2N1bWVudGF0aW9uIENvbnZlbnRpb25zIGZvciBFeHByZXNzaW5nIFlB
TkcgaW4gWE1MIEktRCBiYXNlZCBvbiBsYXN0IG1lZXRpbmcgZGlzY3Vzc2lvbi4NCj4gPiBUaGUg
Y2hhbmdlcyBpbmNsdWRlOg0KPiA+IDEuIEFkZCBKU09OIHN1cHBvcnQuDQo+ID4gMi4gQWRkIG9i
amVjdGl2ZXMgc2VjdGlvbg0KPiA+IDMuIENvbnNvbGlkYXRlIE1hbmRhdG9yeSBCb2lsZXJwbGF0
ZSBmb3IgYm90aCBsZWFmIG5vZGUgYW5kIG1ldGFkYXRhIGFubm90YXRpb24uDQo+ID4gNC4gTW92
ZSBjb21wbGV4IGNhc2UgdG8gQXBwZW5kaXguDQo+ID4gNS4gQmV0dGVyIEFsaWduIGFic3RyYWN0
IGFuZCBpbnRyb2R1Y3Rpb24gc2VjdGlvbiB3aXRoIG9iamVjdGl2ZXMgc2VjdGlvbnMuDQo+ID4g
VGhlIGRpZmYgaXM6DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0
LXd1LW5ldG1vZC15YW5nLXhtbC1kb2MtY29udmUNCj4gPiBudA0KPiA+IGlvbnMtMDEgV2UgYmVs
aWV2ZSB0aGUgdi0oMDEpIGFkZHJlc3MgYWxsIHRoZSBjb21tZW50cyBpbiBsYXN0IA0KPiA+IG1l
ZXRpbmcgYW5kIGNhbiBzZXJ2ZSBhIGdvb2QgYmFzaXMgdG8gbW92ZSB0byB0aGUgbmV4dCBzdGVw
Lg0KPiA+IFRoYW5rcy4gRnVydGhlciBDb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNv
bWUuDQo+ID4gDQo+ID4gLVFpbg0KPiA+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4gPiDlj5Hk
u7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp
ZXRmLm9yZ10NCj4gPiDlj5HpgIHml7bpl7Q6IDIwMTjlubQ15pyIMzDml6UgOToxNw0KPiA+IOaU
tuS7tuS6ujogQmVub2l0IENsYWlzZTsgUWluIFd1OyBBZHJpYW4gRmFycmVsOyBCZW5vw650IENs
YWlzZQ0KPiA+IOS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+IGRyYWZ0
LXd1LW5ldG1vZC15YW5nLXhtbC1kb2MtY29udmVudGlvbnMtMDEudHh0DQo+ID4gDQo+ID4gDQo+
ID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIA0KPiA+IGRyYWZ0LXd1LW5ldG1vZC15YW5nLXhtbC1k
b2MtY29udmVudGlvbnMtMDEudHh0DQo+ID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl
ZCBieSBRaW4gV3UgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KPiA+IA0KPiA+
IE5hbWU6CQlkcmFmdC13dS1uZXRtb2QteWFuZy14bWwtZG9jLWNvbnZlbnRpb25zDQo+ID4gUmV2
aXNpb246CTAxDQo+ID4gVGl0bGU6CQlEb2N1bWVudGF0aW9uIENvbnZlbnRpb25zIGZvciBFeHBy
ZXNzaW5nIFlBTkcgaW4gWE1MDQo+ID4gRG9jdW1lbnQgZGF0ZToJMjAxOC0wNS0yOQ0KPiA+IEdy
b3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ID4gUGFnZXM6CQkxMA0KPiA+IFVSTDogICAg
ICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd3UtbmV0
bW9kLXlhbmcteG1sLWRvYy1jb252ZW50aW9ucy0wMS50eHQNCj4gPiBTdGF0dXM6ICAgICAgICAg
aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd3UtbmV0bW9kLXlhbmcteG1s
LWRvYy1jb252ZW50aW9ucy8NCj4gPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LXd1LW5ldG1vZC15YW5nLXhtbC1kb2MtY29udmVudGlvbnMtMDENCj4g
PiBIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9k
cmFmdC13dS1uZXRtb2QteWFuZy14bWwtZG9jLWNvbnZlbnRpb25zDQo+ID4gRGlmZjogICAgICAg
ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC13dS1uZXRtb2QteWFu
Zy14bWwtZG9jLWNvbnZlbnRpb25zLTAxDQo+ID4gDQo+ID4gQWJzdHJhY3Q6DQo+ID4gICAgTWFu
eSBkb2N1bWVudHMgdGhhdCBkZWZpbmUgWUFORyBtb2R1bGVzIGFsc28gaW5jbHVkZSBhcnR3b3Jr
IGV4YW1wbGVzDQo+ID4gICAgcHJlc2VudGVkIGluIFhNTC9KU09OLg0KPiA+IA0KPiA+ICAgIElF
VEYgZG9jdW1lbnRhdGlvbiBoYXMgc3BlY2lmaWMgbGltaXRzIG9uIGxpbmUgbGVuZ3RoIGFuZCBz
b21lDQo+ID4gICAgYXJ0d29yayBleGFtcGxlcyBzdWNoIGFzIFhNTCBleGFtcGxlcyBoYXZlIHRv
IGluY2x1ZGUgbGluZSB3cmFwcyB0aGF0DQo+ID4gICAgd291bGQgbm90IG5vcm1hbGx5IGJlIGFs
bG93ZWQgYWNjb3JkaW5nIHRvIHRoZSBYTUwgcmVwcmVzZW50YXRpb24NCj4gPiAgICBydWxlcyBv
ZiBSRkM3OTUwIGFuZCBSRkM3OTUyLlRoZSBzYW1lIGFwcGxpZXMgdG8gSlNPTi4NCj4gPiANCj4g
PiAgICBUaGlzIGRvY3VtZW50IGxheXMgb3V0IGRvY3VtZW50YXRpb24gY29udmVudGlvbnMgdGhh
dCBhbGxvdyBZQU5HDQo+ID4gICAgZXhhbXBsZXMgdG8gYmUgcHJlc2VudGVkIGluIElFVEYgZG9j
dW1lbnRhdGlvbiB3aGVuIFhNTC9KU09OIGVuY29kZWQNCj4gPiAgICBZQU5HIGRhdGEgaW5zdGFu
Y2Ugd291bGQgb3RoZXJ3aXNlIGV4Y2VlZCB0aGUgbWF4aW11bSBsaW5lIGxlbmd0aCBhbmQNCj4g
PiAgICBwcm92aWRlIGNvbnNpc3RlbnQgWE1ML0pTT04gZW5jb2RlZCBZQU5HIGRhdGEgbm9kZSBp
bnN0YW5jZSBleGFtcGxlDQo+ID4gICAgd2l0aGluIGFuIEludGVybmV0LURyYWZ0IG9yIFJGQy4g
IFRoZXJlIGFyZSBubyBpbXBsaWNhdGlvbnMgaW4gdGhpcw0KPiA+ICAgIGRvY3VtZW50IGZvciBZ
QU5HIHBhcnNlcnM6IHRoaXMgZG9jdW1lbnQgZG9lcyBub3QgY2hhbmdlIHRoZSBydWxlcw0KPiA+
ICAgIGZvciBwcmVzZW50aW5nIFlBTkcgbW9kZWxzIG9yIGZvciBlbmNvZGluZyBZQU5HIGluIGRh
dGEgZmlsZXMgb3IgaW4NCj4gPiAgICB0aGUgd2lyZS4NCj4gPiANCj4gPiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgDQo+ID4gDQo+ID4gDQo+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr
ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0
aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu
b3JnLg0KPiA+IA0KPiA+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+ID4gDQo+ID4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBuZXRtb2QgbWFpbGlu
ZyBsaXN0DQo+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9uZXRtb2QNCj4gDQo+IC0tIA0KPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIg
ICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiBQaG9uZTogKzQ5IDQy
MSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55
DQo+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vd3d3LmphY29icy11
bml2ZXJzaXR5LmRlLz4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+
IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCi0tIA0KSnVl
cmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dt
YkgNClBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5
IEJyZW1lbiB8IEdlcm1hbnkNCkZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBz
Oi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg==