From nobody Thu Dec 1 00:20:55 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E87129C2A for ; Thu, 1 Dec 2016 00:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 Kqm-jSbUFuaf for ; Thu, 1 Dec 2016 00:20:52 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2009B129C2B for ; Thu, 1 Dec 2016 00:20:52 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A3EA98D0; Thu, 1 Dec 2016 09:20:50 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id wkMufAvPd1Bx; Thu, 1 Dec 2016 09:20:47 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 1 Dec 2016 09:20:50 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5EB922005E; Thu, 1 Dec 2016 09:20:50 +0100 (CET) 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 MBv2rKbEDFDs; Thu, 1 Dec 2016 09:20:50 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 066F42005F; Thu, 1 Dec 2016 09:20:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 747653D8060E; Thu, 1 Dec 2016 09:20:49 +0100 (CET) Date: Thu, 1 Dec 2016 09:20:49 +0100 From: Juergen Schoenwaelder To: "Acee Lindem (acee)" Message-ID: <20161201082049.GA1748@elstar.local> Mail-Followup-To: "Acee Lindem (acee)" , "netmod@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Key Strings in ietf-key-chain operational state X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 08:20:54 -0000 On Wed, Nov 30, 2016 at 09:37:21PM +0000, Acee Lindem (acee) wrote: > In the days of MIBs, we used to omit key strings from the data that would be returned. This was ostensibly done for security purposes. This is not correct. In SMIv2, INDEX objects are not accessible because the values of these objects are embedded in the instance identifier. In other words, making INDEX objects not-accessible was a performance optimization, forcing SNMP managers to extract the INDEX object values out of the instance identifiers. Making INDEX objects not accessible does _not_ hide any information. /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 Dec 1 05:35:21 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C861294C4 for ; Thu, 1 Dec 2016 05:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujOxlKykYgIz for ; Thu, 1 Dec 2016 05:35:17 -0800 (PST) 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 9CA561294C0 for ; Thu, 1 Dec 2016 05:35:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2488; q=dns/txt; s=iport; t=1480599317; x=1481808917; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=imieSXVXgg3ceY0IwVL9lu/rB/XN+BkcRhrv9A6XvCE=; b=dN/cpI4MizedlnrXPj+4QY2nCAW2oblcDQesZg7Jo7Pm9gdPy2uP2zw8 rK/gQ7wZ43GNVXxKzyF8ulQZIGdYSDHBbcZhGVN0dI/B5+QmFEbMvi2l9 +oNbiCH615bEllPVV7/0ZhKPyTCnAfGhzDvNLJ1CeSexVG9wU5IKnlc0W E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQBoJkBY/4sNJK1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM4AQEBAQEfWIEGB40+lwuUeIIFJYV9AoIDPxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRpAQEEOj8OAgIBCA4CCBgGEBsXJQIEDgWIba17i1IBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEcBYsUhGogBgeFEwWaXgGRD4FyiDyGCI16hAsBHjeBGYNdG4Fdcog?= =?us-ascii?q?2gQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,282,1477958400"; d="scan'208";a="176211982" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Dec 2016 13:35:16 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id uB1DZGNF028076 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Dec 2016 13:35:16 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 1 Dec 2016 08:35:15 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 1 Dec 2016 08:35:15 -0500 From: "Acee Lindem (acee)" To: Juergen Schoenwaelder Thread-Topic: [netmod] Key Strings in ietf-key-chain operational state Thread-Index: AQHSS6vaEFwy9pC/jk+kWPZA/iaYSqDzGCCA Date: Thu, 1 Dec 2016 13:35:15 +0000 Message-ID: References: <20161201082049.GA1748@elstar.local> In-Reply-To: <20161201082049.GA1748@elstar.local> 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.204] Content-Type: text/plain; charset="us-ascii" Content-ID: <8DB153D5BBE0E347B6ACE96E2B54341A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Key Strings in ietf-key-chain operational state X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 13:35:19 -0000 On 12/1/16, 3:20 AM, "Juergen Schoenwaelder" wrote: >On Wed, Nov 30, 2016 at 09:37:21PM +0000, Acee Lindem (acee) wrote: > >> In the days of MIBs, we used to omit key strings from the data that >>would be returned. This was ostensibly done for security purposes. > >This is not correct. In SMIv2, INDEX objects are not accessible >because the values of these objects are embedded in the instance >identifier. In other words, making INDEX objects not-accessible was a >performance optimization, forcing SNMP managers to extract the INDEX >object values out of the instance identifiers. Making INDEX objects >not accessible does _not_ hide any information. This is a different issue. What I am referring to is never returning the keys in a read request (get, get-next, get-many, etc). For example, (excerpted from RFC 4750): ospfIfAuthKey OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..256)) MAX-ACCESS read-create STATUS current DESCRIPTION "The cleartext password used as an OSPF authentication key when simplePassword security is enabled. This object does not access any OSPF cryptogaphic (e.g., MD5) authentication key under any circumstance. If the key length is shorter than 8 octets, the agent will left adjust and zero fill to 8 octets. Unauthenticated interfaces need no authentication key, and simple password authentication cannot use a key of more than 8 octets. Note that the use of simplePassword authentication is NOT recommended when there is concern regarding attack upon the OSPF system. SimplePassword authentication is only sufficient to protect against accidental misconfigurations because it re-uses cleartext passwords [RFC1704]. When read, ospfIfAuthKey always returns an octet string of length zero." REFERENCE "OSPF Version 2, Section 9 The Interface Data Structure" DEFVAL { '0000000000000000'H } -- 0.0.0.0.0.0.0.0 ::=3D { ospfIfEntry 16 } Thanks, Acee=20 > >/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 Thu Dec 1 08:29:01 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A061295CE for ; Thu, 1 Dec 2016 08:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 lvZd7eejHZHT for ; Thu, 1 Dec 2016 08:28:57 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46ED51293F5 for ; Thu, 1 Dec 2016 08:28:57 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A52C1151F; Thu, 1 Dec 2016 17:28:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id fRFdJ7JNgt_6; Thu, 1 Dec 2016 17:28:52 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 1 Dec 2016 17:28:55 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 285982005F; Thu, 1 Dec 2016 17:28:55 +0100 (CET) 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 Bu1mKL11yK3L; Thu, 1 Dec 2016 17:28:54 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7CBA62005E; Thu, 1 Dec 2016 17:28:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2399E3D982F7; Thu, 1 Dec 2016 17:28:54 +0100 (CET) Date: Thu, 1 Dec 2016 17:28:54 +0100 From: Juergen Schoenwaelder To: "Acee Lindem (acee)" Message-ID: <20161201162854.GA89230@elstar.local> Mail-Followup-To: "Acee Lindem (acee)" , "netmod@ietf.org" References: <20161201082049.GA1748@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Key Strings in ietf-key-chain operational state X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 16:29:00 -0000 OK. I misread your statement. Sorry for the noise. /js On Thu, Dec 01, 2016 at 01:35:15PM +0000, Acee Lindem (acee) wrote: > > > On 12/1/16, 3:20 AM, "Juergen Schoenwaelder" > wrote: > > >On Wed, Nov 30, 2016 at 09:37:21PM +0000, Acee Lindem (acee) wrote: > > > >> In the days of MIBs, we used to omit key strings from the data that > >>would be returned. This was ostensibly done for security purposes. > > > >This is not correct. In SMIv2, INDEX objects are not accessible > >because the values of these objects are embedded in the instance > >identifier. In other words, making INDEX objects not-accessible was a > >performance optimization, forcing SNMP managers to extract the INDEX > >object values out of the instance identifiers. Making INDEX objects > >not accessible does _not_ hide any information. > > This is a different issue. What I am referring to is never returning the > keys in a read request (get, get-next, get-many, etc). For example, > (excerpted from RFC 4750): > > ospfIfAuthKey OBJECT-TYPE > SYNTAX OCTET STRING (SIZE (0..256)) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The cleartext password used as an OSPF > authentication key when simplePassword security > is enabled. This object does not access any OSPF > cryptogaphic (e.g., MD5) authentication key under > any circumstance. > > If the key length is shorter than 8 octets, the > agent will left adjust and zero fill to 8 octets. > > Unauthenticated interfaces need no authentication > key, and simple password authentication cannot use > a key of more than 8 octets. > > Note that the use of simplePassword authentication > is NOT recommended when there is concern regarding > attack upon the OSPF system. SimplePassword > authentication is only sufficient to protect against > accidental misconfigurations because it re-uses > cleartext passwords [RFC1704]. > > When read, ospfIfAuthKey always returns an octet > string of length zero." > REFERENCE > "OSPF Version 2, Section 9 The Interface Data > Structure" > DEFVAL { '0000000000000000'H } -- 0.0.0.0.0.0.0.0 > ::= { ospfIfEntry 16 } > > > > Thanks, > Acee > > > > > > > > >/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 Thu Dec 1 13:32:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707691295AA; Thu, 1 Dec 2016 13:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXn6Y4AzCMpq; Thu, 1 Dec 2016 13:32:24 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0137.outbound.protection.outlook.com [104.47.42.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8082B1298C3; Thu, 1 Dec 2016 13:32:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=V47ldlW7PhxXbRL7i7N81F9da7FgjJTXft1e+kLw3l4=; b=DRue/NFESb07SB5bh5t/HvEYGOVyQrCg4gN3QA2vKNZjf1erM77i9d1I4/b66feTA1NfUKxwrvqpRs/oIRnBRVXboJiKOxR7ymQNdGeDlYTlG8NCXKD4WU8xTQP7kW1+zIeBrO6K02c98xR+Fb5pvHe8VUT3lA0oHguH9Vj8/QI= Received: from BY2PR05CA032.namprd05.prod.outlook.com (10.141.250.22) by CO2PR05MB2726.namprd05.prod.outlook.com (10.166.200.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.5; Thu, 1 Dec 2016 21:32:23 +0000 Received: from BY2FFO11FD022.protection.gbl (2a01:111:f400:7c0c::141) by BY2PR05CA032.outlook.office365.com (2a01:111:e400:2c5f::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.4 via Frontend Transport; Thu, 1 Dec 2016 21:32:23 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BY2FFO11FD022.mail.protection.outlook.com (10.1.15.211) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.734.4 via Frontend Transport; Thu, 1 Dec 2016 21:32:23 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:; UpperCasedChecksum:; SizeAsReceived:1220; Count:13 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 1 Dec 2016 13:32:22 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id uB1LWJZV025789; Thu, 1 Dec 2016 13:32:20 -0800 (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id uB1LSF2m098528; Thu, 1 Dec 2016 16:28:15 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201612012128.uB1LSF2m098528@idle.juniper.net> To: Lou Berger In-Reply-To: Date: Thu, 1 Dec 2016 16:28:15 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-IncomingHeaderCount: 13 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(189002)(199003)(7846002)(305945005)(7696004)(110136003)(47776003)(189998001)(356003)(8276002)(8936002)(48376002)(8676002)(81156014)(81166006)(86362001)(50466002)(97736004)(230783001)(4326007)(2810700001)(38730400001)(92566002)(105596002)(76506005)(77096006)(229853002)(2906002)(54356999)(50986999)(106466001)(6916009)(2950100002)(7126002)(5660300001)(5003940100001)(53416004)(1076002)(69596002)(558084003)(68736007)(626004); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2726; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD022; 1:COHloAg8HqwraYyebqoKyaVRhibU7WDBU62Qw5a84+0qQV+xcWRBNjLOpJxSjCKVgo0atbpksCQdGlVP5j8Mns/6MMtbNAIBqZIpp8bL+PK4RmqDq8dBv7Vbl7srw1Y2pYTbo7Z/YuV2ievoyqAX3d9oKtOrjbUf4VXBYYktyYM+KbWoU9n77vXoyDiePoRptKXEP5TZpfX6FdEXRw363GethkrGcRnvVn7kQdDcDOaD0Q8Bn02PPCYBh4Ygb13yqJyizXE3emiJx4nE63Xg5lB9JAUdkI2bHHGMMgbMI667R8wgph51wfW77dBLqnpl+cQNimvj7YSMhEDnes4wbfCOOOHH7yDCJxOxISNu2991+LnU/xhLoK1uP3zmO+qqTM0pvawBdh+rug62UiNrX0LqwuyDv7gjzwQGR/Nh8nMHy0ZRLGnuISFOuk5JiYyM0mzqpl61Nis1iGeyqqfpF+2E3Tq8Iqo+3Sf+OEyQPRfhoeHjv/VmAY5q4b4Im5La83Kb9++RZgN5ocLA9xTm/UWzGTciul5hIhZ5mAExsPy5FufFKk1wI/t82xeXnsWKsQjkObtkSlDaYUIg+tclWKx1MRP3FCc8wwT1tUK5wVM= X-MS-Office365-Filtering-Correlation-Id: 1ac35039-a5ba-44b0-c3a6-08d41a3189d8 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CO2PR05MB2726; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2726; 3:D/j927G+Y5FrRUz2zjvWXIt8RhwFjRoC+RITOIrnyPoWXFGu+cztfEmWgYzbG2OGzcSW1frBQZvfywl+mcFbwOml4vLuUzvitn1KJye14e2VJN1usUshDjC5R2ZEedo5W86vmZYMFNWbsRr5wjGLfZU+9DAyRDtx/GD98S58qM4FqUOf8v36xh739hlWe9rN++YFyJj/Rxe669IXdffBBcFkczqgrqUrrexXhNm+PKUO7L76P8JpWUoBi3UAGxkHnKcraYYjIE27BJ50jCzr/RUkVrhzC0RLovaoiivVf45HVh57Q3UZRt9HK5Xl0J/IZnl45Onl9wj21DEPztXPdz4xabp5pfzJNtbHi8z9io4tt3ZJvr9VPP3AuXKv/du9; 25:mdXWaU9ymCW8y+V8m7Mv89unvDBKAcDaZj+/2CNvjDQZmp5qGfRYrItMRKOuqBa3O7DG5bsy5pP4TfYGPgxGwLLpzDAL+IzBcA/EikXNnUNt0h4Ynx1F5ROfTfIHoCnaGNojHY1yH6lq7x2/khpzVOLRTBG2kfQzoeIGD2wre2p6dJl7yYxdALnfeZQGxNf5VK+PrBZeizadOgruxvk+bL/msRVMm8y5TueBflp1GzzqL/rVm8JArUiiol0G/tYKlEdr97ACc8Qk5sIFb8M0f+JT/ua4sQ47Ia08ojZp+Ae8TaPDunt3+jyRUfRQSlqZLk5hl/VkIwMbcZBtWA5XXbcNGJq5WVAAkr5nkAXLoVs/jqewqha0jniCAq3aUT1JNSxwq+ddWjkt60xjTIYlVbRUzGCwnlYpVOQISiA8VsYzf6j0b4g1uPlGUemKGkbpv9/B7BR+rePuI3w+oVRIHg== X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2726; 31:zXTBk2ZDZT7xS3XkPcsinxj+A6rrcFLCkw4U4+aOY0vAWlk3XQiyrA5LKn8mnmjt8PG71rnwreey1t2TdLJa5FmOMtj5nD+MpD/PtKG0KMjOOFGdM/Hkldswutk+l78Zy2sM+h0gVJYa3RXxAI59NqPa2amp/IE1EUY5ugzYU2mk1TV/oia+FsR3YbkIpSImCs37fwYaWiH/kUnVW1SJdUKkcXDx+sTl91MJHHv1WTc3MovgwTosVH4DXp1L07Z2+eGUrJlfX+xpVXI3AFeIeg==; 20:eTP2z5zpongiyQEoRWfcRnSyezm8tu/acMoLnaoFPhR6Cs0X86anW3c/lgHGEcgmlKmtEA6SHmwVxBnbeC6ZWY1ADty5r6PuV42GL50hsMHEmLbUU4u5RGiEwW+75Av1KmheREJHfb/2z9VeABfv27uGWa+//d+Wyxn2hQmpjgVDKgJTXCIueWF2ZXd1AOxFuZyH487WQMVr5q768T1sYPjw3weQsHxSSRr6pjdMkhXUeDqC3HrxYnbxidNNS4wK7t38rXi3bmvljlHa+HL/Qelsq7Nm2NfVuR7aNJWoxZB/ADZ3RchqbHswAd3+QTdl9s7/l6346DGjZAMQRA08pVYpccswJjMTFaZY9seeu6+Ao+vYzepL+B4/nWdflvQ3eTh5xpWpZ6mez5svUlCdksa/DnZPpI1wPeC/U7nMoaAfiGhJBduLl3FpqdxVeRm18WMhQ1xdNjw1DAUD+Gh8xpVYkGIhv1lwwJvXA7HSRIElVakkqcKGUvg9oeyVrpyS X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13017025)(13023025)(13015025)(13024025)(13018025)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6042181)(6072148); SRVR:CO2PR05MB2726; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2726; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2726; 4:bXfU/F6UMNdRxqmhjghhHsapwZavmdb/ZOiOyqMsY+DwYPg3nZt8BjWpuxKeXaSFP5D376HWw5A3hm81yOGoszivtepfgTVGLVHKR0ubBmNbbEsHAZkVesDqk2e9dN5eV5l5186+j2JXV56wC02WLvO5qaVinr4EzhZSi1mnVJjm1pzHcdrPQ/+7Za52Lq3YdwrZ4RSLFyeQM64/kvgWwP2wFvDbHePdzKytwL3Lihec4GxMa9el79Po5vybfGGUsawoS6zMPFmJzGvuo2LZ0/Dakolv0QjpGdRA9xi9UpHb7etXFTX5bs4Qu0Pb77pGhzXgSxfPmDS96cVVusEgoPTJoD4Y+W/N6WeMZRUjJDUFcALTjjM4Fv/5ZEz/sLRjkLJJ3fZvWIU8pDfOtQ9IMMp7IiQgoYOQGxlUy084qtdas9UnAUnVPnAS4pMK0VuIsfAry3YVCeLBI2YAPnhTCZwHLPdSw26Kv0IlnT2Uy15//+B4XBEFumw8SwFSIFNZ/UR75+r5SI3J+QpKSVHnQcxOha7kjXcaZtAQD+ci7fEQJ8l9qZTaRMKnATE3ElhKzB0XQXBWr3c5t1sXf6gfO9gKDB3+6oUCV1tbKdokcE75hDdtwuYpDeU5DQOO9o6SORFt3x/i27ZNZYzp0JGyAMX97W9kn1mNqwhp2Efok0U5BSd5y9ayye+UdgcghmifIuS+bD7+2eJZeZA/B22Klw== X-Forefront-PRVS: 014304E855 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2726; 23:hFVHuKY+OgzS0TvV3aJjDOXbae7C2XdJoVWWGwdiB?= =?us-ascii?Q?vXSVh8HYErvr+olUWtYDvEGGvUzdpyAR9jVUHWh33za+pwbeRfR5EoAocTZq?= =?us-ascii?Q?spHySsc5eXEJECqGH8o/bLtduKDeGxC7zZ8Py/9c/Ii1UTllVCPOSQOeC7dD?= =?us-ascii?Q?rdb3qUrk9iE1xoZ4+UTgDRH2OcxyNGhXIssOZa+dGp3ZayFgZdzcWeuncOPY?= =?us-ascii?Q?gPCrNgRTa8C7riw+anKgnX4DZq/iiJsGteaQbpMVFm3NCcpiMf+TjzZFV8fs?= =?us-ascii?Q?pICmctcoUgaveM0/iUIUir62E6UOTRdUEI6LZvQFG+0SFYotRgaKXdfPN0w6?= =?us-ascii?Q?J3FiY0sqNIBhysIQoKtRVnPNUFknHqee2/TQODyKzm+4JRZTSGBBGzVopb9r?= =?us-ascii?Q?aBFMCsGL3olRKkMzLqv6+MNo6QWgMIrokeCzsUvyBkWMZdsugsR4ovVjEN3b?= =?us-ascii?Q?YVGFcVJdLZyZjYlODb+OW1Bq8EOu9Z/bNPiHTf4ZYBKTaKbAQUqUWWKRbE2y?= =?us-ascii?Q?WwbZFxonm2Tpi5MxM0eAXJnAyB/C5NBDJfplH20jVPuS+TbhGQByjaTtESb+?= =?us-ascii?Q?2uZF0rocmiOuvWNVj81VsrL6MRhTyRCY7sYAl5MdWjKOdRM6SGKxcjRGhdkM?= =?us-ascii?Q?VZbNYfSu/6zlNINuD1vBQzZBty+II5VbMKDX5ddwo3DVmJp3fgy+zfYk+635?= =?us-ascii?Q?7BSuqm5biHCxEziblAaN7f9Kf2mAGALLckQZoxBrH7b0CrAUbGe2qr6m5hCS?= =?us-ascii?Q?IKiXsHYu4lxIja8j6mvg818E5VOvdxINDC99n4qKKCeslHaz/vDADhkLJwsD?= =?us-ascii?Q?Uxneipfe8Q7S4vJ1VgjRzHC6VvR3G3+CYMK9ejQPRmEjvgv9lrEz5NR0HQMz?= =?us-ascii?Q?X+aTGpSrfXW79C9DwWfXzJBflqushugU5GmnQ8QVrUpj2ywSYnZ30wCnTDI8?= =?us-ascii?Q?ekBdokW/qF0aI34t0eOknokXCWL8q7E7QzpQGRMoehGhddYiocquTjYEG+aU?= =?us-ascii?Q?l9dOf68x95Iwh/SC+lKWiPaC0PJubMgfLif8eUQdGgnp8yTknP3Iu9WiIiPq?= =?us-ascii?Q?hlGflD+vmWILxJQ7Ye1yYCcSLyo?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2726; 6:lTRBSMxqISBD3SqZB3CrfG/sBKFl5xwgTn+dFtG/2pBAS1A/qdTSHvXtSMFIzxDThOh0TYAqC8RPLKw1Ut0oHrqfgdK5zcXP1QHotg8t/kMC5KSRAbbYAvcpaCd+bUsoWfaS3ir7dP8ozb17Mc2qoK/eKISgKBYZBaEKpsVVqoPxCTR04T8SGDI0bmUKz5Bu1kbgnQA/QqS7xxDOGFj159XrfH7phee1d9zP1A4yXZgS8SNvGKE4RLg5Xf6cckzs+ErTgQiYpEEScHQGxh6uQjdRsE2ZcNLFgYFblD+39uTNX5lYqWT+xtjTdSM4kU4BNjncXKr2Hxf0E1LJ9OIhD65qPNUotLl5KtIJUzfZW1VGj5SadrxIIo3IRWBxFEBEcBrh3MocT+GFGv9xcSX/VC0PBFhuA/uq6DvDZdTloOA3+Q8G5SN4WU2o9xu15uWDN2/ZZ44T9ITVMNxT0RVK1PhI6Zl/2udxQzmr+0C605Bv4iquxyv0kdGmlQBLGxar; 5:5/FvHmdAty/nXDhEXQPDDaLRpc7YoeBh7Aedun1z4x0i4nE2coXJ2kQXqTa7vbzGlHe4REyLAQUXCMu85zzCKE8y2kaXSoSE+P61yOKPlcesjndQfoWLBFmfR8sW9IWszPL6ILXWKMRKbmKh/I7tHA==; 24:hpx0WUt+ydFFmRGVPfKD3xgvRDQ8OVBxF6NfNGBQT2+yOrsWIGS31xTzh2dG18f9Yl+EyUyN7tW6qQyqLVbbAZADbhvKLwYGoG05r3SqU0Y= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2726; 7:FJLYhsgnR4W/57VAkh3iJ/NmCOsqi1peVd6swAij4+MvjacnrRmlC2OfaIq5l3Rx7ksqA0DTxoH6aChq3CyzLoHUSeV7rX3F0BnJrHPtqJZZBi294Xfjf1aXn0BRC6CQJ45HTB82nsapP8nwC32fX64roIbHjB1kw79OnTj1kXNP7axAGWExlqPibeYu66PN9pB0YHaIcRk7Om5MuQ3YbrVwT2/a5PZPpmHL4HDlpWL91QSjtEtxpSJM1eudgvvf04J/aTqhh2qhQy2WW+OTO5SF3ZvcDIGkdKtjgO3/I1YvEBDBv+8AOlMN700HdOe4xec9BkabrDEpZvmauPEdiTQKQIesp8M5TAIROiW1O11HJ/gojj+hAdky+wkzuNNk4cUUdAcxk83kBSbCSLBCMHJNeFHcBv4RuyZnWQwB/fFKNjwudn6WnnGWp7GXWRKB8UyHjnYnDMZzOR4E3tBFhw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Dec 2016 21:32:23.0118 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2726 Archived-At: Cc: NetMod Chairs , NetMod WG Subject: Re: [netmod] Regarding IPR on draft-nmdsdt-netmod-revised-datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 21:32:26 -0000 Lou Berger writes: >"No, I'm not aware of any IPR that applies to this draft" No, I'm not aware of any IPR that applies to this draft Thanks, Phil From nobody Fri Dec 2 00:35:45 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1BB129431 for ; Fri, 2 Dec 2016 00:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 vZ8ILD4CowfD for ; Fri, 2 Dec 2016 00:35:41 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A8F126BF7 for ; Fri, 2 Dec 2016 00:35:40 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2457F12A2 for ; Fri, 2 Dec 2016 09:35:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id a2Wz0BiMNAjO for ; Fri, 2 Dec 2016 09:35:35 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 2 Dec 2016 09:35:38 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 96DCD2005F for ; Fri, 2 Dec 2016 09:35:38 +0100 (CET) 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 P86CVySJxC8S; Fri, 2 Dec 2016 09:35:38 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01B542005E; Fri, 2 Dec 2016 09:35:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EBA773D99533; Fri, 2 Dec 2016 09:35:37 +0100 (CET) Date: Fri, 2 Dec 2016 09:35:37 +0100 From: Juergen Schoenwaelder To: NETMOD WG Message-ID: <20161202083537.GA89856@elstar.local> Mail-Followup-To: NETMOD WG References: <5d05d686-5962-9ffc-16d4-c4459baf9c7a@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5d05d686-5962-9ffc-16d4-c4459baf9c7a@labn.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-yang-model-classification-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 08:35:43 -0000 Hi, I have read this document and I think it is in good shape and useful, hence I support the publication. Some comments below, but nothing that I consider a showstopper. - I think the RFC editor does not like citation in an abstract. But this is actually not my point, I am more wondering why the abstract says YANG is defined in RFC 6020 given that we have YANG 1.1 defined in RFC 7950. The easiest fix is to remove the citation from the abstract (might make the RFC editor happy anyway). - Sometimes you use 'data modeling language' sometimes just 'modeling language'. I am not sure whether we have to be consistent or even whether there is a reason why the document uses different terms. - The relationship of the terms '(YANG) data model' and '(YANG) module' is not necessarily clear. My understanding has been there might be a 1:1 relationship between a data model and a YANG module but a data model may also be expressed using a collection of YANG modules (and submodules). (Perhaps we should have clarified these terms better in the terminology section of RFC 7950.) One option to resolve this issue could be to simply not talk about models at all; the title says this is a classification of YANG modules. - I am not sure what 'ready to be used by operators' means since you put this into the context of Network Service YANG modules. I believe Network Element YANG modules are also to be used by operators, no? - Is it 'they propose in their products' or is it 'they support in their products'? - The module definition in the terminology section is not the definition contained in RFC 7950. It is the old definition from RFC 6020 but you refer rightly to RFC 7950, so this needs to be updated. - s/perform the intent of the service/realize the service/ (trying to avoid intent as people may read too much into this) - Should there be a short discussion in the security considerations? Are there different aspects to consider for service modules? Network element modules essentially put network elements at risk and the network (if network elements misbehave). Service modules put complete services at risk, i.e., a security flaws in a service module or an implementation of a service module may have much higher impact (orchestrated failures or misbehavior of network elements). /js On Wed, Nov 30, 2016 at 12:35:44PM -0500, Lou Berger wrote: > All, > This starts a two-week working group last call on > draft-ietf-netmod-yang-model-classification-04. > > The working group last call ends on December 14. Please send your > comments to the netmod mailing list. > > Positive comments, e.g., "I've reviewed this document and > believe it is ready for publication", are welcome! > This is useful and important, even from authors. > > Thank you, > Netmod Chairs > > _______________________________________________ > 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 Fri Dec 2 09:30:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDC11295D5; Fri, 2 Dec 2016 09:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iA8Lb1smc8rg; Fri, 2 Dec 2016 09:30:29 -0800 (PST) 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 149171295D2; Fri, 2 Dec 2016 09:30:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3066; q=dns/txt; s=iport; t=1480699829; x=1481909429; h=from:subject:to:cc:message-id:date:mime-version; bh=J6VwwZNJiHyYhL6274uVNlZEDMfa1NTzBCbMyWqLVnI=; b=Xl+pBPWXKn9vDGJu783RtEBWRqoPTzyQy1TT/j+pQteXrO/Nu4URsg/i XeEy3yQTVhtpnQJFoAUjY72FTTnmvHLYyujzOFMEVlg9a+vKiKXtitaKC W80mjo7bNLo8e6XhX3iisZusSzbBFVzxYBQjL9kzyq82zjmcT4W/8HM27 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B1AwD4rkFY/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzgBAQEBAXmBBrQqgxOEFSmFeYJeEQECAQEBAQEBAWIohRJWHwE9Al8?= =?us-ascii?q?BDAgBAYhrDqw3gikviwEBAQEBAQUBAQEBAQEBIIY+gX2BVohVgl0FmmOGS4pJg?= =?us-ascii?q?kKHS4Ysih6HbzUheBMOhBCBRj00AYh9AQEB?= X-IronPort-AV: E=Sophos;i="5.33,287,1477958400"; d="scan'208,217";a="648583095" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Dec 2016 17:30:27 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uB2HUQnH025356; Fri, 2 Dec 2016 17:30:26 GMT From: Benoit Claise To: NETMOD Working Group , YANG Doctors Message-ID: Date: Fri, 2 Dec 2016 18:30:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------292CD7C4FDE4001F8A2D1C39" Archived-At: Subject: [netmod] IETF YANG module compilation: now four different compilers to check your modules. X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 17:30:31 -0000 This is a multi-part message in MIME format. --------------292CD7C4FDE4001F8A2D1C39 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, During the IETF hackathon, I inserted two more compilers part of the daily cron job on my web site. Next to pyang, confdc, we know have yangdump-pro (from Yumaworks) and yanglint (thanks to Radek for the help) See for the results here . The compilation field is based on the outcome of the 4 compilers, to the best of my knowledge, as there is a little bit of analytic here. As you can see, the number of YANG modules that pass compilation dropped . This is fine, as the quality of the YANG modules will eventually improve. The comparison of 4 different compilers helped tremendously finding bugs in the compilers on one hand (many are solved already or will be solved in the next compiler version), and clarifying the YANG specifications on the other hand (perfect timing as draft-ietf-netmod-rfc6087bis-09 is being finalized). I advice you to look up your YANG modules on the web site. The new compilers might have discovered new issues. Regards, Benoit --------------292CD7C4FDE4001F8A2D1C39 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

During the IETF hackathon, I inserted two more compilers part of the daily cron job on my web site.
Next to pyang, confdc, we know have yangdump-pro (from Yumaworks) and yanglint (thanks to Radek for the help)

See for the results here.
The compilation field is based on the outcome of the 4 compilers, to the best of my knowledge, as there is a little bit of analytic here.

As you can see, the number of YANG modules that pass compilation dropped.
This is fine, as the quality of the YANG modules will eventually improve.
The comparison of 4 different compilers helped tremendously finding bugs in the compilers on one hand (many are solved already or will be solved in the next compiler version), and clarifying the YANG specifications on the other hand (perfect timing as draft-ietf-netmod-rfc6087bis-09 is being finalized).

I advice you to look up your YANG modules on the web site. The new compilers might have discovered new issues.

Regards, Benoit
 


 


--------------292CD7C4FDE4001F8A2D1C39-- From nobody Fri Dec 2 12:15:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A36C1279EB for ; Fri, 2 Dec 2016 12:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wq2rU7gHT_15 for ; Fri, 2 Dec 2016 12:15:28 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0096.outbound.protection.outlook.com [104.47.34.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43943120725 for ; Fri, 2 Dec 2016 12:15:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CQaZ89cAKkLms7P036BjMi20YXWdodN3tc9J1/1qJbg=; b=QJegWe5EIEQAW8dcGh6eA7Z29GRTHKF4sRS72kICR7CSS4YA/PwCpov0HLzDTceVoJ6Qj/LULzEd2RdnXEhDwmk3f2kfXNapHWQT/xuvdr+K3uBf9fRC1o+INnSsh9BHUNdtJ+MQCHdJtCRIfjA7nUd3lIybGrkunCsV/BZzV4w= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.4; Fri, 2 Dec 2016 20:15:26 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0761.013; Fri, 2 Dec 2016 20:15:27 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "Acee Lindem (acee)" Thread-Topic: [netmod] Key Strings in ietf-key-chain operational state Thread-Index: AQHSS1Hu3gEYh3opOk2NCMc25X0loKDywQGAgABX2oCAADCEAIABfc2A Date: Fri, 2 Dec 2016 20:15:26 +0000 Message-ID: <83DB4ED2-F0BB-47CB-BB1E-981CA48098C5@juniper.net> References: <20161201082049.GA1748@elstar.local> <20161201162854.GA89230@elstar.local> In-Reply-To: <20161201162854.GA89230@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1c.1.161117 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: 02dfd87f-28fc-4677-8483-08d41aeff4ae x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1441; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:cmODVbmkRCSF5GRw27xJ0xjiJLYYIC+xgTFuM+DYaeiUwgDRYf2fYdjwJBDuLSVUhjDAvST1c3svsLxt/erS1xGrleXAEolbQW5A24Q3Zz8shudgey/h0OLYO4fviboT9W+8kzgFwINTUFxrj4GbdZWUVXFQkSmRBVDJ5qpOLEYU8wLMQZHqaawS1m+q4wxtrlAf99xEjBNptLnHZITe0oXpj+S/gywdI1JMXz+dWWCTrmBlxOD2LKZtolRexluE7G0aXVaQsbkj/JdwZHoZrUtVVPrmV6G8Y0BRhAQt49EHDYOCvD6mr/4UtU3NSCBTWt9Ho+Y0kgPbZeeJHp/7NUKrBUVXnaUKWtEiLvxJ9tEK+knO0xtkZ5KBHcU4WbqQ1S7cG+Y1IQfq1wN/ivX+mai/Utj1NdQikffZ/chMa5Ws0qKyTJHr+8FIGSTVYHYBrbje9IxY9zDefJ18RJFRYA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(200054503718035); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(2003001)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 0144B30E41 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(76104003)(377454003)(199003)(24454002)(189002)(6486002)(93886004)(66066001)(86362001)(82746002)(101416001)(551544002)(102836003)(76176999)(230783001)(54356999)(33656002)(50986999)(36756003)(6506005)(6512005)(2950100002)(68736007)(6116002)(3846002)(81166006)(4326007)(2906002)(97736004)(92566002)(38730400001)(7846002)(305945005)(7736002)(8936002)(8676002)(83716003)(2900100001)(81156014)(229853002)(5660300001)(39410400001)(77096006)(39450400002)(99286002)(3660700001)(106356001)(105586002)(106116001)(83506001)(5001770100001)(122556002)(189998001)(3280700002)(4001350100001)(50919006)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2016 20:15:26.8224 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Key Strings in ietf-key-chain operational state X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 20:15:31 -0000 SGkgQWNlZSwNCg0KU29ycnkgZm9yIGJlaW5nIGxhdGUgdG8gdGhpcyB0aHJlYWQuICBBcyBNZWhl c2ggbWVudGlvbmVkLCB0aGlzIGFzcGVjdCBvZiB0aGUga2V5c3RvcmUgbW9kZSBpcyBjdXJyZW50 bHkgb3BlbiwgYW5kIGJlaW5nIHRyYWNrZWQgYnkgZ2l0aHViIGlzc3VlICMyLiAgDQoNCkl0IGlz IG15IHVuZGVyc3RhbmRpbmcgdGhhdCB0aGUgd29ya2luZyBncm91cCB3b3VsZCBsaWtlIHRvIHB1 cnN1ZSBhIHN0cmF0ZWd5IHRoYXQgc3VwcG9ydHMgYmFja3VwL3Jlc3RvcmUgb3BlcmF0aW9ucyB0 byB0aGUgZ3JlYXRlc3QgZXh0ZW50IHBvc3NpYmxlLiAgDQoNCkluIG9yZGVyIHRvIHByZXZlbnQg dW5hdXRob3JpemVkIGFjY2VzcywgTkFDTSBydWxlcyBjYW4gYmUgdXNlZCB0byBtYXJrIHRoZSBw cml2YXRlIGtleSBkYXRhIGxlYWYgKG5vdCBpdHMgcGFyZW50IGxpc3QgZW50cnkpIHdpdGgg4oCc bmFjbTpkZWZhdWx0LWRlbnktYWxs4oCdLg0KDQpJbiBvcmRlciB0byBzdXBwb3J0IGhhcmR3YXJl IHByb3RlY3RlZCBrZXlzLCB0aGUgcHJpdmF0ZSBrZXkgZGF0YSBsZWFmIGNhbiBiZSBtYXJrZWQg YXMgbWFuZGF0b3J5IGZhbHNlLCB3aXRoIHRoZSBleHBsYW5hdGlvbiB0aGF0LCBpZiBub3QgcmV0 dXJuZWQsIGl0IG1pZ2h0IGJlIGJlY2F1c2UgdGhlIGtleSBpcyBwcm90ZWN0ZWQgYnkgaGFyZHdh cmUuDQoNCk5vdCBzdGF0ZWQgeWV0LCBidXQgdGhlIHRoaW5raW5nIGlzIHRoYXQgdGhlIHByaXZh dGUga2V5IGRhdGEgbGVhZiB3b3VsZCBiZSBjb25maWcgdHJ1ZSwgdG8gc3VwcG9ydCB0aGUgYmFj a3VwL3Jlc3RvcmUgY2FzZSBvZiB0aGUgTkMvUkMgY2xpZW50IHBhc3NpbmcgdGhlIHByaXZhdGUg dG8gdGhlIGRldmljZSAgKG9wZW4gaXNzdWU6IGhvdyB0byBkaXJlY3Qgc3BlY2lhbGl6ZWQgaGFy ZHdhcmUgdG8gZ2VuZXJhdGUgYSBuZXcgcHJvdGVjdGVkIGtleSkuICBQZXJ0aW5lbnRseSwgZm9y IHRoZSBhcHBsaWVkL29wZXJhdGlvbmFsLXN0YXRlIGRhdGFzdG9yZXMsIHRoZSBOQUNNIGFuZCBt YW5kYXRvcnkgYXR0cmlidXRlcyBjYXJyeSBvdmVyLCBzbyBzdGlsbCB0aGUga2V5IGlzIHByb3Rl Y3RlZCBmcm9tIHVuYXV0aG9yaXplZCBhY2Nlc3MgYW5kIHN0aWxsIHRoZSBzb2x1dGlvbiBzdXBw b3J0cyBoYXJkd2FyZSBwcm90ZWN0ZWQga2V5cy4NCg0KV2hhdCBkbyB5b3UgdGhpbms/DQoNCktl bnQNCiAgDQoNCg0KT24gMTIvMS8xNiwgMTE6MjggQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIEp1 ZXJnZW4gU2Nob2Vud2FlbGRlciIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv ZiBqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KDQpPSy4gSSBt aXNyZWFkIHlvdXIgc3RhdGVtZW50LiBTb3JyeSBmb3IgdGhlIG5vaXNlLg0KDQovanMNCg0KT24g VGh1LCBEZWMgMDEsIDIwMTYgYXQgMDE6MzU6MTVQTSArMDAwMCwgQWNlZSBMaW5kZW0gKGFjZWUp IHdyb3RlOg0KPiANCj4gDQo+IE9uIDEyLzEvMTYsIDM6MjAgQU0sICJKdWVyZ2VuIFNjaG9lbndh ZWxkZXIiDQo+IDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0K PiANCj4gPk9uIFdlZCwgTm92IDMwLCAyMDE2IGF0IDA5OjM3OjIxUE0gKzAwMDAsIEFjZWUgTGlu ZGVtIChhY2VlKSB3cm90ZToNCj4gPg0KPiA+PiBJbiB0aGUgZGF5cyBvZiBNSUJzLCB3ZSB1c2Vk IHRvIG9taXQga2V5IHN0cmluZ3MgZnJvbSB0aGUgZGF0YSB0aGF0DQo+ID4+d291bGQgYmUgcmV0 dXJuZWQuIFRoaXMgd2FzIG9zdGVuc2libHkgZG9uZSBmb3Igc2VjdXJpdHkgcHVycG9zZXMuDQo+ ID4NCj4gPlRoaXMgaXMgbm90IGNvcnJlY3QuIEluIFNNSXYyLCBJTkRFWCBvYmplY3RzIGFyZSBu b3QgYWNjZXNzaWJsZQ0KPiA+YmVjYXVzZSB0aGUgdmFsdWVzIG9mIHRoZXNlIG9iamVjdHMgYXJl IGVtYmVkZGVkIGluIHRoZSBpbnN0YW5jZQ0KPiA+aWRlbnRpZmllci4gSW4gb3RoZXIgd29yZHMs IG1ha2luZyBJTkRFWCBvYmplY3RzIG5vdC1hY2Nlc3NpYmxlIHdhcyBhDQo+ID5wZXJmb3JtYW5j ZSBvcHRpbWl6YXRpb24sIGZvcmNpbmcgU05NUCBtYW5hZ2VycyB0byBleHRyYWN0IHRoZSBJTkRF WA0KPiA+b2JqZWN0IHZhbHVlcyBvdXQgb2YgdGhlIGluc3RhbmNlIGlkZW50aWZpZXJzLiBNYWtp bmcgSU5ERVggb2JqZWN0cw0KPiA+bm90IGFjY2Vzc2libGUgZG9lcyBfbm90XyBoaWRlIGFueSBp bmZvcm1hdGlvbi4NCj4gDQo+IFRoaXMgaXMgYSBkaWZmZXJlbnQgaXNzdWUuIFdoYXQgSSBhbSBy ZWZlcnJpbmcgdG8gaXMgbmV2ZXIgcmV0dXJuaW5nIHRoZQ0KPiBrZXlzIGluIGEgcmVhZCByZXF1 ZXN0IChnZXQsIGdldC1uZXh0LCBnZXQtbWFueSwgZXRjKS4gRm9yIGV4YW1wbGUsDQo+IChleGNl cnB0ZWQgZnJvbSBSRkMgNDc1MCk6DQo+IA0KPiAgb3NwZklmQXV0aEtleSBPQkpFQ1QtVFlQRQ0K PiAgICAgICAgU1lOVEFYICAgICAgIE9DVEVUIFNUUklORyAoU0laRSAoMC4uMjU2KSkNCj4gICAg ICAgIE1BWC1BQ0NFU1MgICByZWFkLWNyZWF0ZQ0KPiAgICAgICAgU1RBVFVTICAgICAgIGN1cnJl bnQNCj4gICAgICAgREVTQ1JJUFRJT04NCj4gICAgICAgICAgICJUaGUgY2xlYXJ0ZXh0IHBhc3N3 b3JkIHVzZWQgYXMgYW4gT1NQRg0KPiAgICAgICAgICAgYXV0aGVudGljYXRpb24ga2V5IHdoZW4g c2ltcGxlUGFzc3dvcmQgc2VjdXJpdHkNCj4gICAgICAgICAgIGlzIGVuYWJsZWQuICBUaGlzIG9i amVjdCBkb2VzIG5vdCBhY2Nlc3MgYW55IE9TUEYNCj4gICAgICAgICAgIGNyeXB0b2dhcGhpYyAo ZS5nLiwgTUQ1KSBhdXRoZW50aWNhdGlvbiBrZXkgdW5kZXINCj4gICAgICAgICAgIGFueSBjaXJj dW1zdGFuY2UuDQo+IA0KPiAgICAgICAgICAgSWYgdGhlIGtleSBsZW5ndGggaXMgc2hvcnRlciB0 aGFuIDggb2N0ZXRzLCB0aGUNCj4gICAgICAgICAgIGFnZW50IHdpbGwgbGVmdCBhZGp1c3QgYW5k IHplcm8gZmlsbCB0byA4IG9jdGV0cy4NCj4gDQo+ICAgICAgICAgICBVbmF1dGhlbnRpY2F0ZWQg aW50ZXJmYWNlcyBuZWVkIG5vIGF1dGhlbnRpY2F0aW9uDQo+ICAgICAgICAgICBrZXksIGFuZCBz aW1wbGUgcGFzc3dvcmQgYXV0aGVudGljYXRpb24gY2Fubm90IHVzZQ0KPiAgICAgICAgICAgYSBr ZXkgb2YgbW9yZSB0aGFuIDggb2N0ZXRzLg0KPiANCj4gICAgICAgICAgIE5vdGUgdGhhdCB0aGUg dXNlIG9mIHNpbXBsZVBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uDQo+ICAgICAgICAgICBpcyBOT1Qg cmVjb21tZW5kZWQgd2hlbiB0aGVyZSBpcyBjb25jZXJuIHJlZ2FyZGluZw0KPiAgICAgICAgICAg YXR0YWNrIHVwb24gdGhlIE9TUEYgc3lzdGVtLiAgU2ltcGxlUGFzc3dvcmQNCj4gICAgICAgICAg IGF1dGhlbnRpY2F0aW9uIGlzIG9ubHkgc3VmZmljaWVudCB0byBwcm90ZWN0IGFnYWluc3QNCj4g ICAgICAgICAgIGFjY2lkZW50YWwgbWlzY29uZmlndXJhdGlvbnMgYmVjYXVzZSBpdCByZS11c2Vz DQo+ICAgICAgICAgICBjbGVhcnRleHQgcGFzc3dvcmRzIFtSRkMxNzA0XS4NCj4gDQo+ICAgICAg ICAgICBXaGVuIHJlYWQsIG9zcGZJZkF1dGhLZXkgYWx3YXlzIHJldHVybnMgYW4gb2N0ZXQNCj4g ICAgICAgICAgIHN0cmluZyBvZiBsZW5ndGggemVyby4iDQo+ICAgICAgICBSRUZFUkVOQ0UNCj4g ICAgICAgICAgICJPU1BGIFZlcnNpb24gMiwgU2VjdGlvbiA5IFRoZSBJbnRlcmZhY2UgRGF0YQ0K PiAgICAgICAgICAgU3RydWN0dXJlIg0KPiAgICAgICAgREVGVkFMIHsgJzAwMDAwMDAwMDAwMDAw MDAnSCB9IC0tIDAuMC4wLjAuMC4wLjAuMA0KPiAgICAgICAgOjo9IHsgb3NwZklmRW50cnkgMTYg fQ0KPiANCj4gDQo+IA0KPiBUaGFua3MsDQo+IEFjZWUgDQo+IA0KPiANCj4gDQo+IA0KPiANCj4g Pg0KPiA+L2pzDQo+ID4NCj4gPi0tIA0KPiA+SnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAg ICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gPlBob25lOiArNDkgNDIxIDIwMCAz NTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4gPkZh eDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNp dHkuZGUvPg0KPiANCg0KLS0gDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29i cyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAg ICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEg MjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFp bGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kDQoNCg0K From nobody Fri Dec 2 13:17:48 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978EC120725; Fri, 2 Dec 2016 13:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 V965sJeLN00h; Fri, 2 Dec 2016 13:17:42 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D60128E19; Fri, 2 Dec 2016 13:17:42 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3DA90AD6; Fri, 2 Dec 2016 22:17:40 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id W91W629jsNTN; Fri, 2 Dec 2016 22:17:35 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 2 Dec 2016 22:17:39 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C6C1C2005F; Fri, 2 Dec 2016 22:17:39 +0100 (CET) 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 rfaenLYUGshu; Fri, 2 Dec 2016 22:17:39 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 65F632005E; Fri, 2 Dec 2016 22:17:39 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3D8C03D9AA52; Fri, 2 Dec 2016 22:17:39 +0100 (CET) Date: Fri, 2 Dec 2016 22:17:39 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20161202211739.GB90771@elstar.local> Mail-Followup-To: Benoit Claise , NETMOD Working Group , YANG Doctors References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: YANG Doctors , NETMOD Working Group Subject: Re: [netmod] [yang-doctors] IETF YANG module compilation: now four different compilers to check your modules. X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 21:17:45 -0000 Benoit, would it be possible to create a table that does _not_ include the specific error messages but provides the error messages via separate links? I am usually getting lost while scrolling through tables of this size... /js On Fri, Dec 02, 2016 at 06:30:27PM +0100, Benoit Claise wrote: > Dear all, > > During the IETF hackathon, I inserted two more compilers part of the daily > cron job on my web site. > Next to pyang, confdc, we know have yangdump-pro (from Yumaworks) and > yanglint (thanks to Radek for the help) > > See for the results here > . > The compilation field is based on the outcome of the 4 compilers, to the > best of my knowledge, as there is a little bit of analytic here. > > As you can see, the number of YANG modules that pass compilation dropped > . > This is fine, as the quality of the YANG modules will eventually improve. > The comparison of 4 different compilers helped tremendously finding bugs in > the compilers on one hand (many are solved already or will be solved in the > next compiler version), and clarifying the YANG specifications on the other > hand (perfect timing as draft-ietf-netmod-rfc6087bis-09 is being finalized). > > I advice you to look up your YANG modules on the web site. The new compilers > might have discovered new issues. > > Regards, Benoit > > > > > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Dec 2 13:27:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2ED12941A for ; Fri, 2 Dec 2016 13:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjcWiCOXeOr8 for ; Fri, 2 Dec 2016 13:26:52 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 83CC8129416 for ; Fri, 2 Dec 2016 13:26:48 -0800 (PST) Received: (qmail 11861 invoked by uid 0); 2 Dec 2016 21:26:43 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy10.mail.unifiedlayer.com with SMTP; 2 Dec 2016 21:26:43 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id F9Sf1u00k2SSUrH019SiQP; Fri, 02 Dec 2016 14:26:43 -0700 X-Authority-Analysis: v=2.1 cv=Zpp+dbLG c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=hr3fZA_3Cl8A:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=n5n_aSjo0skA:10 a=p48BXsAlf3bYlEjPzqgA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:Cc:To; bh=23u7vEoO9dSCuF+6vKz8Fz67xp449Qt8IMwHUjxHdPg=; b=j/uEtd+ldomqALAQkKjcyMUw8H tzcSxUntqsBl+0mWbcEeCJi2pF9RsrFzuVmhSHQPOGyRbazndPlenaJwE9Tjj9k/2VI0Moc7Su3hn l1tle0CFT5nCMj+PiI3FA0mlm; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:39607 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1cCvLr-0004U5-Ml; Fri, 02 Dec 2016 14:26:39 -0700 To: NetMod WG , NetConf WG From: Lou Berger Message-ID: Date: Fri, 2 Dec 2016 16:26:35 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cCvLr-0004U5-Ml X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:39607 X-Source-Auth: lberger@labn.net X-Email-Count: 9 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs Subject: [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 21:26:54 -0000 All, This is start of a two week poll on making draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group document. This document is unusual in that WG last call will be jointly held in both the NetConf and NetMod WGs, while adoption and day-to-day processing will take place in NetMod. Please send email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your reservations with the document. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. The poll ends December 16. Thank you, NetConf and NetMod WG Chairs From nobody Fri Dec 2 13:44:48 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E47F12941A for ; Fri, 2 Dec 2016 13:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hxjuu_F8wcMO for ; Fri, 2 Dec 2016 13:44:35 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8D812941D for ; Fri, 2 Dec 2016 13:44:35 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id w33so264472981qtc.3 for ; Fri, 02 Dec 2016 13:44:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8IYpm5ZwkCvPjNbyZRDpiJWdiF21zKCncZB2vMgLRzA=; b=T6+hwjEa/YgrKP15PETgbESbI69W3ehZc5uw5Wav4CxMpLFvfWOrDea5Zvat9J9Jzi R3azPiIsZUNN3TDIpDDCItoqefTP0rAtRZSe48z36s2aDO9xIsFOSKOkryl5ASJBXEFp niMUIM4bmO52mhsOQTjFFYTaABNwepU0FQga20u9ZLiNNjRsR2ADY16IOZL4EmJtipG+ XplUbEqLKxYYjAEpik7Xfa44nigVCmgbHmdG7OH7zuF7UW9dame2k3gwPvM243hmZ6j3 5GO+AMNT36sKhgR3gXaBX6QcX/+NiTppOxQIKzl0u+HvKkM6mi/9V5JgLht+TfLf+lDx /ZYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8IYpm5ZwkCvPjNbyZRDpiJWdiF21zKCncZB2vMgLRzA=; b=fdfgu6puACZ0anw9FWsPzJMUYNj/3hgYqAKPCGeUprJrVIEy3fF6vq2fBf7EhEoOxF Gjov+uUaQTkhg6mVFPUpJ3c57tWeJGO5xfiXj9w5xz3j6m27uoErwr5IJ0VTTdeWJWco n6kTCkj+ED23uIK7VklOdZ77yRWfbtgvpfQofujKqCWc14CEEWr2WpJCgCAX8kETTbzI V+i6QyFG5LyMfVdAAY48YDK+wA9pHu81nLh89Ea2Mk5EyX+dKSgUNvO0AegtjY71Z44H Vek1gsh1dTbjblE9JZw4HdeUzBgttrNeP++FytYkILTmbSWWJtCITT5wKTLA96S3ITmG VmCw== X-Gm-Message-State: AKaTC02bB4reKtJsYTth+jq2ROorNbIyz6LIHRzRh2DmdF0iv1KtLD5eySaEB8NDD2ldjaUlMgB0BI5lqNGJoQ== X-Received: by 10.237.63.25 with SMTP id p25mr39693832qtf.18.1480715074462; Fri, 02 Dec 2016 13:44:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.113 with HTTP; Fri, 2 Dec 2016 13:44:34 -0800 (PST) In-Reply-To: References: From: Andy Bierman Date: Fri, 2 Dec 2016 13:44:34 -0800 Message-ID: To: Lou Berger Content-Type: multipart/alternative; boundary=001a1138ed6e06fc8f0542b3d8c4 Archived-At: Cc: NetMod WG Chairs , NetConf WG , NetMod WG , NetConf WG Chairs Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 21:44:41 -0000 --001a1138ed6e06fc8f0542b3d8c4 Content-Type: text/plain; charset=UTF-8 Hi, Which specific NETMOD WG charter item authorizes this work? I have concerns about impact of this work on all YANG-based protocols. I have asked several times "how do you decide which servers need to implement the intended and applied datastores?" and never got an answer. I think an Applicability Statement is needed for this work because some systems converge so fast that the difference between intended and applied (for real edits, forget cards not plugged in) will be insignificant. Andy On Fri, Dec 2, 2016 at 1:26 PM, Lou Berger wrote: > All, > > This is start of a two week poll on making > draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group > document. This document is unusual in that WG last call will be jointly > held in both the NetConf and NetMod WGs, while adoption and day-to-day > processing > will take place in NetMod. > > Please send email to the list indicating "yes/support" or "no/do not > support". If indicating no, please state your reservations with the > document. If yes, please also feel free to provide comments you'd like > to see addressed once the document is a WG document. > > The poll ends December 16. > > Thank you, > NetConf and NetMod WG Chairs > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a1138ed6e06fc8f0542b3d8c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Which specific NETMOD WG charter it= em authorizes this work?

I have concerns about imp= act of this work on all YANG-based protocols.
I have asked severa= l times "how do you decide which servers need to
implement t= he intended and applied datastores?" and never got an answer.

I think an Applicability Statement is needed for this work= because some systems
converge so fast that the difference betwee= n intended and applied
(for real edits, forget cards not plugged = in) will be insignificant.


Andy



On Fri, Dec 2, 2016 at 1:26 PM, Lou Berger <lberger@= labn.net> wrote:
All,

This is start of a two week poll on making
draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group
document.=C2=A0 This document is unusual in that WG last call will be joint= ly
held in both the NetConf and NetMod WGs, while adoption and day-to-day proc= essing
will take place in NetMod.

Please send email to the list indicating "yes/support" or "n= o/do not
support".=C2=A0 If indicating no, please state your reservations with = the
document.=C2=A0 If yes, please also feel free to provide comments you'd= like
to see addressed once the document is a WG document.

The poll ends December 16.

Thank you,
NetConf and NetMod WG Chairs

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf<= br>

--001a1138ed6e06fc8f0542b3d8c4-- From nobody Fri Dec 2 13:46:43 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A7612941D; Fri, 2 Dec 2016 13:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8z_xXEBJhkg; Fri, 2 Dec 2016 13:46:32 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A265B12941A; Fri, 2 Dec 2016 13:46:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=941; q=dns/txt; s=iport; t=1480715192; x=1481924792; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4LEyasIEqJ9aVOq1Qed3SQTaEFzRlVykImySqf56V1A=; b=g8jzob3mfa3bc/lMJfhlkolAJV6G9Y9xHF5l49D+gSNMn+vDqf8P/EqB /KKywnOGiCv0kY2Tg64S2BFSBSItIwry217mb0gc+f3nzb62C97H+JiaY 0q+n2F8j6HkrIGcHnRW8UAaRv2AyoPWHn7CV6DsrEDuT8+AR/4uwizj9Z A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQB160FY/49dJa1WBhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM4AQEBAQEfWoEGB40/rAeCBh4LhS9KAoIdPxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRpAgQBATg0CxACAQgOKBAnCyUCBAENBYhvDq5li0QBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEXBYsZhBsRAQ6FbwWaYwGRE4FyhHyJS5IMAR83YTgjhTJyhlCBIYE?= =?us-ascii?q?NAQEB?= X-IronPort-AV: E=Sophos;i="5.33,288,1477958400"; d="scan'208";a="181708374" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Dec 2016 21:46:26 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id uB2LkQcC029780 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Dec 2016 21:46:26 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 2 Dec 2016 16:46:25 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 2 Dec 2016 16:46:25 -0500 From: "Acee Lindem (acee)" To: Lou Berger , NetMod WG , NetConf WG Thread-Topic: [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 Thread-Index: AQHSTOLZwuoJLAnCWkuIzILo37i0BaD1MUUA Date: Fri, 2 Dec 2016 21:46:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.204] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs Subject: Re: [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 21:46:37 -0000 Yes/Support On 12/2/16, 4:26 PM, "netmod on behalf of Lou Berger" wrote: >All, > >This is start of a two week poll on making >draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group >document. This document is unusual in that WG last call will be jointly >held in both the NetConf and NetMod WGs, while adoption and day-to-day >processing >will take place in NetMod. > >Please send email to the list indicating "yes/support" or "no/do not >support". If indicating no, please state your reservations with the >document. If yes, please also feel free to provide comments you'd like >to see addressed once the document is a WG document. > >The poll ends December 16. > >Thank you, >NetConf and NetMod WG Chairs > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Dec 2 14:04:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308DB129429 for ; Fri, 2 Dec 2016 14:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLbe-C9T-AG1 for ; Fri, 2 Dec 2016 14:04:35 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id D36C3129430 for ; Fri, 2 Dec 2016 14:04:33 -0800 (PST) Received: (qmail 13304 invoked by uid 0); 2 Dec 2016 22:04:29 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy7.mail.unifiedlayer.com with SMTP; 2 Dec 2016 22:04:28 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id FA4P1u00v2SSUrH01A4Shy; Fri, 02 Dec 2016 15:04:27 -0700 X-Authority-Analysis: v=2.1 cv=E8Je+8tl c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=n5n_aSjo0skA:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=7UnvXNs-l5HMQwuUSsoA:9 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject; bh=JAl095fmHBtDoodxllT5aimewgeyeQ4PcPvQTRvpdlw=; b=THYgVsfm151YMS5slXLf5o6KYP N12YZhedTWDRWqzfTNmE4PK3kDyj4S0OjkS9CYR+cEoV5rlI3dFAyN68PvtiaFXM7NOm5wA+47R/T 5VKLjktbX5o72cQW/dq1vHEV7; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:33159 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1cCvwP-0001AB-9k; Fri, 02 Dec 2016 15:04:25 -0700 To: Andy Bierman References: From: Lou Berger Message-ID: <1591c9b5-5949-bf16-0dee-f8d34cc45011@labn.net> Date: Fri, 2 Dec 2016 17:04:21 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cCvwP-0001AB-9k X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:33159 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: NetMod WG Chairs , NetConf WG , NetMod WG , NetConf WG Chairs Subject: [netmod] Charter updates (was: [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 22:04:37 -0000 Andy, There are different approaches to detail in charters, I'm personally comfortable with this work being covered by our/netmod current charter(under supporting ongoing deployment of YANG). This said, the chairs expect there to be discussions with our AD on respective charter updates. Obviously the WG will have an opportunity to provide input on any update. Do you have any specific changes you'd like to propose? Thanks, Lou On 12/2/2016 4:44 PM, Andy Bierman wrote: > Hi, > > Which specific NETMOD WG charter item authorizes this work? > > I have concerns about impact of this work on all YANG-based protocols. > I have asked several times "how do you decide which servers need to > implement the intended and applied datastores?" and never got an answer. > > I think an Applicability Statement is needed for this work because > some systems > converge so fast that the difference between intended and applied > (for real edits, forget cards not plugged in) will be insignificant. > > > Andy > > > > On Fri, Dec 2, 2016 at 1:26 PM, Lou Berger > wrote: > > All, > > This is start of a two week poll on making > draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group > document. This document is unusual in that WG last call will be > jointly > held in both the NetConf and NetMod WGs, while adoption and > day-to-day processing > will take place in NetMod. > > Please send email to the list indicating "yes/support" or "no/do not > support". If indicating no, please state your reservations with the > document. If yes, please also feel free to provide comments you'd > like > to see addressed once the document is a WG document. > > The poll ends December 16. > > Thank you, > NetConf and NetMod WG Chairs > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > From nobody Fri Dec 2 14:15:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C018812944E for ; Fri, 2 Dec 2016 14:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCTqOhv97uIN for ; Fri, 2 Dec 2016 14:15:47 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50C4E12943C for ; Fri, 2 Dec 2016 14:15:47 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id w33so265123296qtc.3 for ; Fri, 02 Dec 2016 14:15:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KRSTtgEZbJn2/mAnz5KpGjDt64P45uF/C/B4kkBY8Wg=; b=Q33zLthpedG7aMbPx3/IRaaZ1L5oXg+jdXz5LoivUokKfaQn8cpy1XtjzoxxjY5Amj TxSMuEQ+g1sYl8vGsfFTz77wtb7t7VIaQNhtpagMNN3xLiNiKknVkPaIGLCaOFsRHczi ZLCnwary0u7i1UbE81QB6a6u1ytKCiyTvTvN/HuWdbTdP1JpeZzDFTBlzpue1g91vvsx dWXHrTKFibRJqMgCUp7/iXuuc8Rf3Al16uQ5jMcNNvIHeoe+qZY0uVocmGkXilO6dLHd 41EvogA3PRoTDuLdH9b4HJtEubkVsdEhCi7mLBYTK0VccleZJzzHaLMbPhAP+crW9yFj qcYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KRSTtgEZbJn2/mAnz5KpGjDt64P45uF/C/B4kkBY8Wg=; b=OafmzNnAtS2cn2buyuN+lq3zrPeIMvmAj9AVLLCQRSgmDUBD0oiEiB1KFot5mNzBz/ qPDsw/Lc0h8Kd6xqzOmGrGuZFi7SzcEJ/XJLHVpN7lBVjmPIHd1cAxFARqSjZq/nBSFs xICsoS3spzpxLnbCOkgrcPkbd7ISqt8jxRSUT5DNL3P7aSdpo6G9xayadArm5aHaXplG 4z7UBZk8/1XHAufTlI9WZ9O7LJurfBnXdWEq9af8n8LjEtgYliVbq+Lk5UKJYZks35xW 3Cq86iIsVmHbZQY2lsL6QiRLrCvgTPrSeYy7eIDHrNUcZeWIAdXGCqo44O1Cx9MCFKL+ ssow== X-Gm-Message-State: AKaTC0047WjwkaSr9ogTnMQ62HuoPLLPgpQ6O5AaGGMkEQfGwnk3oWI5uSdw6fy4xCUh6yvHZOpLAzPbd4Ts5Q== X-Received: by 10.200.37.52 with SMTP id 49mr39251698qtm.240.1480716946466; Fri, 02 Dec 2016 14:15:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.113 with HTTP; Fri, 2 Dec 2016 14:15:46 -0800 (PST) In-Reply-To: <1591c9b5-5949-bf16-0dee-f8d34cc45011@labn.net> References: <1591c9b5-5949-bf16-0dee-f8d34cc45011@labn.net> From: Andy Bierman Date: Fri, 2 Dec 2016 14:15:46 -0800 Message-ID: To: Lou Berger Content-Type: multipart/alternative; boundary=001a1135b1ec9b87480542b44748 Archived-At: Cc: NetMod WG Chairs , NetConf WG , NetMod WG , NetConf WG Chairs Subject: Re: [netmod] Charter updates (was: [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 22:15:50 -0000 --001a1135b1ec9b87480542b44748 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 2, 2016 at 2:04 PM, Lou Berger wrote: > Andy, > > There are different approaches to detail in charters, I'm personally > comfortable with this work being covered by our/netmod current > charter(under supporting ongoing deployment of YANG). This said, the > chairs expect there to be discussions with our AD on respective charter > updates. Obviously the WG will have an opportunity to provide input on > any update. > > Do you have any specific changes you'd like to propose? > > I assume you mean this bullet in the charter: The NETMOD WG may also develop any additional data models written in YANG that the WG considers core building blocks and that do not fall under the charters of other active IETF working groups. The NETMOD WG may simply add such milestones as it sees fit, with the advice and consent of the responsible AD. I do not have charter changes to propose. > Thanks, > > Lou > > Andy > > On 12/2/2016 4:44 PM, Andy Bierman wrote: > > Hi, > > > > Which specific NETMOD WG charter item authorizes this work? > > > > I have concerns about impact of this work on all YANG-based protocols. > > I have asked several times "how do you decide which servers need to > > implement the intended and applied datastores?" and never got an answer. > > > > I think an Applicability Statement is needed for this work because > > some systems > > converge so fast that the difference between intended and applied > > (for real edits, forget cards not plugged in) will be insignificant. > > > > > > Andy > > > > > > > > On Fri, Dec 2, 2016 at 1:26 PM, Lou Berger > > wrote: > > > > All, > > > > This is start of a two week poll on making > > draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group > > document. This document is unusual in that WG last call will be > > jointly > > held in both the NetConf and NetMod WGs, while adoption and > > day-to-day processing > > will take place in NetMod. > > > > Please send email to the list indicating "yes/support" or "no/do not > > support". If indicating no, please state your reservations with the > > document. If yes, please also feel free to provide comments you'd > > like > > to see addressed once the document is a WG document. > > > > The poll ends December 16. > > > > Thank you, > > NetConf and NetMod WG Chairs > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > --001a1135b1ec9b87480542b44748 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Dec 2, 2016 at 2:04 PM, Lou Berger <lberger@labn.net> wrote:
Andy,

There are different approaches to detail in charters, I'm personally comfortable with this work being covered by our/netmod current
charter(under supporting ongoing deployment of YANG).=C2=A0 This said, the<= br> chairs expect there to be discussions with our AD on respective charter
updates.=C2=A0 Obviously the WG will have an opportunity to provide input o= n
any update.

Do you have any specific=C2=A0 changes you'd like to propose?


I assume you mean this bullet in the c= harter:

The NETMOD WG may also develop any additional data models written in YAN= G that the WG considers core building blocks and that do not fall under the= charters of other active IETF working groups. The NETMOD WG may simply add= such milestones as it sees fit, with the advice and consent of the respons= ible AD.


I do not have chart= er changes to propose.


=C2=A0
=
Thanks,

Lou



Andy
=C2=A0

On 12/2/2016 4:44 PM, Andy Bierman wrote:
> Hi,
>
> Which specific NETMOD WG charter item authorizes this work?
>
> I have concerns about impact of this work on all YANG-based protocols.=
> I have asked several times "how do you decide which servers need = to
> implement the intended and applied datastores?" and never got an = answer.
>
> I think an Applicability Statement is needed for this work because
> some systems
> converge so fast that the difference between intended and applied
> (for real edits, forget cards not plugged in) will be insignificant. >
>
> Andy
>
>
>
> On Fri, Dec 2, 2016 at 1:26 PM, Lou Berger <lberger@labn.net
> <mailto:lberger@labn.net>= ;> wrote:
>
>=C2=A0 =C2=A0 =C2=A0All,
>
>=C2=A0 =C2=A0 =C2=A0This is start of a two week poll on making
>=C2=A0 =C2=A0 =C2=A0draft-nmdsdt-netmod-revised-datastores-00 a Ne= tMod working group
>=C2=A0 =C2=A0 =C2=A0document.=C2=A0 This document is unusual in that WG= last call will be
>=C2=A0 =C2=A0 =C2=A0jointly
>=C2=A0 =C2=A0 =C2=A0held in both the NetConf and NetMod WGs, while adop= tion and
>=C2=A0 =C2=A0 =C2=A0day-to-day processing
>=C2=A0 =C2=A0 =C2=A0will take place in NetMod.
>
>=C2=A0 =C2=A0 =C2=A0Please send email to the list indicating "yes/= support" or "no/do not
>=C2=A0 =C2=A0 =C2=A0support".=C2=A0 If indicating no, please state= your reservations with the
>=C2=A0 =C2=A0 =C2=A0document.=C2=A0 If yes, please also feel free to pr= ovide comments you'd
>=C2=A0 =C2=A0 =C2=A0like
>=C2=A0 =C2=A0 =C2=A0to see addressed once the document is a WG document= .
>
>=C2=A0 =C2=A0 =C2=A0The poll ends December 16.
>
>=C2=A0 =C2=A0 =C2=A0Thank you,
>=C2=A0 =C2=A0 =C2=A0NetConf and NetMod WG Chairs
>
>=C2=A0 =C2=A0 =C2=A0______________________________________________= _
>=C2=A0 =C2=A0 =C2=A0Netconf mailing list
>=C2=A0 =C2=A0 =C2=A0Netconf@ietf.or= g <mailto:Netconf@ietf.org&g= t;
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/netconf
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailma= n/listinfo/netconf>
>
>


--001a1135b1ec9b87480542b44748-- From nobody Fri Dec 2 16:45:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560F01294AA for ; Fri, 2 Dec 2016 16:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RquALSAtzWsQ for ; Fri, 2 Dec 2016 16:45:26 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C751294A4 for ; Fri, 2 Dec 2016 16:45:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4875; q=dns/txt; s=iport; t=1480725925; x=1481935525; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mnBhw2w8n7ET1bwP6G3qtwsgCLKzm1Pr909NhJ1nBY0=; b=RFKW03aoOlKUKoW2cQhK4nghKSVyMNChveKlJwUc3Lklmn3Xb3gY7TMQ q5IkJB8jbq6O8q+qe3lW5JxCONiXcX6T2veoCLiKbN+I53clabj0ZZ1ze A9NXJsRhCWUj26exyz7/stJaN13poi4CUkXX9tB94vfXamaOYMGNLvy4B w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AzAQD+FEJY/4kNJK1ZAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM4AQEBAQEfWoEGB41AlwuUfIIIHguFL0oCgh0/FAECAQEBAQE?= =?us-ascii?q?BAWIohGkBAQQBAWwLDgICAQgOAggYFhsMCyUCBAENBRuIVA6udItFAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHAWLFIQSWCAGB4UTBY88iygBiVqHOYFyiD6GCY4AhAw?= =?us-ascii?q?BHzeBGSODOhuBXXKHcYENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,289,1477958400"; d="scan'208";a="180963497" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Dec 2016 00:45:24 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uB30jOli022306 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 3 Dec 2016 00:45:24 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.1210.3; Fri, 2 Dec 2016 19:45:23 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 2 Dec 2016 19:45:23 -0500 From: "Acee Lindem (acee)" To: Kent Watsen , Juergen Schoenwaelder Thread-Topic: [netmod] Key Strings in ietf-key-chain operational state Thread-Index: AQHSS6vaEFwy9pC/jk+kWPZA/iaYSqDzGCCAgACEXQCAAdGgAP//95GA Date: Sat, 3 Dec 2016 00:45:23 +0000 Message-ID: References: <20161201082049.GA1748@elstar.local> <20161201162854.GA89230@elstar.local> <83DB4ED2-F0BB-47CB-BB1E-981CA48098C5@juniper.net> In-Reply-To: <83DB4ED2-F0BB-47CB-BB1E-981CA48098C5@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.204] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6C4463942151FF43A9BD4EA7F701E4D5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Key Strings in ietf-key-chain operational state X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 00:45:28 -0000 Hi Kent,=20 So are you suggesting the nacm:default-deny-all for key strings rather than omitting it from the operational state? Thanks, Acee=20 On 12/2/16, 3:15 PM, "Kent Watsen" wrote: >Hi Acee, > >Sorry for being late to this thread. As Mehesh mentioned, this aspect of >the keystore mode is currently open, and being tracked by github issue >#2. =20 > >It is my understanding that the working group would like to pursue a >strategy that supports backup/restore operations to the greatest extent >possible. =20 > >In order to prevent unauthorized access, NACM rules can be used to mark >the private key data leaf (not its parent list entry) with >=B3nacm:default-deny-all=B2. > >In order to support hardware protected keys, the private key data leaf >can be marked as mandatory false, with the explanation that, if not >returned, it might be because the key is protected by hardware. > >Not stated yet, but the thinking is that the private key data leaf would >be config true, to support the backup/restore case of the NC/RC client >passing the private to the device (open issue: how to direct specialized >hardware to generate a new protected key). Pertinently, for the >applied/operational-state datastores, the NACM and mandatory attributes >carry over, so still the key is protected from unauthorized access and >still the solution supports hardware protected keys. > >What do you think? > >Kent > =20 > > >On 12/1/16, 11:28 AM, "netmod on behalf of Juergen Schoenwaelder" >j.schoenwaelder@jacobs-university.de> wrote: > >OK. I misread your statement. Sorry for the noise. > >/js > >On Thu, Dec 01, 2016 at 01:35:15PM +0000, Acee Lindem (acee) wrote: >>=20 >>=20 >> On 12/1/16, 3:20 AM, "Juergen Schoenwaelder" >> wrote: >>=20 >> >On Wed, Nov 30, 2016 at 09:37:21PM +0000, Acee Lindem (acee) wrote: >> > >> >> In the days of MIBs, we used to omit key strings from the data that >> >>would be returned. This was ostensibly done for security purposes. >> > >> >This is not correct. In SMIv2, INDEX objects are not accessible >> >because the values of these objects are embedded in the instance >> >identifier. In other words, making INDEX objects not-accessible was a >> >performance optimization, forcing SNMP managers to extract the INDEX >> >object values out of the instance identifiers. Making INDEX objects >> >not accessible does _not_ hide any information. >>=20 >> This is a different issue. What I am referring to is never returning the >> keys in a read request (get, get-next, get-many, etc). For example, >> (excerpted from RFC 4750): >>=20 >> ospfIfAuthKey OBJECT-TYPE >> SYNTAX OCTET STRING (SIZE (0..256)) >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "The cleartext password used as an OSPF >> authentication key when simplePassword security >> is enabled. This object does not access any OSPF >> cryptogaphic (e.g., MD5) authentication key under >> any circumstance. >>=20 >> If the key length is shorter than 8 octets, the >> agent will left adjust and zero fill to 8 octets. >>=20 >> Unauthenticated interfaces need no authentication >> key, and simple password authentication cannot use >> a key of more than 8 octets. >>=20 >> Note that the use of simplePassword authentication >> is NOT recommended when there is concern regarding >> attack upon the OSPF system. SimplePassword >> authentication is only sufficient to protect against >> accidental misconfigurations because it re-uses >> cleartext passwords [RFC1704]. >>=20 >> When read, ospfIfAuthKey always returns an octet >> string of length zero." >> REFERENCE >> "OSPF Version 2, Section 9 The Interface Data >> Structure" >> DEFVAL { '0000000000000000'H } -- 0.0.0.0.0.0.0.0 >> ::=3D { ospfIfEntry 16 } >>=20 >>=20 >>=20 >> Thanks, >> Acee=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> > >> >/js >> > >> >--=20 >> >Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> >Fax: +49 421 200 3103 >>=20 > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >Fax: +49 421 200 3103 > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod > > From nobody Sat Dec 3 01:01:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBBF12963A; Sat, 3 Dec 2016 01:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 8kxv2ARa2CTA; Sat, 3 Dec 2016 01:01:28 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57C96129635; Sat, 3 Dec 2016 01:01:27 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 85E38103A; Sat, 3 Dec 2016 10:01:26 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id kl8ad5zDwa8q; Sat, 3 Dec 2016 10:01:26 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 3 Dec 2016 10:01:26 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C1A62005E; Sat, 3 Dec 2016 10:01:26 +0100 (CET) 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 12nbU9Rgu4pK; Sat, 3 Dec 2016 10:01:25 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C1D652005F; Sat, 3 Dec 2016 10:01:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B865D3D9B2AF; Sat, 3 Dec 2016 10:01:25 +0100 (CET) Date: Sat, 3 Dec 2016 10:01:25 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20161203090125.GB91185@elstar.local> Mail-Followup-To: Andy Bierman , NetMod WG Chairs , NetConf WG , NetMod WG , NetConf WG Chairs References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NetMod WG Chairs , NetConf WG , NetMod WG , NetConf WG Chairs Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 09:01:30 -0000 On Fri, Dec 02, 2016 at 01:44:34PM -0800, Andy Bierman wrote: > > I have concerns about impact of this work on all YANG-based protocols. > I have asked several times "how do you decide which servers need to > implement the intended and applied datastores?" and never got an answer. > I do not think people proposed to make the implementation of intended and applied datastores mandatory to implement. What this proposal is trying to achieve is to provide an architectural framework that allows to provide access to additional datastores without having to write data models in certain ways. Keeping the specific datastore semantics out of data models (and thereby simplifying data models) is what I see as the main value of this work. > I think an Applicability Statement is needed for this work because some > systems > converge so fast that the difference between intended and applied > (for real edits, forget cards not plugged in) will be insignificant. The current I-D says in section 6.1: o Support for , , and should be optional to implement. /js PS: Do we have to run the discussion via cross-posts on two lists or can the chairs agree to just use one list, assuming that those who care can manage to follow this one list? -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sat Dec 3 06:58:06 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC5F129891; Sat, 3 Dec 2016 06:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Abk5ADna5xaq; Sat, 3 Dec 2016 06:58:01 -0800 (PST) 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 F35C9129890; Sat, 3 Dec 2016 06:58:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1853; q=dns/txt; s=iport; t=1480777081; x=1481986681; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=YoC365yyyKP9T/HzWRO1qQU82jmHoOop0v6VuYtf3z4=; b=dCRlNeWAbQuxr3QTpJ6YlY9jBV7JfqOmeFALbO+tBUkb5kv1YdRSVEiX SGroTpQr0kIt2uQlf4HOjQZaWj2g4C8z0QvqQ1gpqkaQG+Nr/Ij+Hcwv5 kowl70Vr/jLy3/nzWF5tXhEcIWtpk0nDjB/g2x/oRo5iicC8vAMSpRYQj o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AADb3EJY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzgBAQEBAXmBBo1HlwuUfYIIHguFeQKCXBQBAgEBAQEBAQFiKIR?= =?us-ascii?q?pAQEEAQE2NhsLGCMLJzAGAQwGAgEBiGsOr2yLPgEBAQEBAQEDAQEBAQEBASCGP?= =?us-ascii?q?oF9gVaBCIoLHgEEmmaGS4pMgkKHT4Ysih+DY4QNHzd4Ew4jg22BRj00AYl/AQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.33,736,1477958400"; d="scan'208";a="647580329" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Dec 2016 14:57:34 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uB3EvXa7021536; Sat, 3 Dec 2016 14:57:34 GMT To: NETMOD Working Group , YANG Doctors References: <20161202211739.GB90771@elstar.local> From: Benoit Claise Message-ID: <4e87b595-fb1c-50b3-076e-513300e7c721@cisco.com> Date: Sat, 3 Dec 2016 15:57:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <20161202211739.GB90771@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] [yang-doctors] IETF YANG module compilation: now four different compilers to check your modules. X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 14:58:03 -0000 Hi Juergen, Thanks for the interest. I could, but this is a presentation layer task, and hence a low priority for me :-) Regards, Benoit > Benoit, > > would it be possible to create a table that does _not_ include the > specific error messages but provides the error messages via separate > links? I am usually getting lost while scrolling through tables of > this size... > > /js > > On Fri, Dec 02, 2016 at 06:30:27PM +0100, Benoit Claise wrote: >> Dear all, >> >> During the IETF hackathon, I inserted two more compilers part of the daily >> cron job on my web site. >> Next to pyang, confdc, we know have yangdump-pro (from Yumaworks) and >> yanglint (thanks to Radek for the help) >> >> See for the results here >> . >> The compilation field is based on the outcome of the 4 compilers, to the >> best of my knowledge, as there is a little bit of analytic here. >> >> As you can see, the number of YANG modules that pass compilation dropped >> . >> This is fine, as the quality of the YANG modules will eventually improve. >> The comparison of 4 different compilers helped tremendously finding bugs in >> the compilers on one hand (many are solved already or will be solved in the >> next compiler version), and clarifying the YANG specifications on the other >> hand (perfect timing as draft-ietf-netmod-rfc6087bis-09 is being finalized). >> >> I advice you to look up your YANG modules on the web site. The new compilers >> might have discovered new issues. >> >> Regards, Benoit >> >> >> >> >> >> >> _______________________________________________ >> yang-doctors mailing list >> yang-doctors@ietf.org >> https://www.ietf.org/mailman/listinfo/yang-doctors > From nobody Sun Dec 4 21:38:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E667A12943C for ; Sun, 4 Dec 2016 21:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.116 X-Spam-Level: X-Spam-Status: No, score=-7.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, 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 YrDxiv-Q9CMr for ; Sun, 4 Dec 2016 21:38:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02451126BF6 for ; Sun, 4 Dec 2016 21:38:19 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CWN89750; Mon, 05 Dec 2016 05:38:17 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 5 Dec 2016 05:38:15 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.151]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Mon, 5 Dec 2016 13:38:12 +0800 From: Daixinning To: "netmod@ietf.org" Thread-Topic: A question about data tree Thread-Index: AdJOuXqJMW+jldgjQhqKGMPnoDan8Q== Date: Mon, 5 Dec 2016 05:38:12 +0000 Message-ID: <73CF6B172361F5419537C3F59B2C0A092FEAA88B@nkgeml513-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.27.15] Content-Type: multipart/alternative; boundary="_000_73CF6B172361F5419537C3F59B2C0A092FEAA88Bnkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0204.5844FD49.02C4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.151, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6b186e8f135d3cfd70623ec615c19a12 Archived-At: Subject: [netmod] A question about data tree X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 05:38:23 -0000 --_000_73CF6B172361F5419537C3F59B2C0A092FEAA88Bnkgeml513mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, RFC7950 has defined a terminology "data tree", shown as below: o data tree: An instantiated tree of any data modeled with YANG, e.g., configuration data, state data, combined configuration and state data, RPC or action input, RPC or action output, or notification. I have a question on this issue, that is, Whether the content of the node in is a "data tree",= and does it need to follow the constraints of the "data tree" (e.g., The c= ontainer node exists an most one instance in the data tree). For example, the netconf message content is like this xxx@yyy.com Ubuntu-test-01 These two tags is disobeyed the constraint or not? Thanks. --_000_73CF6B172361F5419537C3F59B2C0A092FEAA88Bnkgeml513mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

RFC7950 has defined a terminolo= gy “data tree”, shown as below:

   o  data tree:= An instantiated tree of any data modeled with YANG,

      = e.g., configuration data, state data, combined configuration and=

      = state data, RPC or action input, RPC or action output, or=

      = notification.

 

I have a question on this issue= , that is,

Whether the content of the <= config> node in <edit-config> is a “data tree”, and do= es it need to follow the constraints of the “data tree” (e.g., = The container node exists an most one instance in the data tree).

For example, the netconf messag= e content is like this

 

<edit-config><= /span>

    <target&g= t;<running/></target>

    <config&g= t;

     &= nbsp;  <system xmlns=3D" urn:ietf:params:xml:ns:yang:ietf-syst= em">

     &= nbsp;      <contact>xxx@yyy.com</contact&= gt;

     &= nbsp;  </system>

     &= nbsp;  <system xmlns=3D" urn:ietf:params:xml:ns:yang:ietf-syst= em">

     &= nbsp;      <hostname>Ubuntu-test-01</host= name>

     &= nbsp;  </system>

    </config&= gt;

</edit-config>=

 

These two <system> tags i= s disobeyed the constraint or not?

 

Thanks.

--_000_73CF6B172361F5419537C3F59B2C0A092FEAA88Bnkgeml513mbxchi_-- From nobody Mon Dec 5 01:18:39 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC8F129410; Mon, 5 Dec 2016 01:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 sXGrpyO9gpjB; Mon, 5 Dec 2016 01:18:35 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56457129849; Mon, 5 Dec 2016 01:18:34 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:40e6:f180:9f62:2967] (unknown [IPv6:2001:718:1a02:1:40e6:f180:9f62:2967]) by mail.nic.cz (Postfix) with ESMTPSA id C0A7B62434; Mon, 5 Dec 2016 10:18:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1480929512; bh=UHx8ukW22D7DEMtClWtZ/Qj40Ih+59BENQXFYY9g9t0=; h=From:Date:To; b=j1FzB5CTLviMyFKzrD19u2GQ3MOhOWouZwpVaL2LSktUKUL+ad4rVbZiCET21nKVS MQVoYOSCFCGCQmioUQs84jbq/SfhJP4PWGR6Nr2j5/MdRHpFijPzYnG0T4OLpoeN01 Mn9TKj7EiVNZo+iFSp/BvJTcoPW4wHi5NmsELhdY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 5 Dec 2016 10:18:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Lou Berger X-Mailer: Apple Mail (2.3251) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG Chairs , Netconf , NetMod WG , NetConf WG Chairs Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 09:18:37 -0000 > On 2 Dec 2016, at 22:26, Lou Berger wrote: >=20 > All, >=20 > This is start of a two week poll on making > draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group > document. This document is unusual in that WG last call will be = jointly > held in both the NetConf and NetMod WGs, while adoption and day-to-day = processing > will take place in NetMod. There seems to be no impact on YANG syntax or semantics - the one = mentioned in sec. 6.3 is in fact protocol stuff that doesn't belong to = the definition of YANG the language. Therefore, this work has nothing to = do with data modelling and in fact belongs to the NETCONF WG. This would = also solve the indicated WG schizophrenia that should IMO be avoided in = any case. A useful thing to do in the NETMOD WG would be to remove all = NETCONF-specific text from the YANG spec because whenever YANG is used = outside the NETCONF context (I2RS, CORE), that text is mostly ignored = anyway. Lada=20 >=20 > Please send email to the list indicating "yes/support" or "no/do not > support". If indicating no, please state your reservations with the > document. If yes, please also feel free to provide comments you'd = like > to see addressed once the document is a WG document. >=20 > The poll ends December 16. >=20 > Thank you, > NetConf and NetMod WG Chairs >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Dec 5 01:39:06 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D52F129855; Mon, 5 Dec 2016 01:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 oYUWC6g7qQFQ; Mon, 5 Dec 2016 01:39:01 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F643129410; Mon, 5 Dec 2016 01:39:01 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 42DCD74C; Mon, 5 Dec 2016 10:38:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 9nlEIrjCTLiv; Mon, 5 Dec 2016 10:38:58 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 5 Dec 2016 10:38:58 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2B912005F; Mon, 5 Dec 2016 10:38:58 +0100 (CET) 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 mSUSC_FTWkWC; Mon, 5 Dec 2016 10:38:58 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2925B2005E; Mon, 5 Dec 2016 10:38:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1F26B3D9D805; Mon, 5 Dec 2016 10:38:58 +0100 (CET) Date: Mon, 5 Dec 2016 10:38:58 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20161205093858.GA97253@elstar.local> Mail-Followup-To: Ladislav Lhotka , Lou Berger , NetMod WG Chairs , Netconf , NetMod WG , NetConf WG Chairs References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NetMod WG Chairs , Netconf , NetMod WG , NetConf WG Chairs Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 09:39:04 -0000 On Mon, Dec 05, 2016 at 10:18:32AM +0100, Ladislav Lhotka wrote: > > > On 2 Dec 2016, at 22:26, Lou Berger wrote: > > > > All, > > > > This is start of a two week poll on making > > draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group > > document. This document is unusual in that WG last call will be jointly > > held in both the NetConf and NetMod WGs, while adoption and day-to-day processing > > will take place in NetMod. > > There seems to be no impact on YANG syntax or semantics - the one mentioned in sec. 6.3 is in fact protocol stuff that doesn't belong to the definition of YANG the language. Therefore, this work has nothing to do with data modelling and in fact belongs to the NETCONF WG. This would also solve the indicated WG sch izophrenia that should IMO be avoided in any case. I disagree that the datastore model is a protocol specific aspect. I consider datastores an architectural component binding data models and protocols together. In fact, the 'traditional' datastore model together with the semantics of the operation caused us to write data models in a very specific way. Since the number of protocols transporting YANG defined data is growing, it is crucial that architectural aspects are more clearly spelled out as such. (And the only architectural document we have so far was done in NETMOD. But at the end, I find the discussion which WG is responsible somewhat pointless, it is the same set of active technical contributors anyway.) > A useful thing to do in the NETMOD WG would be to remove all > NETCONF-specific text from the YANG spec because whenever YANG is > used outside the NETCONF context (I2RS, CORE), that text is mostly > ignored anyway. If there is an opportunity to update all core documents together, we may clean up some of this; so far, we never had such an opportunity. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Dec 5 02:37:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0AB412995B; Mon, 5 Dec 2016 02:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 umjIknFlKkjp; Mon, 5 Dec 2016 02:37:27 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15CD129427; Mon, 5 Dec 2016 02:36:12 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:40e6:f180:9f62:2967] (unknown [IPv6:2001:718:1a02:1:40e6:f180:9f62:2967]) by mail.nic.cz (Postfix) with ESMTPSA id B0E0E62183; Mon, 5 Dec 2016 11:36:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1480934171; bh=YHmJ5CSG4pDC92qjX7TVjzQ4VXJsH7Rxt923z+Xp3zk=; h=From:Date:To; b=Jp0AP8eB8rzSXVlAw4b9Tl8LxgXyiFtY1hsDcuLJL1clcdPGXayu7JTqXMIAT3qSB j99ShBorT9L2ZYrFLH00uTIZnNKzXpd3DTLzINQPR6Ppsi4j15Ott/5mejvoLN/u6v iGXQwDHYo63yuPZ4qybc6y3ikuBT9Tx0UjuFVI34= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Ladislav Lhotka In-Reply-To: <20161205093858.GA97253@elstar.local> Date: Mon, 5 Dec 2016 11:36:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> References: <20161205093858.GA97253@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3251) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG Chairs , Netconf , NetMod WG , NetConf WG Chairs Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 10:37:29 -0000 > On 5 Dec 2016, at 10:38, Juergen Schoenwaelder = wrote: >=20 > On Mon, Dec 05, 2016 at 10:18:32AM +0100, Ladislav Lhotka wrote: >>=20 >>> On 2 Dec 2016, at 22:26, Lou Berger wrote: >>>=20 >>> All, >>>=20 >>> This is start of a two week poll on making >>> draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group >>> document. This document is unusual in that WG last call will be = jointly >>> held in both the NetConf and NetMod WGs, while adoption and = day-to-day processing >>> will take place in NetMod. >>=20 >> There seems to be no impact on YANG syntax or semantics - the one = mentioned in sec. 6.3 is in fact protocol stuff that doesn't belong to = the definition of YANG the language. Therefore, this work has nothing to = do with data modelling and in fact belongs to the NETCONF WG. This would = also solve the indicated WG sch > izophrenia that should IMO be avoided in any case. >=20 > I disagree that the datastore model is a protocol specific aspect. I > consider datastores an architectural component binding data models and > protocols together. In fact, the 'traditional' datastore model I would agree with this if datastores were a general concept in YANG, = but the revised-datastores draft explicitly introduces the "intended" = and "applied" datastores that may be irrelevant to other protocols using = YANG, and even needn't be used in all NETCONF implementations. I = wouldn't call this "an architectural component" of YANG. If you are saying that it will have nontrivial impact on YANG, I would = like to see it explained in sec. 6.3. Without this information I am = quite reluctant to agree with the adoption. > together with the semantics of the operation caused us to write > data models in a very specific way. Since the number of protocols Yes, to work around a flaw in the NETCONF protocol. > transporting YANG defined data is growing, it is crucial that > architectural aspects are more clearly spelled out as such. (And the See above - architectural aspects need to be relevant to all protocols. > only architectural document we have so far was done in NETMOD. But at > the end, I find the discussion which WG is responsible somewhat > pointless, it is the same set of active technical contributors > anyway.) Mehmet rightly argued in Seoul that this work should be done in NETMOD = WG because it will certainly have implications for the NETCONF protocol. = It is thus understandable that NETCONF chairs want to exercise some = control. >=20 >> A useful thing to do in the NETMOD WG would be to remove all >> NETCONF-specific text from the YANG spec because whenever YANG is >> used outside the NETCONF context (I2RS, CORE), that text is mostly >> ignored anyway. >=20 > If there is an opportunity to update all core documents together, we > may clean up some of this; so far, we never had such an opportunity. I don't know what you mean by all core documents. In my view, it would = be sufficient to split RFC 7950 into two documents - the other one could = be something like "Adapting NETCONF for use with YANG". If we don't do this, it is difficult to propose YANG for use with other = protocols (as we did for I2RS) because we have to say: "You know, some = parts of the YANG spec appear mandatory but they are irrelevant for you, = so just ignore them". This was actually the case already for RESTCONF. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Dec 5 02:42:04 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E0F129976; Mon, 5 Dec 2016 02:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 zaImqIRtwnmO; Mon, 5 Dec 2016 02:41:58 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C605129995; Mon, 5 Dec 2016 02:40:16 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:40e6:f180:9f62:2967] (unknown [IPv6:2001:718:1a02:1:40e6:f180:9f62:2967]) by mail.nic.cz (Postfix) with ESMTPSA id DBBC462467; Mon, 5 Dec 2016 11:40:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1480934414; bh=y4uKPDTuV2SN7GbYK1QJFpDGJvMQ8uUxyj7IJU4+PcQ=; h=From:Date:To; b=GulTGAbJ9Y1d7XrsGWm1tSethfTY1MX1eq3r5F6V0AsDbo+r/A6yM2HbZD6D6+m1X wMKLvwsbS2HgaeQWjduBJGGJwZME3C9hsZQG0UkgOZICdOVpVBS5k78sBi+UHYQG6Z ogEnz6Cd7TGq2pEyrYyuW9ktOyhd+2iu4TKEPE4A= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Ladislav Lhotka In-Reply-To: <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> Date: Mon, 5 Dec 2016 11:40:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2CAE4795-EE6A-4754-AF18-FBB7139C6B99@nic.cz> References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3251) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG Chairs , Netconf , NetMod WG , NetConf WG Chairs Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 10:42:00 -0000 > On 5 Dec 2016, at 11:36, Ladislav Lhotka wrote: >=20 >>=20 >> On 5 Dec 2016, at 10:38, Juergen Schoenwaelder = wrote: >>=20 >> On Mon, Dec 05, 2016 at 10:18:32AM +0100, Ladislav Lhotka wrote: >>>=20 >>>> On 2 Dec 2016, at 22:26, Lou Berger wrote: >>>>=20 >>>> All, >>>>=20 >>>> This is start of a two week poll on making >>>> draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group >>>> document. This document is unusual in that WG last call will be = jointly >>>> held in both the NetConf and NetMod WGs, while adoption and = day-to-day processing >>>> will take place in NetMod. >>>=20 >>> There seems to be no impact on YANG syntax or semantics - the one = mentioned in sec. 6.3 is in fact protocol stuff that doesn't belong to = the definition of YANG the language. Therefore, this work has nothing to = do with data modelling and in fact belongs to the NETCONF WG. This would = also solve the indicated WG sch >> izophrenia that should IMO be avoided in any case. >>=20 >> I disagree that the datastore model is a protocol specific aspect. I >> consider datastores an architectural component binding data models = and >> protocols together. In fact, the 'traditional' datastore model >=20 > I would agree with this if datastores were a general concept in YANG, = but the revised-datastores draft explicitly introduces the "intended" = and "applied" datastores that may be irrelevant to other protocols using = YANG, and even needn't be used in all NETCONF implementations. I = wouldn't call this "an architectural component" of YANG. >=20 > If you are saying that it will have nontrivial impact on YANG, I would = like to see it explained in sec. 6.3. Without this information I am = quite reluctant to agree with the adoption. >=20 >> together with the semantics of the operation caused us to = write >> data models in a very specific way. Since the number of protocols >=20 > Yes, to work around a flaw in the NETCONF protocol. >=20 >> transporting YANG defined data is growing, it is crucial that >> architectural aspects are more clearly spelled out as such. (And the >=20 > See above - architectural aspects need to be relevant to all = protocols. >=20 >> only architectural document we have so far was done in NETMOD. But at >> the end, I find the discussion which WG is responsible somewhat >> pointless, it is the same set of active technical contributors >> anyway.) >=20 > Mehmet rightly argued in Seoul that this work should be done in NETMOD = WG because it will certainly have implications for the NETCONF Sorry, of course I meant NETCONF WG. Lada > protocol. It is thus understandable that NETCONF chairs want to = exercise some control. >=20 >>=20 >>> A useful thing to do in the NETMOD WG would be to remove all >>> NETCONF-specific text from the YANG spec because whenever YANG is >>> used outside the NETCONF context (I2RS, CORE), that text is mostly >>> ignored anyway. >>=20 >> If there is an opportunity to update all core documents together, we >> may clean up some of this; so far, we never had such an opportunity. >=20 > I don't know what you mean by all core documents. In my view, it would = be sufficient to split RFC 7950 into two documents - the other one could = be something like "Adapting NETCONF for use with YANG". >=20 > If we don't do this, it is difficult to propose YANG for use with = other protocols (as we did for I2RS) because we have to say: "You know, = some parts of the YANG spec appear mandatory but they are irrelevant for = you, so just ignore them". This was actually the case already for = RESTCONF. >=20 > Lada >=20 >>=20 >> /js >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Dec 5 02:50:13 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2701299A9 for ; Mon, 5 Dec 2016 02:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 h7Uwpsz-ny6d for ; Mon, 5 Dec 2016 02:50:11 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AB8EE129957 for ; Mon, 5 Dec 2016 02:49:48 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 940DB1AE0118; Mon, 5 Dec 2016 11:49:47 +0100 (CET) Date: Mon, 05 Dec 2016 11:49:47 +0100 (CET) Message-Id: <20161205.114947.143688002879843595.mbj@tail-f.com> To: daixinning@huawei.com From: Martin Bjorklund In-Reply-To: <73CF6B172361F5419537C3F59B2C0A092FEAA88B@nkgeml513-mbx.china.huawei.com> References: <73CF6B172361F5419537C3F59B2C0A092FEAA88B@nkgeml513-mbx.china.huawei.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] A question about data tree X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 10:50:12 -0000 Hi, Daixinning wrote: > Hi, > > RFC7950 has defined a terminology "data tree", shown as below: > o data tree: An instantiated tree of any data modeled with YANG, > e.g., configuration data, state data, combined configuration and > state data, RPC or action input, RPC or action output, or > notification. > > I have a question on this issue, that is, > Whether the content of the node in is a "data > tree" No, the "config" is modelled as "anyxml" so it just an "XML blob". >, and does it need to follow the constraints of the "data tree" > (e.g., The container node exists an most one instance in the data > tree). > For example, the netconf message content is like this > > > > > > xxx@yyy.com > > > Ubuntu-test-01 > > > > > These two tags is disobeyed the constraint or not? No. /martin From nobody Mon Dec 5 04:03:11 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B054129A27; Mon, 5 Dec 2016 04:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 jQ8t6pYAxOGm; Mon, 5 Dec 2016 04:03:08 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B16F129A31; Mon, 5 Dec 2016 04:02:12 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 20D5AA99; Mon, 5 Dec 2016 13:02:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id jt78GQwea0BG; Mon, 5 Dec 2016 13:02:10 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 5 Dec 2016 13:02:10 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C31512005F; Mon, 5 Dec 2016 13:02:10 +0100 (CET) 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 9Aw6UPDe_AcK; Mon, 5 Dec 2016 13:02:10 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 64A4E2005E; Mon, 5 Dec 2016 13:02:10 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 43C263D9DD89; Mon, 5 Dec 2016 13:02:10 +0100 (CET) Date: Mon, 5 Dec 2016 13:02:10 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20161205120210.GA97559@elstar.local> Mail-Followup-To: Ladislav Lhotka , Lou Berger , NetMod WG Chairs , Netconf , NetMod WG , NetConf WG Chairs References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NetMod WG Chairs , Netconf , NetMod WG , NetConf WG Chairs Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 12:03:10 -0000 On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: > > > > > I disagree that the datastore model is a protocol specific aspect. I > > consider datastores an architectural component binding data models and > > protocols together. In fact, the 'traditional' datastore model > > I would agree with this if datastores were a general concept in YANG, but the revised-datastores draft explicitly introduces the "intended" and "applied" datastores that may be irrelevant to other protocols using YANG, and even needn't be used in all NETCONF implementations. I wouldn't call this "an architectural component" of YANG. > An architectural component of this new management framework (that does not have a name). The fact that not all protocols may expose all datastores is IMHO not a reason that the datastore model is not an architectural framework. > If you are saying that it will have nontrivial impact on YANG, I would like to see it explained in sec. 6.3. Without this information I am quite reluctant to agree with the adoption. An operational state datastore has implications how one writes data models. It may not directly affect YANG itself but surely the usage of YANG. > See above - architectural aspects need to be relevant to all protocols. Yes, but relevant to all protocols does not mean every protocol needs to expose say all datastores. But every protocol should be clear about how what it exposes relates to the architectural framework. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Dec 5 04:47:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509D3129484 for ; Mon, 5 Dec 2016 04:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUNPEQvHG09G for ; Mon, 5 Dec 2016 04:47:20 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 2AC54129465 for ; Mon, 5 Dec 2016 04:47:20 -0800 (PST) Received: (qmail 18382 invoked by uid 0); 5 Dec 2016 12:40:40 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy9.mail.unifiedlayer.com with SMTP; 5 Dec 2016 12:40:40 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id GCgd1u0082SSUrH01CggxY; Mon, 05 Dec 2016 05:40:40 -0700 X-Authority-Analysis: v=2.1 cv=K/+xQUmI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=n5n_aSjo0skA:10 a=Tx2h5zIgdRmTOk5BwFAA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:Cc:References:To:Subject:From; bh=DCqBbXC8ee0gDJuBC7Mtxb9wcU2g3kY3J3tyBJG31T8=; b=cD89zE7b5p1xv72bJ/U0nuT6r3 LuFOLGH0iLJt9T4R9ppKt3/NU1nh5M7UNuNTsCv0pVzYSyW0TyKU1fvgZhIKV1qdkH9GJho6uIhPD 1+lQ18U/Spg3lbQA2L3Yc+M9M; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:34670 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1cDsZR-0007qn-1f; Mon, 05 Dec 2016 05:40:37 -0700 From: Lou Berger To: Juergen Schoenwaelder , Andy Bierman References: <20161203090125.GB91185@elstar.local> Message-ID: <85303135-e96d-873e-8a79-07db261cae6c@labn.net> Date: Mon, 5 Dec 2016 07:40:31 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <20161203090125.GB91185@elstar.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cDsZR-0007qn-1f X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:34670 X-Source-Auth: lberger@labn.net X-Email-Count: 8 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: NetMod WG Chairs , NetConf WG , NetMod WG , NetConf WG Chairs Subject: [netmod] Which list/WG? (Re: WG adoption poll draft-nmdsdt-netmod-revised-datastores-00) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 12:47:21 -0000 On December 3, 2016 4:02:02 AM Juergen Schoenwaelder wrote: > ... > > PS: Do we have to run the discussion via cross-posts on two lists or > can the chairs agree to just use one list, assuming that those who > care can manage to follow this one list? > I agree that this adoption call is not the usual. The reason for this is basically due to the "which WG" issue that Lada is raising. The agreement between the chairs and the AD is that this work would be run in NetMod and that any resulting netconf/restconf protocol work would be done in netconf (i.e., the group that owns the protocol). To ensure all are in sync on this activity, the agreement between the chairs is to do the adoption discussion in both groups, and then once the normal process has been run in NetMod to do a joint WG last call. We know this makes for some duplicate messages, but it ensures the WGs are in sync. Lou From nobody Mon Dec 5 09:19:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07CE0129B9B for ; Mon, 5 Dec 2016 09:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJWxw0Of9fZs for ; Mon, 5 Dec 2016 09:19:01 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9176F129784 for ; Mon, 5 Dec 2016 09:19:01 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id c47so320611208qtc.2 for ; Mon, 05 Dec 2016 09:19:01 -0800 (PST) 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=GrlVtn64V+KfhvGzWcUmZb7R9WHd7OuHs8FTvWf+r0Y=; b=0uxG01vcL0NEqk2uqYUI/ItthuC7RBC5hYlNaT+iomGQD81WfjweH4u9Pa8VnfUGRT q0GGAs9H5LyOL4k5y6VmvST8BgZY/+3ptUlcld5HIpBhWUZeFdtQVh5nTMZYHfxh+pg3 b6WPuenhvey75o+FuREV796zseoEXOcZ+wDXMSuLY1LsamlxlsNASMZNQyevSqXn0t3Q UE9xGXzylqSRP/7NsaspUvdhlbvywsZT1dI44Pq8b9aJYdErnElQtujdFcclKhPEDeHH ARMVre+EmIpFMSPJN92j9D7J+vdg0CiMUTnvGCZTD8ULoZfdD4z9ClcPLterjv0TX9TP m3BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=GrlVtn64V+KfhvGzWcUmZb7R9WHd7OuHs8FTvWf+r0Y=; b=clnFxSztcskludsskVLnGGdcsiNeVJrYrRdJ1HT4yaRLcThkhPWwBv9j6Edq+/aKcm C4+yBxl9vY9uOmcXUC/S9rlopKoHfPKFopDqnC75n5WHA9f35DPsna37hl6e5sUyyGe1 792v/LkH1rZ5e9oSau1gIDea1O87Qq3IvBpJaD8RQZRfL5wOWZ1qYi19ktU35nmeLDqr ipuOCa6teVJOCU05KM1Lc+BSemsGu/bYx/iAS+JWT8DuFQoWG+lZZZ+uz5KYSdDtw30x fmm0AB6URB1xIyP1p7XGc5D9TI5xL3q8Hz2upmHRLNdwOOwdiae9Tz8WA3hs++TcLLM0 7nuw== X-Gm-Message-State: AKaTC01LVxkSVsabyz5rxCU68uvAyCu23sV5N7+ZLfwe1bKMEy4RUH9y+fqzGT/jTpBipRiml+STwW3P6rgjvQ== X-Received: by 10.200.41.171 with SMTP id 40mr56571735qts.235.1480958340658; Mon, 05 Dec 2016 09:19:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Mon, 5 Dec 2016 09:18:59 -0800 (PST) In-Reply-To: <20161205120210.GA97559@elstar.local> References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> From: Andy Bierman Date: Mon, 5 Dec 2016 09:18:59 -0800 Message-ID: To: Juergen Schoenwaelder , Ladislav Lhotka , Lou Berger , NetMod WG Chairs , Netconf , NetMod WG , NetConf WG Chairs Content-Type: multipart/alternative; boundary=001a11406578d2c1310542ec7b0d Archived-At: Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 17:19:08 -0000 --001a11406578d2c1310542ec7b0d Content-Type: text/plain; charset=UTF-8 On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: > > > > > > > > I disagree that the datastore model is a protocol specific aspect. I > > > consider datastores an architectural component binding data models and > > > protocols together. In fact, the 'traditional' datastore model > > > > I would agree with this if datastores were a general concept in YANG, > but the revised-datastores draft explicitly introduces the "intended" and > "applied" datastores that may be irrelevant to other protocols using YANG, > and even needn't be used in all NETCONF implementations. I wouldn't call > this "an architectural component" of YANG. > > > > An architectural component of this new management framework (that does > not have a name). The fact that not all protocols may expose all > datastores is IMHO not a reason that the datastore model is not an > architectural framework. > > > If you are saying that it will have nontrivial impact on YANG, I would > like to see it explained in sec. 6.3. Without this information I am quite > reluctant to agree with the adoption. > > An operational state datastore has implications how one writes data > models. It may not directly affect YANG itself but surely the usage of > YANG. > > > See above - architectural aspects need to be relevant to all protocols. > > Yes, but relevant to all protocols does not mean every protocol needs > to expose say all datastores. But every protocol should be clear about > how what it exposes relates to the architectural framework. > > There is a "current solution" consisting of hard-wired object semantics (e.g., ifAdminStatus and ifOperStatus). This solution does not require special protocols or datastores, but it is being replaced by a generic solution. If the "generic" solution requires special procedures which differ on each protocol, then it might end up be worse than the hard-wired solution that works on every protocol. So I agree with Juergen that this is primarily an architectural issue. /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 > --001a11406578d2c1310542ec7b0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lh= otka wrote:
>
> >
> > I disagree that the datastore model is a protocol specific aspect= . I
> > consider datastores an architectural component binding data model= s and
> > protocols together. In fact, the 'traditional' datastore = model
>
> I would agree with this if datastores were a general concept in YANG, = but the revised-datastores draft explicitly introduces the "intended&q= uot; and "applied" datastores that may be irrelevant to other pro= tocols using YANG, and even needn't be used in all NETCONF implementati= ons. I wouldn't call this "an architectural component" of YAN= G.
>

An architectural component of this new management framework (that does
not have a name). The fact that not all protocols may expose all
datastores is IMHO not a reason that the datastore model is not an
architectural framework.

> If you are saying that it will have nontrivial impact on YANG, I would= like to see it explained in sec. 6.3. Without this information I am quite = reluctant to agree with the adoption.

An operational state datastore has implications how one writes data
models. It may not directly affect YANG itself but surely the usage of
YANG.

> See above - architectural aspects need to be relevant to all protocols= .

Yes, but relevant to all protocols does not mean every protocol needs
to expose say all datastores. But every protocol should be clear about
how what it exposes relates to the architectural framework.



There is a "current solution&quo= t; consisting of hard-wired object semantics
(e.g., ifAdminStatus= and ifOperStatus).=C2=A0 This solution does not require
special = protocols or datastores, but it is being replaced by a generic solution.

If the "generic" solution requires special= procedures which differ on each protocol,
then it might end up b= e worse than the hard-wired solution that works on every protocol.
So I agree with Juergen that this is primarily an architectural issue.


/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<http://www.jacobs-university.de/>

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

--001a11406578d2c1310542ec7b0d-- From nobody Mon Dec 5 10:10:53 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026F2129C4D for ; Mon, 5 Dec 2016 10:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqWGQkfa4lX4 for ; Mon, 5 Dec 2016 10:10:50 -0800 (PST) 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 11B88129C47 for ; Mon, 5 Dec 2016 10:10:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2136; q=dns/txt; s=iport; t=1480961450; x=1482171050; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=UXkwac2clF7XWkgeeenjhACTe+NmnOevnSLTIyNJoeg=; b=lcqJF6i0t0heXYSOV3zrWFLEeeAuQsOg+Ii69aHAgQV5qoDRz8V/WB4+ XMYqWV8KZC282W/lZ1h1R+gcQUFZkHCNUwELI0Ptmdg+dkb7+vt52dIcP QgQipaYTv71O5E3g98pSJtzN15lSNXFMf+W9CskIWkwYlFg4VQzP34N+T M=; X-IronPort-AV: E=Sophos;i="5.33,305,1477958400"; d="scan'208";a="690186688" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Dec 2016 18:10:48 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uB5IAlIS007183; Mon, 5 Dec 2016 18:10:48 GMT To: "netmod@ietf.org" From: Robert Wilton Message-ID: <5bc806b2-4941-dded-8e78-a3ffbaeeb9a6@cisco.com> Date: Mon, 5 Dec 2016 18:10:47 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Peter Jones Subject: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 18:10:52 -0000 Hi, We are currently working on modelling 802.3 Ethernet YANG within the 802.3 YANG study group. One interesting issue that has come up is the scope of the operational state data that could be modeled: At the top level, an operator may just want to know whether an Ethernet interface is up or down. At a second level, if the Ethernet interface is down, then there is some high level diagnostics information that may be useful to an operator to diagnose why the interface isn't up (e.g. alarms information, optical power levels, auto-negotiation protocol status). There is also a third level, of very detailed, 802.3 hardware register information defined in 802.3 Clause 45. Such information is probably of most relevance to the engineers developing and programming Ethernet chips and PHYs, but is sometimes useful for resolving potential vendor inter-operation issues. Retrieving this information out of the Ethernet chips can be comparatively slow. The question that was being discussed is whether it is appropriate to model all three levels on information in the 802.3 Ethernet YANG models, or whether only the top level and second level information can/should be modeled via YANG? If we were to model the third level information in YANG then it would seem highly desirable for that information to not be returned in response to a general NETCONF request because the information is generally not of relevance and has potential performance issues in returning it. Instead, it would seem desirable to only return this data if it was specifically requested (e.g. a request on the node containing the third level information), or if a hypothetical filter extension was specified and used to explicitly include it in the response. Given that there doesn't seem to a great way to currently achieve this in YANG, this makes me think that it isn't sensible to model this third level of detailed information in YANG at this time. Do others agree? Have others faced similar issues, and if so, how have you solved them? Input welcome. Thanks, Rob From nobody Mon Dec 5 15:24:24 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B747129E7E for ; Mon, 5 Dec 2016 15:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GHhwhEvQDEK for ; Mon, 5 Dec 2016 15:24:20 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0124.outbound.protection.outlook.com [104.47.33.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA6DD129E69 for ; Mon, 5 Dec 2016 15:24:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Qe4HR4xQjytYhOYwRe6L201FADKiaU2ueZdJMmNx3D0=; b=IpbgmA1+Q/HjoFJN1BHFIPrmG+3EICvYnuZENRxa4WrYbYnS3S22FDlPR9apeE6eP/F9TPX673NnBENjg2ExP21o7vxsUM7uIQGaYtvi3XMyOdOpJf/uUaVsyUbiKI+YYk3I9tCrDDh5rnppuML8GgsmQApMeoH4SS38qcg4nqM= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.4; Mon, 5 Dec 2016 23:24:18 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0771.006; Mon, 5 Dec 2016 23:24:18 +0000 From: Kent Watsen To: "Acee Lindem (acee)" , Juergen Schoenwaelder Thread-Topic: [netmod] Key Strings in ietf-key-chain operational state Thread-Index: AQHSS1Hu3gEYh3opOk2NCMc25X0loKDywQGAgABX2oCAADCEAIABfc2AgACfP4CABEyDAA== Date: Mon, 5 Dec 2016 23:24:17 +0000 Message-ID: <7DB54F1D-ABA9-4308-871F-75CD6730ADE6@juniper.net> References: <20161201082049.GA1748@elstar.local> <20161201162854.GA89230@elstar.local> <83DB4ED2-F0BB-47CB-BB1E-981CA48098C5@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1c.1.161117 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: e199597e-d4a4-4f85-4f78-08d41d65d5c7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1444; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 7:y4ASWOmzeQx6QEnO7e2vXWsEYyBTaq2DK0KlwXEcLJBJ3+Y7FGQaTAWOgsD2+lUyeLjNqyv8JOrajw8SkX+sIjMau1bc7CHYABlakglPZ7I+SxNSxdX9xQc0vIqZiK/SZ+LrTA36DZvKqh2mwbn1Z7CVTRgmG8uReJshLrEay1UW3JnzEy/81skarX+eA3RKsFuTK/5qVjyavNKTTdzKzulzfl6+NovD2C48LnosHlRET5iy1FdLfvK/erybwGkadhGEtjRpCoCsek5/gia9abepDksCrLbA5hYfaLmUP06N3nOZDRPc4Qlxd9lKP4/1IDrjqrm8e6gGrSWkarLINEEVNc8NI+27MzyRUWzKEgCSywqhkozLVHCN7UGzakDW2RbUscwRq3Y+PSGDwsrAC/y6x/8TG8wzKHXl8fu5y1GAXATIiWLldLsEXPf0O+O0iE2mqSx2rKYVkSij5rYALA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(138986009662008)(200054503718035)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(2003001)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 0147E151B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(24454002)(76104003)(189002)(377454003)(6116002)(7846002)(33656002)(230783001)(39410400001)(102836003)(105586002)(4326007)(122556002)(3280700002)(106356001)(83716003)(2906002)(3846002)(2950100002)(101416001)(106116001)(551544002)(6512006)(86362001)(39840400001)(36756003)(83506001)(39860400001)(3660700001)(8936002)(5660300001)(6506006)(82746002)(8676002)(5001770100001)(97736004)(81166006)(81156014)(92566002)(68736007)(93886004)(2900100001)(54356999)(4001350100001)(66066001)(99286002)(50986999)(305945005)(77096006)(76176999)(39850400001)(7736002)(39450400002)(189998001)(561944003)(6486002)(229853002)(38730400001)(50919006)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <19F24047DCDDCE47A0738E926043AB44@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2016 23:24:17.9392 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Key Strings in ietf-key-chain operational state X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 23:24:23 -0000 DQpFeGFjdGx5LCB3aXRoIGFjY2Vzcy1jb250cm9sLCBsZXNzIHByaXZpbGVnZWQgY2xpZW50cyB3 b3VsZCBuZXZlciBvYnRhaW4gdGhlIHByaXZhdGUga2V5IGRhdGEsIGV2ZW4gd2hlbiByZWFkaW5n IG9wZXJhdGlvbmFsIHN0YXRlLg0KDQpJIGRvbuKAmXQgdGhpbmsgdGhpcyBoYXMgYmVlbiBkaXNj dXNzZWQgb24gbGlzdCB5ZXQgc28sIHRvIGJlIGNsZWFyLCBJ4oCZbSBzYXlpbmcgdGhhdCBOQUNN IGFubm90YXRpb25zIE1VU1QgYmUgZW5mb3JjZWQgZm9yIGFsbCB0aGUgbmV3IGRhdGFzdG9yZXMg aW4gdGhlIHJldmlzZWQgZGF0YXN0b3JlIHByb3Bvc2FsLg0KDQpLLg0KDQoNCk9uIDEyLzIvMTYs IDc6NDUgUE0sICJBY2VlIExpbmRlbSAoYWNlZSkiIDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQoN CkhpIEtlbnQsIA0KU28gYXJlIHlvdSBzdWdnZXN0aW5nIHRoZSBuYWNtOmRlZmF1bHQtZGVueS1h bGwgZm9yIGtleSBzdHJpbmdzIHJhdGhlcg0KdGhhbiBvbWl0dGluZyBpdCBmcm9tIHRoZSBvcGVy YXRpb25hbCBzdGF0ZT8NClRoYW5rcywNCkFjZWUgDQoNCk9uIDEyLzIvMTYsIDM6MTUgUE0sICJL ZW50IFdhdHNlbiIgPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KDQo+SGkgQWNlZSwNCj4N Cj5Tb3JyeSBmb3IgYmVpbmcgbGF0ZSB0byB0aGlzIHRocmVhZC4gIEFzIE1laGVzaCBtZW50aW9u ZWQsIHRoaXMgYXNwZWN0IG9mDQo+dGhlIGtleXN0b3JlIG1vZGUgaXMgY3VycmVudGx5IG9wZW4s IGFuZCBiZWluZyB0cmFja2VkIGJ5IGdpdGh1YiBpc3N1ZQ0KPiMyLiAgDQo+DQo+SXQgaXMgbXkg dW5kZXJzdGFuZGluZyB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIHdvdWxkIGxpa2UgdG8gcHVyc3Vl IGENCj5zdHJhdGVneSB0aGF0IHN1cHBvcnRzIGJhY2t1cC9yZXN0b3JlIG9wZXJhdGlvbnMgdG8g dGhlIGdyZWF0ZXN0IGV4dGVudA0KPnBvc3NpYmxlLiAgDQo+DQo+SW4gb3JkZXIgdG8gcHJldmVu dCB1bmF1dGhvcml6ZWQgYWNjZXNzLCBOQUNNIHJ1bGVzIGNhbiBiZSB1c2VkIHRvIG1hcmsNCj50 aGUgcHJpdmF0ZSBrZXkgZGF0YSBsZWFmIChub3QgaXRzIHBhcmVudCBsaXN0IGVudHJ5KSB3aXRo DQo+wrNuYWNtOmRlZmF1bHQtZGVueS1hbGzCsi4NCj4NCj5JbiBvcmRlciB0byBzdXBwb3J0IGhh cmR3YXJlIHByb3RlY3RlZCBrZXlzLCB0aGUgcHJpdmF0ZSBrZXkgZGF0YSBsZWFmDQo+Y2FuIGJl IG1hcmtlZCBhcyBtYW5kYXRvcnkgZmFsc2UsIHdpdGggdGhlIGV4cGxhbmF0aW9uIHRoYXQsIGlm IG5vdA0KPnJldHVybmVkLCBpdCBtaWdodCBiZSBiZWNhdXNlIHRoZSBrZXkgaXMgcHJvdGVjdGVk IGJ5IGhhcmR3YXJlLg0KPg0KPk5vdCBzdGF0ZWQgeWV0LCBidXQgdGhlIHRoaW5raW5nIGlzIHRo YXQgdGhlIHByaXZhdGUga2V5IGRhdGEgbGVhZiB3b3VsZA0KPmJlIGNvbmZpZyB0cnVlLCB0byBz dXBwb3J0IHRoZSBiYWNrdXAvcmVzdG9yZSBjYXNlIG9mIHRoZSBOQy9SQyBjbGllbnQNCj5wYXNz aW5nIHRoZSBwcml2YXRlIHRvIHRoZSBkZXZpY2UgIChvcGVuIGlzc3VlOiBob3cgdG8gZGlyZWN0 IHNwZWNpYWxpemVkDQo+aGFyZHdhcmUgdG8gZ2VuZXJhdGUgYSBuZXcgcHJvdGVjdGVkIGtleSku ICBQZXJ0aW5lbnRseSwgZm9yIHRoZQ0KPmFwcGxpZWQvb3BlcmF0aW9uYWwtc3RhdGUgZGF0YXN0 b3JlcywgdGhlIE5BQ00gYW5kIG1hbmRhdG9yeSBhdHRyaWJ1dGVzDQo+Y2Fycnkgb3Zlciwgc28g c3RpbGwgdGhlIGtleSBpcyBwcm90ZWN0ZWQgZnJvbSB1bmF1dGhvcml6ZWQgYWNjZXNzIGFuZA0K PnN0aWxsIHRoZSBzb2x1dGlvbiBzdXBwb3J0cyBoYXJkd2FyZSBwcm90ZWN0ZWQga2V5cy4NCj4N Cj5XaGF0IGRvIHlvdSB0aGluaz8NCj4NCj5LZW50DQo+ICANCj4NCj4NCj5PbiAxMi8xLzE2LCAx MToyOCBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgSnVlcmdlbiBTY2hvZW53YWVsZGVyIg0KPjxu ZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YNCj5qLnNjaG9lbndhZWxkZXJAamFj b2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KPg0KPk9LLiBJIG1pc3JlYWQgeW91ciBzdGF0ZW1l bnQuIFNvcnJ5IGZvciB0aGUgbm9pc2UuDQo+DQo+L2pzDQo+DQo+T24gVGh1LCBEZWMgMDEsIDIw MTYgYXQgMDE6MzU6MTVQTSArMDAwMCwgQWNlZSBMaW5kZW0gKGFjZWUpIHdyb3RlOg0KPj4gDQo+ PiANCj4+IE9uIDEyLzEvMTYsIDM6MjAgQU0sICJKdWVyZ2VuIFNjaG9lbndhZWxkZXIiDQo+PiA8 ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCj4+IA0KPj4gPk9u IFdlZCwgTm92IDMwLCAyMDE2IGF0IDA5OjM3OjIxUE0gKzAwMDAsIEFjZWUgTGluZGVtIChhY2Vl KSB3cm90ZToNCj4+ID4NCj4+ID4+IEluIHRoZSBkYXlzIG9mIE1JQnMsIHdlIHVzZWQgdG8gb21p dCBrZXkgc3RyaW5ncyBmcm9tIHRoZSBkYXRhIHRoYXQNCj4+ID4+d291bGQgYmUgcmV0dXJuZWQu IFRoaXMgd2FzIG9zdGVuc2libHkgZG9uZSBmb3Igc2VjdXJpdHkgcHVycG9zZXMuDQo+PiA+DQo+ PiA+VGhpcyBpcyBub3QgY29ycmVjdC4gSW4gU01JdjIsIElOREVYIG9iamVjdHMgYXJlIG5vdCBh Y2Nlc3NpYmxlDQo+PiA+YmVjYXVzZSB0aGUgdmFsdWVzIG9mIHRoZXNlIG9iamVjdHMgYXJlIGVt YmVkZGVkIGluIHRoZSBpbnN0YW5jZQ0KPj4gPmlkZW50aWZpZXIuIEluIG90aGVyIHdvcmRzLCBt YWtpbmcgSU5ERVggb2JqZWN0cyBub3QtYWNjZXNzaWJsZSB3YXMgYQ0KPj4gPnBlcmZvcm1hbmNl IG9wdGltaXphdGlvbiwgZm9yY2luZyBTTk1QIG1hbmFnZXJzIHRvIGV4dHJhY3QgdGhlIElOREVY DQo+PiA+b2JqZWN0IHZhbHVlcyBvdXQgb2YgdGhlIGluc3RhbmNlIGlkZW50aWZpZXJzLiBNYWtp bmcgSU5ERVggb2JqZWN0cw0KPj4gPm5vdCBhY2Nlc3NpYmxlIGRvZXMgX25vdF8gaGlkZSBhbnkg aW5mb3JtYXRpb24uDQo+PiANCj4+IFRoaXMgaXMgYSBkaWZmZXJlbnQgaXNzdWUuIFdoYXQgSSBh bSByZWZlcnJpbmcgdG8gaXMgbmV2ZXIgcmV0dXJuaW5nIHRoZQ0KPj4ga2V5cyBpbiBhIHJlYWQg cmVxdWVzdCAoZ2V0LCBnZXQtbmV4dCwgZ2V0LW1hbnksIGV0YykuIEZvciBleGFtcGxlLA0KPj4g KGV4Y2VycHRlZCBmcm9tIFJGQyA0NzUwKToNCj4+IA0KPj4gIG9zcGZJZkF1dGhLZXkgT0JKRUNU LVRZUEUNCj4+ICAgICAgICBTWU5UQVggICAgICAgT0NURVQgU1RSSU5HIChTSVpFICgwLi4yNTYp KQ0KPj4gICAgICAgIE1BWC1BQ0NFU1MgICByZWFkLWNyZWF0ZQ0KPj4gICAgICAgIFNUQVRVUyAg ICAgICBjdXJyZW50DQo+PiAgICAgICBERVNDUklQVElPTg0KPj4gICAgICAgICAgICJUaGUgY2xl YXJ0ZXh0IHBhc3N3b3JkIHVzZWQgYXMgYW4gT1NQRg0KPj4gICAgICAgICAgIGF1dGhlbnRpY2F0 aW9uIGtleSB3aGVuIHNpbXBsZVBhc3N3b3JkIHNlY3VyaXR5DQo+PiAgICAgICAgICAgaXMgZW5h YmxlZC4gIFRoaXMgb2JqZWN0IGRvZXMgbm90IGFjY2VzcyBhbnkgT1NQRg0KPj4gICAgICAgICAg IGNyeXB0b2dhcGhpYyAoZS5nLiwgTUQ1KSBhdXRoZW50aWNhdGlvbiBrZXkgdW5kZXINCj4+ICAg ICAgICAgICBhbnkgY2lyY3Vtc3RhbmNlLg0KPj4gDQo+PiAgICAgICAgICAgSWYgdGhlIGtleSBs ZW5ndGggaXMgc2hvcnRlciB0aGFuIDggb2N0ZXRzLCB0aGUNCj4+ICAgICAgICAgICBhZ2VudCB3 aWxsIGxlZnQgYWRqdXN0IGFuZCB6ZXJvIGZpbGwgdG8gOCBvY3RldHMuDQo+PiANCj4+ICAgICAg ICAgICBVbmF1dGhlbnRpY2F0ZWQgaW50ZXJmYWNlcyBuZWVkIG5vIGF1dGhlbnRpY2F0aW9uDQo+ PiAgICAgICAgICAga2V5LCBhbmQgc2ltcGxlIHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uIGNhbm5v dCB1c2UNCj4+ICAgICAgICAgICBhIGtleSBvZiBtb3JlIHRoYW4gOCBvY3RldHMuDQo+PiANCj4+ ICAgICAgICAgICBOb3RlIHRoYXQgdGhlIHVzZSBvZiBzaW1wbGVQYXNzd29yZCBhdXRoZW50aWNh dGlvbg0KPj4gICAgICAgICAgIGlzIE5PVCByZWNvbW1lbmRlZCB3aGVuIHRoZXJlIGlzIGNvbmNl cm4gcmVnYXJkaW5nDQo+PiAgICAgICAgICAgYXR0YWNrIHVwb24gdGhlIE9TUEYgc3lzdGVtLiAg U2ltcGxlUGFzc3dvcmQNCj4+ICAgICAgICAgICBhdXRoZW50aWNhdGlvbiBpcyBvbmx5IHN1ZmZp Y2llbnQgdG8gcHJvdGVjdCBhZ2FpbnN0DQo+PiAgICAgICAgICAgYWNjaWRlbnRhbCBtaXNjb25m aWd1cmF0aW9ucyBiZWNhdXNlIGl0IHJlLXVzZXMNCj4+ICAgICAgICAgICBjbGVhcnRleHQgcGFz c3dvcmRzIFtSRkMxNzA0XS4NCj4+IA0KPj4gICAgICAgICAgIFdoZW4gcmVhZCwgb3NwZklmQXV0 aEtleSBhbHdheXMgcmV0dXJucyBhbiBvY3RldA0KPj4gICAgICAgICAgIHN0cmluZyBvZiBsZW5n dGggemVyby4iDQo+PiAgICAgICAgUkVGRVJFTkNFDQo+PiAgICAgICAgICAgIk9TUEYgVmVyc2lv biAyLCBTZWN0aW9uIDkgVGhlIEludGVyZmFjZSBEYXRhDQo+PiAgICAgICAgICAgU3RydWN0dXJl Ig0KPj4gICAgICAgIERFRlZBTCB7ICcwMDAwMDAwMDAwMDAwMDAwJ0ggfSAtLSAwLjAuMC4wLjAu MC4wLjANCj4+ICAgICAgICA6Oj0geyBvc3BmSWZFbnRyeSAxNiB9DQo+PiANCj4+IA0KPj4gDQo+ PiBUaGFua3MsDQo+PiBBY2VlIA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+ID4NCj4+ID4v anMNCj4+ID4NCj4+ID4tLSANCj4+ID5KdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEph Y29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPj4gPlBob25lOiArNDkgNDIxIDIwMCAzNTg3 ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4+ID5GYXg6 ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5 LmRlLz4NCj4+IA0KPg0KPi0tIA0KPkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFj b2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+UGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAg ICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPkZheDogICArNDkg NDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K Pg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bmV0 bW9kIG1haWxpbmcgbGlzdA0KPm5ldG1vZEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+DQo+DQoNCg0KDQo= From nobody Mon Dec 5 15:36:36 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C30C129553 for ; Mon, 5 Dec 2016 15:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQJR1GYl_CrG for ; Mon, 5 Dec 2016 15:36:32 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E865812961F for ; Mon, 5 Dec 2016 15:36:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7780; q=dns/txt; s=iport; t=1480980991; x=1482190591; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kEzbgVIJMyQxfIJYUNuqTO9r8olioa41DotwgmoIdMw=; b=OVwbHP6JuHt3PV2sTUCRWx/gbvas0faWx0VTPauV8pIwQXmb01kyElSW X9/dOCd2nAFMJizz8b1hAJH98XCM1DFAa7hXbn0dyG41MahxM4NL/UoT4 H3gHPX4iJUznRutHf6NtULQ1McMXiP/QqlOq/rZufmO4FJ32bCAy5Xeyh A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAQA4+UVY/5hdJa1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM4AQEBAQEfWoEGB41AlwqUfYIIHguFL0oCGoF5PxQBAgEBAQE?= =?us-ascii?q?BAQFiKIRpAQEEAQEyOgsOAgIBCA4CCAQUFAICGQwLJQIEAQ0FG4hUDoxPnT8Gg?= =?us-ascii?q?iuLSQEBAQEBAQEBAQEBAQEBAQEBAQEBARwFgQCKFIQRNxcKIAYHgjCCYwWaZgG?= =?us-ascii?q?JWoc8gXKIQoYJjgKEDAEfN4EZI4M6G4FdcodsgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,750,1477958400"; d="scan'208";a="177914357" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Dec 2016 23:36:30 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uB5NaUfr023094 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Dec 2016 23:36:30 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 5 Dec 2016 18:36:29 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Mon, 5 Dec 2016 18:36:29 -0500 From: "Acee Lindem (acee)" To: Kent Watsen , Juergen Schoenwaelder Thread-Topic: [netmod] Key Strings in ietf-key-chain operational state Thread-Index: AQHSS6vaEFwy9pC/jk+kWPZA/iaYSqDzGCCAgACEXQCAAdGgAP//95GAgAT0MYD//6+IgA== Date: Mon, 5 Dec 2016 23:36:29 +0000 Message-ID: References: <20161201082049.GA1748@elstar.local> <20161201162854.GA89230@elstar.local> <83DB4ED2-F0BB-47CB-BB1E-981CA48098C5@juniper.net> <7DB54F1D-ABA9-4308-871F-75CD6730ADE6@juniper.net> In-Reply-To: <7DB54F1D-ABA9-4308-871F-75CD6730ADE6@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.204] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Key Strings in ietf-key-chain operational state X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 23:36:34 -0000 Rm9yIGtleS1jaGFpbnMsIHdlIGRvIHdhbnQgdG8gYWxsb3cgY3JlYXRpb24gb2YgZW50cmllcyBj b21wbGV0ZSB3aXRoIHRoZQ0Ka2V5LXN0cmluZy4gT3RoZXJ3aXNlLCB0aGUgbW9kZWwgd291bGQg bm90IGJlIG9mIG11Y2ggdXNloaYuIEhvdyB3b3VsZCBvbmUNCmNvZGUgdGhpcyBpbiB0aGUgWUFO RyBtb2RlbD8gUkZDIDY1MzYgaXMgbGFja2luZyBvZiBhbnkgZXhhbXBsZXMuDQpUaGFua3MsDQpB Y2VlIA0KDQpPbiAxMi81LzE2LCA2OjI0IFBNLCAiS2VudCBXYXRzZW4iIDxrd2F0c2VuQGp1bmlw ZXIubmV0PiB3cm90ZToNCg0KPg0KPkV4YWN0bHksIHdpdGggYWNjZXNzLWNvbnRyb2wsIGxlc3Mg cHJpdmlsZWdlZCBjbGllbnRzIHdvdWxkIG5ldmVyIG9idGFpbg0KPnRoZSBwcml2YXRlIGtleSBk YXRhLCBldmVuIHdoZW4gcmVhZGluZyBvcGVyYXRpb25hbCBzdGF0ZS4NCj4NCj5JIGRvbqGvdCB0 aGluayB0aGlzIGhhcyBiZWVuIGRpc2N1c3NlZCBvbiBsaXN0IHlldCBzbywgdG8gYmUgY2xlYXIs IEmhr20NCj5zYXlpbmcgdGhhdCBOQUNNIGFubm90YXRpb25zIE1VU1QgYmUgZW5mb3JjZWQgZm9y IGFsbCB0aGUgbmV3IGRhdGFzdG9yZXMNCj5pbiB0aGUgcmV2aXNlZCBkYXRhc3RvcmUgcHJvcG9z YWwuDQo+DQo+Sy4NCj4NCj4NCj5PbiAxMi8yLzE2LCA3OjQ1IFBNLCAiQWNlZSBMaW5kZW0gKGFj ZWUpIiA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0KPg0KPkhpIEtlbnQsIA0KPlNvIGFyZSB5b3Ug c3VnZ2VzdGluZyB0aGUgbmFjbTpkZWZhdWx0LWRlbnktYWxsIGZvciBrZXkgc3RyaW5ncyByYXRo ZXINCj50aGFuIG9taXR0aW5nIGl0IGZyb20gdGhlIG9wZXJhdGlvbmFsIHN0YXRlPw0KPlRoYW5r cywNCj5BY2VlIA0KPg0KPk9uIDEyLzIvMTYsIDM6MTUgUE0sICJLZW50IFdhdHNlbiIgPGt3YXRz ZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KPg0KPj5IaSBBY2VlLA0KPj4NCj4+U29ycnkgZm9yIGJl aW5nIGxhdGUgdG8gdGhpcyB0aHJlYWQuICBBcyBNZWhlc2ggbWVudGlvbmVkLCB0aGlzIGFzcGVj dCBvZg0KPj50aGUga2V5c3RvcmUgbW9kZSBpcyBjdXJyZW50bHkgb3BlbiwgYW5kIGJlaW5nIHRy YWNrZWQgYnkgZ2l0aHViIGlzc3VlDQo+PiMyLiAgDQo+Pg0KPj5JdCBpcyBteSB1bmRlcnN0YW5k aW5nIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgd291bGQgbGlrZSB0byBwdXJzdWUgYQ0KPj5zdHJh dGVneSB0aGF0IHN1cHBvcnRzIGJhY2t1cC9yZXN0b3JlIG9wZXJhdGlvbnMgdG8gdGhlIGdyZWF0 ZXN0IGV4dGVudA0KPj5wb3NzaWJsZS4gIA0KPj4NCj4+SW4gb3JkZXIgdG8gcHJldmVudCB1bmF1 dGhvcml6ZWQgYWNjZXNzLCBOQUNNIHJ1bGVzIGNhbiBiZSB1c2VkIHRvIG1hcmsNCj4+dGhlIHBy aXZhdGUga2V5IGRhdGEgbGVhZiAobm90IGl0cyBwYXJlbnQgbGlzdCBlbnRyeSkgd2l0aA0KPj6p +G5hY206ZGVmYXVsdC1kZW55LWFsbKn3Lg0KPj4NCj4+SW4gb3JkZXIgdG8gc3VwcG9ydCBoYXJk d2FyZSBwcm90ZWN0ZWQga2V5cywgdGhlIHByaXZhdGUga2V5IGRhdGEgbGVhZg0KPj5jYW4gYmUg bWFya2VkIGFzIG1hbmRhdG9yeSBmYWxzZSwgd2l0aCB0aGUgZXhwbGFuYXRpb24gdGhhdCwgaWYg bm90DQo+PnJldHVybmVkLCBpdCBtaWdodCBiZSBiZWNhdXNlIHRoZSBrZXkgaXMgcHJvdGVjdGVk IGJ5IGhhcmR3YXJlLg0KPj4NCj4+Tm90IHN0YXRlZCB5ZXQsIGJ1dCB0aGUgdGhpbmtpbmcgaXMg dGhhdCB0aGUgcHJpdmF0ZSBrZXkgZGF0YSBsZWFmIHdvdWxkDQo+PmJlIGNvbmZpZyB0cnVlLCB0 byBzdXBwb3J0IHRoZSBiYWNrdXAvcmVzdG9yZSBjYXNlIG9mIHRoZSBOQy9SQyBjbGllbnQNCj4+ cGFzc2luZyB0aGUgcHJpdmF0ZSB0byB0aGUgZGV2aWNlICAob3BlbiBpc3N1ZTogaG93IHRvIGRp cmVjdCBzcGVjaWFsaXplZA0KPj5oYXJkd2FyZSB0byBnZW5lcmF0ZSBhIG5ldyBwcm90ZWN0ZWQg a2V5KS4gIFBlcnRpbmVudGx5LCBmb3IgdGhlDQo+PmFwcGxpZWQvb3BlcmF0aW9uYWwtc3RhdGUg ZGF0YXN0b3JlcywgdGhlIE5BQ00gYW5kIG1hbmRhdG9yeSBhdHRyaWJ1dGVzDQo+PmNhcnJ5IG92 ZXIsIHNvIHN0aWxsIHRoZSBrZXkgaXMgcHJvdGVjdGVkIGZyb20gdW5hdXRob3JpemVkIGFjY2Vz cyBhbmQNCj4+c3RpbGwgdGhlIHNvbHV0aW9uIHN1cHBvcnRzIGhhcmR3YXJlIHByb3RlY3RlZCBr ZXlzLg0KPj4NCj4+V2hhdCBkbyB5b3UgdGhpbms/DQo+Pg0KPj5LZW50DQo+PiAgDQo+Pg0KPj4N Cj4+T24gMTIvMS8xNiwgMTE6MjggQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIEp1ZXJnZW4gU2No b2Vud2FlbGRlciINCj4+PG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZg0KPj5q LnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KPj4NCj4+T0suIEkg bWlzcmVhZCB5b3VyIHN0YXRlbWVudC4gU29ycnkgZm9yIHRoZSBub2lzZS4NCj4+DQo+Pi9qcw0K Pj4NCj4+T24gVGh1LCBEZWMgMDEsIDIwMTYgYXQgMDE6MzU6MTVQTSArMDAwMCwgQWNlZSBMaW5k ZW0gKGFjZWUpIHdyb3RlOg0KPj4+IA0KPj4+IA0KPj4+IE9uIDEyLzEvMTYsIDM6MjAgQU0sICJK dWVyZ2VuIFNjaG9lbndhZWxkZXIiDQo+Pj4gPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVy c2l0eS5kZT4gd3JvdGU6DQo+Pj4gDQo+Pj4gPk9uIFdlZCwgTm92IDMwLCAyMDE2IGF0IDA5OjM3 OjIxUE0gKzAwMDAsIEFjZWUgTGluZGVtIChhY2VlKSB3cm90ZToNCj4+PiA+DQo+Pj4gPj4gSW4g dGhlIGRheXMgb2YgTUlCcywgd2UgdXNlZCB0byBvbWl0IGtleSBzdHJpbmdzIGZyb20gdGhlIGRh dGEgdGhhdA0KPj4+ID4+d291bGQgYmUgcmV0dXJuZWQuIFRoaXMgd2FzIG9zdGVuc2libHkgZG9u ZSBmb3Igc2VjdXJpdHkgcHVycG9zZXMuDQo+Pj4gPg0KPj4+ID5UaGlzIGlzIG5vdCBjb3JyZWN0 LiBJbiBTTUl2MiwgSU5ERVggb2JqZWN0cyBhcmUgbm90IGFjY2Vzc2libGUNCj4+PiA+YmVjYXVz ZSB0aGUgdmFsdWVzIG9mIHRoZXNlIG9iamVjdHMgYXJlIGVtYmVkZGVkIGluIHRoZSBpbnN0YW5j ZQ0KPj4+ID5pZGVudGlmaWVyLiBJbiBvdGhlciB3b3JkcywgbWFraW5nIElOREVYIG9iamVjdHMg bm90LWFjY2Vzc2libGUgd2FzIGENCj4+PiA+cGVyZm9ybWFuY2Ugb3B0aW1pemF0aW9uLCBmb3Jj aW5nIFNOTVAgbWFuYWdlcnMgdG8gZXh0cmFjdCB0aGUgSU5ERVgNCj4+PiA+b2JqZWN0IHZhbHVl cyBvdXQgb2YgdGhlIGluc3RhbmNlIGlkZW50aWZpZXJzLiBNYWtpbmcgSU5ERVggb2JqZWN0cw0K Pj4+ID5ub3QgYWNjZXNzaWJsZSBkb2VzIF9ub3RfIGhpZGUgYW55IGluZm9ybWF0aW9uLg0KPj4+ IA0KPj4+IFRoaXMgaXMgYSBkaWZmZXJlbnQgaXNzdWUuIFdoYXQgSSBhbSByZWZlcnJpbmcgdG8g aXMgbmV2ZXIgcmV0dXJuaW5nDQo+Pj50aGUNCj4+PiBrZXlzIGluIGEgcmVhZCByZXF1ZXN0IChn ZXQsIGdldC1uZXh0LCBnZXQtbWFueSwgZXRjKS4gRm9yIGV4YW1wbGUsDQo+Pj4gKGV4Y2VycHRl ZCBmcm9tIFJGQyA0NzUwKToNCj4+PiANCj4+PiAgb3NwZklmQXV0aEtleSBPQkpFQ1QtVFlQRQ0K Pj4+ICAgICAgICBTWU5UQVggICAgICAgT0NURVQgU1RSSU5HIChTSVpFICgwLi4yNTYpKQ0KPj4+ ICAgICAgICBNQVgtQUNDRVNTICAgcmVhZC1jcmVhdGUNCj4+PiAgICAgICAgU1RBVFVTICAgICAg IGN1cnJlbnQNCj4+PiAgICAgICBERVNDUklQVElPTg0KPj4+ICAgICAgICAgICAiVGhlIGNsZWFy dGV4dCBwYXNzd29yZCB1c2VkIGFzIGFuIE9TUEYNCj4+PiAgICAgICAgICAgYXV0aGVudGljYXRp b24ga2V5IHdoZW4gc2ltcGxlUGFzc3dvcmQgc2VjdXJpdHkNCj4+PiAgICAgICAgICAgaXMgZW5h YmxlZC4gIFRoaXMgb2JqZWN0IGRvZXMgbm90IGFjY2VzcyBhbnkgT1NQRg0KPj4+ICAgICAgICAg ICBjcnlwdG9nYXBoaWMgKGUuZy4sIE1ENSkgYXV0aGVudGljYXRpb24ga2V5IHVuZGVyDQo+Pj4g ICAgICAgICAgIGFueSBjaXJjdW1zdGFuY2UuDQo+Pj4gDQo+Pj4gICAgICAgICAgIElmIHRoZSBr ZXkgbGVuZ3RoIGlzIHNob3J0ZXIgdGhhbiA4IG9jdGV0cywgdGhlDQo+Pj4gICAgICAgICAgIGFn ZW50IHdpbGwgbGVmdCBhZGp1c3QgYW5kIHplcm8gZmlsbCB0byA4IG9jdGV0cy4NCj4+PiANCj4+ PiAgICAgICAgICAgVW5hdXRoZW50aWNhdGVkIGludGVyZmFjZXMgbmVlZCBubyBhdXRoZW50aWNh dGlvbg0KPj4+ICAgICAgICAgICBrZXksIGFuZCBzaW1wbGUgcGFzc3dvcmQgYXV0aGVudGljYXRp b24gY2Fubm90IHVzZQ0KPj4+ICAgICAgICAgICBhIGtleSBvZiBtb3JlIHRoYW4gOCBvY3RldHMu DQo+Pj4gDQo+Pj4gICAgICAgICAgIE5vdGUgdGhhdCB0aGUgdXNlIG9mIHNpbXBsZVBhc3N3b3Jk IGF1dGhlbnRpY2F0aW9uDQo+Pj4gICAgICAgICAgIGlzIE5PVCByZWNvbW1lbmRlZCB3aGVuIHRo ZXJlIGlzIGNvbmNlcm4gcmVnYXJkaW5nDQo+Pj4gICAgICAgICAgIGF0dGFjayB1cG9uIHRoZSBP U1BGIHN5c3RlbS4gIFNpbXBsZVBhc3N3b3JkDQo+Pj4gICAgICAgICAgIGF1dGhlbnRpY2F0aW9u IGlzIG9ubHkgc3VmZmljaWVudCB0byBwcm90ZWN0IGFnYWluc3QNCj4+PiAgICAgICAgICAgYWNj aWRlbnRhbCBtaXNjb25maWd1cmF0aW9ucyBiZWNhdXNlIGl0IHJlLXVzZXMNCj4+PiAgICAgICAg ICAgY2xlYXJ0ZXh0IHBhc3N3b3JkcyBbUkZDMTcwNF0uDQo+Pj4gDQo+Pj4gICAgICAgICAgIFdo ZW4gcmVhZCwgb3NwZklmQXV0aEtleSBhbHdheXMgcmV0dXJucyBhbiBvY3RldA0KPj4+ICAgICAg ICAgICBzdHJpbmcgb2YgbGVuZ3RoIHplcm8uIg0KPj4+ICAgICAgICBSRUZFUkVOQ0UNCj4+PiAg ICAgICAgICAgIk9TUEYgVmVyc2lvbiAyLCBTZWN0aW9uIDkgVGhlIEludGVyZmFjZSBEYXRhDQo+ Pj4gICAgICAgICAgIFN0cnVjdHVyZSINCj4+PiAgICAgICAgREVGVkFMIHsgJzAwMDAwMDAwMDAw MDAwMDAnSCB9IC0tIDAuMC4wLjAuMC4wLjAuMA0KPj4+ICAgICAgICA6Oj0geyBvc3BmSWZFbnRy eSAxNiB9DQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gVGhhbmtzLA0KPj4+IEFjZWUgDQo+Pj4gDQo+ Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gPg0KPj4+ID4vanMNCj4+PiA+DQo+Pj4gPi0tIA0K Pj4+ID5KdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJy ZW1lbiBnR21iSA0KPj4+ID5QaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBS aW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQo+Pj4gPkZheDogICArNDkgNDIxIDIwMCAz MTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPj4+IA0KPj4N Cj4+LS0gDQo+Pkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNp dHkgQnJlbWVuIGdHbWJIDQo+PlBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVz IFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4+RmF4OiAgICs0OSA0MjEgMjAwIDMx MDMgICAgICAgICA8aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo+Pg0KPj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5uZXRtb2QgbWFp bGluZyBsaXN0DQo+Pm5ldG1vZEBpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldG1vZA0KPj4NCj4+DQo+DQo+DQo+DQoNCg== From nobody Mon Dec 5 16:21:24 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6CA12962D for ; Mon, 5 Dec 2016 16:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.117 X-Spam-Level: X-Spam-Status: No, score=-7.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, 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 d0xuQRjSDnOx for ; Mon, 5 Dec 2016 16:21:19 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD88F1293EE for ; Mon, 5 Dec 2016 16:21:18 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CWP33396; Tue, 06 Dec 2016 00:21:16 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 6 Dec 2016 00:21:15 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.151]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Tue, 6 Dec 2016 08:21:10 +0800 From: Daixinning To: Martin Bjorklund Thread-Topic: [netmod] A question about data tree Thread-Index: AdJOuXqJMW+jldgjQhqKGMPnoDan8f//0YWA//6XXVA= Date: Tue, 6 Dec 2016 00:21:10 +0000 Message-ID: <73CF6B172361F5419537C3F59B2C0A092FEAAD8D@nkgeml513-mbx.china.huawei.com> References: <73CF6B172361F5419537C3F59B2C0A092FEAA88B@nkgeml513-mbx.china.huawei.com> <20161205.114947.143688002879843595.mbj@tail-f.com> In-Reply-To: <20161205.114947.143688002879843595.mbj@tail-f.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.27.15] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5846047C.0325, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.151, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e5e8364a4e3b6acf94a9f23a563054b8 Archived-At: Cc: "netmod@ietf.org" Subject: [netmod] =?gb2312?b?tPC4tDogIEEgcXVlc3Rpb24gYWJvdXQgZGF0YSB0cmVl?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 00:21:22 -0000 T0ssIHRoYW5rcyBhIGxvdC4NCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IE1hcnRpbiBC am9ya2x1bmQgW21haWx0bzptYmpAdGFpbC1mLmNvbV0gDQq3osvNyrG85DogMjAxNsTqMTLUwjXI 1SAxODo1MA0KytW8/sjLOiBEYWl4aW5uaW5nDQqzrcvNOiBuZXRtb2RAaWV0Zi5vcmcNCtb3zOI6 IFJlOiBbbmV0bW9kXSBBIHF1ZXN0aW9uIGFib3V0IGRhdGEgdHJlZQ0KDQpIaSwNCg0KRGFpeGlu bmluZyA8ZGFpeGlubmluZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4gSGksDQo+IA0KPiBSRkM3OTUw IGhhcyBkZWZpbmVkIGEgdGVybWlub2xvZ3kgImRhdGEgdHJlZSIsIHNob3duIGFzIGJlbG93Og0K PiAgICBvICBkYXRhIHRyZWU6IEFuIGluc3RhbnRpYXRlZCB0cmVlIG9mIGFueSBkYXRhIG1vZGVs ZWQgd2l0aCBZQU5HLA0KPiAgICAgICBlLmcuLCBjb25maWd1cmF0aW9uIGRhdGEsIHN0YXRlIGRh dGEsIGNvbWJpbmVkIGNvbmZpZ3VyYXRpb24gYW5kDQo+ICAgICAgIHN0YXRlIGRhdGEsIFJQQyBv ciBhY3Rpb24gaW5wdXQsIFJQQyBvciBhY3Rpb24gb3V0cHV0LCBvcg0KPiAgICAgICBub3RpZmlj YXRpb24uDQo+IA0KPiBJIGhhdmUgYSBxdWVzdGlvbiBvbiB0aGlzIGlzc3VlLCB0aGF0IGlzLCBX aGV0aGVyIHRoZSBjb250ZW50IG9mIHRoZSANCj4gPGNvbmZpZz4gbm9kZSBpbiA8ZWRpdC1jb25m aWc+IGlzIGEgImRhdGEgdHJlZSINCg0KTm8sIHRoZSAiY29uZmlnIiBpcyBtb2RlbGxlZCBhcyAi YW55eG1sIiBzbyBpdCBqdXN0IGFuICJYTUwgYmxvYiIuDQoNCj4sIGFuZCBkb2VzIGl0IG5lZWQg dG8gZm9sbG93IHRoZSBjb25zdHJhaW50cyBvZiB0aGUgImRhdGEgdHJlZSINCj4gKGUuZy4sIFRo ZSBjb250YWluZXIgbm9kZSBleGlzdHMgYW4gbW9zdCBvbmUgaW5zdGFuY2UgaW4gdGhlIGRhdGEg IA0KPnRyZWUpLg0KPiBGb3IgZXhhbXBsZSwgdGhlIG5ldGNvbmYgbWVzc2FnZSBjb250ZW50IGlz IGxpa2UgdGhpcw0KPiANCj4gPGVkaXQtY29uZmlnPg0KPiAgICAgPHRhcmdldD48cnVubmluZy8+ PC90YXJnZXQ+DQo+ICAgICA8Y29uZmlnPg0KPiAgICAgICAgIDxzeXN0ZW0geG1sbnM9IiB1cm46 aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1zeXN0ZW0iPg0KPiAgICAgICAgICAgICA8Y29u dGFjdD54eHhAeXl5LmNvbTwvY29udGFjdD4NCj4gICAgICAgICA8L3N5c3RlbT4NCj4gICAgICAg ICA8c3lzdGVtIHhtbG5zPSIgdXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtc3lzdGVt Ij4NCj4gICAgICAgICAgICAgPGhvc3RuYW1lPlVidW50dS10ZXN0LTAxPC9ob3N0bmFtZT4NCj4g ICAgICAgICA8L3N5c3RlbT4NCj4gICAgIDwvY29uZmlnPg0KPiA8L2VkaXQtY29uZmlnPg0KPiAN Cj4gVGhlc2UgdHdvIDxzeXN0ZW0+IHRhZ3MgaXMgZGlzb2JleWVkIHRoZSBjb25zdHJhaW50IG9y IG5vdD8NCg0KTm8uDQoNCg0KL21hcnRpbg0K From nobody Tue Dec 6 02:34:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE64129FD9 for ; Tue, 6 Dec 2016 02:34:55 -0800 (PST) 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 wjw3OUtbaTnJ for ; Tue, 6 Dec 2016 02:34:52 -0800 (PST) Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE859129FD7 for ; Tue, 6 Dec 2016 02:34:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 9351C1422ED9; Tue, 6 Dec 2016 11:34:45 +0100 (CET) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id n-KaIbq-F_rl; Tue, 6 Dec 2016 11:34:45 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 6AB241422EDD; Tue, 6 Dec 2016 11:34:45 +0100 (CET) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bJxGJq6srDEc; Tue, 6 Dec 2016 11:34:45 +0100 (CET) Received: from [192.168.209.111] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 413631422ED9; Tue, 6 Dec 2016 11:34:45 +0100 (CET) To: Robert Wilton , netmod@ietf.org References: <5bc806b2-4941-dded-8e78-a3ffbaeeb9a6@cisco.com> From: Vladimir Vassilev Message-ID: Date: Tue, 6 Dec 2016 11:34:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: <5bc806b2-4941-dded-8e78-a3ffbaeeb9a6@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 10:34:55 -0000 On 12/05/2016 07:10 PM, Robert Wilton wrote: > Hi, > > We are currently working on modelling 802.3 Ethernet YANG within the > 802.3 YANG study group. > > One interesting issue that has come up is the scope of the operational > state data that could be modeled: > > At the top level, an operator may just want to know whether an > Ethernet interface is up or down. > > At a second level, if the Ethernet interface is down, then there is > some high level diagnostics information that may be useful to an > operator to diagnose why the interface isn't up (e.g. alarms > information, optical power levels, auto-negotiation protocol status). > > There is also a third level, of very detailed, 802.3 hardware register > information defined in 802.3 Clause 45. Such information is probably > of most relevance to the engineers developing and programming Ethernet > chips and PHYs, but is sometimes useful for resolving potential vendor > inter-operation issues. Retrieving this information out of the > Ethernet chips can be comparatively slow. > > The question that was being discussed is whether it is appropriate to > model all three levels on information in the 802.3 Ethernet YANG > models, or whether only the top level and second level information > can/should be modeled via YANG? > > If we were to model the third level information in YANG then it would > seem highly desirable for that information to not be returned in > response to a general NETCONF request because the information > is generally not of relevance and has potential performance issues in > returning it. Instead, it would seem desirable to only return this > data if it was specifically requested (e.g. a request on the > node containing the third level information), or if a hypothetical > filter extension was specified and used to explicitly include it in > the response. Given that there doesn't seem to a great way to > currently achieve this in YANG, this makes me think that it isn't > sensible to model this third level of detailed information in YANG at > this time. Do others agree? > > Have others faced similar issues, and if so, how have you solved them? How about having this state data reside under a config=true presence container e.g. /interfaces/interface/ethernet-detailed-state... . The user can then create the container for the interfaces he is interested in reading the detailed state data. Or have dedicated RPC in the model that enables/disables the presence of the detailed state information for certain interfaces. Since the state container is not mandatory. In any case a grouping with the 802.3 Clause 45 information data will definitely be usefull. /Vladimir > > Input welcome. Thanks, > Rob From nobody Tue Dec 6 06:32:55 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1E812A107 for ; Tue, 6 Dec 2016 06:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBgrZ7ChgAue for ; Tue, 6 Dec 2016 06:32:48 -0800 (PST) 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 4FC0A12A0F6 for ; Tue, 6 Dec 2016 06:32:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3965; q=dns/txt; s=iport; t=1481034754; x=1482244354; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=F59QdQctm2uvxgOSKpy5vS/UQK6HpUbYkyjVTtdaUoo=; b=X4f+PyrPTwYjkbJlj0DEeECsnyz5c19E10bSmjS1ANWeDrSl2Vy9Ddm9 M00blhzJc6Dk7SQnUdFChjUSX+3Dd+0IxcjpM2NkG8z0Q8+DKx7M2SDzV Fng+ezO1CeT+F9SvqKEu7ZNz5eaEOQ60wWm3Zy+thxAgPBYRGWZFN7oiw w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BOAQDMykZY/xbLJq1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzkBAQEBAY9Glw2Sb4IPggeGIgKCXhQBAgEBAQEBAQFiKIRoAQEBAwE?= =?us-ascii?q?4UQsYLlcGAQwIAQGIYwisAYtDAQEBAQEBAQECAQEBAQEBIYY+gX2CXoQuhXsBB?= =?us-ascii?q?JpmkRiBc4R9gyIjhgqKIINjhA4fN3gTDoVVPolCAQEB?= X-IronPort-AV: E=Sophos;i="5.33,310,1477958400"; d="scan'208";a="648679879" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Dec 2016 14:32:32 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uB6EWVuI002614; Tue, 6 Dec 2016 14:32:32 GMT To: Vladimir Vassilev , netmod@ietf.org References: <5bc806b2-4941-dded-8e78-a3ffbaeeb9a6@cisco.com> From: Robert Wilton Message-ID: Date: Tue, 6 Dec 2016 14:32:31 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 14:32:53 -0000 Hi Vladimir, Thanks for your suggestion. Please see some comments inline ... On 06/12/2016 10:34, Vladimir Vassilev wrote: > On 12/05/2016 07:10 PM, Robert Wilton wrote: > >> Hi, >> >> We are currently working on modelling 802.3 Ethernet YANG within the >> 802.3 YANG study group. >> >> One interesting issue that has come up is the scope of the >> operational state data that could be modeled: >> >> At the top level, an operator may just want to know whether an >> Ethernet interface is up or down. >> >> At a second level, if the Ethernet interface is down, then there is >> some high level diagnostics information that may be useful to an >> operator to diagnose why the interface isn't up (e.g. alarms >> information, optical power levels, auto-negotiation protocol status). >> >> There is also a third level, of very detailed, 802.3 hardware >> register information defined in 802.3 Clause 45. Such information is >> probably of most relevance to the engineers developing and >> programming Ethernet chips and PHYs, but is sometimes useful for >> resolving potential vendor inter-operation issues. Retrieving this >> information out of the Ethernet chips can be comparatively slow. >> >> The question that was being discussed is whether it is appropriate to >> model all three levels on information in the 802.3 Ethernet YANG >> models, or whether only the top level and second level information >> can/should be modeled via YANG? >> >> If we were to model the third level information in YANG then it would >> seem highly desirable for that information to not be returned in >> response to a general NETCONF request because the information >> is generally not of relevance and has potential performance issues in >> returning it. Instead, it would seem desirable to only return this >> data if it was specifically requested (e.g. a request on the >> node containing the third level information), or if a hypothetical >> filter extension was specified and used to explicitly include it in >> the response. Given that there doesn't seem to a great way to >> currently achieve this in YANG, this makes me think that it isn't >> sensible to model this third level of detailed information in YANG at >> this time. Do others agree? >> >> Have others faced similar issues, and if so, how have you solved them? > How about having this state data reside under a config=true presence > container e.g. /interfaces/interface/ethernet-detailed-state... . The > user can then create the container for the interfaces he is interested > in reading the detailed state data. I'm not too keen on this approach. This would mean that an operator would need to have NACM permissions to modify the configuration to be allowed to retrieve read-only diagnostics information. > > Or have dedicated RPC in the model that enables/disables the presence > of the detailed state information for certain interfaces. Since the > state container is not mandatory. This would sort of work, but then there is still some magic involved for the client and device to have the knowledge not to return the diagnostics information in a standard get request. I was thinking that defining an extension to mark the leaves in the schema as being diagnostics information might be the right way forward. However, I was also thinking that just getting the basic (non diagnostics) operational YANG specified would be a useful first step along the 802.3 Ethernet model path. > > In any case a grouping with the 802.3 Clause 45 information data will > definitely be usefull. Given that there are a quite a lot of registers to define. It is quite possible that defining YANG for all these registers would be deferred until a future phase - do you see any issue with this? Thanks, Rob > > /Vladimir >> >> Input welcome. Thanks, >> Rob > > . > From nobody Tue Dec 6 06:59:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585911294A8 for ; Tue, 6 Dec 2016 06:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXIP4AaroWAc for ; Tue, 6 Dec 2016 06:58:59 -0800 (PST) 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 72B95129401 for ; Tue, 6 Dec 2016 06:58:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9623; q=dns/txt; s=iport; t=1481036338; x=1482245938; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=bAjtZkH/T+OTTpaU2WnsQRHIqfa0rWYiEVSvVOO9HGI=; b=emCD8amz9pdQ7BDcMnQAAX82dVLnUrxRyPhutyAn+1D98ddSrxKNS7v/ AOKabo19aGvXWBHjyPO2sXkXO3uUq1gxhXb09CIE7WWrW3MsRg09+Uoos HUjoaFKsUIG8h+CT1w0mbQMjNWlFRvDVeobeMvbSBUM0zDkWU76PbZrdD E=; X-IronPort-AV: E=Sophos;i="5.33,310,1477958400"; d="scan'208,217";a="650501105" 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; 06 Dec 2016 14:58:56 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uB6Ewuve011655; Tue, 6 Dec 2016 14:58:56 GMT To: Athanasios Kyparlis , "netmod@ietf.org" References: <5bc806b2-4941-dded-8e78-a3ffbaeeb9a6@cisco.com> From: Robert Wilton Message-ID: <7b942d40-5b46-36ed-d940-ae12e2e93082@cisco.com> Date: Tue, 6 Dec 2016 14:58:56 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------00C00AD843FF970AF3C463F5" Archived-At: Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 14:59:01 -0000 This is a multi-part message in MIME format. --------------00C00AD843FF970AF3C463F5 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Athanasios, Thanks for the suggestion. As per my reply to Vladimir, I think that this solves the question of how to get them, but doesn't really solve the issue of how a client is expected to know that they wouldn't be included in a regular get request. Thanks, Rob On 05/12/2016 18:25, Athanasios Kyparlis wrote: > > Maybe not ideal, but could we use an action or rpc for them? > > ------------------------------------------------------------------------ > *From:* netmod on behalf of Robert Wilton > > *Sent:* Monday, December 5, 2016 1:10:47 PM > *To:* netmod@ietf.org > *Cc:* Peter Jones > *Subject:* [netmod] Modelling different "levels" of data in YANG > Hi, > > We are currently working on modelling 802.3 Ethernet YANG within the > 802.3 YANG study group. > > One interesting issue that has come up is the scope of the operational > state data that could be modeled: > > At the top level, an operator may just want to know whether an Ethernet > interface is up or down. > > At a second level, if the Ethernet interface is down, then there is some > high level diagnostics information that may be useful to an operator to > diagnose why the interface isn't up (e.g. alarms information, optical > power levels, auto-negotiation protocol status). > > There is also a third level, of very detailed, 802.3 hardware register > information defined in 802.3 Clause 45. Such information is probably of > most relevance to the engineers developing and programming Ethernet > chips and PHYs, but is sometimes useful for resolving potential vendor > inter-operation issues. Retrieving this information out of the Ethernet > chips can be comparatively slow. > > The question that was being discussed is whether it is appropriate to > model all three levels on information in the 802.3 Ethernet YANG models, > or whether only the top level and second level information can/should be > modeled via YANG? > > If we were to model the third level information in YANG then it would > seem highly desirable for that information to not be returned in > response to a general NETCONF request because the information is > generally not of relevance and has potential performance issues in > returning it. Instead, it would seem desirable to only return this data > if it was specifically requested (e.g. a request on the node > containing the third level information), or if a hypothetical filter > extension was specified and used to explicitly include it in the > response. Given that there doesn't seem to a great way to currently > achieve this in YANG, this makes me think that it isn't sensible to > model this third level of detailed information in YANG at this time. Do > others agree? > > Have others faced similar issues, and if so, how have you solved them? > > Input welcome. Thanks, > Rob > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------00C00AD843FF970AF3C463F5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Athanasios,


Thanks for the suggestion. As per my reply to Vladimir, I think that this solves the question of how to get them, but doesn't really solve the issue of how a client is expected to know that they wouldn't be included in a regular get request.


Thanks,
Rob



On 05/12/2016 18:25, Athanasios Kyparlis wrote:

Maybe not ideal, but could we use an action or rpc for them?

From: netmod <netmod-bounces@ietf.org> on behalf of Robert Wilton <rwilton@cisco.com>
Sent: Monday, December 5, 2016 1:10:47 PM
To: netmod@ietf.org
Cc: Peter Jones
Subject: [netmod] Modelling different "levels" of data in YANG
Hi,

We are currently working on modelling 802.3 Ethernet YANG within the
802.3 YANG study group.

One interesting issue that has come up is the scope of the operational
state data that could be modeled:

At the top level, an operator may just want to know whether an Ethernet
interface is up or down.

At a second level, if the Ethernet interface is down, then there is some
high level diagnostics information that may be useful to an operator to
diagnose why the interface isn't up (e.g. alarms information, optical
power levels, auto-negotiation protocol status).

There is also a third level, of very detailed, 802.3 hardware register
information defined in 802.3 Clause 45. Such information is probably of
most relevance to the engineers developing and programming Ethernet
chips and PHYs, but is sometimes useful for resolving potential vendor
inter-operation issues. Retrieving this information out of the Ethernet
chips can be comparatively slow.

The question that was being discussed is whether it is appropriate to
model all three levels on information in the 802.3 Ethernet YANG models,
or whether only the top level and second level information can/should be
modeled via YANG?

If we were to model the third level information in YANG then it would
seem highly desirable for that information to not be returned in
response to a general NETCONF <get/> request because the information is
generally not of relevance and has potential performance issues in
returning it. Instead, it would seem desirable to only return this data
if it was specifically requested (e.g. a <get/> request on the node
containing the third level information), or if a hypothetical filter
extension was specified and used to explicitly include it in the
response. Given that there doesn't seem to a great way to currently
achieve this in YANG, this makes me think that it isn't sensible to
model this third level of detailed information in YANG at this time. Do
others agree?

Have others faced similar issues, and if so, how have you solved them?

Input welcome. Thanks,
Rob


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

--------------00C00AD843FF970AF3C463F5-- From nobody Tue Dec 6 13:03:14 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4518E129C78 for ; Tue, 6 Dec 2016 13:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.896, 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 NW-faHBn7rVD for ; Tue, 6 Dec 2016 13:03:11 -0800 (PST) Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26710129C75 for ; Tue, 6 Dec 2016 13:03:11 -0800 (PST) From: Alex Campbell To: Robert Wilton , Athanasios Kyparlis , "netmod@ietf.org" Thread-Topic: [netmod] Modelling different "levels" of data in YANG Thread-Index: AQHSTyLu3XCXO7TdWkWUKi3dkySfuKD7BFCDgABj1GA= Date: Tue, 6 Dec 2016 21:03:09 +0000 Message-ID: <1481058189709.95115@Aviatnet.com> References: <5bc806b2-4941-dded-8e78-a3ffbaeeb9a6@cisco.com> , <7b942d40-5b46-36ed-d940-ae12e2e93082@cisco.com> In-Reply-To: <7b942d40-5b46-36ed-d940-ae12e2e93082@cisco.com> Accept-Language: en-NZ, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.15.6.10] Content-Type: multipart/alternative; boundary="_000_148105818970995115Aviatnetcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 21:03:13 -0000 --_000_148105818970995115Aviatnetcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IMO using an action or rpc is an okay solution for now, certainly better th= an than not including the data at all. Perhaps in the future the client could specify which YANG modules it cares = about, in addition to a subtree filter. Then you could put the extended dia= gnostic information into another module (using "augment"), and clients that= don't know about the extended diagnostic information wouldn't request it, = and clients that do would know to only request it when they need it. The problem also makes me think of ConfD's "hide groups", but it's hard to = see how those would be extended to support programmatic interfaces. ________________________________ From: netmod on behalf of Robert Wilton Sent: Wednesday, 7 December 2016 3:58 a.m. To: Athanasios Kyparlis; netmod@ietf.org Subject: Re: [netmod] Modelling different "levels" of data in YANG Hi Athanasios, Thanks for the suggestion. As per my reply to Vladimir, I think that this = solves the question of how to get them, but doesn't really solve the issue = of how a client is expected to know that they wouldn't be included in a reg= ular get request. Thanks, Rob On 05/12/2016 18:25, Athanasios Kyparlis wrote: Maybe not ideal, but could we use an action or rpc for them? ________________________________ From: netmod on b= ehalf of Robert Wilton Sent: Monday, December 5, 2016 1:10:47 PM To: netmod@ietf.org Cc: Peter Jones Subject: [netmod] Modelling different "levels" of data in YANG Hi, We are currently working on modelling 802.3 Ethernet YANG within the 802.3 YANG study group. One interesting issue that has come up is the scope of the operational state data that could be modeled: At the top level, an operator may just want to know whether an Ethernet interface is up or down. At a second level, if the Ethernet interface is down, then there is some high level diagnostics information that may be useful to an operator to diagnose why the interface isn't up (e.g. alarms information, optical power levels, auto-negotiation protocol status). There is also a third level, of very detailed, 802.3 hardware register information defined in 802.3 Clause 45. Such information is probably of most relevance to the engineers developing and programming Ethernet chips and PHYs, but is sometimes useful for resolving potential vendor inter-operation issues. Retrieving this information out of the Ethernet chips can be comparatively slow. The question that was being discussed is whether it is appropriate to model all three levels on information in the 802.3 Ethernet YANG models, or whether only the top level and second level information can/should be modeled via YANG? If we were to model the third level information in YANG then it would seem highly desirable for that information to not be returned in response to a general NETCONF request because the information is generally not of relevance and has potential performance issues in returning it. Instead, it would seem desirable to only return this data if it was specifically requested (e.g. a request on the node containing the third level information), or if a hypothetical filter extension was specified and used to explicitly include it in the response. Given that there doesn't seem to a great way to currently achieve this in YANG, this makes me think that it isn't sensible to model this third level of detailed information in YANG at this time. Do others agree? Have others faced similar issues, and if so, how have you solved them? Input welcome. Thanks, Rob _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_148105818970995115Aviatnetcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

IMO using an action or rpc is an okay solution for now, certainly better= than than not including the data at all.


Perhaps in the future the client could specify which YANG modules it cares = about, in addition to a subtree filter. Then you could put the extended dia= gnostic information into another module (using "augment"), and cl= ients that don't know about the extended diagnostic information wouldn't request it, and clients that do would know to only re= quest it when they need it.


The problem also makes me think of ConfD's "hide groups", but = it's hard to see how those would be extended to support programmatic interf= aces.
 

From: netmod <netmod-bo= unces@ietf.org> on behalf of Robert Wilton <rwilton@cisco.com>
Sent: Wednesday, 7 December 2016 3:58 a.m.
To: Athanasios Kyparlis; netmod@ietf.org
Subject: Re: [netmod] Modelling different "levels" of data= in YANG
 

Hi Athanasios,


Thanks for the suggestion.  As per my reply to Vladimir, I think th= at this solves the question of how to get them, but doesn't really solve th= e issue of how a client is expected to know that they wouldn't be included = in a regular get request.


Thanks,
Rob



On 05/12/2016 18:25, Athanasios Kyparlis wro= te:

Maybe not ideal, but could we use an action or rpc for them?

From: netmod = <netmod-bounces@ietf.org> on behalf of Robert Wilton <rw= ilton@cisco.com>
Sent: Monday, December 5, 2016 1:10:47 PM
To: netmod@ietf.org
Cc: Peter Jones
Subject: [netmod] Modelling different "levels" of data in = YANG
 
Hi,

We are currently working on modelling 802.3 Ethernet YANG within the
802.3 YANG study group.

One interesting issue that has come up is the scope of the operational
state data that could be modeled:

At the top level, an operator may just want to know whether an Ethernet interface is up or down.

At a second level, if the Ethernet interface is down, then there is some high level diagnostics information that may be useful to an operator to diagnose why the interface isn't up (e.g. alarms information, optical
power levels, auto-negotiation protocol status).

There is also a third level, of very detailed, 802.3 hardware register
information defined in 802.3 Clause 45.  Such information is probably = of
most relevance to the engineers developing and programming Ethernet
chips and PHYs, but is sometimes useful for resolving potential vendor
inter-operation issues.  Retrieving this information out of the Ethern= et
chips can be comparatively slow.

The question that was being discussed is whether it is appropriate to
model all three levels on information in the 802.3 Ethernet YANG models, or whether only the top level and second level information can/should be modeled via YANG?

If we were to model the third level information in YANG then it would
seem highly desirable for that information to not be returned in
response to a general NETCONF <get/> request because the information = is
generally not of relevance and has potential performance issues in
returning it.  Instead, it would seem desirable to only return this da= ta
if it was specifically requested (e.g. a <get/> request on the node <= br> containing the third level information), or if a hypothetical filter
extension was specified and used to explicitly include it in the
response. Given that there doesn't seem to a great way to currently
achieve this in YANG, this makes me think that it isn't sensible to
model this third level of detailed information in YANG at this time.  = Do
others agree?

Have others faced similar issues, and if so, how have you solved them?

Input welcome.  Thanks,
Rob


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

--_000_148105818970995115Aviatnetcom_-- From nobody Tue Dec 6 13:27:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBE8129CA0 for ; Tue, 6 Dec 2016 13:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kuatrotechnology.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppf9lF_1M0l7 for ; Tue, 6 Dec 2016 13:27:24 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30074.outbound.protection.outlook.com [40.107.3.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CAEC129C99 for ; Tue, 6 Dec 2016 13:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Fus+EgIFf1W257xbqaCK71sWMOz9ns275DIcqZ4/nKI=; b=Bka+306ZB5AESxjxxqGaxM6Lmm/LlQodW5MuQv1e1ldWwA9XjoYv6799D5DmB1RBACWAK42IfSnWo0Roz0p/dRJSEgHyw1mLcLXUBI57yYaypaPP2qaAmeAKeAoEBd0kiO81jONEP87xQ1PBQH2o04j9AxhEKh/umN5bCia+nX0= Received: from AM5PR0602MB2786.eurprd06.prod.outlook.com (10.175.39.147) by AM5PR0602MB2788.eurprd06.prod.outlook.com (10.175.39.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.9; Tue, 6 Dec 2016 21:27:21 +0000 Received: from AM5PR0602MB2786.eurprd06.prod.outlook.com ([10.175.39.147]) by AM5PR0602MB2786.eurprd06.prod.outlook.com ([10.175.39.147]) with mapi id 15.01.0761.017; Tue, 6 Dec 2016 21:27:21 +0000 From: Athanasios Kyparlis To: Alex Campbell , Robert Wilton , "netmod@ietf.org" Thread-Topic: [netmod] Modelling different "levels" of data in YANG Thread-Index: AQHSTyLuK4hXU5IZ+EGqzMq+JvrSlaD5q1pCgAFY6ACAAGXDgIAAADtAgAAGctA= Date: Tue, 6 Dec 2016 21:27:21 +0000 Message-ID: References: <5bc806b2-4941-dded-8e78-a3ffbaeeb9a6@cisco.com> , <7b942d40-5b46-36ed-d940-ae12e2e93082@cisco.com> <1481058189709.95115@Aviatnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=akyparlis@kuatrotech.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: b842357c-92cc-4251-d0c7-08d41e1eaa17 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0602MB2788; x-microsoft-exchange-diagnostics: 1; AM5PR0602MB2788; 7:pNorGTNrbDAXIcEAmI66PvwxCS1Ntrs4SgdAhTJfe75+/MeJkdelw1uOoPtOpCtxlIKZbaGZUt4MKY/FUG5uZWk8hM1mhFH8sK6iOByeyjPxQ1+ObyZozAdgiXMyZBNMbHZQD5z32jDWnXILJBXxRFbrdm07YanAI6uo7V8xcE0N0DOhTAai2ifKWaLy6k0ZRCnzmnSo6/ED1MezmHCKg/w3KkjTQNP1BHLIqWfHdC3FMNGq96DPE34NBh3gYfwy0qanKDfbYMlHAR8gxIrgk1ykdA8doZJBBFhXv5+A+L1GyHazrSmyVtIQPv0G6N3S3MKk5bFNvnod8ibGKZNUca7yjd92ylAAe5tpffWHECmzmRxZp9kVSHDvYWdb0tzM3VD9gfIGNQImXsKazAxh5J2vZGUgbIJKGgxehR9bklmbEAEJQeqkDlKukHqv7ijYxALgfJAJytiXHgwQWByGMg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014)(21748063052155)(21534305686606); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(2016111802025)(6043046)(6072148); SRVR:AM5PR0602MB2788; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0602MB2788; x-forefront-prvs: 01480965DA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(24454002)(51914003)(51444003)(199003)(377454003)(189002)(3900700001)(106356001)(54356999)(68736007)(2950100002)(3280700002)(93886004)(7846002)(7736002)(229853002)(606004)(3660700001)(105586002)(9686002)(76176999)(39410400001)(8936002)(38730400001)(39840400001)(6506006)(50986999)(8676002)(102836003)(6116002)(3846002)(81166006)(106116001)(81156014)(39450400002)(77096006)(76576001)(790700001)(2906002)(2900100001)(97736004)(5001770100001)(66066001)(2501003)(189998001)(7696004)(101416001)(107886002)(7906003)(74316002)(92566002)(33656002)(122556002)(86362001)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0602MB2788; H:AM5PR0602MB2786.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: kuatrotech.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0602MB27861C97E01DD38B27A7B97CDF820AM5PR0602MB2786_" MIME-Version: 1.0 X-OriginatorOrg: kuatrotech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2016 21:27:21.7051 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0602MB2788 Archived-At: Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 21:27:28 -0000 --_000_AM5PR0602MB27861C97E01DD38B27A7B97CDF820AM5PR0602MB2786_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Athanasios Kyparlis Sent: Tuesday, December 6, 2016 4:06 PM To: 'Alex Campbell' ; Robert Wilton ; netmod@ietf.org Subject: RE: [netmod] Modelling different "levels" of data in YANG To answer Rob's question (if I understand it correctly), the client would k= now the data is not included in a regular get, as the data definition will = only exist in the action/rpc output definition. Thanks From: Alex Campbell [mailto:Alex.Campbell@Aviatnet.com] Sent: Tuesday, December 6, 2016 4:03 PM To: Robert Wilton >; Athanasios= Kyparlis >; netmod@ietf.org Subject: Re: [netmod] Modelling different "levels" of data in YANG IMO using an action or rpc is an okay solution for now, certainly better th= an than not including the data at all. Perhaps in the future the client could specify which YANG modules it cares = about, in addition to a subtree filter. Then you could put the extended dia= gnostic information into another module (using "augment"), and clients that= don't know about the extended diagnostic information wouldn't request it, = and clients that do would know to only request it when they need it. The problem also makes me think of ConfD's "hide groups", but it's hard to = see how those would be extended to support programmatic interfaces. ________________________________ From: netmod > on b= ehalf of Robert Wilton > Sent: Wednesday, 7 December 2016 3:58 a.m. To: Athanasios Kyparlis; netmod@ietf.org Subject: Re: [netmod] Modelling different "levels" of data in YANG Hi Athanasios, Thanks for the suggestion. As per my reply to Vladimir, I think that this = solves the question of how to get them, but doesn't really solve the issue = of how a client is expected to know that they wouldn't be included in a reg= ular get request. Thanks, Rob On 05/12/2016 18:25, Athanasios Kyparlis wrote: Maybe not ideal, but could we use an action or rpc for them? ________________________________ From: netmod on b= ehalf of Robert Wilton Sent: Monday, December 5, 2016 1:10:47 PM To: netmod@ietf.org Cc: Peter Jones Subject: [netmod] Modelling different "levels" of data in YANG Hi, We are currently working on modelling 802.3 Ethernet YANG within the 802.3 YANG study group. One interesting issue that has come up is the scope of the operational state data that could be modeled: At the top level, an operator may just want to know whether an Ethernet interface is up or down. At a second level, if the Ethernet interface is down, then there is some high level diagnostics information that may be useful to an operator to diagnose why the interface isn't up (e.g. alarms information, optical power levels, auto-negotiation protocol status). There is also a third level, of very detailed, 802.3 hardware register information defined in 802.3 Clause 45. Such information is probably of most relevance to the engineers developing and programming Ethernet chips and PHYs, but is sometimes useful for resolving potential vendor inter-operation issues. Retrieving this information out of the Ethernet chips can be comparatively slow. The question that was being discussed is whether it is appropriate to model all three levels on information in the 802.3 Ethernet YANG models, or whether only the top level and second level information can/should be modeled via YANG? If we were to model the third level information in YANG then it would seem highly desirable for that information to not be returned in response to a general NETCONF request because the information is generally not of relevance and has potential performance issues in returning it. Instead, it would seem desirable to only return this data if it was specifically requested (e.g. a request on the node containing the third level information), or if a hypothetical filter extension was specified and used to explicitly include it in the response. Given that there doesn't seem to a great way to currently achieve this in YANG, this makes me think that it isn't sensible to model this third level of detailed information in YANG at this time. Do others agree? Have others faced similar issues, and if so, how have you solved them? Input welcome. Thanks, Rob _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_AM5PR0602MB27861C97E01DD38B27A7B97CDF820AM5PR0602MB2786_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Athanasios Kyparlis
Sent: Tuesday, December 6, 2016 4:06 PM
To: 'Alex Campbell' <Alex.Campbell@Aviatnet.com>; Robert Wilto= n <rwilton@cisco.com>; netmod@ietf.org
Subject: RE: [netmod] Modelling different "levels" of data= in YANG

 

To answer Rob’s question (if I understand it = correctly), the client would know the data is not included in a regular get= , as the data definition will only exist in the action/rpc output definition.

 

Thanks

 

 

From: Alex Campbell [mailto:Alex.Campbell@Aviatnet.com]
Sent: Tuesday, December 6, 2016 4:03 PM
To: Robert Wilton <rwilton@c= isco.com>; Athanasios Kyparlis <Athanasios_Kyparlis@jabil.com>; netmod@ietf.org
Subject: Re: [netmod] Modelling different "levels" of data= in YANG

 

I= MO using an action or rpc is an okay solution for now, certainly better tha= n than not including the data at all.

<= o:p> 

Perhaps in the future the client could specify which YAN= G modules it cares about, in addition to a subtree filter. Then you could p= ut the extended diagnostic information into another module (using "augment"), and clients that don't know about the = extended diagnostic information wouldn't request it, and clients that do wo= uld know to only request it when they need it.

<= o:p> 

T= he problem also makes me think of ConfD's "hide groups", but it's= hard to see how those would be extended to support programmatic interfaces= .
 

From: netmod= <netmod-bounces@ietf.org= > on behalf of Robert Wilton <rwilto= n@cisco.com>
Sent: Wednesday, 7 December 2016 3:58 a.m.
To: Athanasios Kyparlis; netmod@i= etf.org
Subject: Re: [netmod] Modelling different "levels" of data= in YANG

 

Hi Athanasios,

 

Thanks for the suggestion.  As per my reply to Vladimir, I think that= this solves the question of how to get them, but doesn't really solve the = issue of how a client is expected to know that they wouldn't be included in a regular get request.

 

Thanks,
Rob

 

 

On 05/12/2016 18:25, Athanasios Kyparlis wrote:

M= aybe not ideal, but could we use an action or rpc for them?

From: netmod <netmod-bounces@ietf.org><= /a> on behalf of Robert Wilton <rwilton@cisco.com>
Sent: Monday, December 5, 2016 1:10:47 PM
To: netmod@ietf.org
Cc: Peter Jones
Subject: [netmod] Modelling different "levels" of data in = YANG

 

Hi,

We are currently working on modelling 802.3 Ethernet YANG within the
802.3 YANG study group.

One interesting issue that has come up is the scope of the operational
state data that could be modeled:

At the top level, an operator may just want to know whether an Ethernet interface is up or down.

At a second level, if the Ethernet interface is down, then there is some high level diagnostics information that may be useful to an operator to diagnose why the interface isn't up (e.g. alarms information, optical
power levels, auto-negotiation protocol status).

There is also a third level, of very detailed, 802.3 hardware register
information defined in 802.3 Clause 45.  Such information is probably = of
most relevance to the engineers developing and programming Ethernet
chips and PHYs, but is sometimes useful for resolving potential vendor
inter-operation issues.  Retrieving this information out of the Ethern= et
chips can be comparatively slow.

The question that was being discussed is whether it is appropriate to
model all three levels on information in the 802.3 Ethernet YANG models, or whether only the top level and second level information can/should be modeled via YANG?

If we were to model the third level information in YANG then it would
seem highly desirable for that information to not be returned in
response to a general NETCONF <get/> request because the information = is
generally not of relevance and has potential performance issues in
returning it.  Instead, it would seem desirable to only return this da= ta
if it was specifically requested (e.g. a <get/> request on the node <= br> containing the third level information), or if a hypothetical filter
extension was specified and used to explicitly include it in the
response. Given that there doesn't seem to a great way to currently
achieve this in YANG, this makes me think that it isn't sensible to
model this third level of detailed information in YANG at this time.  = Do
others agree?

Have others faced similar issues, and if so, how have you solved them?

Input welcome.  Thanks,
Rob


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

 

--_000_AM5PR0602MB27861C97E01DD38B27A7B97CDF820AM5PR0602MB2786_-- From nobody Tue Dec 6 13:40:48 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D6A129CBE for ; Tue, 6 Dec 2016 13:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 XwB-RvTrGHdw for ; Tue, 6 Dec 2016 13:40:45 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8532129CB2 for ; Tue, 6 Dec 2016 13:40:44 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0BF5E7CB for ; Tue, 6 Dec 2016 22:40:43 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id r2Iylh1WizLJ for ; Tue, 6 Dec 2016 22:40:40 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 6 Dec 2016 22:40:42 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5AC4520067 for ; Tue, 6 Dec 2016 22:40:42 +0100 (CET) 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 ABTC7qVqU3ky; Tue, 6 Dec 2016 22:40:41 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A4DD20062; Tue, 6 Dec 2016 22:40:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 635143DA0663; Tue, 6 Dec 2016 22:40:41 +0100 (CET) Date: Tue, 6 Dec 2016 22:40:41 +0100 From: Juergen Schoenwaelder To: "netmod@ietf.org" Message-ID: <20161206214040.GA99577@elstar.local> Mail-Followup-To: "netmod@ietf.org" References: <5bc806b2-4941-dded-8e78-a3ffbaeeb9a6@cisco.com> <7b942d40-5b46-36ed-d940-ae12e2e93082@cisco.com> <1481058189709.95115@Aviatnet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1481058189709.95115@Aviatnet.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 21:40:48 -0000 I fear that a dumb client sending a without a proper filter to select the data that is relevant for the client will not necessarily get smarter by defining additional operations. Sometimes access control can help to control dumb clients that try to get everything (and then ignore most of the data they receive); simply make sure that only the information is accessible to a client that is actually needed by a client. In other words, the filtering logic does not have to be hard coded in the data model. /js On Tue, Dec 06, 2016 at 09:03:09PM +0000, Alex Campbell wrote: > IMO using an action or rpc is an okay solution for now, certainly better than than not including the data at all. > > > Perhaps in the future the client could specify which YANG modules it cares about, in addition to a subtree filter. Then you could put the extended diagnostic information into another module (using "augment"), and clients that don't know about the extended diagnostic information wouldn't request it, and clients that do would know to only request it when they need it. > > > The problem also makes me think of ConfD's "hide groups", but it's hard to see how those would be extended to support programmatic interfaces. > > > ________________________________ > From: netmod on behalf of Robert Wilton > Sent: Wednesday, 7 December 2016 3:58 a.m. > To: Athanasios Kyparlis; netmod@ietf.org > Subject: Re: [netmod] Modelling different "levels" of data in YANG > > > Hi Athanasios, > > > Thanks for the suggestion. As per my reply to Vladimir, I think that this solves the question of how to get them, but doesn't really solve the issue of how a client is expected to know that they wouldn't be included in a regular get request. > > > Thanks, > Rob > > > On 05/12/2016 18:25, Athanasios Kyparlis wrote: > > Maybe not ideal, but could we use an action or rpc for them? > > ________________________________ > From: netmod on behalf of Robert Wilton > Sent: Monday, December 5, 2016 1:10:47 PM > To: netmod@ietf.org > Cc: Peter Jones > Subject: [netmod] Modelling different "levels" of data in YANG > > Hi, > > We are currently working on modelling 802.3 Ethernet YANG within the > 802.3 YANG study group. > > One interesting issue that has come up is the scope of the operational > state data that could be modeled: > > At the top level, an operator may just want to know whether an Ethernet > interface is up or down. > > At a second level, if the Ethernet interface is down, then there is some > high level diagnostics information that may be useful to an operator to > diagnose why the interface isn't up (e.g. alarms information, optical > power levels, auto-negotiation protocol status). > > There is also a third level, of very detailed, 802.3 hardware register > information defined in 802.3 Clause 45. Such information is probably of > most relevance to the engineers developing and programming Ethernet > chips and PHYs, but is sometimes useful for resolving potential vendor > inter-operation issues. Retrieving this information out of the Ethernet > chips can be comparatively slow. > > The question that was being discussed is whether it is appropriate to > model all three levels on information in the 802.3 Ethernet YANG models, > or whether only the top level and second level information can/should be > modeled via YANG? > > If we were to model the third level information in YANG then it would > seem highly desirable for that information to not be returned in > response to a general NETCONF request because the information is > generally not of relevance and has potential performance issues in > returning it. Instead, it would seem desirable to only return this data > if it was specifically requested (e.g. a request on the node > containing the third level information), or if a hypothetical filter > extension was specified and used to explicitly include it in the > response. Given that there doesn't seem to a great way to currently > achieve this in YANG, this makes me think that it isn't sensible to > model this third level of detailed information in YANG at this time. Do > others agree? > > Have others faced similar issues, and if so, how have you solved them? > > Input welcome. Thanks, > Rob > > > _______________________________________________ > 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 Wed Dec 7 03:26:14 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C6A129D9D for ; Wed, 7 Dec 2016 03:26:13 -0800 (PST) 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 Bj0EpTVE4qMc for ; Wed, 7 Dec 2016 03:26:10 -0800 (PST) Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2319712969F for ; Wed, 7 Dec 2016 03:26:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 49D402FA04F6; Wed, 7 Dec 2016 12:26:00 +0100 (CET) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id twuhdth9OtB6; Wed, 7 Dec 2016 12:26:00 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 1F7F22FA04F9; Wed, 7 Dec 2016 12:26:00 +0100 (CET) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id epZaU2ZVsLID; Wed, 7 Dec 2016 12:26:00 +0100 (CET) Received: from [192.168.209.111] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id ED6562FA04F6; Wed, 7 Dec 2016 12:25:59 +0100 (CET) To: Juergen Schoenwaelder , netmod@ietf.org References: <5bc806b2-4941-dded-8e78-a3ffbaeeb9a6@cisco.com> <7b942d40-5b46-36ed-d940-ae12e2e93082@cisco.com> <1481058189709.95115@Aviatnet.com> <20161206214040.GA99577@elstar.local> From: Vladimir Vassilev Message-ID: <08b61190-5e87-0000-34b3-f7ef099efa98@transpacket.com> Date: Wed, 7 Dec 2016 12:25:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161206214040.GA99577@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 11:26:13 -0000 On 12/06/2016 10:40 PM, Juergen Schoenwaelder wrote: > I fear that a dumb client sending a without a proper filter to > select the data that is relevant for the client will not necessarily > get smarter by defining additional operations. > > Sometimes access control can help to control dumb clients that try to > get everything (and then ignore most of the data they receive); simply > make sure that only the information is accessible to a client that is > actually needed by a client. In other words, the filtering logic does > not have to be hard coded in the data model. +1 One additional solution for consideration is a new top level config=false container with a list e.g. /ethernet-interfaces-state/ethernet-interface/... where the key is leafref to /interfaces-state/interface/name With this solution IMO all requirements mentioned in the discussion so far are satisfied without the need to introduce any RPCs or hard coding filtering logic in the model. /Vladimir > > /js From nobody Wed Dec 7 05:09:22 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9AC129F0E for ; Wed, 7 Dec 2016 05:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 Oay3gq4bKZWs for ; Wed, 7 Dec 2016 05:09:18 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 088D6129F0C for ; Wed, 7 Dec 2016 05:03:28 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5778D7EF for ; Wed, 7 Dec 2016 14:03:26 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id guFCWstd1sq8 for ; Wed, 7 Dec 2016 14:03:23 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 7 Dec 2016 14:03:26 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C0A620063 for ; Wed, 7 Dec 2016 14:03:26 +0100 (CET) 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 xNg5IGi3xhJW for ; Wed, 7 Dec 2016 14:03:25 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C48042005F for ; Wed, 7 Dec 2016 14:03:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6C3B33DA1887; Wed, 7 Dec 2016 13:57:01 +0100 (CET) Date: Wed, 7 Dec 2016 13:57:01 +0100 From: Juergen Schoenwaelder To: Vladimir Vassilev Message-ID: <20161207125701.GA609@elstar.local> Mail-Followup-To: Vladimir Vassilev , netmod@ietf.org References: <5bc806b2-4941-dded-8e78-a3ffbaeeb9a6@cisco.com> <7b942d40-5b46-36ed-d940-ae12e2e93082@cisco.com> <1481058189709.95115@Aviatnet.com> <20161206214040.GA99577@elstar.local> <08b61190-5e87-0000-34b3-f7ef099efa98@transpacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <08b61190-5e87-0000-34b3-f7ef099efa98@transpacket.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 13:09:21 -0000 On Wed, Dec 07, 2016 at 12:25:59PM +0100, Vladimir Vassilev wrote: > On 12/06/2016 10:40 PM, Juergen Schoenwaelder wrote: > > > I fear that a dumb client sending a without a proper filter to > > select the data that is relevant for the client will not necessarily > > get smarter by defining additional operations. > > > > Sometimes access control can help to control dumb clients that try to > > get everything (and then ignore most of the data they receive); simply > > make sure that only the information is accessible to a client that is > > actually needed by a client. In other words, the filtering logic does > > not have to be hard coded in the data model. > +1 > > One additional solution for consideration is a new top level config=false > container with a list e.g. /ethernet-interfaces-state/ethernet-interface/... > where the key is leafref to /interfaces-state/interface/name With this > solution IMO all requirements mentioned in the discussion so far are > satisfied without the need to introduce any RPCs or hard coding filtering > logic in the model. > This may help until the dumb client grabs /ethernet-interfaces-state as well. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Dec 7 05:16:28 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B575129A65 for ; Wed, 7 Dec 2016 05:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B827WZ1-fAbQ for ; Wed, 7 Dec 2016 05:16:24 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B795129EC2 for ; Wed, 7 Dec 2016 05:12:45 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 48FEAE864141A for ; Wed, 7 Dec 2016 13:10:50 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uB7DApPv020255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 7 Dec 2016 13:10:52 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id uB7DA8lC027865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 7 Dec 2016 13:10:43 GMT Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.164]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Wed, 7 Dec 2016 14:07:57 +0100 From: "Bogaert, Bart (Nokia - BE)" To: "netmod@ietf.org" Thread-Topic: Question about if-feature Thread-Index: AdJQii4ueXVsQidGTBaSKYQg9JhGAQ== Date: Wed, 7 Dec 2016 13:07:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_030D_01D25093.4E87E870" MIME-Version: 1.0 Archived-At: Subject: [netmod] Question about if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 13:16:27 -0000 ------=_NextPart_000_030D_01D25093.4E87E870 Content-Type: multipart/alternative; boundary="----=_NextPart_001_030E_01D25093.4E87E870" ------=_NextPart_001_030E_01D25093.4E87E870 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi I have a question about the usage of if-feature. Assume the following YANG module: module performance-management { namespace "http://www.example.com/performance-management"; prefix if-pm; import ietf-interfaces { prefix if; } feature performance-24hr { description "Indicates that collection of 24 hour performance intervals is supported"; } augment "/if:interfaces-state/if:interface" { description "Data nodes for the performance status parameters"; container performance { description "Performance parameters"; container intervals-24hr { if-feature performance-24hr; description "24 hour interval performance history"; container current { description "Contains the counts that are currently accumulating."; } list history { key interval-number; max-elements 7; description "A history of 24 hour intervals."; leaf interval-number { type uint16; description "The number of the interval relative to the current interval."; } } } } } } Another YANG module augments the container which is defined under a feature. module use-performance-management { yang-version 1.1; namespace "http://www.example.com/use-performance-management"; prefix use-pm; import ietf-interfaces { prefix if; } import performance-management { prefix if-pm; } augment '/if:interfaces-state/if:interface/if-pm:performance/' + 'if-pm:intervals-24hr/if-pm:current' { description "Augment the current 24 hour interface performance counts with Ethernet specific attributes."; container ethernet { description "Current 24 hour Ethernet performance counters."; leaf some-value { type uint32; } } } } According to me an if-feature statement is missing here: how can a module augment a container defined under the 'restriction" of a feature. If the feature is not supported then the container is not there and hence one can't augment that container in another YANG module. Is my understanding correct? Best regards - Vriendelijke groeten, Bart Bogaert Broadband-Access System Architect Data Contact number +32 3 2408310 (+32 477 673952) NOKIA Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE 0404 621 642 Register of Legal Entities Antwerp << This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited without the prior consent of its author. >> ------=_NextPart_001_030E_01D25093.4E87E870 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi I have a question about the usage of if-feature.  = Assume the following YANG module:

 

module performance-management = {

  = namespace = "http://www.example.com/performance-management";  =

  prefix if-pm;

 

  import ietf-interfaces = {

    prefix if;

  }

 

  feature = performance-24hr {

    description

      = "Indicates that collection of 24 hour performance = intervals

       is = supported";

  }

 

  augment = "/if:interfaces-state/if:interface" {

    description =

      "Data nodes for = the performance status parameters";

      =

    container performance = {

      = description

        = "Performance parameters";

 

      = container intervals-24hr {

        if-feature = performance-24hr;

        = description

          = "24 hour interval performance = history";

 

        container = current {

          = description

          =   "Contains the counts that are currently = accumulating.";

        = }

 

        list history = {

          key = interval-number;

          = max-elements 7;

          = description

          =   "A history of 24 hour = intervals.";

 

          leaf = interval-number {

          =   type uint16;

          =   description

          =     "The number of the interval relative to the = current

          =      interval.";

          = }

        = }

      }

    = }

  = }

}

 

Another YANG module augments the container which is defined = under a feature.

 

module use-performance-management {

  yang-version = 1.1;

  = namespace = "http://www.example.com/use-performance-management";=

  prefix = use-pm;

 

  import ietf-interfaces {

    prefix = if;

  = }

 

  import performance-management = {

    prefix if-pm;

  }

 

  augment = '/if:interfaces-state/if:interface/if-pm:performance/'<= /p>

        + = 'if-pm:intervals-24hr/if-pm:current' {

    = description

      "Augment the current 24 = hour interface performance counts with

       Ethernet specific = attributes.";

 

    container ethernet = {

      = description

        "Current 24 = hour Ethernet performance counters.";

      leaf = some-value {

        type = uint32;

      }

    = }

  = }

}

 

According to me an if-feature statement is missing here: = how can a module augment a container defined under the = ‘restriction” of a feature.  If the feature is not = supported then the container is not there and hence one can’t = augment that container in another YANG module.  Is my understanding = correct?

 

 

Best regards - Vriendelijke groeten,

Bart Bogaert

Broadband-Access System Architect Data

Contact number +32 3 2408310 (+32 477 = 673952)

 

NOKIA

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

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

 

------=_NextPart_001_030E_01D25093.4E87E870-- ------=_NextPart_000_030D_01D25093.4E87E870 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/TCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr 4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0 ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3 dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93 d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy 7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6 /XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYzCCBkugAwIBAgIKXRYRuwAAAADQ8TANBgkq hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDE2MDU1MjI4WhcNMTcwNDE1 MDU1MjI4WjBDMREwDwYDVQQDEwhib2dhZXJ0YjEuMCwGCSqGSIb3DQEJARYfYmFydC5ib2dhZXJ0 QGFsY2F0ZWwtbHVjZW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJBS7alw mZfOimfXIdJjyp1G8U+E4Rs5y+eXtDfKWEuy6UOCstRCUiSz+eljCu737ZPkMHmPMdXDHZGnsV9y HsInD5cZHBTNnboc8lV7zLVpTrtrnflClsOiRD75CS1Vvehx+JnFuW4Mo/VeWjQtUD4tUU67W7b0 QPOkcB3KkZixozjERSxPUFHf6pMShshwQlKtvV6YLdhnNePiuFimfYqUDiOQs1LR8C+r3eSMHi8o lyWTHf49vFPL7z62HWSldeEkf6vhtuZuWLfH7xqO3CIQH63zUJF9p23ko2/Gtc1MpAcdWMwV3ymj V8ef+gZac/SFwFgA547zeawhhvtdiOUCAwEAAaOCBBQwggQQMD0GCSsGAQQBgjcVBwQwMC4GJisG AQQBgjcVCIW9xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisG AQQBgjcKAwQGCCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQB gjcKAwQwCgYIKwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZI hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBTzjeedsBUMWk5eyOwD8/c9 1B1G8jAfBgNVHSMEGDAWgBTZ7Gu9llgi99imd83+TYHvupe9EjCCAV0GA1UdHwSCAVQwggFQMIIB TKCCAUigggFEhoHZbGRhcDovLy9DTj1BbGNhdGVsJTIwTHVjZW50JTIwSW50ZXJuYWwlMjBTdWIl MjBDQSxDTj11c25hdnNwa2kwM3AsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NlcnRp ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu dIYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmyGOGh0dHA6Ly9z ZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0EuY3JsMIIBYQYIKwYB BQUHAQEEggFTMIIBTzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQl MjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWx1YWQsREM9bHVjZW50LERDPWNvbT9jQUNl cnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA4BggrBgEF BQcwAoYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwRAYIKwYB BQUHMAKGOGh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3Vi Q0EuY3J0MCoGA1UdEQQjMCGBH2JhcnQuYm9nYWVydEBhbGNhdGVsLWx1Y2VudC5jb20wDQYJKoZI hvcNAQEFBQADggEBAEARoPJfuwXhstAQ/fAz/XKDC//Je9A0RG9Q5XV7+URvR5GxhwuikL/MEtXs Dspufv0eHG/b92AVZxaSgdpzC6neLoW2Q/Rdeavuifm7H/Ob645vIufqDQEqRqsyt9xRP+31VphA do994d7kU6v5BI7DAA8s5rl6h4PFbtvY5qe8VLNiTnon1dCwPQ+mRSrLfgjlZUw+WsMh69JEOWZX EufZMg0oUvCboUe3LNNvh8+DtLafaT1gS/kpv3c+dXVApTjb1tPbeZHc5L85AVQBsbq/vYpWhiZR qDiyVyPh+dh7vTa/GBJx/UVLwv6IswAwtCWZ/r9aReHssqkgMH9evF8xggQpMIIEJQIBATCBlDCB hTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT 8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1 Y2VudCBJbnRlcm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwCQYFKw4DAhoFAKCCAmkwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMjA3MTMwNzU1WjAjBgkqhkiG9w0B CQQxFgQUEyjF5yF0zEnYaM8KkaH8DY/YgBMwgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQBs HVEoF/i0crDa5oUYDqu0RdiVvR1EHJaRi0dg06+/zu5WuFyKQEtLpa1NGVHymh+PzZRvmQ9gX2kh AZzZGE7DjECarvk2luOrl2lO5xpsdogzU1fCj9/1n15xzxHrbaArDIXHFkKLkR1IHV9GIScGWP5N BuE4O3UJ1eW49auBLU8xK/ggccsclJAEVjeVVBAQEkiP+mO2FshfY516k9zyc6DngQNXtvLLvXk3 1B/9ppLn2oHSMyXBNsPe2cyc7phbTmyjzk0aKZK4EbQAMWCUjK7gevv4Xa71AHKjbgOi5+ClgjdN LQCkxDz0JK7e9GzsGTJN3rqjbu96GfYn+I+zAAAAAAAA ------=_NextPart_000_030D_01D25093.4E87E870-- From nobody Wed Dec 7 05:30:19 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87792129990 for ; Wed, 7 Dec 2016 05:30:17 -0800 (PST) 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 GI5KQkWoGqsJ for ; Wed, 7 Dec 2016 05:30:15 -0800 (PST) Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1F0A1298C3 for ; Wed, 7 Dec 2016 05:30:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id F1E561422C76; Wed, 7 Dec 2016 14:30:12 +0100 (CET) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id JT0ACk-KZHeI; Wed, 7 Dec 2016 14:30:12 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id C58001422CAE; Wed, 7 Dec 2016 14:30:12 +0100 (CET) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id y0QyQkMLJxOR; Wed, 7 Dec 2016 14:30:12 +0100 (CET) Received: from [192.168.209.111] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 9FA2B1422C76; Wed, 7 Dec 2016 14:30:12 +0100 (CET) To: Alex Campbell , netmod@ietf.org References: <5bc806b2-4941-dded-8e78-a3ffbaeeb9a6@cisco.com> <7b942d40-5b46-36ed-d940-ae12e2e93082@cisco.com> <1481058189709.95115@Aviatnet.com> From: Vladimir Vassilev Message-ID: <40eebd36-0e41-0082-f169-177dc95a537b@transpacket.com> Date: Wed, 7 Dec 2016 14:30:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: <1481058189709.95115@Aviatnet.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 13:30:17 -0000 On 12/06/2016 10:03 PM, Alex Campbell wrote: > IMO using an action or rpc is an okay solution for now, certainly > better than than not including the data at all. > If I have to chose between RPC with 'output' containing the state data for selected interface and mapping the data to a container/list not under /interfaces-state (e.g. another top level container) I prefer the second option since notifications and data models in general can refer to it as part of the data tree. It allows for simpler monitoring and implementation of alarms etc. > > > Perhaps in the future the client could specify which YANG modules it > cares about, in addition to a subtree filter. Then you could put the > extended diagnostic information into another module (using "augment"), > and clients that don't know about the extended diagnostic information > wouldn't request it, and clients that do would know to only request it > when they need it. One can use xpath 1.0 filter. This option is already available. Example RPC retrieving only state data of interest. ... ... Sane server implementations will skip the time consuming calbacks retrieving detailed data defined in other modules then ietf-intefaces and ietf-system. /Vladimir From nobody Wed Dec 7 05:33:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81DD1296F5 for ; Wed, 7 Dec 2016 05:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 1sJV1T5N5x9G for ; Wed, 7 Dec 2016 05:33:26 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BAB311296D3 for ; Wed, 7 Dec 2016 05:33:26 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id A61EE1AE028C; Wed, 7 Dec 2016 14:33:25 +0100 (CET) Date: Wed, 07 Dec 2016 14:33:25 +0100 (CET) Message-Id: <20161207.143325.638220940543467190.mbj@tail-f.com> To: bart.bogaert@nokia.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Question about if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 13:33:29 -0000 "Bogaert, Bart (Nokia - BE)" wrote: > Hi I have a question about the usage of if-feature. Assume the following > YANG module: > > > > module performance-management { > > namespace "http://www.example.com/performance-management"; > > prefix if-pm; > > > > import ietf-interfaces { > > prefix if; > > } > > > > feature performance-24hr { > > description > > "Indicates that collection of 24 hour performance intervals > > is supported"; > > } > > > > augment "/if:interfaces-state/if:interface" { > > description > > "Data nodes for the performance status parameters"; > > > > container performance { > > description > > "Performance parameters"; > > > > container intervals-24hr { > > if-feature performance-24hr; > > description > > "24 hour interval performance history"; > > > > container current { > > description > > "Contains the counts that are currently accumulating."; > > } > > > > list history { > > key interval-number; > > max-elements 7; > > description > > "A history of 24 hour intervals."; > > > > leaf interval-number { > > type uint16; > > description > > "The number of the interval relative to the current > > interval."; > > } > > } > > } > > } > > } > > } > > > > Another YANG module augments the container which is defined under a feature. > > > > module use-performance-management { > > yang-version 1.1; > > namespace "http://www.example.com/use-performance-management"; > > prefix use-pm; > > > > import ietf-interfaces { > > prefix if; > > } > > > > import performance-management { > > prefix if-pm; > > } > > > > augment '/if:interfaces-state/if:interface/if-pm:performance/' > > + 'if-pm:intervals-24hr/if-pm:current' { > > description > > "Augment the current 24 hour interface performance counts with > > Ethernet specific attributes."; > > > > container ethernet { > > description > > "Current 24 hour Ethernet performance counters."; > > leaf some-value { > > type uint32; > > } > > } > > } > > } > > > > According to me an if-feature statement is missing here: how can a module > augment a container defined under the 'restriction" of a feature. If the > feature is not supported then the container is not there and hence one can't > augment that container in another YANG module. Is my understanding correct? Note that "support a feature" is a run-time property, whereas the augmentation happens at design-time. If a server doesn't support the feature, it will not support the container, and thus not support anything in the schema below that container (added via augmentation or not). /martin From nobody Wed Dec 7 06:39:31 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532891294AD for ; Wed, 7 Dec 2016 06:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wf1QNSQts2wv for ; Wed, 7 Dec 2016 06:39:27 -0800 (PST) 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 5472C12949D for ; Wed, 7 Dec 2016 06:39:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3051; q=dns/txt; s=iport; t=1481121545; x=1482331145; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=LBwZra0g7bnYBRPjI8mxlv9gQyD2DjD9+oyZdrvxiL0=; b=NwKjmfKluOzG3ANqlJ64urYUbE7ZuS7N+FvnZzgNsY32tB8r1L6k5ElO uDM3LlV8z30+oiWPGBg+mA01znTTY1qyZlnv6mC7GvKn1YwRiB1qJaB7u w0UmVkyTerGxadqnx2Y3NnM9aJcbcbJz6Q8Cn18HciXajMazAcVv96inD 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AAApHkhY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgysOAQEBAQF5gQaNSJcQlH6CBx4LhS9KAoI1FAECAQEBAQEBAWI?= =?us-ascii?q?ohGkBAQQBATY2GwsYLicwBgEMBgIBAReIVA6qZ4s+AQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARkFhj6BfYJehDKFdwEEmmaRGIoShi2KIINjhA4fNzBIEw4jhTI+NIlGAQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.33,310,1477958400"; d="scan'208";a="650543234" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Dec 2016 14:39:00 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uB7Ecxes009513; Wed, 7 Dec 2016 14:39:00 GMT To: Vladimir Vassilev , Alex Campbell , netmod@ietf.org References: <5bc806b2-4941-dded-8e78-a3ffbaeeb9a6@cisco.com> <7b942d40-5b46-36ed-d940-ae12e2e93082@cisco.com> <1481058189709.95115@Aviatnet.com> <40eebd36-0e41-0082-f169-177dc95a537b@transpacket.com> From: Robert Wilton Message-ID: <4c900f1f-7b57-1bb0-1d41-3beec6c03bab@cisco.com> Date: Wed, 7 Dec 2016 14:39:00 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <40eebd36-0e41-0082-f169-177dc95a537b@transpacket.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 14:39:29 -0000 Hi, On 07/12/2016 13:30, Vladimir Vassilev wrote: > On 12/06/2016 10:03 PM, Alex Campbell wrote: > >> IMO using an action or rpc is an okay solution for now, certainly >> better than than not including the data at all. >> > If I have to chose between RPC with 'output' containing the state data > for selected interface and mapping the data to a container/list not > under /interfaces-state (e.g. another top level container) I prefer > the second option since notifications and data models in general can > refer to it as part of the data tree. It allows for simpler monitoring > and implementation of alarms etc. Given that there is a desire (draft-nmdsdt-netmod-revised-datastores-00, section 6.4) to deprecate "/foo-state" and to merge it with the configuration held under "/foo" then I would think that introducing a new top level "/foo-diagnostics" would seem to be heading in the wrong direction. Athanasios' suggestion to just define RPCs for this information, and only make the information available via RPC operations, seems like a reasonable one. Clients don't get spammed with stuff that they don't care about, but the information is still programmatically available if it is required. >> >> >> Perhaps in the future the client could specify which YANG modules it >> cares about, in addition to a subtree filter. Then you could put the >> extended diagnostic information into another module (using >> "augment"), and clients that don't know about the extended diagnostic >> information wouldn't request it, and clients that do would know to >> only request it when they need it. > One can use xpath 1.0 filter. This option is already available. > Example RPC retrieving only state data of interest. > > ... > > select="//*[namespace-uri()='urn:ietf:params:xml:ns:yang:ietf-interfaces' > or namespace-uri()='urn:ietf:params:xml:ns:yang:ietf-system']"/> > > ... > > Sane server implementations will skip the time consuming calbacks > retrieving detailed data defined in other modules then ietf-intefaces > and ietf-system. Alas, xpath filtering is optional, and I'm not sure how many devices have implemented support for it. Further, this still requires every client to be coded to avoid receiving the information that they are very unlikely to be interested in. I would much prefer a solution where the clients don't get this (mostly noise) data unless they explicitly ask for it. Otherwise for an Ethernet interface you might return 10 leaves of potentially useful opstate information, along with 50+ leaves of quite low layer diagnostics information that is likely to be of very little use except for to the select few people that are actively involved in trying to diagnose hardware faults. Thanks, Rob > > /Vladimir > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Wed Dec 7 08:13:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4851294EF for ; Wed, 7 Dec 2016 08:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 TlptjO17gtoM for ; Wed, 7 Dec 2016 08:13:39 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10A0612947F for ; Wed, 7 Dec 2016 08:13:39 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D0E016C1; Wed, 7 Dec 2016 17:13:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id m957yV7qLmNl; Wed, 7 Dec 2016 17:13:35 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 7 Dec 2016 17:13:37 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A6AA20062; Wed, 7 Dec 2016 17:13:37 +0100 (CET) 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 EqWhUs3wQvlN; Wed, 7 Dec 2016 17:13:36 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 604EF20063; Wed, 7 Dec 2016 17:13:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 24B183DA1DFD; Wed, 7 Dec 2016 17:13:36 +0100 (CET) Date: Wed, 7 Dec 2016 17:13:36 +0100 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20161207161336.GB792@elstar.local> Mail-Followup-To: Robert Wilton , Vladimir Vassilev , Alex Campbell , netmod@ietf.org References: <5bc806b2-4941-dded-8e78-a3ffbaeeb9a6@cisco.com> <7b942d40-5b46-36ed-d940-ae12e2e93082@cisco.com> <1481058189709.95115@Aviatnet.com> <40eebd36-0e41-0082-f169-177dc95a537b@transpacket.com> <4c900f1f-7b57-1bb0-1d41-3beec6c03bab@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4c900f1f-7b57-1bb0-1d41-3beec6c03bab@cisco.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 16:13:43 -0000 On Wed, Dec 07, 2016 at 02:39:00PM +0000, Robert Wilton wrote: > > Alas, xpath filtering is optional, and I'm not sure how many devices have > implemented support for it. Further, this still requires every client to be > coded to avoid receiving the information that they are very unlikely to be > interested in. > > I would much prefer a solution where the clients don't get this (mostly > noise) data unless they explicitly ask for it. Otherwise for an Ethernet > interface you might return 10 leaves of potentially useful opstate > information, along with 50+ leaves of quite low layer diagnostics > information that is likely to be of very little use except for to the select > few people that are actively involved in trying to diagnose hardware faults. > I expect that there will be many augmentations to lets say /interfaces (or /interfaces-state). How does a data model writer determine which ones are 'noise' and which ones are not? How does a a data model writer determine which ones are costly to implement and which ones are not (since this may vary widely between systems)? Perhaps it is useful to tell client writers that well behaving clients should ask for what they need (and understand) and that they should avoid asking generic 'give me everything you have' questions. If you have to deal with lazy clients that like to grab everything, you can control them via NACM. Simply exclude access to some branches. /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 Dec 7 10:17:25 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FDA1296FA; Wed, 7 Dec 2016 10:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2COidHXVkKv6; Wed, 7 Dec 2016 10:17:18 -0800 (PST) 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 3FEC6129548; Wed, 7 Dec 2016 10:17:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=342; q=dns/txt; s=iport; t=1481134638; x=1482344238; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=FARsRV3i6gLfNeTkRWxlOGVa/G5O1C9eF7KLqrklu3o=; b=acLR2fjU0g1HMuPjh1auy+fxK3i7sFIiv4pXXdsXarzNpehx6jQtUocj B9TtdRInz83gWNjmycQGvgI+vaXfsfYpwe0bv0azSdclCkKbCPW2ej54B a8tZ7FK9+vnikDqwtqea60+XWT8kwfkvt1Akid7Zx8xeEG11ytbFRR3zK Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CHCAD5UEhY/xbLJq1eHAEBBAEBCgEBg?= =?us-ascii?q?zkBAQEBAXmBB7dHhBYrhW2CSBABAgEBAQEBAQFiKIUSFXYCJgJfAQwIAQGIaw6?= =?us-ascii?q?oJoIpizUBAQEHAiWBC4UzgX2ELYV9gl0FlHyFapEYgVwBiDWGLYogg2OEDjYge?= =?us-ascii?q?BMOhVY9hz8rghABAQE?= X-IronPort-AV: E=Sophos;i="5.33,314,1477958400"; d="scan'208";a="690267847" 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; 07 Dec 2016 18:17:13 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uB7IHD3M007635; Wed, 7 Dec 2016 18:17:13 GMT To: NETMOD Working Group , YANG Doctors From: Benoit Claise Message-ID: <3d4a849b-f18f-69d8-bea6-52adce698a18@cisco.com> Date: Wed, 7 Dec 2016 19:17:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] Blog: YANG Opensource Tools for Data Modeling-driven Management X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 18:17:20 -0000 Dear all, This blog describes some of the opensource tools around YANG. While there exist some tools around the YANG language validation, I want to cover the bigger landscape of data modeling-driven management tools. http://www.claise.be/2016/12/yang-opensource-tools-for-data-modeling-driven-management/ Enjoy. Regards, B. From nobody Wed Dec 7 11:33:59 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C6B1298CF; Wed, 7 Dec 2016 11:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLJETHJRYkZK; Wed, 7 Dec 2016 11:33:52 -0800 (PST) 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 AF64C129A6E; Wed, 7 Dec 2016 11:33:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12327; q=dns/txt; s=iport; t=1481139231; x=1482348831; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=n7G3qGJmIE3oLNfwzS5+6xnRrwnWUg+F0Pzgkln6t7k=; b=gSG0iRyricDENoD2j0TiH0aPxu8m//7CKgcjjJcqvzFdliAe8XezxjIU LWLIV+/7yB5sgpHqrc6lZHk8Z83/fzWOtagdEdSmd7NC/n/Hd2DJxmbY8 icrXJoS/XO8tZSDtemnxo7jKoOm+pX4rHTwEeHVwjbHjeJyFPsOQmoK1i A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAQDNY0hY/4UNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnNGAQEBAQEfWncPB41ClxCHdIdphSKCBx4BCoUvSgKBez8UAQI?= =?us-ascii?q?BAQEBAQEBYiiEaAEBAQQBAWwLEAIBCBEDAQIoByEGCxQJCAIEAQ0FiFUDFw6qZ?= =?us-ascii?q?Yc/DYNpAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWLGYJIgV1DhUEFjz2KdTUBjTi?= =?us-ascii?q?DYoFziEOGCodjgW2ENYQNAR83gRkjgzkcgV1yhmSBL4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,315,1477958400"; d="scan'208,217";a="357987152" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Dec 2016 19:33:48 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id uB7JXmhk009853 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Dec 2016 19:33:48 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 7 Dec 2016 14:33:47 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 7 Dec 2016 14:33:47 -0500 From: "Acee Lindem (acee)" To: "Acee Lindem (acee)" , Routing WG Thread-Topic: [netmod] Key Strings in ietf-key-chain operational state Thread-Index: AQHSS1iZm2sOa4d7iUCSVwturK10T6D86u4A Date: Wed, 7 Dec 2016 19:33:47 +0000 Message-ID: References: <18241D36-ED37-4DB7-8751-061AF72E6AB2@gmail.com> <776D09FD-8664-4176-AC50-84F0FD2ED7E3@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.204] Content-Type: multipart/alternative; boundary="_000_D46DCD7B8EE72aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Mahesh Jethanandani \(mahesh\)" , "netmod@ietf.org" Subject: Re: [netmod] Key Strings in ietf-key-chain operational state X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 19:33:54 -0000 --_000_D46DCD7B8EE72aceeciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ok - I've looked at this from a different angle and I now think we should u= se NACM to limit access to the strings by default. It doesn't make sense to= address read access without addressing read and create access. Thanks, Acee BTW, I always though the OSPF MIB decision to simply omit the string was so= mewhat lame. However, write wasn't a factor since most implementations didn= 't support MIB variable update. From: rtgwg > on beha= lf of Acee Lindem > Date: Friday, December 2, 2016 at 12:07 PM To: Routing WG > Subject: FW: [netmod] Key Strings in ietf-key-chain operational state Note that omitting the keystring data node from the operational state in ie= tf-key-chain is consistent with what the approach in the NETMOD ietf-keysto= re model. Thanks, Acee From: Mahesh Jethanandani > Date: Wednesday, November 30, 2016 at 9:36 PM To: Acee Lindem > Cc: "netmod@ietf.org" > Subject: Re: [netmod] Key Strings in ietf-key-chain operational state On Nov 30, 2016, at 2:33 PM, Acee Lindem (acee) > wrote: This is something we ran into with ietf-keystore model also. The thoughts a= re that key strings should never leave the device. If anything most devices= have tamper proof capability (FIPS 140-2) to wipe the keys out if tampered= with or exported. So exporting the string, encrypted, even with NACM would= defy that. So, what we have today would with the key strings omitted from the operatio= nal state would be consistent with the direction for the ietf-keystore mode= l. Correct? That is correct. Kent can correct me, but we are still trying to figure how= to model it in YANG and in the datastores ( and ). How will this be enforced when we have an applied-config datastore? Thanks, Acee On Nov 30, 2016, at 1:37 PM, Acee Lindem (acee) > wrote: In the days of MIBs, we used to omit key strings from the data that would b= e returned. This was ostensibly done for security purposes. We did the same= for the operational state returned for keystring in key-chain-entries. I'm= now thinking this was a mistake. Rather, it would seem that one could use = RFC 6536 rules to accomplish this at a more granular level. Note that the model also support keystring encryption as described in RFC 5= 649. Thanks, Acee _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com --_000_D46DCD7B8EE72aceeciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <316592EFCE7BC74CABE7ED77C8AF31BD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Ok – I’ve looked at this from a different angle and I now = think we should use NACM to limit access to the strings by default. It does= n’t make sense to address read access without addressing read and cre= ate access. 

Thanks,
Acee 

BTW, I always though the OSPF MIB decision to simply omit the string w= as somewhat lame. However, write wasn’t a factor since most implement= ations didn’t support MIB variable update. 

From: rtgwg <rtgwg-bounces@ietf.org> on behalf of Acee Lin= dem <acee@cisco.com>
Date: Friday, December 2, 2016 at 1= 2:07 PM
To: Routing WG <rtgwg@ietf.org>
Subject: FW: [netmod] Key Strings i= n ietf-key-chain operational state

Note that omitting the keystring data node from the operational state = in ietf-key-chain is consistent with what the approach in the NETMOD ietf-k= eystore model.

Thanks,
Acee

From: Mahesh Jethanandani <mjethanandani@gmail.com>
Date: Wednesday, November 30, 2016 = at 9:36 PM
To: Acee Lindem <acee@cisco.com>
Cc: "netmod@ietf.org" <= netmod@ietf.org>
Subject: Re: [netmod] Key Strings i= n ietf-key-chain operational state


On Nov 30, 2016, at 2:33 PM, Acee Lindem (acee) <acee@cisco.com> wrote:


This is something we ran into with ietf-keystore model also= . The thoughts are that key strings should never leave the device. If anyth= ing most devices have tamper proof capability (FIPS 140-2) to wipe the keys= out if tampered with or exported. So exporting the string, encrypted, even with NACM would defy that.

So, what we have today would with the key strings omitted f= rom the operational state would be consistent with the direction for the ie= tf-keystore model. Correct? 

That is correct. Kent can correct me, but we are still trying to figure how= to model it in YANG and in the datastores (<applied> and <operati= onal-state>).


How will this be enforced when we have an applied-config da= tastore? 

Thanks,
Acee 






On Nov 30, 2016, at 1:37 PM, Acee Lindem (acee) <acee@cisco.com> wrote:

In the days of MIBs, we used to omit key strings from the d= ata that would be returned. This was ostensibly done for security purposes.= We did the same for the operational state returned for keystring in key-ch= ain-entries. I’m now thinking this was a mistake. Rather, it would seem that one could use RFC 6536 rules to = accomplish this at a more granular level. 

Note that the model also support keystring encryption as de= scribed in RFC 5649. 

Thanks,
Acee 

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

Mahesh Jethanandani
mjeth= anandani@gmail.com




Mahesh Jethanandani
mjeth= anandani@gmail.com



 --_000_D46DCD7B8EE72aceeciscocom_-- From nobody Thu Dec 8 09:49:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D94212951C for ; Thu, 8 Dec 2016 09:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-7xQBv6nFA9 for ; Thu, 8 Dec 2016 09:49:17 -0800 (PST) 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 F188B1294EF for ; Thu, 8 Dec 2016 09:49:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4640; q=dns/txt; s=iport; t=1481219357; x=1482428957; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=Ytb4+pAo2rIO77Px3iVzS9UEQ8EvOGQj+GsUbNXc56Y=; b=e2QEzCIG66YcSkzl4A76gvWLaJRrfQ0+kMQtipBg2YuTt+Qdl4vUEF9K aabFFpC7fHLvvY/83foqNLmzcSSLW98Oti5AulFamLiMbBR772euUcOEy MH8Yl4dBi3ZnD59ohaeqS/sHtj0yOLhmIaEeI4SFpLxqATNye/dknGcMY 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DAAQCdnElY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgywLAQEBAQGBJ44ilxOScoIPggiGIQKCNhQBAgEBAQEBAQFiKIR?= =?us-ascii?q?oAQEBAwE4UQsYLlcGAQwIAQEXiEgIqXeLLgEBAQEBAQEBAgEBAQEBAQEhhj6Bf?= =?us-ascii?q?QiCVoopBZpqkR+KFIYtiiWDY4QOHzd4Ew6FVj6IZgEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,320,1477958400"; d="scan'208";a="690306558" 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; 08 Dec 2016 17:49:12 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uB8HnBxw014211; Thu, 8 Dec 2016 17:49:12 GMT To: Vladimir Vassilev , Alex Campbell , netmod@ietf.org References: <5bc806b2-4941-dded-8e78-a3ffbaeeb9a6@cisco.com> <7b942d40-5b46-36ed-d940-ae12e2e93082@cisco.com> <1481058189709.95115@Aviatnet.com> <40eebd36-0e41-0082-f169-177dc95a537b@transpacket.com> <4c900f1f-7b57-1bb0-1d41-3beec6c03bab@cisco.com> <20161207161336.GB792@elstar.local> From: Robert Wilton Message-ID: <8c3ebda5-9775-8b0c-c569-194cefcd4ae9@cisco.com> Date: Thu, 8 Dec 2016 17:49:11 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161207161336.GB792@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 17:49:19 -0000 On 07/12/2016 16:13, Juergen Schoenwaelder wrote: > On Wed, Dec 07, 2016 at 02:39:00PM +0000, Robert Wilton wrote: >> Alas, xpath filtering is optional, and I'm not sure how many devices have >> implemented support for it. Further, this still requires every client to be >> coded to avoid receiving the information that they are very unlikely to be >> interested in. >> >> I would much prefer a solution where the clients don't get this (mostly >> noise) data unless they explicitly ask for it. Otherwise for an Ethernet >> interface you might return 10 leaves of potentially useful opstate >> information, along with 50+ leaves of quite low layer diagnostics >> information that is likely to be of very little use except for to the select >> few people that are actively involved in trying to diagnose hardware faults. >> > I expect that there will be many augmentations to lets say /interfaces > (or /interfaces-state). How does a data model writer determine which > ones are 'noise' and which ones are not? How does a a data model > writer determine which ones are costly to implement and which ones are > not (since this may vary widely between systems)? It isn't so much as it being noise. I see that the two quite different sets of config false nodes are: (1) The first set of nodes are those that are useful to a client to manage a device and to determine whether the device's actual behaviour matches the expected behaviour based on the configuration. This is the same set of data that has traditionally been modeled via SNMP, and I think of as being the operational state of the device. (2) If it is determined from the nodes above that a device is behaving in an abnormal way, then the second set of nodes are aimed at device developers/engineers to ascertain why the device is not behaving as specified. A lot of this internal diagnostics information may only be of use to a developer who is familiar with the code (or intricacies of the hardware), and/or has a deep level of understanding of how a particular feature works. I would see that most of this information is very likely to be device specific, and presented in a device specific way, and may include internal debug and dumps of internal data-structures. I believe that most of the time, operators are only interested in interacting with that first set of data because that is all that is useful and required to manage their devices, and hence that is what I think should be modeled in the operational state datastore. However, in many cases, having a standard automated way of fetching that second set of data is still useful, because it facilitates more efficient diagnostic tools to be created in the future. Specifically for Ethernet, 802.3 specifies a clear separation between what they expect to be made available via a management protocol vs what is regarded as being an internal API, specifically: -802.3 Clause 30 specifies the main management objects, that I would expect to be broadly accessible to management clients, and what we are planning on basing the Ethernet YANG on. (This is consistent with what is available in the Ethernet related MIBs and the OpenConfig Ethernet model). - the internal interface is defined as the MDIO registers in 802.3 Clause 45. Looking at these register definitions, although the registers themselves can be given meaningful names, the values themselves would probably just be returned as opaque 16 bit register values, since the YANG "bits" type isn't flexible enough to represent the packed values they sometimes contain (specifically where they are using a set of bits to represent an enumerated value). > > Perhaps it is useful to tell client writers that well behaving clients > should ask for what they need (and understand) and that they should > avoid asking generic 'give me everything you have' questions. I really think that there are two separate classes of data here, and it makes more sense to treat them as such. Defining RPCs to fetch the internal diagnostics data on demand seems OK to me, or alternatively marking the nodes as being diagnostics related and putting that in a separate datastore would seem to be reasonable. > > If you have to deal with lazy clients that like to grab everything, > you can control them via NACM. Simply exclude access to some branches. This will likely just mean that every device would have to support this NACM to handle the mainline case. That sounds like a lot of extra unnecessary work for everyone. Thanks, Rob > > /js > From nobody Thu Dec 8 11:11:21 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653AB129655 for ; Thu, 8 Dec 2016 11:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 SBzn5B9xwr7p for ; Thu, 8 Dec 2016 11:11:17 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A76C129526 for ; Thu, 8 Dec 2016 11:11:17 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 50C767F0; Thu, 8 Dec 2016 20:11:16 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id k41pGexf-BPR; Thu, 8 Dec 2016 20:11:12 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 8 Dec 2016 20:11:15 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C113C20067; Thu, 8 Dec 2016 20:11:19 +0100 (CET) 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 U7gzIEI3mS3Y; Thu, 8 Dec 2016 20:11:14 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C92820063; Thu, 8 Dec 2016 20:11:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 324E33DAFAA7; Thu, 8 Dec 2016 20:11:11 +0100 (CET) Date: Thu, 8 Dec 2016 20:11:11 +0100 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20161208191111.GA92046@elstar.local> Mail-Followup-To: Robert Wilton , Vladimir Vassilev , Alex Campbell , netmod@ietf.org References: <5bc806b2-4941-dded-8e78-a3ffbaeeb9a6@cisco.com> <7b942d40-5b46-36ed-d940-ae12e2e93082@cisco.com> <1481058189709.95115@Aviatnet.com> <40eebd36-0e41-0082-f169-177dc95a537b@transpacket.com> <4c900f1f-7b57-1bb0-1d41-3beec6c03bab@cisco.com> <20161207161336.GB792@elstar.local> <8c3ebda5-9775-8b0c-c569-194cefcd4ae9@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8c3ebda5-9775-8b0c-c569-194cefcd4ae9@cisco.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 19:11:19 -0000 On Thu, Dec 08, 2016 at 05:49:11PM +0000, Robert Wilton wrote: > > On 07/12/2016 16:13, Juergen Schoenwaelder wrote: > > On Wed, Dec 07, 2016 at 02:39:00PM +0000, Robert Wilton wrote: > > > Alas, xpath filtering is optional, and I'm not sure how many devices have > > > implemented support for it. Further, this still requires every client to be > > > coded to avoid receiving the information that they are very unlikely to be > > > interested in. > > > > > > I would much prefer a solution where the clients don't get this (mostly > > > noise) data unless they explicitly ask for it. Otherwise for an Ethernet > > > interface you might return 10 leaves of potentially useful opstate > > > information, along with 50+ leaves of quite low layer diagnostics > > > information that is likely to be of very little use except for to the select > > > few people that are actively involved in trying to diagnose hardware faults. > > > > > I expect that there will be many augmentations to lets say /interfaces > > (or /interfaces-state). How does a data model writer determine which > > ones are 'noise' and which ones are not? How does a a data model > > writer determine which ones are costly to implement and which ones are > > not (since this may vary widely between systems)? > It isn't so much as it being noise. I see that the two quite different sets > of config false nodes are: > > (1) The first set of nodes are those that are useful to a client to manage a > device and to determine whether the device's actual behaviour matches the > expected behaviour based on the configuration. This is the same set of data > that has traditionally been modeled via SNMP, and I think of as being the > operational state of the device. > > (2) If it is determined from the nodes above that a device is behaving in an > abnormal way, then the second set of nodes are aimed at device > developers/engineers to ascertain why the device is not behaving as > specified. A lot of this internal diagnostics information may only be of > use to a developer who is familiar with the code (or intricacies of the > hardware), and/or has a deep level of understanding of how a particular > feature works. I would see that most of this information is very likely to > be device specific, and presented in a device specific way, and may include > internal debug and dumps of internal data-structures. The simply disable this module on a production system. > I believe that most of the time, operators are only interested in > interacting with that first set of data because that is all that is useful > and required to manage their devices, and hence that is what I think should > be modeled in the operational state datastore. However, in many cases, > having a standard automated way of fetching that second set of data is still > useful, because it facilitates more efficient diagnostic tools to be created > in the future. Than leave the data model active and make NACM grant access to this data only for engineers. /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 Dec 8 13:48:05 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FCF1296DD for ; Thu, 8 Dec 2016 13:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2AcmQVMnkKx for ; Thu, 8 Dec 2016 13:48:02 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 024A912948C for ; Thu, 8 Dec 2016 13:48:01 -0800 (PST) Received: (qmail 24078 invoked by uid 0); 8 Dec 2016 21:48:00 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy10.mail.unifiedlayer.com with SMTP; 8 Dec 2016 21:48:00 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id HZnw1u00m2SSUrH01ZnzPc; Thu, 08 Dec 2016 14:48:00 -0700 X-Authority-Analysis: v=2.1 cv=Zpp+dbLG c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=n5n_aSjo0skA:10 a=48vgC7mUAAAA:8 a=-tsAPJKn6S7ax0J5AdsA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:To:Cc:Subject:From; bh=SHTEAq+fXcNaCT8TwWyXbL+UPZykCseTnVJdMGzcu7I=; b=N5Y5DXqGuU45PfMRoNlaqM9ixD FYXomcJzXcZHkpZ6bhNWsCnPihSo26kgT4XtQJlcIyX1ZpLZlxoWuxC94o1oHrWfnfo8wuts6zuQp uE3RqYBgaVaxE0EEv5cVJesur; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:40759 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1cF6Xk-0004AB-L6; Thu, 08 Dec 2016 14:47:56 -0700 From: Lou Berger To: Robert Wilton , David Ball , tapsingh@cisco.com, ssivaraj@juniper.net Message-ID: <61336d77-830e-7e33-3cd3-202e31124d8e@labn.net> Date: Thu, 8 Dec 2016 16:47:55 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cF6Xk-0004AB-L6 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:40759 X-Source-Auth: lberger@labn.net X-Email-Count: 7 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: NetMod Chairs , NetMod WG Subject: [netmod] Regarding IPR on draft-wilton-netmod-intf-vlan-yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 21:48:04 -0000 Authors, Contributors, WG, As part of preparation for WG Adoption Are you aware of any IPR that applies to drafts 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 so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer 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 http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, NETMOD WG Chairs PS Please include all listed in the headers of this message in your response. From nobody Thu Dec 8 13:53:27 2016 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA33F129A47; Thu, 8 Dec 2016 13:53:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148123400595.6995.12129607322212010654.idtracker@ietfa.amsl.com> Date: Thu, 08 Dec 2016 13:53:25 -0800 Archived-At: Subject: [netmod] The NETMOD WG has placed draft-wilton-netmod-intf-vlan-yang in state "Candidate for WG Adoption" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 21:53:26 -0000 The NETMOD WG has placed draft-wilton-netmod-intf-vlan-yang in state Candidate for WG Adoption (entered by Lou Berger) The document is available at https://datatracker.ietf.org/doc/draft-wilton-netmod-intf-vlan-yang/ Comment: IPR Poll started: https://www.ietf.org/mail-archive/web/netmod/current/msg17146.html 4 pending responses: rwilton@cisco.com, daviball@cisco.com, tapsingh@cisco.com, ssivaraj@juniper.net From nobody Thu Dec 8 14:21:14 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C41B1299FA; Thu, 8 Dec 2016 14:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTpIXLECTOMN; Thu, 8 Dec 2016 14:21:10 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD525129B9E; Thu, 8 Dec 2016 14:17:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2492; q=dns/txt; s=iport; t=1481235459; x=1482445059; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YG6TVmaRS/0ry99ZA6WKPh6H1rKExtZyUwcKaz8X3c8=; b=NsVOuzt5whkIlqtVG/l6h1bAusbH45raTlu+v3ogMicnszS/1378h0l5 wUZp1ZvpGz/C2EdN8XZLxytXtV1pqa9rlDt0FcuinZ7PjJ0BObXn5OGnK UBSXQTlGsDzj1qOg3UjoLZQ6MHTE4lA7uQlx1iADF90s17ffVWvUfZ4+v E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAQCw20lY/51dJa1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzcBAQEBAR9agQYHAY1DrBSCCCmFeAIagWA/FAECAQEBAQEBAWIohGk?= =?us-ascii?q?GIxFABRACAQgODAImAgICMBUQAgQBDQWIaw6nSIIpiywBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEdgQuFM4F9gl6EGhEBHBeCbS2CMAWaagGGTopQgXNQhC2JUZIVAR8?= =?us-ascii?q?3YTgjDgEBhSNyAYZqgSEBgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.33,321,1477958400"; d="scan'208";a="179017880" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Dec 2016 22:17:38 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id uB8MHcZf005482 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Dec 2016 22:17:38 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 8 Dec 2016 16:17:38 -0600 Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1210.000; Thu, 8 Dec 2016 16:17:38 -0600 From: "Tapraj Singh (tapsingh)" To: Lou Berger , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , "David Ball -X (daviball - ENSOFT LIMITED at Cisco)" , "ssivaraj@juniper.net" Thread-Topic: Regarding IPR on draft-wilton-netmod-intf-vlan-yang Thread-Index: AQHSUZzLxyFPIgQPIkC6GxCuNQZwcqD+fQKA Date: Thu, 8 Dec 2016 22:17:38 +0000 Message-ID: References: <61336d77-830e-7e33-3cd3-202e31124d8e@labn.net> In-Reply-To: <61336d77-830e-7e33-3cd3-202e31124d8e@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.150.67] Content-Type: text/plain; charset="utf-8" Content-ID: <778DA533435464448C7B92F079A8134C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: NetMod Chairs , NetMod WG Subject: Re: [netmod] Regarding IPR on draft-wilton-netmod-intf-vlan-yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 22:21:12 -0000 QXMgYSBjby1hdXRoZXIgIEkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIuDQoNClRoYW5rcw0KVGFw cmFqDQoNCg0KDQoNCk9uIDEyLzgvMTYsIDE6NDcgUE0sICJMb3UgQmVyZ2VyIiA8bGJlcmdlckBs YWJuLm5ldD4gd3JvdGU6DQoNCj4NCj5BdXRob3JzLCBDb250cmlidXRvcnMsIFdHLA0KPg0KPkFz IHBhcnQgb2YgcHJlcGFyYXRpb24gZm9yIFdHIEFkb3B0aW9uDQo+DQo+QXJlIHlvdSBhd2FyZSBv ZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdHMgaWRlbnRpZmllZCBhYm92ZT8NCj4NCj5Q bGVhc2Ugc3RhdGUgZWl0aGVyOg0KPg0KPiJObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRo YXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KPm9yDQo+IlllcywgSSdtIGF3YXJlIG9mIElQUiB0 aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCj4NCj5JZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4g ZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcw0KPihzZWUgUkZDcyAz OTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpPw0KPg0KPklmIHllcyB0 byB0aGUgYWJvdmUsIHBsZWFzZSBzdGF0ZSBlaXRoZXI6DQo+DQo+IlllcywgdGhlIElQUiBoYXMg YmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIg0KPm9yDQo+ Ik5vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQiDQo+DQo+SWYgeW91IGFuc3dlciBu bywgcGxlYXNlIHByb3ZpZGUgYW55IGFkZGl0aW9uYWwgZGV0YWlscyB5b3UgdGhpbmsNCj5hcHBy b3ByaWF0ZS4NCj4NCj5JZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBj b250cmlidXRvciBwbGVhc2UgYW5zd2VyIHRoZQ0KPmFib3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhp cyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUNCj5hd2FyZSBvZiBh bnkgcmVsZXZhbnQgSVBSLiBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5l eHQNCj5zdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBh dXRob3IgYW5kIGxpc3RlZA0KPmNvbnRyaWJ1dG9yLiBOT1RFOiBUSElTIEFQUExJRVMgVE8gQUxM IE9GIFlPVSBMSVNURUQgSU4gVEhJUyBNRVNTQUdFJ1MNCj5UTyBMSU5FUy4NCj4NCj5JZiB5b3Ug YXJlIG9uIHRoZSBXRyBlbWFpbCBsaXN0IG9yIGF0dGVuZCBXRyBtZWV0aW5ncyBidXQgYXJlIG5v dCBsaXN0ZWQNCj5hcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ugb2Yg eW91ciBvYmxpZ2F0aW9ucyB1bmRlcg0KPnRoZSBJRVRGIElQUiBydWxlcyB3aGljaCBlbmNvdXJh Z2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZQ0KPmF3YXJlIG9mIElQUiBvZiBv dGhlcnMgb24gYW4gSUVURiBjb250cmlidXRpb24sIG9yIHRvIHJlZnJhaW4gZnJvbQ0KPnBhcnRp Y2lwYXRpbmcgaW4gYW55IGNvbnRyaWJ1dGlvbiBvciBkaXNjdXNzaW9uIHJlbGF0ZWQgdG8geW91 cg0KPnVuZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhl IFJGQ3MgbGlzdGVkIGFib3ZlDQo+YW5kDQo+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3Jv dXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHkuDQo+DQo+VGhhbmsgeW91LA0K Pk5FVE1PRCBXRyBDaGFpcnMNCj4NCj5QUyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRo ZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyDQo+cmVzcG9uc2UuDQo+DQo+DQo= From nobody Thu Dec 8 14:25:52 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B98129AA5; Thu, 8 Dec 2016 14:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSrpECwxlFKO; Thu, 8 Dec 2016 14:25:47 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0100.outbound.protection.outlook.com [104.47.36.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497DF129AF2; Thu, 8 Dec 2016 14:22:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=O/mOquZVikhnT1G7zOHkV+IdyeVJRUleOAuQL9cLRQI=; b=IdX6vpbPLMAMk7+PCvGlotkjYZvG6kkCgjJJJd5Zg+nYkdDZ4nW9l3EjzYAVq6nOY5ucECpyza4w5QwThj4Te3Q4MWEtJTSe3k5ALo5L3UAkRTGKTkLXsTv1F75Qx1+Rxewftji7b5R96y21IWJk3mxZInWz26zK6xWiHPIKcrk= Received: from BN6PR05MB2819.namprd05.prod.outlook.com (10.168.255.14) by BN6PR05MB2819.namprd05.prod.outlook.com (10.168.255.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.5; Thu, 8 Dec 2016 22:22:19 +0000 Received: from BN6PR05MB2819.namprd05.prod.outlook.com ([10.168.255.14]) by BN6PR05MB2819.namprd05.prod.outlook.com ([10.168.255.14]) with mapi id 15.01.0761.016; Thu, 8 Dec 2016 22:22:19 +0000 From: Selvakumar Sivaraj To: Lou Berger , Robert Wilton , "David Ball" , "tapsingh@cisco.com" Thread-Topic: Regarding IPR on draft-wilton-netmod-intf-vlan-yang Thread-Index: AQHSUZy/GBAleQ5stka7jlZLtKUd0aD+Gb2A Date: Thu, 8 Dec 2016 22:22:19 +0000 Message-ID: References: <61336d77-830e-7e33-3cd3-202e31124d8e@labn.net> In-Reply-To: <61336d77-830e-7e33-3cd3-202e31124d8e@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161204 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ssivaraj@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.14] x-ms-office365-filtering-correlation-id: 1b525daa-654c-44a8-58dd-08d41fb8acba x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR05MB2819; x-microsoft-exchange-diagnostics: 1; BN6PR05MB2819; 7:IcEbBHB5F3mE2YlrugJaKV7NoSHCWBPNJpwLlgTr0tlntxykngbkPNjtDRAB0dfJbA4ClYI+YR3qAIb1EJ3yWK9c4QN4ju3b9fRHJQ+X+JTvwnvpBjy6bx+yOPSdUSNQCFds/Sz6LtxMXDsnCGoSHUnola01V1e1tdA0rZGZxcP2VtHtxJ0HxzAURgwUyJGcxZ2D92uLIS1Alw4ufoRpamPqpGttgU7J/OMDLCyYIPDEoNxLcYgO3DU0gbJqjWWWYNSfF6jj1KqjBlDg2YNM1XCZcl3uj4RcfTk3EtY+tqimcIwREkQQ3c3k0mPgkdcEzQQkT0vcy0xhT4cv72QG9bIa6OzO0Yw7zL+4+sCi4XEBOHCkKsS+OMe6fE5r1wSN65xNCb/0yeTfv600GqlkCyx341IdyFMgWVoWGQUS1htKbNd1Vfq8ML/50dMEDoB3Y9HB0gYF2vb0Tp/poKEm6A== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123560025)(20161123558021)(20161123555025)(20161123564025)(6072148); SRVR:BN6PR05MB2819; BCL:0; PCL:0; RULEID:; SRVR:BN6PR05MB2819; x-forefront-prvs: 0150F3F97D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39450400003)(39850400002)(39840400002)(39860400002)(377454003)(199003)(189002)(13464003)(3660700001)(3280700002)(83506001)(82746002)(102836003)(36756003)(122556002)(86362001)(5660300001)(7736002)(50986999)(33656002)(2900100001)(83716003)(92566002)(76176999)(54356999)(2950100002)(101416001)(189998001)(305945005)(38730400001)(68736007)(106116001)(106356001)(105586002)(8676002)(99286002)(3846002)(229853002)(2501003)(81166006)(66066001)(2906002)(97736004)(8936002)(4326007)(4001350100001)(77096006)(6512006)(81156014)(5001770100001)(6486002)(230783001)(6506006)(6116002)(6436002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR05MB2819; H:BN6PR05MB2819.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2016 22:22:19.6047 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB2819 Archived-At: Cc: NetMod Chairs , NetMod WG Subject: Re: [netmod] Regarding IPR on draft-wilton-netmod-intf-vlan-yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 22:25:51 -0000 Ik5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQi DQoNClRoYW5rcywNClNlbHZha3VtYXINCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4NCkRhdGU6IFRodXJzZGF5LCBEZWNl bWJlciA4LCAyMDE2IGF0IDE6NDcgUE0NClRvOiBSb2JlcnQgV2lsdG9uIDxyd2lsdG9uQGNpc2Nv LmNvbT4sIERhdmlkIEJhbGwgPGRhdmliYWxsQGNpc2NvLmNvbT4sICJ0YXBzaW5naEBjaXNjby5j b20iIDx0YXBzaW5naEBjaXNjby5jb20+LCBTZWx2YWt1bWFyIFNpdmFyYWogPHNzaXZhcmFqQGp1 bmlwZXIubmV0Pg0KQ2M6IE5ldE1vZCBXRyA8bmV0bW9kQGlldGYub3JnPiwgTmV0TW9kIENoYWly cyA8bmV0bW9kLWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlZ2FyZGluZyBJUFIgb24gZHJh ZnQtd2lsdG9uLW5ldG1vZC1pbnRmLXZsYW4teWFuZw0KDQogICAgDQogICAgQXV0aG9ycywgQ29u dHJpYnV0b3JzLCBXRywNCiAgICANCiAgICBBcyBwYXJ0IG9mIHByZXBhcmF0aW9uIGZvciBXRyBB ZG9wdGlvbg0KICAgIA0KICAgIEFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMg dG8gZHJhZnRzIGlkZW50aWZpZWQgYWJvdmU/DQogICAgDQogICAgUGxlYXNlIHN0YXRlIGVpdGhl cjoNCiAgICANCiAgICAiTm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMg dG8gdGhpcyBkcmFmdCINCiAgICBvcg0KICAgICJZZXMsIEknbSBhd2FyZSBvZiBJUFIgdGhhdCBh cHBsaWVzIHRvIHRoaXMgZHJhZnQiDQogICAgDQogICAgSWYgc28sIGhhcyB0aGlzIElQUiBiZWVu IGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMNCiAgICAoc2VlIFJG Q3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8NCiAgICANCiAg ICBJZiB5ZXMgdG8gdGhlIGFib3ZlLCBwbGVhc2Ugc3RhdGUgZWl0aGVyOg0KICAgIA0KICAgICJZ ZXMsIHRoZSBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQ UiBydWxlcyINCiAgICBvcg0KICAgICJObywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlzY2xvc2Vk Ig0KICAgIA0KICAgIElmIHlvdSBhbnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlv bmFsIGRldGFpbHMgeW91IHRoaW5rDQogICAgYXBwcm9wcmlhdGUuDQogICAgDQogICAgSWYgeW91 IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIGFu c3dlciB0aGUNCiAgICBhYm92ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVz cyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlDQogICAgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQ Ui4gVGhpcyBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0DQogICAgc3RhZ2Ug dW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBs aXN0ZWQNCiAgICBjb250cmlidXRvci4gTk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZT1Ug TElTVEVEIElOIFRISVMgTUVTU0FHRSdTDQogICAgVE8gTElORVMuDQogICAgDQogICAgSWYgeW91 IGFyZSBvbiB0aGUgV0cgZW1haWwgbGlzdCBvciBhdHRlbmQgV0cgbWVldGluZ3MgYnV0IGFyZSBu b3QgbGlzdGVkDQogICAgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQgeW91 IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXINCiAgICB0aGUgSUVURiBJUFIgcnVsZXMgd2hpY2gg ZW5jb3VyYWdlcyB5b3UgdG8gbm90aWZ5IHRoZSBJRVRGIGlmIHlvdSBhcmUNCiAgICBhd2FyZSBv ZiBJUFIgb2Ygb3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9uLCBvciB0byByZWZyYWluIGZy b20NCiAgICBwYXJ0aWNpcGF0aW5nIGluIGFueSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lvbiBy ZWxhdGVkIHRvIHlvdXINCiAgICB1bmRpc2Nsb3NlZCBJUFIuIEZvciBtb3JlIGluZm9ybWF0aW9u LCBwbGVhc2Ugc2VlIHRoZSBSRkNzIGxpc3RlZCBhYm92ZQ0KICAgIGFuZA0KICAgIGh0dHA6Ly90 cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3Bl cnR5Lg0KICAgIA0KICAgIFRoYW5rIHlvdSwNCiAgICBORVRNT0QgV0cgQ2hhaXJzDQogICAgDQog ICAgUFMgUGxlYXNlIGluY2x1ZGUgYWxsIGxpc3RlZCBpbiB0aGUgaGVhZGVycyBvZiB0aGlzIG1l c3NhZ2UgaW4geW91cg0KICAgIHJlc3BvbnNlLg0KICAgIA0KICAgIA0KICAgIA0KDQo= From nobody Fri Dec 9 01:54:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016F4129CD3; Fri, 9 Dec 2016 01:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBNy3gfzvPxc; Fri, 9 Dec 2016 01:54:01 -0800 (PST) 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 95DEA129653; Fri, 9 Dec 2016 01:54:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1847; q=dns/txt; s=iport; t=1481277240; x=1482486840; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=hNCcF11DKUm0fsYIKbn3aKLfSBee+HEDa/hrsCAkWiU=; b=SoBuzoT0qX02LD17D5SqVsus2z/9LRqTptjuPL+bppR7rfw1rTEbOVeq ThXXKhm9ey5Wce/xBz4f/k6izoRd7y+K2/PUlmFRvCozofif3k2DnJ6CO 0+jVBp+k5mFKgUvVcSBDlB/aoallW/C2jmBiTfv5VoGYDODk4o328/LpP c=; X-IronPort-AV: E=Sophos;i="5.33,323,1477958400"; d="scan'208";a="650602336" 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; 09 Dec 2016 09:53:58 +0000 Received: from [10.63.23.165] (dhcp-ensft1-uk-vla370-10-63-23-165.cisco.com [10.63.23.165]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uB99rwId021605; Fri, 9 Dec 2016 09:53:58 GMT To: Lou Berger , Robert Wilton , tapsingh@cisco.com, ssivaraj@juniper.net References: <61336d77-830e-7e33-3cd3-202e31124d8e@labn.net> From: David Ball Message-ID: <7a454afa-68cc-34b0-030d-58c7c0f04cbe@cisco.com> Date: Fri, 9 Dec 2016 09:53:58 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <61336d77-830e-7e33-3cd3-202e31124d8e@labn.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: NetMod Chairs , NetMod WG Subject: Re: [netmod] Regarding IPR on draft-wilton-netmod-intf-vlan-yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 09:54:03 -0000 No I am not aware of any IPR. David On 08/12/2016 21:47, Lou Berger wrote: > Authors, Contributors, WG, > > As part of preparation for WG Adoption > > Are you aware of any IPR that applies to drafts 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 so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer 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 > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > NETMOD WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > -- David Ball From nobody Fri Dec 9 01:56:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B755D129CBD; Fri, 9 Dec 2016 01:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaJUalpQX41v; Fri, 9 Dec 2016 01:56:47 -0800 (PST) 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 6B10C1296B6; Fri, 9 Dec 2016 01:56:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1843; q=dns/txt; s=iport; t=1481277406; x=1482487006; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=k1AtQpEdvkU7/qETdlrYrNrKr5KJ02NJgffpShPkoDQ=; b=i/v2aumUmUdd02c7xPyERYoxk8iLwfqh79xBhJsRSmxPc1KjHIS+Yp8y XnXW3aczF5oQCdZQwrV2MJh/7cvav5yxIyJ3N2uswYIzOo3kZQeWyFk7T CKgFbIjMbtY3liC3PsD1u2fsqyrPxFx0B+RDQrX//VtQxQ9AjE3QqeO2j g=; X-IronPort-AV: E=Sophos;i="5.33,323,1477958400"; d="scan'208";a="650602381" 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; 09 Dec 2016 09:56:44 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uB99uiWh031211; Fri, 9 Dec 2016 09:56:44 GMT To: Lou Berger , NetMod WG , NetMod Chairs References: <61336d77-830e-7e33-3cd3-202e31124d8e@labn.net> From: Robert Wilton Message-ID: Date: Fri, 9 Dec 2016 09:56:46 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <61336d77-830e-7e33-3cd3-202e31124d8e@labn.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: David Ball , tapsingh@cisco.com Subject: Re: [netmod] Regarding IPR on draft-wilton-netmod-intf-vlan-yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 09:56:49 -0000 No, I'm not aware of any IPR that applies to this draft. Thanks, Rob On 08/12/2016 21:47, Lou Berger wrote: > Authors, Contributors, WG, > > As part of preparation for WG Adoption > > Are you aware of any IPR that applies to drafts 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 so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer 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 > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > NETMOD WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > > . > From nobody Fri Dec 9 02:34:08 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C309E12A387 for ; Fri, 9 Dec 2016 02:34:06 -0800 (PST) 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 wR2Ev8V23Y1g for ; Fri, 9 Dec 2016 02:34:04 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5D912A38F for ; Fri, 9 Dec 2016 02:34:04 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id BE9B81CC0B65; Fri, 9 Dec 2016 11:33:59 +0100 (CET) From: Ladislav Lhotka To: Robert Wilton , Vladimir Vassilev , Alex Campbell , netmod@ietf.org In-Reply-To: <8c3ebda5-9775-8b0c-c569-194cefcd4ae9@cisco.com> References: <5bc806b2-4941-dded-8e78-a3ffbaeeb9a6@cisco.com> <7b942d40-5b46-36ed-d940-ae12e2e93082@cisco.com> <1481058189709.95115@Aviatnet.com> <40eebd36-0e41-0082-f169-177dc95a537b@transpacket.com> <4c900f1f-7b57-1bb0-1d41-3beec6c03bab@cisco.com> <20161207161336.GB792@elstar.local> <8c3ebda5-9775-8b0c-c569-194cefcd4ae9@cisco.com> Date: Fri, 09 Dec 2016 11:33:59 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 10:34:07 -0000 Hi Rob, I didn't follow the previous discussion closely but a natural solution seems to be to define a leaf like "debug" - it could be just boolean or an enumeration of debug levels. And then add the diagnostic data as an augment that conditionally depends on the value of the "debug" leaf. Would this work? Lada Robert Wilton writes: > On 07/12/2016 16:13, Juergen Schoenwaelder wrote: >> On Wed, Dec 07, 2016 at 02:39:00PM +0000, Robert Wilton wrote: >>> Alas, xpath filtering is optional, and I'm not sure how many devices have >>> implemented support for it. Further, this still requires every client to be >>> coded to avoid receiving the information that they are very unlikely to be >>> interested in. >>> >>> I would much prefer a solution where the clients don't get this (mostly >>> noise) data unless they explicitly ask for it. Otherwise for an Ethernet >>> interface you might return 10 leaves of potentially useful opstate >>> information, along with 50+ leaves of quite low layer diagnostics >>> information that is likely to be of very little use except for to the select >>> few people that are actively involved in trying to diagnose hardware faults. >>> >> I expect that there will be many augmentations to lets say /interfaces >> (or /interfaces-state). How does a data model writer determine which >> ones are 'noise' and which ones are not? How does a a data model >> writer determine which ones are costly to implement and which ones are >> not (since this may vary widely between systems)? > It isn't so much as it being noise. I see that the two quite different > sets of config false nodes are: > > (1) The first set of nodes are those that are useful to a client to > manage a device and to determine whether the device's actual behaviour > matches the expected behaviour based on the configuration. This is the > same set of data that has traditionally been modeled via SNMP, and I > think of as being the operational state of the device. > > (2) If it is determined from the nodes above that a device is behaving > in an abnormal way, then the second set of nodes are aimed at device > developers/engineers to ascertain why the device is not behaving as > specified. A lot of this internal diagnostics information may only be > of use to a developer who is familiar with the code (or intricacies of > the hardware), and/or has a deep level of understanding of how a > particular feature works. I would see that most of this information is > very likely to be device specific, and presented in a device specific > way, and may include internal debug and dumps of internal data-structures. > > I believe that most of the time, operators are only interested in > interacting with that first set of data because that is all that is > useful and required to manage their devices, and hence that is what I > think should be modeled in the operational state datastore. However, in > many cases, having a standard automated way of fetching that second set > of data is still useful, because it facilitates more efficient > diagnostic tools to be created in the future. > > Specifically for Ethernet, 802.3 specifies a clear separation between > what they expect to be made available via a management protocol vs what > is regarded as being an internal API, specifically: > -802.3 Clause 30 specifies the main management objects, that I would > expect to be broadly accessible to management clients, and what we are > planning on basing the Ethernet YANG on. (This is consistent with what > is available in the Ethernet related MIBs and the OpenConfig Ethernet > model). > - the internal interface is defined as the MDIO registers in 802.3 > Clause 45. Looking at these register definitions, although the > registers themselves can be given meaningful names, the values > themselves would probably just be returned as opaque 16 bit register > values, since the YANG "bits" type isn't flexible enough to represent > the packed values they sometimes contain (specifically where they are > using a set of bits to represent an enumerated value). > > >> >> Perhaps it is useful to tell client writers that well behaving clients >> should ask for what they need (and understand) and that they should >> avoid asking generic 'give me everything you have' questions. > I really think that there are two separate classes of data here, and it > makes more sense to treat them as such. > > Defining RPCs to fetch the internal diagnostics data on demand seems OK > to me, or alternatively marking the nodes as being diagnostics related > and putting that in a separate datastore would seem to be reasonable. > >> >> If you have to deal with lazy clients that like to grab everything, >> you can control them via NACM. Simply exclude access to some branches. > This will likely just mean that every device would have to support this > NACM to handle the mainline case. That sounds like a lot of extra > unnecessary work for everyone. > > Thanks, > Rob > >> >> /js >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Dec 9 02:48:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A803129CBE for ; Fri, 9 Dec 2016 02:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCcBRVC-qhQM for ; Fri, 9 Dec 2016 02:48:48 -0800 (PST) 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 ACFE0128874 for ; Fri, 9 Dec 2016 02:48:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6164; q=dns/txt; s=iport; t=1481280527; x=1482490127; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=CXNZUPpXzNuzvFbHOO58WFp3z71PD0/6jADBiUMtyDU=; b=WIX6nZDbiqcZWkYdO5s/NQzI+l/yZLEZU9Uh05g4rR64TEgi4NY3TiWY nMK4e8vPdCIlODnz/Kh+uoCWaG+V7ReEzP8Lh/OQTNFbgheHnhh039Ftm XvkXnRnGZH0UMRPzkS6OgTNnfkP4Zrexn2vmxPeBev0+q+SuHA8LldwrC 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAQBHi0pY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAXkuWI1JlxSVAoIKHguFLkoCgj8UAQIBAQEBAQEBYii?= =?us-ascii?q?EaAEBAQMBAQE2NAIICAsLGC4nMAYBDAYCAQEXiEgIDqpAiyoBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARkFhj6BfQiCVoopBZprkSGKF4YuiiiDY4QOHzd+FQ4khTU+NIk?= =?us-ascii?q?ZAQEB?= X-IronPort-AV: E=Sophos;i="5.33,324,1477958400"; d="scan'208";a="650603768" 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; 09 Dec 2016 10:48:45 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uB9Amjbx023318; Fri, 9 Dec 2016 10:48:45 GMT To: Ladislav Lhotka , Vladimir Vassilev , Alex Campbell , netmod@ietf.org References: <5bc806b2-4941-dded-8e78-a3ffbaeeb9a6@cisco.com> <7b942d40-5b46-36ed-d940-ae12e2e93082@cisco.com> <1481058189709.95115@Aviatnet.com> <40eebd36-0e41-0082-f169-177dc95a537b@transpacket.com> <4c900f1f-7b57-1bb0-1d41-3beec6c03bab@cisco.com> <20161207161336.GB792@elstar.local> <8c3ebda5-9775-8b0c-c569-194cefcd4ae9@cisco.com> From: Robert Wilton Message-ID: Date: Fri, 9 Dec 2016 10:48:46 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 10:48:50 -0000 Hi Lada, On 09/12/2016 10:33, Ladislav Lhotka wrote: > Hi Rob, > > I didn't follow the previous discussion closely but a natural solution > seems to be to define a leaf like "debug" - it could be just boolean or > an enumeration of debug levels. And then add the diagnostic > data as an augment that conditionally depends on the value of the > "debug" leaf. > > Would this work? I'm not sure. Historically debug has been separate from configuration. I.e. you wouldn't normally expect debug settings to persist after rebooting the device. Possibly debug could be modeled using I2RS, but that would be tying its fate to I2RS, and I'm not sure whether I2RS will gain widespread adoption. Although I raised my concern specification related to Ethernet clause 45 registers, I think that my question is really more general about whether debug/diagnostics should be modeled in YANG and if so how that should be done. Perhaps, we should just concentrate on getting the basis config and operational state models sorted out initially and then figure out how diagnostics should be modeled at a later date? Rob > Lada > > Robert Wilton writes: > >> On 07/12/2016 16:13, Juergen Schoenwaelder wrote: >>> On Wed, Dec 07, 2016 at 02:39:00PM +0000, Robert Wilton wrote: >>>> Alas, xpath filtering is optional, and I'm not sure how many devices have >>>> implemented support for it. Further, this still requires every client to be >>>> coded to avoid receiving the information that they are very unlikely to be >>>> interested in. >>>> >>>> I would much prefer a solution where the clients don't get this (mostly >>>> noise) data unless they explicitly ask for it. Otherwise for an Ethernet >>>> interface you might return 10 leaves of potentially useful opstate >>>> information, along with 50+ leaves of quite low layer diagnostics >>>> information that is likely to be of very little use except for to the select >>>> few people that are actively involved in trying to diagnose hardware faults. >>>> >>> I expect that there will be many augmentations to lets say /interfaces >>> (or /interfaces-state). How does a data model writer determine which >>> ones are 'noise' and which ones are not? How does a a data model >>> writer determine which ones are costly to implement and which ones are >>> not (since this may vary widely between systems)? >> It isn't so much as it being noise. I see that the two quite different >> sets of config false nodes are: >> >> (1) The first set of nodes are those that are useful to a client to >> manage a device and to determine whether the device's actual behaviour >> matches the expected behaviour based on the configuration. This is the >> same set of data that has traditionally been modeled via SNMP, and I >> think of as being the operational state of the device. >> >> (2) If it is determined from the nodes above that a device is behaving >> in an abnormal way, then the second set of nodes are aimed at device >> developers/engineers to ascertain why the device is not behaving as >> specified. A lot of this internal diagnostics information may only be >> of use to a developer who is familiar with the code (or intricacies of >> the hardware), and/or has a deep level of understanding of how a >> particular feature works. I would see that most of this information is >> very likely to be device specific, and presented in a device specific >> way, and may include internal debug and dumps of internal data-structures. >> >> I believe that most of the time, operators are only interested in >> interacting with that first set of data because that is all that is >> useful and required to manage their devices, and hence that is what I >> think should be modeled in the operational state datastore. However, in >> many cases, having a standard automated way of fetching that second set >> of data is still useful, because it facilitates more efficient >> diagnostic tools to be created in the future. >> >> Specifically for Ethernet, 802.3 specifies a clear separation between >> what they expect to be made available via a management protocol vs what >> is regarded as being an internal API, specifically: >> -802.3 Clause 30 specifies the main management objects, that I would >> expect to be broadly accessible to management clients, and what we are >> planning on basing the Ethernet YANG on. (This is consistent with what >> is available in the Ethernet related MIBs and the OpenConfig Ethernet >> model). >> - the internal interface is defined as the MDIO registers in 802.3 >> Clause 45. Looking at these register definitions, although the >> registers themselves can be given meaningful names, the values >> themselves would probably just be returned as opaque 16 bit register >> values, since the YANG "bits" type isn't flexible enough to represent >> the packed values they sometimes contain (specifically where they are >> using a set of bits to represent an enumerated value). >> >> >>> Perhaps it is useful to tell client writers that well behaving clients >>> should ask for what they need (and understand) and that they should >>> avoid asking generic 'give me everything you have' questions. >> I really think that there are two separate classes of data here, and it >> makes more sense to treat them as such. >> >> Defining RPCs to fetch the internal diagnostics data on demand seems OK >> to me, or alternatively marking the nodes as being diagnostics related >> and putting that in a separate datastore would seem to be reasonable. >> >>> If you have to deal with lazy clients that like to grab everything, >>> you can control them via NACM. Simply exclude access to some branches. >> This will likely just mean that every device would have to support this >> NACM to handle the mainline case. That sounds like a lot of extra >> unnecessary work for everyone. >> >> Thanks, >> Rob >> >>> /js >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Dec 9 02:54:59 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533FF12A3E2 for ; Fri, 9 Dec 2016 02:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcGScv_5PLjR for ; Fri, 9 Dec 2016 02:54:55 -0800 (PST) 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 CD48112A3CF for ; Fri, 9 Dec 2016 02:54:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3802; q=dns/txt; s=iport; t=1481280857; x=1482490457; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=tD7gufepWsQq8olAaJb1EYo/2BMn4sSGHepmB0S5iEA=; b=apU4uWTXrspTia9Zow5uOqorchbCJqkZtDiDHFmJ9sMS0LM7KgRuTZRp aRVnoa/7zREgsZ1r/8bsjbEBqZEV8QGmh6+e36IAKftqvgjjpGNitQSHZ LPH3Vjy55zc48RPMLbQhfQ6CKTZ1gx/ODKBPO0E9TISkOBS2l8tFdsveR 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAQDfjEpY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAYEnjiGXFJJzgg+CCoYhAoI/FAECAQEBAQEBAWIohGg?= =?us-ascii?q?BAQEDAThRCxguVwYBDAgBAReISAiqU4sqAQEBAQEBAQECAQEBAQEBIoY+gX2CX?= =?us-ascii?q?oQyhXcBBJprkSGKF4YuiiiDY4QOHzd+FQ6FWT6JTQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,324,1477958400"; d="scan'208";a="647763184" 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; 09 Dec 2016 10:54:13 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uB9AsCev005091; Fri, 9 Dec 2016 10:54:13 GMT To: Vladimir Vassilev , Alex Campbell , netmod@ietf.org References: <5bc806b2-4941-dded-8e78-a3ffbaeeb9a6@cisco.com> <7b942d40-5b46-36ed-d940-ae12e2e93082@cisco.com> <1481058189709.95115@Aviatnet.com> <40eebd36-0e41-0082-f169-177dc95a537b@transpacket.com> <4c900f1f-7b57-1bb0-1d41-3beec6c03bab@cisco.com> <20161207161336.GB792@elstar.local> <8c3ebda5-9775-8b0c-c569-194cefcd4ae9@cisco.com> <20161208191111.GA92046@elstar.local> From: Robert Wilton Message-ID: <56095eab-f167-5f3d-371d-a92346eb062e@cisco.com> Date: Fri, 9 Dec 2016 10:54:14 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161208191111.GA92046@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 10:54:57 -0000 On 08/12/2016 19:11, Juergen Schoenwaelder wrote: > On Thu, Dec 08, 2016 at 05:49:11PM +0000, Robert Wilton wrote: >> On 07/12/2016 16:13, Juergen Schoenwaelder wrote: >>> On Wed, Dec 07, 2016 at 02:39:00PM +0000, Robert Wilton wrote: >>>> Alas, xpath filtering is optional, and I'm not sure how many devices have >>>> implemented support for it. Further, this still requires every client to be >>>> coded to avoid receiving the information that they are very unlikely to be >>>> interested in. >>>> >>>> I would much prefer a solution where the clients don't get this (mostly >>>> noise) data unless they explicitly ask for it. Otherwise for an Ethernet >>>> interface you might return 10 leaves of potentially useful opstate >>>> information, along with 50+ leaves of quite low layer diagnostics >>>> information that is likely to be of very little use except for to the select >>>> few people that are actively involved in trying to diagnose hardware faults. >>>> >>> I expect that there will be many augmentations to lets say /interfaces >>> (or /interfaces-state). How does a data model writer determine which >>> ones are 'noise' and which ones are not? How does a a data model >>> writer determine which ones are costly to implement and which ones are >>> not (since this may vary widely between systems)? >> It isn't so much as it being noise. I see that the two quite different sets >> of config false nodes are: >> >> (1) The first set of nodes are those that are useful to a client to manage a >> device and to determine whether the device's actual behaviour matches the >> expected behaviour based on the configuration. This is the same set of data >> that has traditionally been modeled via SNMP, and I think of as being the >> operational state of the device. >> >> (2) If it is determined from the nodes above that a device is behaving in an >> abnormal way, then the second set of nodes are aimed at device >> developers/engineers to ascertain why the device is not behaving as >> specified. A lot of this internal diagnostics information may only be of >> use to a developer who is familiar with the code (or intricacies of the >> hardware), and/or has a deep level of understanding of how a particular >> feature works. I would see that most of this information is very likely to >> be device specific, and presented in a device specific way, and may include >> internal debug and dumps of internal data-structures. > The simply disable this module on a production system. Alas I don't think that this would help. The aim is that the information is still available on production systems, just not returned by default. >> I believe that most of the time, operators are only interested in >> interacting with that first set of data because that is all that is useful >> and required to manage their devices, and hence that is what I think should >> be modeled in the operational state datastore. However, in many cases, >> having a standard automated way of fetching that second set of data is still >> useful, because it facilitates more efficient diagnostic tools to be created >> in the future. > Than leave the data model active and make NACM grant access to this > data only for engineers. Assuming that diagnostics information was specified for each of N different protocols on a device. Then this would seem to mean that every device would have to install N default NACM deny entries (one for each supported protocol) to ensure that the device has sensible default operator semantics. This would seem to be quite a burden on the industry. A solution that doesn't rely on every server inserting lots of NACM entries by default seems like a better choice to me. Thanks, Rob > > /js > From nobody Fri Dec 9 03:05:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA2112A3D8 for ; Fri, 9 Dec 2016 03:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] autolearn=unavailable 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 N1I0BOkR0see for ; Fri, 9 Dec 2016 03:05:26 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8023E12A3D0 for ; Fri, 9 Dec 2016 02:54:22 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:ade0:95a:a7e1:737f] (unknown [IPv6:2001:718:1a02:1:ade0:95a:a7e1:737f]) by mail.nic.cz (Postfix) with ESMTPSA id CC68B60FD6; Fri, 9 Dec 2016 11:54:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1481280860; bh=j0PW/pGbox3ek2ewii9FNIwVXZefX5sGyGAOLoev96Q=; h=From:Date:To; b=kIF4QUu6DNFdc003tuslcg2gDYUUpfgImCGv5RYpdj/3R/uKjzuB+y2lHRf33XJe8 ym1nNfRNdXs+E1voAthWtedgk/mJU5dZgzK56f7UNWhwyFnq2FxE1aVYRWQwyrInEj 2At8jHjRy6M7iPIoAPd5TfRBrMZH49txTOwFuYNY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 9 Dec 2016 11:54:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0039E3A0-76D4-4ACB-B35F-2BAEBA962D90@nic.cz> References: <5bc806b2-4941-dded-8e78-a3ffbaeeb9a6@cisco.com> <7b942d40-5b46-36ed-d940-ae12e2e93082@cisco.com> <1481058189709.95115@Aviatnet.com> <40eebd36-0e41-0082-f169-177dc95a537b@transpacket.com> <4c900f1f-7b57-1bb0-1d41-3beec6c03bab@cisco.com> <20161207161336.GB792@elstar.local> <8c3ebda5-9775-8b0c-c569-194cefcd4ae9@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3251) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 11:05:30 -0000 > On 9 Dec 2016, at 11:48, Robert Wilton wrote: >=20 > Hi Lada, >=20 >=20 > On 09/12/2016 10:33, Ladislav Lhotka wrote: >> Hi Rob, >>=20 >> I didn't follow the previous discussion closely but a natural = solution >> seems to be to define a leaf like "debug" - it could be just boolean = or >> an enumeration of debug levels. And then add the diagnostic >> data as an augment that conditionally depends on the value of the >> "debug" leaf. >>=20 >> Would this work? > I'm not sure. >=20 > Historically debug has been separate from configuration. I.e. you = wouldn't normally expect debug settings to persist after rebooting the = device. Yes, good point. So what you can do is to have a "debug" RPC, show = "debug" value in state data, and still make the augment with diagnostics = conditionally dependent on the debug leaf. Lada > Possibly debug could be modeled using I2RS, but that would be tying = its fate to I2RS, and I'm not sure whether I2RS will gain widespread = adoption. >=20 > Although I raised my concern specification related to Ethernet clause = 45 registers, I think that my question is really more general about = whether debug/diagnostics should be modeled in YANG and if so how that = should be done. Perhaps, we should just concentrate on getting the = basis config and operational state models sorted out initially and then = figure out how diagnostics should be modeled at a later date? >=20 > Rob >=20 >> Lada >>=20 >> Robert Wilton writes: >>=20 >>> On 07/12/2016 16:13, Juergen Schoenwaelder wrote: >>>> On Wed, Dec 07, 2016 at 02:39:00PM +0000, Robert Wilton wrote: >>>>> Alas, xpath filtering is optional, and I'm not sure how many = devices have >>>>> implemented support for it. Further, this still requires every = client to be >>>>> coded to avoid receiving the information that they are very = unlikely to be >>>>> interested in. >>>>>=20 >>>>> I would much prefer a solution where the clients don't get this = (mostly >>>>> noise) data unless they explicitly ask for it. Otherwise for an = Ethernet >>>>> interface you might return 10 leaves of potentially useful opstate >>>>> information, along with 50+ leaves of quite low layer diagnostics >>>>> information that is likely to be of very little use except for to = the select >>>>> few people that are actively involved in trying to diagnose = hardware faults. >>>>>=20 >>>> I expect that there will be many augmentations to lets say = /interfaces >>>> (or /interfaces-state). How does a data model writer determine = which >>>> ones are 'noise' and which ones are not? How does a a data model >>>> writer determine which ones are costly to implement and which ones = are >>>> not (since this may vary widely between systems)? >>> It isn't so much as it being noise. I see that the two quite = different >>> sets of config false nodes are: >>>=20 >>> (1) The first set of nodes are those that are useful to a client to >>> manage a device and to determine whether the device's actual = behaviour >>> matches the expected behaviour based on the configuration. This is = the >>> same set of data that has traditionally been modeled via SNMP, and I >>> think of as being the operational state of the device. >>>=20 >>> (2) If it is determined from the nodes above that a device is = behaving >>> in an abnormal way, then the second set of nodes are aimed at device >>> developers/engineers to ascertain why the device is not behaving as >>> specified. A lot of this internal diagnostics information may only = be >>> of use to a developer who is familiar with the code (or intricacies = of >>> the hardware), and/or has a deep level of understanding of how a >>> particular feature works. I would see that most of this information = is >>> very likely to be device specific, and presented in a device = specific >>> way, and may include internal debug and dumps of internal = data-structures. >>>=20 >>> I believe that most of the time, operators are only interested in >>> interacting with that first set of data because that is all that is >>> useful and required to manage their devices, and hence that is what = I >>> think should be modeled in the operational state datastore. However, = in >>> many cases, having a standard automated way of fetching that second = set >>> of data is still useful, because it facilitates more efficient >>> diagnostic tools to be created in the future. >>>=20 >>> Specifically for Ethernet, 802.3 specifies a clear separation = between >>> what they expect to be made available via a management protocol vs = what >>> is regarded as being an internal API, specifically: >>> -802.3 Clause 30 specifies the main management objects, that I = would >>> expect to be broadly accessible to management clients, and what we = are >>> planning on basing the Ethernet YANG on. (This is consistent with = what >>> is available in the Ethernet related MIBs and the OpenConfig = Ethernet >>> model). >>> - the internal interface is defined as the MDIO registers in 802.3 >>> Clause 45. Looking at these register definitions, although the >>> registers themselves can be given meaningful names, the values >>> themselves would probably just be returned as opaque 16 bit register >>> values, since the YANG "bits" type isn't flexible enough to = represent >>> the packed values they sometimes contain (specifically where they = are >>> using a set of bits to represent an enumerated value). >>>=20 >>>=20 >>>> Perhaps it is useful to tell client writers that well behaving = clients >>>> should ask for what they need (and understand) and that they should >>>> avoid asking generic 'give me everything you have' questions. >>> I really think that there are two separate classes of data here, and = it >>> makes more sense to treat them as such. >>>=20 >>> Defining RPCs to fetch the internal diagnostics data on demand seems = OK >>> to me, or alternatively marking the nodes as being diagnostics = related >>> and putting that in a separate datastore would seem to be = reasonable. >>>=20 >>>> If you have to deal with lazy clients that like to grab everything, >>>> you can control them via NACM. Simply exclude access to some = branches. >>> This will likely just mean that every device would have to support = this >>> NACM to handle the mainline case. That sounds like a lot of extra >>> unnecessary work for everyone. >>>=20 >>> Thanks, >>> Rob >>>=20 >>>> /js >>>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Dec 9 03:11:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538B812A3F7 for ; Fri, 9 Dec 2016 03:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9IcbXFxllJ5 for ; Fri, 9 Dec 2016 03:11:47 -0800 (PST) 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 8DBE912A3DB for ; Fri, 9 Dec 2016 03:05:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1276; q=dns/txt; s=iport; t=1481281550; x=1482491150; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=NRAbOCxjDCtoTc8dpk2Cu34AoZ0oIpKxtvyfhca2lUM=; b=QU9H6gQOAgEgOl0KiPTFdsHReuU+EuDrf0RZwDerV4GKpNv4o4zeA6or S6dbJcwUzaFzxdYQxdf1iyfVCZ3ljzb2rKCLvVcA30NHDaiB0I87jczMR xwpO6beBNZtOV/GcQ3sE6mcxYCHNELVZLAxOVqFZENeowKnj6cX50y3Qu 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAQC6jkpY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAYEnWI1JlxSSc4IPggqGIQKCPxQBAgEBAQEBAQFiKIR?= =?us-ascii?q?pAQU4QRALGC5XBg0GAgEBF4hQqkiLKQEBAQEBAQEBAQEBAQEBAQEBIYY+gX2CX?= =?us-ascii?q?oopAQSaa5EhiheGLooog2OEDh83fhUOhVk+NIkZAQEB?= X-IronPort-AV: E=Sophos;i="5.33,324,1477958400"; d="scan'208";a="690323548" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Dec 2016 11:05:46 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uB9B5jIu007748; Fri, 9 Dec 2016 11:05:46 GMT To: Ladislav Lhotka References: <5bc806b2-4941-dded-8e78-a3ffbaeeb9a6@cisco.com> <7b942d40-5b46-36ed-d940-ae12e2e93082@cisco.com> <1481058189709.95115@Aviatnet.com> <40eebd36-0e41-0082-f169-177dc95a537b@transpacket.com> <4c900f1f-7b57-1bb0-1d41-3beec6c03bab@cisco.com> <20161207161336.GB792@elstar.local> <8c3ebda5-9775-8b0c-c569-194cefcd4ae9@cisco.com> <0039E3A0-76D4-4ACB-B35F-2BAEBA962D90@nic.cz> From: Robert Wilton Message-ID: Date: Fri, 9 Dec 2016 11:05:47 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <0039E3A0-76D4-4ACB-B35F-2BAEBA962D90@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 11:11:48 -0000 On 09/12/2016 10:54, Ladislav Lhotka wrote: >> On 9 Dec 2016, at 11:48, Robert Wilton wrote: >> >> Hi Lada, >> >> >> On 09/12/2016 10:33, Ladislav Lhotka wrote: >>> Hi Rob, >>> >>> I didn't follow the previous discussion closely but a natural solution >>> seems to be to define a leaf like "debug" - it could be just boolean or >>> an enumeration of debug levels. And then add the diagnostic >>> data as an augment that conditionally depends on the value of the >>> "debug" leaf. >>> >>> Would this work? >> I'm not sure. >> >> Historically debug has been separate from configuration. I.e. you wouldn't normally expect debug settings to persist after rebooting the device. > Yes, good point. So what you can do is to have a "debug" RPC, show "debug" value in state data, and still make the augment with diagnostics conditionally dependent on the debug leaf. OK, so this is closer, but still would mean that enabling the debug flag via RPC would potentially cause all clients to start to see the diagnostics information (which may break them). Hence I think that there is a requirement that the diagnostics data is restricted to only the specific client session that it has been requested on/enabled on. Thanks, Rob From nobody Fri Dec 9 03:23:43 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94AF512A3C5 for ; Fri, 9 Dec 2016 03:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 0RIrbPv9RypV for ; Fri, 9 Dec 2016 03:23:32 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70B4412A457 for ; Fri, 9 Dec 2016 03:16:39 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 91836732; Fri, 9 Dec 2016 12:16:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id qTCXAirA2zHi; Fri, 9 Dec 2016 12:16:33 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 9 Dec 2016 12:16:37 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5911120067; Fri, 9 Dec 2016 12:16:41 +0100 (CET) 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 yMt27oesYxJx; Fri, 9 Dec 2016 12:16:37 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1DC9D20063; Fri, 9 Dec 2016 12:16:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 54FDA3DB0C8D; Fri, 9 Dec 2016 12:16:36 +0100 (CET) Date: Fri, 9 Dec 2016 12:16:36 +0100 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20161209111636.GA93398@elstar.local> Mail-Followup-To: Robert Wilton , Ladislav Lhotka , netmod@ietf.org References: <7b942d40-5b46-36ed-d940-ae12e2e93082@cisco.com> <1481058189709.95115@Aviatnet.com> <40eebd36-0e41-0082-f169-177dc95a537b@transpacket.com> <4c900f1f-7b57-1bb0-1d41-3beec6c03bab@cisco.com> <20161207161336.GB792@elstar.local> <8c3ebda5-9775-8b0c-c569-194cefcd4ae9@cisco.com> <0039E3A0-76D4-4ACB-B35F-2BAEBA962D90@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 11:23:42 -0000 On Fri, Dec 09, 2016 at 11:05:47AM +0000, Robert Wilton wrote: > > OK, so this is closer, but still would mean that enabling the debug flag via > RPC would potentially cause all clients to start to see the diagnostics > information (which may break them). > A client that breaks when receiving unknown data is a broken client. The earlier they fall apart the better so that they get fixed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Dec 9 03:26:52 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBEC12A4CB for ; Fri, 9 Dec 2016 03:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 hxGw-Rp2YmHV for ; Fri, 9 Dec 2016 03:26:43 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9513312A3FB for ; Fri, 9 Dec 2016 03:19:40 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6511D783; Fri, 9 Dec 2016 12:19:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id s9jw1Jr3e3ie; Fri, 9 Dec 2016 12:19:35 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 9 Dec 2016 12:19:39 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F82F20067; Fri, 9 Dec 2016 12:19:43 +0100 (CET) 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 2oQfOnzIv7Vy; Fri, 9 Dec 2016 12:19:38 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0FF920063; Fri, 9 Dec 2016 12:19:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AF3E13DB0CE1; Fri, 9 Dec 2016 12:19:38 +0100 (CET) Date: Fri, 9 Dec 2016 12:19:38 +0100 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20161209111938.GB93398@elstar.local> Mail-Followup-To: Robert Wilton , Vladimir Vassilev , Alex Campbell , netmod@ietf.org References: <5bc806b2-4941-dded-8e78-a3ffbaeeb9a6@cisco.com> <7b942d40-5b46-36ed-d940-ae12e2e93082@cisco.com> <1481058189709.95115@Aviatnet.com> <40eebd36-0e41-0082-f169-177dc95a537b@transpacket.com> <4c900f1f-7b57-1bb0-1d41-3beec6c03bab@cisco.com> <20161207161336.GB792@elstar.local> <8c3ebda5-9775-8b0c-c569-194cefcd4ae9@cisco.com> <20161208191111.GA92046@elstar.local> <56095eab-f167-5f3d-371d-a92346eb062e@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56095eab-f167-5f3d-371d-a92346eb062e@cisco.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 11:26:50 -0000 On Fri, Dec 09, 2016 at 10:54:14AM +0000, Robert Wilton wrote: > > Assuming that diagnostics information was specified for each of N different > protocols on a device. Then this would seem to mean that every device would > have to install N default NACM deny entries (one for each supported > protocol) to ensure that the device has sensible default operator semantics. > This would seem to be quite a burden on the industry. > > A solution that doesn't rely on every server inserting lots of NACM entries > by default seems like a better choice to me. > Did I say that there need to be N? And why would N hard coded toggles in data models be simpler and not a burden for the industry? What is the definition of 'burden for the industry' anyway? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Dec 9 03:32:22 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C97512A50E for ; Fri, 9 Dec 2016 03:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SlDs3ct-bPD for ; Fri, 9 Dec 2016 03:32:18 -0800 (PST) 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 CA50A12A542 for ; Fri, 9 Dec 2016 03:25:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=968; q=dns/txt; s=iport; t=1481282738; x=1482492338; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=W6SxbjXvogWw2HLzwx+8WxoVRsBHzROqMlNjoVSqxu4=; b=lptoi4C+mUImvdxGFX6AhvLfyvGVHA2yRvnPRw7WhC58kf8KlfUutsBD Po9BdPFnscNlXteSCVXv6tDwjv0PSOvK9Cg3uy0jLHlpuCnmH0loIKl3T 05aCuFGBicLWi1UdLldSZqeCdhuH9MGE61Hy8JyunWC+YKv/y0Q005ZAO s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZAgB7k0pY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgywLAQEBAQGBJ6U1knOCD4IKhiECgkATAQIBAQEBAQEBYiiEaQE?= =?us-ascii?q?FOFELGC5XBgEMCAEBiGeqRIsqAQEBAQEBAQECAQEBAQEBIoQdgiGBfQiCVoopA?= =?us-ascii?q?QSaa5EhiheGLooog2OEDiEBNH4VDoVZPolNAQEB?= X-IronPort-AV: E=Sophos;i="5.33,324,1477958400"; d="scan'208";a="690324695" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Dec 2016 11:25:34 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uB9BPYje011953; Fri, 9 Dec 2016 11:25:34 GMT To: Ladislav Lhotka , netmod@ietf.org References: <7b942d40-5b46-36ed-d940-ae12e2e93082@cisco.com> <1481058189709.95115@Aviatnet.com> <40eebd36-0e41-0082-f169-177dc95a537b@transpacket.com> <4c900f1f-7b57-1bb0-1d41-3beec6c03bab@cisco.com> <20161207161336.GB792@elstar.local> <8c3ebda5-9775-8b0c-c569-194cefcd4ae9@cisco.com> <0039E3A0-76D4-4ACB-B35F-2BAEBA962D90@nic.cz> <20161209111636.GA93398@elstar.local> From: Robert Wilton Message-ID: Date: Fri, 9 Dec 2016 11:25:35 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161209111636.GA93398@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 11:32:20 -0000 On 09/12/2016 11:16, Juergen Schoenwaelder wrote: > On Fri, Dec 09, 2016 at 11:05:47AM +0000, Robert Wilton wrote: >> OK, so this is closer, but still would mean that enabling the debug flag via >> RPC would potentially cause all clients to start to see the diagnostics >> information (which may break them). >> > A client that breaks when receiving unknown data is a broken client. The > earlier they fall apart the better so that they get fixed. Even if they don't break, debug and diagnostics information can be very verbose. If a client had 4 connections to a device for monitoring different things, then you don't want to suddenly start sending a large amount of extra diagnostics data on each of the 4 connections when they have only requested it on one connection. Generating this extra data could overload the client or the device, or certainly lead to degraded performance in some way or another. Thanks, Rob > > /js > From nobody Fri Dec 9 03:52:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708F612A3E5 for ; Fri, 9 Dec 2016 03:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 FYEwXTUQ_pJe for ; Fri, 9 Dec 2016 03:52:05 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A4712A4E6 for ; Fri, 9 Dec 2016 03:43:20 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:ade0:95a:a7e1:737f] (unknown [IPv6:2001:718:1a02:1:ade0:95a:a7e1:737f]) by mail.nic.cz (Postfix) with ESMTPSA id E698B61DFB; Fri, 9 Dec 2016 12:43:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1481283798; bh=4iLmo6DPIhajRt+2SzkSK9z9U9WuIZVFxiwEOB4oOeM=; h=From:Date:To; b=tnqwfT1zhbX+nPnVWgMURSUqPVr4qlqseG/yMNV1u0ynTdOHUVtB0ebCXwtzo+lz7 EMw25buPrc8gkX0Kkgk64p44jCqDfCBY5KjPhrEOCl77Dynv2bVhThUCf6sJ1wlcpW el1v3/j6cYq1QybWE762IDSo+/FWMQZEi6UKI22g= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 9 Dec 2016 12:43:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <02A0A612-3430-4CDB-B993-1859AE8D7115@nic.cz> References: <5bc806b2-4941-dded-8e78-a3ffbaeeb9a6@cisco.com> <7b942d40-5b46-36ed-d940-ae12e2e93082@cisco.com> <1481058189709.95115@Aviatnet.com> <40eebd36-0e41-0082-f169-177dc95a537b@transpacket.com> <4c900f1f-7b57-1bb0-1d41-3beec6c03bab@cisco.com> <20161207161336.GB792@elstar.local> <8c3ebda5-9775-8b0c-c569-194cefcd4ae9@cisco.com> <0039E3A0-76D4-4ACB-B35F-2BAEBA962D90@nic.cz> To: Robert Wilton X-Mailer: Apple Mail (2.3251) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 11:52:07 -0000 > On 9 Dec 2016, at 12:05, Robert Wilton wrote: >=20 >=20 >=20 > On 09/12/2016 10:54, Ladislav Lhotka wrote: >>> On 9 Dec 2016, at 11:48, Robert Wilton wrote: >>>=20 >>> Hi Lada, >>>=20 >>>=20 >>> On 09/12/2016 10:33, Ladislav Lhotka wrote: >>>> Hi Rob, >>>>=20 >>>> I didn't follow the previous discussion closely but a natural = solution >>>> seems to be to define a leaf like "debug" - it could be just = boolean or >>>> an enumeration of debug levels. And then add the diagnostic >>>> data as an augment that conditionally depends on the value of the >>>> "debug" leaf. >>>>=20 >>>> Would this work? >>> I'm not sure. >>>=20 >>> Historically debug has been separate from configuration. I.e. you = wouldn't normally expect debug settings to persist after rebooting the = device. >> Yes, good point. So what you can do is to have a "debug" RPC, show = "debug" value in state data, and still make the augment with diagnostics = conditionally dependent on the debug leaf. > OK, so this is closer, but still would mean that enabling the debug = flag via RPC would potentially cause all clients to start to see the = diagnostics information (which may break them). You can add finer granularity by making "debug" into an action on an = interface, and then I think it's not a big deal.=20 >=20 > Hence I think that there is a requirement that the diagnostics data is = restricted to only the specific client session that it has been = requested on/enabled on. Then an RPC returning the diagnostics, as Vladimir suggested, might be = the best option. Lada >=20 > Thanks, > Rob -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Dec 9 03:55:52 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4AAB12A518 for ; Fri, 9 Dec 2016 03:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_w5a1H2DuEZ for ; Fri, 9 Dec 2016 03:55:46 -0800 (PST) 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 DAC4112A43F for ; Fri, 9 Dec 2016 03:46:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2351; q=dns/txt; s=iport; t=1481284017; x=1482493617; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=xltzqwjqtOYOgUGf+WdbzZ22kJ0NSA1JQgCXDtYG95Y=; b=MnNMOfeN6dWR0zgcod5HMHXBKomrbsxkgRvAOZbsW7ry9EAqGiXWGPMm FWspmBQ3ZKajiG7bfAaPNBZDZ1HPJjKfkmN2zrSIY+9OZm0woo0FIrXta iYNnB5sFEiCsrBxjBBqEo8BQXowWMQlV0Mk0nLHCAKlMnTD4OU8sbQL+j E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AAALmUpY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAY9IlxSSc4IPggqGIQKCPxQBAgEBAQEBAQFiKIRoAQE?= =?us-ascii?q?BAwE4RgsLGC5XBgEMCAEBF4hICKo8iyoBAQEBAQEBAQIBAQEBAQEihj6BfYJeh?= =?us-ascii?q?DKFdwEEmmuRIYFzhH+DJYYuiiiDY4QOHzd+FQ6DYByBXT6JcAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,324,1477958400"; d="scan'208";a="650605661" 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; 09 Dec 2016 11:46:39 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uB9BkdZR018926; Fri, 9 Dec 2016 11:46:39 GMT To: Vladimir Vassilev , Alex Campbell , netmod@ietf.org References: <5bc806b2-4941-dded-8e78-a3ffbaeeb9a6@cisco.com> <7b942d40-5b46-36ed-d940-ae12e2e93082@cisco.com> <1481058189709.95115@Aviatnet.com> <40eebd36-0e41-0082-f169-177dc95a537b@transpacket.com> <4c900f1f-7b57-1bb0-1d41-3beec6c03bab@cisco.com> <20161207161336.GB792@elstar.local> <8c3ebda5-9775-8b0c-c569-194cefcd4ae9@cisco.com> <20161208191111.GA92046@elstar.local> <56095eab-f167-5f3d-371d-a92346eb062e@cisco.com> <20161209111938.GB93398@elstar.local> From: Robert Wilton Message-ID: Date: Fri, 9 Dec 2016 11:46:39 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161209111938.GB93398@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 11:55:50 -0000 Hi Juergen, On 09/12/2016 11:19, Juergen Schoenwaelder wrote: > On Fri, Dec 09, 2016 at 10:54:14AM +0000, Robert Wilton wrote: >> Assuming that diagnostics information was specified for each of N different >> protocols on a device. Then this would seem to mean that every device would >> have to install N default NACM deny entries (one for each supported >> protocol) to ensure that the device has sensible default operator semantics. >> This would seem to be quite a burden on the industry. >> >> A solution that doesn't rely on every server inserting lots of NACM entries >> by default seems like a better choice to me. >> > Did I say that there need to be N? No, I had extrapolated. :-) Please can you expand on your proposed solution if using just one NACM entry. > And why would N hard coded toggles > in data models be simpler and not a burden for the industry? 1. Because by default there is no additional filtering cost to excluding diagnostics data from get/push requests on the operational state datastore. 2. The names of the RPCs could be defined by convention, and hence handled in a generic way. 3. Defining RPCs isn't my preferred solution, but it feels like the most pragmatic one available today. I think that diagnostics is a fundamentally different level of operational state data that may be better served using a separate datastore that sits below the operational state datastore. I.e. it "sees" everything in the operational state datatstore but also contains the extra diagnostics information as well. The diagnostic specific nodes would be marked in the schema, same as config, i2rs, etc, presumably defined in a YANG extension. > What is > the definition of 'burden for the industry' anyway? OK, I agree that it was a nebulous term, but my two specific concerns are: 1. Everyone who implements the model also needs to implement a NACM entry to only return the data that 99% of clients are likely to be generally interested in. 2. I am concerned about the server performance overhead of the extra NACM entry/entries for the mainline case. 3. I think that it requires client to know by magic that the diagnostics information isn't returned by default (but if done in a uniform way this could be solved by convention). Thanks, Rob > > /js > From nobody Fri Dec 9 04:18:54 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBC612984B for ; Fri, 9 Dec 2016 04:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 6KTDxwf1s-jR for ; Fri, 9 Dec 2016 04:18:46 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33F44129A09 for ; Fri, 9 Dec 2016 04:06:57 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0CF521567; Fri, 9 Dec 2016 13:06:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 9ITfoCM33Abq; Fri, 9 Dec 2016 13:06:52 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 9 Dec 2016 13:06:55 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE3F420067; Fri, 9 Dec 2016 13:06:59 +0100 (CET) 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 6xL-wzbe0xaU; Fri, 9 Dec 2016 13:06:55 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7FCF20063; Fri, 9 Dec 2016 13:06:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BA7D03DB0EB2; Fri, 9 Dec 2016 13:06:53 +0100 (CET) Date: Fri, 9 Dec 2016 13:06:53 +0100 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20161209120651.GA93531@elstar.local> Mail-Followup-To: Robert Wilton , Ladislav Lhotka , netmod@ietf.org References: <40eebd36-0e41-0082-f169-177dc95a537b@transpacket.com> <4c900f1f-7b57-1bb0-1d41-3beec6c03bab@cisco.com> <20161207161336.GB792@elstar.local> <8c3ebda5-9775-8b0c-c569-194cefcd4ae9@cisco.com> <0039E3A0-76D4-4ACB-B35F-2BAEBA962D90@nic.cz> <20161209111636.GA93398@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 12:18:52 -0000 On Fri, Dec 09, 2016 at 11:25:35AM +0000, Robert Wilton wrote: > > Even if they don't break, debug and diagnostics information can be very > verbose. > > If a client had 4 connections to a device for monitoring different things, > then you don't want to suddenly start sending a large amount of extra > diagnostics data on each of the 4 connections when they have only requested > it on one connection. Generating this extra data could overload the client > or the device, or certainly lead to degraded performance in some way or > another. > Then the client probably should have used a proper filter. Augments are a key feature of YANG. A client not interested in any additional data should not (implicitely) ask for it. (It does not matter whether the additional data is debugging or other information; if you do not need it, do not as for it if you want to be robust.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Dec 9 04:26:47 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4187129DCD for ; Fri, 9 Dec 2016 04:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 SqL8vXkXcqo9 for ; Fri, 9 Dec 2016 04:26:45 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46CC512A4C6 for ; Fri, 9 Dec 2016 04:17:38 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 16DD577A; Fri, 9 Dec 2016 13:17:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id D2C9EWDpHxqd; Fri, 9 Dec 2016 13:17:33 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 9 Dec 2016 13:17:36 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B72D020067; Fri, 9 Dec 2016 13:17:40 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id N_lmUW-22x_y; Fri, 9 Dec 2016 13:17:36 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5EC3F20063; Fri, 9 Dec 2016 13:17:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3FDAA3DB0F0A; Fri, 9 Dec 2016 13:17:36 +0100 (CET) Date: Fri, 9 Dec 2016 13:17:36 +0100 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20161209121736.GB93531@elstar.local> Mail-Followup-To: Robert Wilton , Vladimir Vassilev , Alex Campbell , netmod@ietf.org References: <7b942d40-5b46-36ed-d940-ae12e2e93082@cisco.com> <1481058189709.95115@Aviatnet.com> <40eebd36-0e41-0082-f169-177dc95a537b@transpacket.com> <4c900f1f-7b57-1bb0-1d41-3beec6c03bab@cisco.com> <20161207161336.GB792@elstar.local> <8c3ebda5-9775-8b0c-c569-194cefcd4ae9@cisco.com> <20161208191111.GA92046@elstar.local> <56095eab-f167-5f3d-371d-a92346eb062e@cisco.com> <20161209111938.GB93398@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 12:26:46 -0000 On Fri, Dec 09, 2016 at 11:46:39AM +0000, Robert Wilton wrote: > Hi Juergen, > > Please can you expand on your proposed solution if using just one NACM > entry. Perhaps we talk past each other because 'NACM entry' is ambiguous. I mean one 'rule-list' entry, you probably mean N 'rule' entries. > > And why would N hard coded toggles > > in data models be simpler and not a burden for the industry? > 1. Because by default there is no additional filtering cost to excluding > diagnostics data from get/push requests on the operational state datastore. > 2. The names of the RPCs could be defined by convention, and hence handled > in a generic way. I generally dislike any solutions that relies on 'naming conventions'. > 3. Defining RPCs isn't my preferred solution, but it feels like the most > pragmatic one available today. I think that diagnostics is a fundamentally > different level of operational state data that may be better served using a > separate datastore that sits below the operational state datastore. I.e. it > "sees" everything in the operational state datatstore but also contains the > extra diagnostics information as well. The diagnostic specific nodes would > be marked in the schema, same as config, i2rs, etc, presumably defined in a > YANG extension. Perhaps you just want to dynamically enable/disable data models supported by a device? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Dec 9 04:31:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B42129873; Fri, 9 Dec 2016 04:31:40 -0800 (PST) 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 K-3cXLw7Blno; Fri, 9 Dec 2016 04:31:34 -0800 (PST) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 A57951296C7; Fri, 9 Dec 2016 04:26:06 -0800 (PST) Received: by mail-wm0-x244.google.com with SMTP id a20so3747828wme.2; Fri, 09 Dec 2016 04:26:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=H5bycSZ6TfMTplNxe3Ko6XOXZoG8sqvt3Lh61rLvc6A=; b=B3DZTpPyUuzQBTEw5HEih/Mg8PU27iHwqozlbgIgmFXKERGZO0CoCAp+4qgudrOmx/ nOsr5zonqhGOYgq2ody4OzleKRmuELaqekSRWB+Z2L0id9idvpoEsh3eGai/a64r9872 TywFO8sPuQiCN64C8iuS/RutNUXho655QhcXGeoTRYIRpLNuHv9Nw7fKHVSU+Dqj9QZ2 arzo3uSbTttr2i/lztfAosqAfEcD0dhl3ncWj5yH7OYYESc4llnhgwqpXNo0wcXgENyU jlq3ZnMf5Ounktuw5nJGhMYxAxouyLX+4qBRoV2n6tplM4VdTqpr5GH3UiEjoZt2QVrM Afog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=H5bycSZ6TfMTplNxe3Ko6XOXZoG8sqvt3Lh61rLvc6A=; b=Il0c6VF8/K8f7kiIY7m1HYA/2uqNuadClxVSw6YQ/SmghOdbIZUxsHc8Wxs0IgmgDV dQkv2PgEIgmdMYRLWdOZqs623xgB0yh21Sc4kaMWWMZbNSa56K8VMdaA0GuzlhnQ0XgR lQed6+R/xLRxmqyK/e6hVG8BChC8rTz0T0I/Xn6Y92FOE4fc5Mc+EsAZmMNtlrUwe9nZ tJizHsaDwjT+/G3Gkp12VIWOSiUAU46m4tt552Mct1M+Zz/uSotdCRwlyjA5bi35eZY1 DNHiKSsFmkTMd5hu+Xl9qu6//NYqWhx5ramSFOw/PQN5GVCwejlme59xc6GKROp9vNV6 uuUw== X-Gm-Message-State: AKaTC02cblKRVwY+ygoQAHWj4I+JXho10TQ/vZ4QHkMs+k7oQhyx+Yaaa1nyS772tK8ueFeLtN3wtDTWucxalg== X-Received: by 10.46.0.102 with SMTP id 99mr32280411lja.15.1481286365033; Fri, 09 Dec 2016 04:26:05 -0800 (PST) MIME-Version: 1.0 References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> In-Reply-To: From: MehmetErsue Date: Fri, 09 Dec 2016 12:25:54 +0000 Message-ID: To: Andy Bierman , Juergen Schoenwaelder , Ladislav Lhotka , Lou Berger , NetMod WG Chairs , Netconf , NetMod WG , NetConf WG Chairs Content-Type: multipart/alternative; boundary=001a1142c5cc993e82054338db77 Archived-At: Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 12:31:40 -0000 --001a1142c5cc993e82054338db77 Content-Type: text/plain; charset=UTF-8 Hi All, I think the adoption of the DT draft is fine. We agreed in IETF 97 to adopt and finalize the DT draft in NETMOD WG, which I still support. I believe the bigger issue is to agree on a plan concerning the related work and the re-organization of existing standards. As a matter of fact this plan will lead to updating the charter of two WGs and the work we are going to start. I see the DT document as a datastore solution proposal. There are different gaps and issues which still need to be addressed and the solution proposal needs yet to be discussed and finalized. The document is providing information on the history, explaining the need for a generic solution as well as is discussing different scenarios. As such I believe the datastore solution proposal from the DT should be published with the intended status Informational RFC. Based on the finalized and agreed datastore solution we should do different updates to existing documents in NETCONF and NETMOD WGs. With this action we can also fix well-known issues. Concerning the NETCONF WG I would see it as valuable if we develop: - a RFC6241bis draft removing the current datasore concept specification, and getting rid of well-known issues e.g. with the operation, - a new protocol- and language-independent standard document (RFC XYZ) defining the generic datastore concept and framework and describing its use (based on and following the DT solution draft), - adding potential extensions to RFC6241bis (following the DT draft and with a normative reference to RFC XYZ), - adding potential extensions to a RESTCONF-bis RFC (following the DT draft and with a normative reference to RFC XYZ), Concerning the NETMOD WG I would see it as valuable if we develop: - RFC7950bis deleting protocol-dependent details and specifying the datastore usage with YANG on a generic level (with a normative reference to RFC XYZ), - adding potential extensions to RFC7950bis, e.g. concerning the proposed element, - possibly an RFC 6244bis to describe architectural aspects. However RFC6244 is Informational and a RFC6244bis would be still Informational. I'm not sure whether this is really necessary. The DT proposal does already describe such a solution and can be seen as an update to RFC 6244. - RFC6087bis giving guidelines on how to use YANG with the new datastore concept. Referring to Lada's proposal concerning the spin off document from RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be provided in the corresponding protocol RFCs, i.e. for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. Hope this helps as a starting point on the way to a good plan. PS: As Benoit suggested some time ago we might also consider to rename NETCONF WG as it is not only on NETCONF protocol anymore. Regards, Mehmet On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman wrote: > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: > > > > > > > > I disagree that the datastore model is a protocol specific aspect. I > > > consider datastores an architectural component binding data models and > > > protocols together. In fact, the 'traditional' datastore model > > > > I would agree with this if datastores were a general concept in YANG, > but the revised-datastores draft explicitly introduces the "intended" and > "applied" datastores that may be irrelevant to other protocols using YANG, > and even needn't be used in all NETCONF implementations. I wouldn't call > this "an architectural component" of YANG. > > > > An architectural component of this new management framework (that does > not have a name). The fact that not all protocols may expose all > datastores is IMHO not a reason that the datastore model is not an > architectural framework. > > > If you are saying that it will have nontrivial impact on YANG, I would > like to see it explained in sec. 6.3. Without this information I am quite > reluctant to agree with the adoption. > > An operational state datastore has implications how one writes data > models. It may not directly affect YANG itself but surely the usage of > YANG. > > > See above - architectural aspects need to be relevant to all protocols. > > Yes, but relevant to all protocols does not mean every protocol needs > to expose say all datastores. But every protocol should be clear about > how what it exposes relates to the architectural framework. > > > > There is a "current solution" consisting of hard-wired object semantics > (e.g., ifAdminStatus and ifOperStatus). This solution does not require > special protocols or datastores, but it is being replaced by a generic > solution. > > If the "generic" solution requires special procedures which differ on each > protocol, > then it might end up be worse than the hard-wired solution that works on > every protocol. > So I agree with Juergen that this is primarily an architectural issue. > > > /js > > > Andy > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 <0421%202003587> Campus Ring 1 | 28759 > Bremen | Germany > Fax: +49 421 200 3103 <0421%202003103> < > http://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > -- Cheers, Mehmet --001a1142c5cc993e82054338db77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,<= br class=3D"gmail_msg">
I think the adoption of the DT draft is fine. We agreed in IETF 97 to adopt and finalize the DT draft in NETMOD WG, which I still support.

I believe the bigger issue is to agree on a plan concerning the related=20 work and the re-organization of existing standards. As a matter of fact=20 this plan will lead to updating the charter of two WGs and the work we=20 are going to start.
=C2=A0
I = see=20 the DT document as a datastore solution proposal. There are different=20 gaps and issues which still need to be addressed and the solution=20 proposal needs yet to be discussed and finalized. The document is=20 providing information on the history, explaining the need for a generic=20 solution as well as is discussing different scenarios. As such I believe the datastore solution proposal from the DT should be published with the intended status Informational=20 RFC.

Based on the finalized= =20 and agreed datastore solution we should do different updates to existing documents in NETCONF and NETMOD WGs. With this action we can also fix=20 well-known issues.

Concernin= g the NETCONF WG I would see it as valuable if we develop:
- a RFC6241bis draft removing the current datasore concept specification, and getting rid of well-known issues e.g. with the <get>=20 operation,
- a new protocol- and=20 language-independent standard document (RFC XYZ) defining the generic=20 datastore concept and framework and describing its use (based on and follow= ing the DT solution=20 draft),
- adding potential extensions to RFC6241bis (following the DT d= raft and with a normative reference to RFC XYZ),
- a= dding potential extensions to a RESTCONF-bis RFC (following the DT draft an= d with a normative reference to RFC XYZ),

Concerning the NETMOD WG I would see it as valuable if we de= velop:
- RFC7950bis deleting protocol-dependent details and specifying the datastor= e usage with YANG on a generic level (with a normative reference to RFC=20 XYZ),
- adding potential extensions to RFC7950bis, e.g. concerning the proposed <notification> element,
-= possibly an RFC 6244bis to describe=20 architectural aspects. However RFC6244 is Informational and a RFC6244bis would be still Informational. I'm not sure whether this is really=20 necessary. The DT proposal does already describe such a solution and can be seen as an update to RFC 6244.
- RFC6087bis givi= ng guidelines on how to use YANG with the new datastore concept.

Referring to Lada's proposal con= cerning the spin off document from RFC7950 ("Adapting NETCONF for use = with YANG"),
I think this can be provided in the corresponding protocol RFCs, i.e.
fo= r NETCONF a section on "Using NETCONF with YANG" in RFC6241bis an= d for RESTCONF=20 "Using RESTCONF with YANG" in RESTCONF-bis RFC.

Hope this helps as a starting point on the way to a go= od plan.

PS: As Benoit suggested some time = ago we might also consider to rename NETCONF WG as it is not only on NETCON= F protocol anymore.

Regards,
Mehmet

On Mon, Dec 5, 2016 at = 6:19 PM Andy Bierman <andy@yumawor= ks.com> wrote:
On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelde= r <j.schoenwael= der@jacobs-university.de> wrote:
On Mon, Dec 05, 2016 at 11:36:11AM +010= 0, Ladislav Lhotka wrote:
>
> >
> > I disagree that the datastore model is a protocol specific aspect= . I
> > consider datastores an architectural component binding data model= s and
> > protocols together. In fact, the 'traditional' datastore = model
>
> I would agree with this if datastores were a general concept in YANG, = but the revised-datastores draft explicitly introduces the "intended&q= uot; and "applied" datastores that may be irrelevant to other pro= tocols using YANG, and even needn't be used in all NETCONF implementati= ons. I wouldn't call this "an architectural component" of YAN= G.
>

An architectural component of this new management framework (that does
not have a name). The fact that not all protocols may expose all
datastores is IMHO not a reason that the datastore model is not an
architectural framework.

> If you are saying that it will have nontrivial impact on YANG, I would= like to see it explained in sec. 6.3. Without this information I am quite = reluctant to agree with the adoption.

An operational state datastore has implications how one writes data
models. It may not directly affect YANG itself but surely the usage of
YANG.

> See above - architectural aspects need to be relevant to all protocols= .

Yes, but relevant to all protocols does not mean every protocol needs
to expose say all datastores. But every protocol should be clear about
how what it exposes relates to the architectural framework.

<= div class=3D"gmail_msg">

There is a "current solution&qu= ot; consisting of hard-wired object semantics
(e.g., ifAdminStatus and ifOperStatus).=C2=A0 This solution does not requi= re
special protocols or datastores, but it is= being replaced by a generic solution.

If the "generic"= solution requires special procedures which differ on each protocol,
<= div class=3D"gmail_msg">then it might end up be worse than the hard-wired s= olution that works on every protocol.
So I ag= ree with Juergen that this is primarily an architectural issue.

<= br class=3D"gmail_msg">
/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 | 28759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0<http://www.jacobs-university.d= e/>

_______________________________________________
netmod mailing list
ne= tmod@ietf.org
https://www.ietf.org/mailman/listinf= o/netmod
--
Cheers,
Mehmet
--001a1142c5cc993e82054338db77-- From nobody Fri Dec 9 04:48:46 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1D8129413; Fri, 9 Dec 2016 04:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 5r-9Z2u94jA5; Fri, 9 Dec 2016 04:48:37 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE73129407; Fri, 9 Dec 2016 04:48:37 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:ade0:95a:a7e1:737f] (unknown [IPv6:2001:718:1a02:1:ade0:95a:a7e1:737f]) by mail.nic.cz (Postfix) with ESMTPSA id 055D061D83; Fri, 9 Dec 2016 13:48:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1481287716; bh=Oztfg1BR3xLx2TtAPlPE7jW9q5pUvv25PzFfMTaTzNg=; h=From:Date:To; b=ab9Y00IWj0jEboN+7dfbEMaDgKuaQT/5TF8olTQaxH7jDAuzSMPsBZAP44a7JK/tV ZXqwGzXf73tpuECEcsph6Smq774Loa4ne1R/+GVwmT9o59mLg441q+SKj0N0Maoekh BltOq7aGDo1S/c5UL73IvULvwI8rTVXBLQH4BJgg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 9 Dec 2016 13:48:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> To: MehmetErsue X-Mailer: Apple Mail (2.3251) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 12:48:41 -0000 Hi Mehmet, I think I could just sign your text at the bottom. Lada > On 9 Dec 2016, at 13:25, MehmetErsue wrote: >=20 > Hi All, >=20 > I think the adoption of the DT draft is fine. We agreed in IETF 97 to = adopt and finalize the DT draft in NETMOD WG, which I still support. >=20 > I believe the bigger issue is to agree on a plan concerning the = related work and the re-organization of existing standards. As a matter = of fact this plan will lead to updating the charter of two WGs and the = work we are going to start. > =20 > I see the DT document as a datastore solution proposal. There are = different gaps and issues which still need to be addressed and the = solution proposal needs yet to be discussed and finalized. The document = is providing information on the history, explaining the need for a = generic solution as well as is discussing different scenarios. As such I = believe the datastore solution proposal from the DT should be published = with the intended status Informational RFC.=20 >=20 > Based on the finalized and agreed datastore solution we should do = different updates to existing documents in NETCONF and NETMOD WGs. With = this action we can also fix well-known issues. >=20 > Concerning the NETCONF WG I would see it as valuable if we develop: > - a RFC6241bis draft removing the current datasore concept = specification, and getting rid of well-known issues e.g. with the = operation, > - a new protocol- and language-independent standard document (RFC XYZ) = defining the generic datastore concept and framework and describing its = use (based on and following the DT solution draft),=20 > - adding potential extensions to RFC6241bis (following the DT draft = and with a normative reference to RFC XYZ), > - adding potential extensions to a RESTCONF-bis RFC (following the DT = draft and with a normative reference to RFC XYZ), >=20 > Concerning the NETMOD WG I would see it as valuable if we develop: > - RFC7950bis deleting protocol-dependent details and specifying the = datastore usage with YANG on a generic level (with a normative reference = to RFC XYZ), > - adding potential extensions to RFC7950bis, e.g. concerning the = proposed element, > - possibly an RFC 6244bis to describe architectural aspects. However = RFC6244 is Informational and a RFC6244bis would be still Informational. = I'm not sure whether this is really necessary. The DT proposal does = already describe such a solution and can be seen as an update to RFC = 6244. > - RFC6087bis giving guidelines on how to use YANG with the new = datastore concept. >=20 > Referring to Lada's proposal concerning the spin off document from = RFC7950 ("Adapting NETCONF for use with YANG"),=20 > I think this can be provided in the corresponding protocol RFCs, i.e.=20= > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and = for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. >=20 > Hope this helps as a starting point on the way to a good plan. >=20 > PS: As Benoit suggested some time ago we might also consider to rename = NETCONF WG as it is not only on NETCONF protocol anymore.=20 >=20 > Regards, > Mehmet=20 >=20 > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman = wrote: > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder = wrote: > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: > > > > > > > > I disagree that the datastore model is a protocol specific aspect. = I > > > consider datastores an architectural component binding data models = and > > > protocols together. In fact, the 'traditional' datastore model > > > > I would agree with this if datastores were a general concept in = YANG, but the revised-datastores draft explicitly introduces the = "intended" and "applied" datastores that may be irrelevant to other = protocols using YANG, and even needn't be used in all NETCONF = implementations. I wouldn't call this "an architectural component" of = YANG. > > >=20 > An architectural component of this new management framework (that does > not have a name). The fact that not all protocols may expose all > datastores is IMHO not a reason that the datastore model is not an > architectural framework. >=20 > > If you are saying that it will have nontrivial impact on YANG, I = would like to see it explained in sec. 6.3. Without this information I = am quite reluctant to agree with the adoption. >=20 > An operational state datastore has implications how one writes data > models. It may not directly affect YANG itself but surely the usage of > YANG. >=20 > > See above - architectural aspects need to be relevant to all = protocols. >=20 > Yes, but relevant to all protocols does not mean every protocol needs > to expose say all datastores. But every protocol should be clear about > how what it exposes relates to the architectural framework. >=20 >=20 >=20 > There is a "current solution" consisting of hard-wired object = semantics > (e.g., ifAdminStatus and ifOperStatus). This solution does not = require > special protocols or datastores, but it is being replaced by a generic = solution. >=20 > If the "generic" solution requires special procedures which differ on = each protocol, > then it might end up be worse than the hard-wired solution that works = on every protocol. > So I agree with Juergen that this is primarily an architectural issue. >=20 >=20 > /js >=20 > Andy >=20 > =20 >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --=20 > Cheers, > Mehmet -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Dec 9 05:08:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5CC12979D; Fri, 9 Dec 2016 05:08:53 -0800 (PST) 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 bRRAM1rtEfuD; Fri, 9 Dec 2016 05:08:51 -0800 (PST) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E1E3129715; Fri, 9 Dec 2016 05:08:50 -0800 (PST) Received: by mail-wm0-x241.google.com with SMTP id m203so3954305wma.3; Fri, 09 Dec 2016 05:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=XFK06eiNR7RJsPkq1q4QXx/QUZIlhtp6IiQ0qZQEDLg=; b=WrU+ZptGXx4c/lEhULdr5k3iQAy6I+Q9uxIDM0Vdym1yPfyXeh3cRLDKOnGIgRNpfp Sj6IOVUIvQaND/j/3b4ZJRu4wq5Xt6WURZhtU+IYRFiZpNhhRRUP8dJKJRWG1pvLIbqd TJETpH1fYS2CPbaq32HzzrTd5+ytVsDxuj7K19ndATe33XoEd+a1EwyIoIhUVpN2oU6/ Z9TgMLEwl4tjssnNAg+yfiyyCW3TwX0MHBJherq7rECgKGgwUu3QDYDRToUcGgD+xjU7 Bjd44/vtdXQvJIQd3JzZuePch//KGdtsxkdXXcRffMWYzEEHbQ8uVx4RRYczwllhgsdM gzfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XFK06eiNR7RJsPkq1q4QXx/QUZIlhtp6IiQ0qZQEDLg=; b=lvlaCYgxg9j3W9SP5iPrJ7zAE3iS8tA9h6f8LV6KzvxCgKqMTsTF6wh/XE7IenFEUW tm+RWajEIHCC5XbyAiaoDq4ujk8GBd3ihLLGjOvUUsF/rgYSPXZ4zwy0b4AghEyJRNWI lJJ6ZEYTVmlr6UVOnR7ZuikpK1upypz6jmw7P0gkD5VFyzXWrLxaYztDIOM1qPbV/cIZ vQZ1ayzXNw7+/Cgx5HLk1BdkmRDR+Mg4gSdTOdUmtvwTbn6DdmNHVTjgDBGE7QjNiGZ0 9i3GeXGVejyIHpENh4AGtR5cSnDWkYWXNMO+rO0qT+hoKXQjiuHNS5QCwOihXwB4SwKW cfCA== X-Gm-Message-State: AKaTC03rrW6tEahxPtRnMhLOBmNT88aFksXwFX9y0fvomx8v2WyXbsWpBDrBaWyvEdlN18gg8FeLfYU+kjBj+w== X-Received: by 10.25.23.221 with SMTP id 90mr27068689lfx.34.1481288928997; Fri, 09 Dec 2016 05:08:48 -0800 (PST) MIME-Version: 1.0 From: MehmetErsue Date: Fri, 09 Dec 2016 13:08:37 +0000 Message-ID: To: Ladislav Lhotka , Lou Berger , Netconf , NetMod WG Content-Type: multipart/alternative; boundary=001a114118a06c3c0005433974dd Archived-At: Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 13:08:54 -0000 --001a114118a06c3c0005433974dd Content-Type: text/plain; charset=UTF-8 *[Sorry for reposting. Gmail client seems to add some confusing quotations.]* Hi All, I think the adoption of the DT draft is fine. We agreed in IETF 97 to adopt and finalize the DT draft in NETMOD WG, which I still support. I believe the bigger issue is to agree on a plan concerning the related work and the re-organization of existing standards. As a matter of fact this plan will lead to updating the charter of two WGs and the work we are going to start. I see the DT document as a datastore solution proposal. There are different gaps and issues which still need to be addressed and the solution proposal needs yet to be discussed and finalized. The document is providing information on the history, explaining the need for a generic solution as well as is discussing different scenarios. As such I believe the datastore solution proposal from the DT should be published with the intended status Informational RFC. Based on the finalized and agreed datastore solution we should do different updates to existing documents in NETCONF and NETMOD WGs. With this action we can also fix well-known issues. Concerning the NETCONF WG I would see it as valuable if we develop: - a RFC6241bis draft removing the current datasore concept specification, and getting rid of well-known issues e.g. with the operation, - a new protocol- and language-independent standard document (RFC XYZ) defining the generic datastore concept and framework and describing its use (based on and following the DT solution draft), - adding potential extensions to RFC6241bis (following the DT draft and with a normative reference to RFC XYZ), - adding potential extensions to a RESTCONF-bis RFC (following the DT draft and with a normative reference to RFC XYZ), Concerning the NETMOD WG I would see it as valuable if we develop: - RFC7950bis deleting protocol-dependent details and specifying the datastore usage with YANG on a generic level (with a normative reference to RFC XYZ), - adding potential extensions to RFC7950bis, e.g. concerning the proposed element, - possibly an RFC 6244bis to describe architectural aspects. However RFC6244 is Informational and a RFC6244bis would be still Informational. I'm not sure whether this is really necessary. The DT proposal does already describe such a solution and can be seen as an update to RFC 6244. - RFC6087bis giving guidelines on how to use YANG with the new datastore concept. Referring to Lada's proposal concerning the spin off document from RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be provided in the corresponding protocol RFCs, i.e. for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. Hope this helps as a starting point on the way to a good plan. PS: As Benoit suggested some time ago we might also consider to rename NETCONF WG as it is not only on NETCONF protocol anymore. Regards, Mehmet -- Cheers, Mehmet --001a114118a06c3c0005433974dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[Sorry for reposting. Gmail client seems to add some co= nfusing quotations.]

Hi All,

I think the adopti= on of the DT draft is fine. We agreed in IETF 97 to adopt and finalize the = DT draft in NETMOD WG, which I still support.

I believe the bigger i= ssue is to agree on a plan concerning the related work and the re-organizat= ion of existing standards. As a matter of fact this plan will lead to updat= ing the charter of two WGs and the work we are going to start.
=C2=A0I see the DT document as a datastore solution proposal. There are differen= t gaps and issues which still need to be addressed and the solution proposa= l needs yet to be discussed and finalized. The document is providing inform= ation on the history, explaining the need for a generic solution as well as= is discussing different scenarios. As such I believe the datastore solutio= n proposal from the DT should be published with the intended status Informa= tional RFC.

Based on the finalized and agreed datastore solution we= should do different updates to existing documents in NETCONF and NETMOD WG= s. With this action we can also fix well-known issues.

Concerning th= e NETCONF WG I would see it as valuable if we develop:
- a RFC6241bis dr= aft removing the current datasore concept specification, and getting rid of= well-known issues e.g. with the <get> operation,
- a new protocol= - and language-independent standard document (RFC XYZ) defining the generic= datastore concept and framework and describing its use (based on and follo= wing the DT solution draft),
- adding potential extensions to RFC6241bis= (following the DT draft and with a normative reference to RFC XYZ),
- a= dding potential extensions to a RESTCONF-bis RFC (following the DT draft an= d with a normative reference to RFC XYZ),

Concerning the NETMOD WG I= would see it as valuable if we develop:
- RFC7950bis deleting protocol-= dependent details and specifying the datastore usage with YANG on a generic= level (with a normative reference to RFC XYZ),
- adding potential exten= sions to RFC7950bis, e.g. concerning the proposed <notification> elem= ent,
- possibly an RFC 6244bis to describe architectural aspects. Howeve= r RFC6244 is Informational and a RFC6244bis would be still Informational. I= 'm not sure whether this is really necessary. The DT proposal does alre= ady describe such a solution and can be seen as an update to RFC 6244.
-= RFC6087bis giving guidelines on how to use YANG with the new datastore con= cept.

Referring to Lada's proposal concerning the spin off docum= ent from RFC7950 ("Adapting NETCONF for use with YANG"),
I thi= nk this can be provided in the corresponding protocol RFCs, i.e.
for NET= CONF a section on "Using NETCONF with YANG" in RFC6241bis and for= RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC.

= Hope this helps as a starting point on the way to a good plan.

PS: A= s Benoit suggested some time ago we might also consider to rename NETCONF W= G as it is not only on NETCONF protocol anymore.

Regards,
Mehmet =
--
Cheers,
Mehmet
--001a114118a06c3c0005433974dd-- From nobody Fri Dec 9 07:00:43 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2DC129460 for ; Fri, 9 Dec 2016 07:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pojFNJn7amQw for ; Fri, 9 Dec 2016 07:00:41 -0800 (PST) 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 78A0912944F for ; Fri, 9 Dec 2016 07:00:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1680; q=dns/txt; s=iport; t=1481295640; x=1482505240; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=QNd8ID3GL2BEaoDIQo7Dy/4RCizooKLXwqgymBZxPTI=; b=bAoAfjdOVZxqoJvwCom3LQlXVkhaG5Wld5CRd0vU7nTu15V25qPRexj4 uPirUAKSbamy0QJ3SLJnpQS1ztx9BVT3MkcVPqE5Ej56evqpSanByLDnx aFUUKu407v5RxqwRWl3ya9ncbu0GF7IyhPeoKm4+CdR92ofQ49tbltPgy w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAgASxkpY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgywLAQEBAQGmXJJzgg+CCoYhAoIuEwECAQEBAQEBAWIohGkBBTh?= =?us-ascii?q?RCxguVwYBDAgBAYhnqmaLLAEBAQEBAQEBAgEBAQEBASKGPoF9CIJWiikBBJprk?= =?us-ascii?q?SGKF4YuiiiDY4QOIQIzfhUOhVk+iXABAQE?= X-IronPort-AV: E=Sophos;i="5.33,324,1477958400"; d="scan'208";a="690329341" 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; 09 Dec 2016 15:00:38 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uB9F0c6a022263; Fri, 9 Dec 2016 15:00:38 GMT To: Ladislav Lhotka , netmod@ietf.org References: <40eebd36-0e41-0082-f169-177dc95a537b@transpacket.com> <4c900f1f-7b57-1bb0-1d41-3beec6c03bab@cisco.com> <20161207161336.GB792@elstar.local> <8c3ebda5-9775-8b0c-c569-194cefcd4ae9@cisco.com> <0039E3A0-76D4-4ACB-B35F-2BAEBA962D90@nic.cz> <20161209111636.GA93398@elstar.local> <20161209120651.GA93531@elstar.local> From: Robert Wilton Message-ID: <03ca5365-8640-5019-a9da-802ed248fb0f@cisco.com> Date: Fri, 9 Dec 2016 15:00:38 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161209120651.GA93531@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 15:00:42 -0000 On 09/12/2016 12:06, Juergen Schoenwaelder wrote: > On Fri, Dec 09, 2016 at 11:25:35AM +0000, Robert Wilton wrote: >> Even if they don't break, debug and diagnostics information can be very >> verbose. >> >> If a client had 4 connections to a device for monitoring different things, >> then you don't want to suddenly start sending a large amount of extra >> diagnostics data on each of the 4 connections when they have only requested >> it on one connection. Generating this extra data could overload the client >> or the device, or certainly lead to degraded performance in some way or >> another. >> > Then the client probably should have used a proper filter. Augments > are a key feature of YANG. A client not interested in any additional > data should not (implicitely) ask for it. (It does not matter whether > the additional data is debugging or other information; if you do not > need it, do not as for it if you want to be robust.) Given that an augmentation could be on any container, then I think that this ends up that every get request needs a potentially complex subtree filter to exclude diagnostics information that they wouldn't really expect to be returned in the first place. Further, if the diagnostics information was controlled by a debug leaf then they probably won't ever see this problem during testing, only when someone needs to get diagnostics information for an Ethernet interface on a production system would the extra data start showing up. To me, this seems to be making YANG models easier for the 0.01% of client request at the expense of the 99.99% of client requests. Thanks, Rob > > /js > From nobody Fri Dec 9 07:17:18 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1E2129454 for ; Fri, 9 Dec 2016 07:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 fThw62REiWUQ for ; Fri, 9 Dec 2016 07:17:13 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 37ECA129444 for ; Fri, 9 Dec 2016 07:17:13 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 7B9231AE02BC; Fri, 9 Dec 2016 16:17:12 +0100 (CET) Date: Fri, 09 Dec 2016 16:17:12 +0100 (CET) Message-Id: <20161209.161712.2008691146816809010.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <03ca5365-8640-5019-a9da-802ed248fb0f@cisco.com> References: <20161209120651.GA93531@elstar.local> <03ca5365-8640-5019-a9da-802ed248fb0f@cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 15:17:15 -0000 Robert Wilton wrote: > > > On 09/12/2016 12:06, Juergen Schoenwaelder wrote: > > On Fri, Dec 09, 2016 at 11:25:35AM +0000, Robert Wilton wrote: > >> Even if they don't break, debug and diagnostics information can be > >> very > >> verbose. > >> > >> If a client had 4 connections to a device for monitoring different > >> things, > >> then you don't want to suddenly start sending a large amount of extra > >> diagnostics data on each of the 4 connections when they have only > >> requested > >> it on one connection. Generating this extra data could overload the > >> client > >> or the device, or certainly lead to degraded performance in some way > >> or > >> another. > >> > > Then the client probably should have used a proper filter. Augments > > are a key feature of YANG. A client not interested in any additional > > data should not (implicitely) ask for it. (It does not matter whether > > the additional data is debugging or other information; if you do not > > need it, do not as for it if you want to be robust.) > Given that an augmentation could be on any container, then I think > that this ends up that every get request needs a potentially complex > subtree filter to exclude diagnostics information that they wouldn't > really expect to be returned in the first place. Further, if the > diagnostics information was controlled by a debug leaf then they > probably won't ever see this problem during testing, only when someone > needs to get diagnostics information for an Ethernet interface on a > production system would the extra data start showing up. > > To me, this seems to be making YANG models easier for the 0.01% of > client request at the expense of the 99.99% of client requests. The problem is that it is a slippery slope. Anyone that designs a data model might think that some data probably not is interesting to all clients, in all cases, so they might just create special RPCs instead of modelling it as config false data. It would be better to model it as config false and work on the protocol to have better filters (like Andy's recently proposed "topic-filter" maybe). /martin From nobody Fri Dec 9 08:20:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E0912711D for ; Fri, 9 Dec 2016 08:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yx4xEYw8PlUO for ; Fri, 9 Dec 2016 08:20:21 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id A8D78129485 for ; Fri, 9 Dec 2016 08:20:21 -0800 (PST) Received: (qmail 31266 invoked by uid 0); 9 Dec 2016 16:20:20 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy10.mail.unifiedlayer.com with SMTP; 9 Dec 2016 16:20:20 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id HsLH1u00K2SSUrH01sLLkd; Fri, 09 Dec 2016 09:20:20 -0700 X-Authority-Analysis: v=2.1 cv=Zpp+dbLG c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=n5n_aSjo0skA:10 a=48vgC7mUAAAA:8 a=kXw8R9zY3SWsAKOfvxgA:9 a=QEXdDO2ut3YA:10 a=RQkQ1X75V3IA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Cc:To:Subject:From; bh=XyPT9x79H6dtpP8WhGmwDVs8hrR4Lqj3ljQnxypmiYc=; b=nxLIVQRn5k84YZOfCYdj9dqVbN NFXa3AFVEyST4E/zDpZ4wcMkix4GFGrDb1KfQOAyhDzljjpgfjOKnmTkFELevfBJhAikQ3XH3rZZV xJRMOaymlso26z9Cg9zulnKR9; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:35639 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1cFNuD-0000tB-5N; Fri, 09 Dec 2016 09:20:17 -0700 From: Lou Berger To: NetMod WG Message-ID: Date: Fri, 9 Dec 2016 11:20:15 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cFNuD-0000tB-5N X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:35639 X-Source-Auth: lberger@labn.net X-Email-Count: 5 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: NetMod WG Chairs Subject: [netmod] IETF97 minutes posted X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 16:20:27 -0000 All, Thanks to Michael (Zitao Wang) and other note takers, we have posted minutes. Please review and comment: Latest rev is in etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-97-netmod *if* you make changes, please discuss them on the list as only discussed changes will be upload to be part of the final meeting record. Thank you, Lou and Kent (and Michael) From nobody Fri Dec 9 10:10:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2FF129665 for ; Fri, 9 Dec 2016 10:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qh9xUPusBX6p for ; Fri, 9 Dec 2016 10:10:37 -0800 (PST) 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 127E6129524 for ; Fri, 9 Dec 2016 10:10:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4300; q=dns/txt; s=iport; t=1481307036; x=1482516636; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=g47UiCv46v7cIJ29AZWcFoUhkoIo2Zr85vZzUh/Wz4w=; b=loCPtm6rjStyxn/li2iBF+hAmoEUNopr1XEHJDwuHdd59ovA8wNtfYvp cTF0V4LORcnVjOf2GaBtoHADqI3ooVp+rjwHqTw7YFCIkq+QWUDKOq2rB DKIpB6y+T8GqmYTMd5GJRinDknmHSY3CrvXmzMtMFK75onoB4yASpAKGq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AAAY80pY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAYF/jUmXE5Jzgg+CCoYhAoIsFAECAQEBAQEBAWIohGk?= =?us-ascii?q?BBThBEAsOCi5XBg0GAgEBiGeobA6DSIsqAQEBAQEBAQEBAQEBAQEBAQEBAQEBH?= =?us-ascii?q?YY+gX2CXoopAQSaa5EhiheGLooog2OEDh83fhUOhVk+NIk8AQEB?= X-IronPort-AV: E=Sophos;i="5.33,324,1477958400"; d="scan'208";a="647772262" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Dec 2016 18:10:33 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uB9IAXv8006133; Fri, 9 Dec 2016 18:10:33 GMT To: Martin Bjorklund References: <20161209120651.GA93531@elstar.local> <03ca5365-8640-5019-a9da-802ed248fb0f@cisco.com> <20161209.161712.2008691146816809010.mbj@tail-f.com> From: Robert Wilton Message-ID: Date: Fri, 9 Dec 2016 18:10:35 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161209.161712.2008691146816809010.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 18:10:42 -0000 On 09/12/2016 15:17, Martin Bjorklund wrote: > Robert Wilton wrote: >> >> On 09/12/2016 12:06, Juergen Schoenwaelder wrote: >>> On Fri, Dec 09, 2016 at 11:25:35AM +0000, Robert Wilton wrote: >>>> Even if they don't break, debug and diagnostics information can be >>>> very >>>> verbose. >>>> >>>> If a client had 4 connections to a device for monitoring different >>>> things, >>>> then you don't want to suddenly start sending a large amount of extra >>>> diagnostics data on each of the 4 connections when they have only >>>> requested >>>> it on one connection. Generating this extra data could overload the >>>> client >>>> or the device, or certainly lead to degraded performance in some way >>>> or >>>> another. >>>> >>> Then the client probably should have used a proper filter. Augments >>> are a key feature of YANG. A client not interested in any additional >>> data should not (implicitely) ask for it. (It does not matter whether >>> the additional data is debugging or other information; if you do not >>> need it, do not as for it if you want to be robust.) >> Given that an augmentation could be on any container, then I think >> that this ends up that every get request needs a potentially complex >> subtree filter to exclude diagnostics information that they wouldn't >> really expect to be returned in the first place. Further, if the >> diagnostics information was controlled by a debug leaf then they >> probably won't ever see this problem during testing, only when someone >> needs to get diagnostics information for an Ethernet interface on a >> production system would the extra data start showing up. >> >> To me, this seems to be making YANG models easier for the 0.01% of >> client request at the expense of the 99.99% of client requests. > The problem is that it is a slippery slope. Anyone that designs a > data model might think that some data probably not is interesting to > all clients, in all cases, so they might just create special RPCs > instead of modelling it as config false data. I would say that a clear separation is fairly easy to define, and the industry has managed to do this fairly well for the last few decades: - If the information is necessary to manage or monitor a device then it should be included in opstate. - if the information is only required for an engineer to diagnose why the device isn't working to the specification then it isn't part of the opstate. There are lots of examples of this: 1) a simple car analogy: - my car dashboard gives me the useful information that I need to safely drive the car, and to monitor that the car is behaving as designed. - if the car stops working properly (perhaps it signals a fault on the dashboard), then I take it to garage, they connect it to a computer, download and analyze the diagnostics to figure out what is wrong (normally at large expense). - as a user of the car, I do not want to see all of that internal diagnostics information on the dashboard all the time. It would obscure the information that is actually important, and I probably wouldn't understand what it all means anyway. 2) My alarm system at home has a "User mode" and "Engineer mode", the information presented in each mode differs. I think that this sort of example can probably be repeated for nearly all of the consumer electronics that I own. 3) The same is for network devices: As a operator of an Ethernet interface, I care: - whether the port is up and able to forward packets, or it is down. - if it is down, whether it is something that I can diagnose and fix (e.g. config error, dirty cable, missing PHY). But I don't personally want to know whether the "PHY XS provides information on transmit path data delay in registers 4.1801 through 4.1804" or whether "PHY XGXS is able to generate test patterns". However, an engineer might find this information useful to diagnose why the Ethernet port isn't working the way that it should. I think that there is a clear split in the intent of this information, and what audience the information is targeted to. I can't see how always lumping these two discrete sets of data together really helps anyone. Thanks, Rob From nobody Fri Dec 9 10:50:21 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75845129514 for ; Fri, 9 Dec 2016 10:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LPekd3051Qm for ; Fri, 9 Dec 2016 10:50:16 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 B00EF129513 for ; Fri, 9 Dec 2016 10:50:15 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id c47so24341691qtc.2 for ; Fri, 09 Dec 2016 10:50:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H+QRbanMhTl8tWFylYv5uFaGTnEZ5Yv0ApblSp8Gpww=; b=kONsH4/+ED0o8xcxYV5pBhikD29lAhKheF5+LbqXWmxbbYHhAL8a/tLQNDH0RNdX0D KurUGXpaMq6hDHFZE1iLNkm/O4xt/CyJMjsC+F0nN4OQIlF06vmO/QZ/34QEbcXGTWcX oxErptAUfiKXKgZef+R3s7gKbvWQBKrdMagnKHs4/5CQ0G27gvwybAzsM27NPzZPvh+O BEG9HnTIWrQxZFWV72I9VdMCYo9PN1cDVlEONfYqXbrvBqzlo1hrTFcHLN4mw9twY9tT +Eb0Torq8i2LeW+91trJwrBjRXCext1d8sMmlJNb7eOxUzTzBsk+cwf3eQ1gbC20XCCT vVUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=H+QRbanMhTl8tWFylYv5uFaGTnEZ5Yv0ApblSp8Gpww=; b=kUy0ILe8RBmWMs55voCSOC0gvR1BFeP6vSOiy+SkqeEwi80yYeZvFE+mvSb92fbx+Z z3c+d7x/CY5lg7/vwhF+cS7MDgf26LHAhrEu/TVqAuxwQ6rOTqJD5GRvVzFRekgPG+19 Jc8Yw9MXSCcLh6MPTkNm1fNvnSOCg3O3PSssOcjglfT8MCJrVN842irABlHUEn6nekQb Zkl5uQV+7JkTAJVmPIOkzruxjaaNC9nLhgX17qNkwA5YjQYlNZbYXI7xsBjEf5a7UfvK xUFNj5t87NIC1QtIWnk1pe9N3WJzbiueAQXtRepjabquipAjnp9WCuIKz62887MEt0rj j5Iw== X-Gm-Message-State: AKaTC03/I245QyxMZoUGVYloLWeekZSSITSRT7eDnHafVLEwj8je5OpREroBZfPkJu+GsbtAjwdDEYtdTCu+Mg== X-Received: by 10.200.50.97 with SMTP id y30mr72429046qta.203.1481309414784; Fri, 09 Dec 2016 10:50:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Fri, 9 Dec 2016 10:50:13 -0800 (PST) In-Reply-To: References: <20161209120651.GA93531@elstar.local> <03ca5365-8640-5019-a9da-802ed248fb0f@cisco.com> <20161209.161712.2008691146816809010.mbj@tail-f.com> From: Andy Bierman Date: Fri, 9 Dec 2016 10:50:13 -0800 Message-ID: To: Robert Wilton Content-Type: multipart/alternative; boundary=001a1140607478973905433e3930 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 18:50:19 -0000 --001a1140607478973905433e3930 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 9, 2016 at 10:10 AM, Robert Wilton wrote: > > > On 09/12/2016 15:17, Martin Bjorklund wrote: > >> Robert Wilton wrote: >> >>> >>> On 09/12/2016 12:06, Juergen Schoenwaelder wrote: >>> >>>> On Fri, Dec 09, 2016 at 11:25:35AM +0000, Robert Wilton wrote: >>>> >>>>> Even if they don't break, debug and diagnostics information can be >>>>> very >>>>> verbose. >>>>> >>>>> If a client had 4 connections to a device for monitoring different >>>>> things, >>>>> then you don't want to suddenly start sending a large amount of extra >>>>> diagnostics data on each of the 4 connections when they have only >>>>> requested >>>>> it on one connection. Generating this extra data could overload the >>>>> client >>>>> or the device, or certainly lead to degraded performance in some way >>>>> or >>>>> another. >>>>> >>>>> Then the client probably should have used a proper filter. Augments >>>> are a key feature of YANG. A client not interested in any additional >>>> data should not (implicitely) ask for it. (It does not matter whether >>>> the additional data is debugging or other information; if you do not >>>> need it, do not as for it if you want to be robust.) >>>> >>> Given that an augmentation could be on any container, then I think >>> that this ends up that every get request needs a potentially complex >>> subtree filter to exclude diagnostics information that they wouldn't >>> really expect to be returned in the first place. Further, if the >>> diagnostics information was controlled by a debug leaf then they >>> probably won't ever see this problem during testing, only when someone >>> needs to get diagnostics information for an Ethernet interface on a >>> production system would the extra data start showing up. >>> >>> To me, this seems to be making YANG models easier for the 0.01% of >>> client request at the expense of the 99.99% of client requests. >>> >> The problem is that it is a slippery slope. Anyone that designs a >> data model might think that some data probably not is interesting to >> all clients, in all cases, so they might just create special RPCs >> instead of modelling it as config false data. >> > I would say that a clear separation is fairly easy to define, and the > industry has managed to do this fairly well for the last few decades: > - If the information is necessary to manage or monitor a device then it > should be included in opstate. > - if the information is only required for an engineer to diagnose why the > device isn't working to the specification then it isn't part of the opstate. > > There are lots of examples of this: > 1) a simple car analogy: > - my car dashboard gives me the useful information that I need to safely > drive the car, and to monitor that the car is behaving as designed. > - if the car stops working properly (perhaps it signals a fault on the > dashboard), then I take it to garage, they connect it to a computer, > download and analyze the diagnostics to figure out what is wrong (normally > at large expense). > - as a user of the car, I do not want to see all of that internal > diagnostics information on the dashboard all the time. It would obscure > the information that is actually important, and I probably wouldn't > understand what it all means anyway. > > 2) My alarm system at home has a "User mode" and "Engineer mode", the > information presented in each mode differs. I think that this sort of > example can probably be repeated for nearly all of the consumer electronics > that I own. > > 3) The same is for network devices: > As a operator of an Ethernet interface, I care: > - whether the port is up and able to forward packets, or it is down. > - if it is down, whether it is something that I can diagnose and fix > (e.g. config error, dirty cable, missing PHY). > But I don't personally want to know whether the "PHY XS provides > information on transmit path data > delay in registers 4.1801 through 4.1804" or whether "PHY XGXS is able to > generate test patterns". However, an engineer might find this information > useful to diagnose why the Ethernet port isn't working the way that it > should. > > I think that there is a clear split in the intent of this information, and > what audience the information is targeted to. > > I can't see how always lumping these two discrete sets of data together > really helps anyone. > > Why can't you use a when-stmt? system ... // config false // when "/top/diag-mode = 'system'" Thanks, > Rob > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1140607478973905433e3930 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Dec 9, 2016 at 10:10 AM, Robert Wilton <rwilton@cisco.com&= gt; wrote:


On 09/12/2016 15:17, Martin Bjorklund wrote:
Robert Wilton <rw= ilton@cisco.com> wrote:

On 09/12/2016 12:06, Juergen Schoenwaelder wrote:
On Fri, Dec 09, 2016 at 11:25:35AM +0000, Robert Wilton wrote:
Even if they don't break, debug and diagnostics information can be
very
verbose.

If a client had 4 connections to a device for monitoring different
things,
then you don't want to suddenly start sending a large amount of extra diagnostics data on each of the 4 connections when they have only
requested
it on one connection.=C2=A0 Generating this extra data could overload the client
or the device, or certainly lead to degraded performance in some way
or
another.

Then the client probably should have used a proper filter. Augments
are a key feature of YANG. A client not interested in any additional
data should not (implicitely) ask for it. (It does not matter whether
the additional data is debugging or other information; if you do not
need it, do not as for it if you want to be robust.)
Given that an augmentation could be on any container, then I think
that this ends up that every get request needs a potentially complex
subtree filter to exclude diagnostics information that they wouldn't really expect to be returned in the first place.=C2=A0 Further, if the
diagnostics information was controlled by a debug leaf then they
probably won't ever see this problem during testing, only when someone<= br> needs to get diagnostics information for an Ethernet interface on a
production system would the extra data start showing up.

To me, this seems to be making YANG models easier for the 0.01% of
client request at the expense of the 99.99% of client requests.
The problem is that it is a slippery slope.=C2=A0 Anyone that designs a
data model might think that some data probably not is interesting to
all clients, in all cases, so they might just create special RPCs
instead of modelling it as config false data.
I would say that a clear separation is fairly easy to define, and the indus= try has managed to do this fairly well for the last few decades:
- If the information is necessary to manage or monitor a device then it sho= uld be included in opstate.
- if the information is only required for an engineer to diagnose why the d= evice isn't working to the specification then it isn't part of the = opstate.

There are lots of examples of this:
=C2=A01) a simple car analogy:
=C2=A0- my car dashboard gives me the useful information that I need to saf= ely drive the car, and to monitor that the car is behaving as designed.
=C2=A0- if the car stops working properly (perhaps it signals a fault on th= e dashboard), then I take it to garage, they connect it to a computer, down= load and analyze the diagnostics to figure out what is wrong (normally at l= arge expense).
=C2=A0- as a user of the car, I do not want to see all of that internal dia= gnostics information on the dashboard all the time.=C2=A0 It would obscure = the information that is actually important, and I probably wouldn't und= erstand what it all means anyway.

2) My alarm system at home has a "User mode" and "Engineer m= ode", the information presented in each mode differs.=C2=A0 I think th= at this sort of example can probably be repeated for nearly all of the cons= umer electronics that I own.

3) The same is for network devices:
As a operator of an Ethernet interface, I care:
=C2=A0- whether the port is up and able to forward packets, or it is down.<= br> =C2=A0- if it is down, whether it is something that I can diagnose and fix = (e.g. config error, dirty cable, missing PHY).
But I don't personally want to know whether the "PHY XS provides i= nformation on transmit path data
delay in registers 4.1801 through 4.1804" or whether "PHY XGXS is= able to generate test patterns".=C2=A0 However, an engineer might fin= d this information useful to diagnose why the Ethernet port isn't worki= ng the way that it should.

I think that there is a clear split in the intent of this information, and = what audience the information is targeted to.

I can't see how always lumping these two discrete sets of data together= really helps anyone.



Why can't you use a= when-stmt?

=C2=A0<top>
=C2=A0 =C2= =A0 =C2=A0<diag-mode>system</diag-mode>
=C2=A0 =C2=A0= =C2=A0<service>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <diag-stats>
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // config false
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 // =C2=A0when =C2=A0"/top/diag-mode =3D '= system'"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </diag-stats>=
=C2=A0 =C2=A0 =C2=A0</service>
=C2=A0</top>= ;


Thanks,
Rob


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

--001a1140607478973905433e3930-- From nobody Fri Dec 9 13:02:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5555D129543 for ; Fri, 9 Dec 2016 13:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYogjrkE-hDY for ; Fri, 9 Dec 2016 13:02:26 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0105.outbound.protection.outlook.com [104.47.32.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA38129456 for ; Fri, 9 Dec 2016 13:02:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FHHHHmHOPm8a9NYeTI4lv0XeNhoOvO9s15xTdP/4Unc=; b=CJhiLk1KzMdfWiIpxdlFZQL8vMA5w8BR8J6jmtVSI0s7K1za6amx/PzYE6k6AQO9HrYySQ1tlkoRXhbalXNZR92Rf0Ezn+k3URq2iH9OpunhNNcWsJQ8xSyFJDAzMe1NkIkkaEzUmcMp/l7YG/g31qD48ZStKG13DfXol6Wde5Q= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.4; Fri, 9 Dec 2016 21:02:25 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0771.011; Fri, 9 Dec 2016 21:02:25 +0000 From: Kent Watsen To: Andy Bierman , Robert Wilton Thread-Topic: [netmod] Modelling different "levels" of data in YANG Thread-Index: AQHSTyLtAX7o6QMy50mp3fLqeP2npKD7BFBDgABltYCAARPHAIAAEzkAgAAabwCAAa0JgIABGL2AgAAEIQCAAAGPAIAAAzOAgAADBQCAAAKDgIAAC4qAgAAwiwCAAAShAIAAMHKAgAALEoD//9EdAA== Date: Fri, 9 Dec 2016 21:02:24 +0000 Message-ID: References: <20161209120651.GA93531@elstar.local> <03ca5365-8640-5019-a9da-802ed248fb0f@cisco.com> <20161209.161712.2008691146816809010.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1c.1.161117 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: d172b70b-6b08-430d-dc9b-08d42076ad50 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1443; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:0spILs1FAuiOfxqOvM9p/d0Qq0JNJjMs2j2nnRIQyWUwuiBeys+P2ApVX5R00uKcVDi7CjbVrJSsSruDVlj69qqsBlVEHd6l2wC6UHZrU6O1UmSty9m9aYDXGRt2OpET8dI/7HBB2Rxg5S0lv7gnDPqLbfVxWbuuVlJSz1WAU8BbUy5vCf63wgBTMOPgi+WGD56ygtj32dcJqSgspn0BFBYD3ktRvXittg3NVMA5zy74r0IcKM05oMyd+DqaCW5E//vXqgFs5nJKGVF6NW2hI9b5MCOUiDF4dEwFB4lVKIkYgnSYeWSCtjbPkWhn8RzIr6rjIxctgh06mxA6VIfBbJE4iFoOobZN2hvH8UOB4nSjgaPxidq3kKmg01NDgas8iXe9ApZLeOZA6jhqYz7G9+WmOsP5+Ui1IbcqDNQ5Z3nZUxDiXvoavdbxnnnqxdQMluW98nTjg2x5WbREYQxQuA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 015114592F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39410400002)(39450400003)(39860400002)(39850400002)(199003)(189002)(6506006)(81156014)(6436002)(102836003)(83716003)(2900100001)(86362001)(38730400001)(92566002)(77096006)(6486002)(8936002)(83506001)(5001770100001)(97736004)(6512006)(8676002)(81166006)(93886004)(68736007)(189998001)(4001350100001)(229853002)(82746002)(7736002)(105586002)(3280700002)(3660700001)(50986999)(76176999)(66066001)(6116002)(5660300001)(122556002)(2906002)(2950100002)(101416001)(33656002)(3846002)(106356001)(99286002)(4326007)(54356999)(106116001)(36756003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D11AA63CE385450899AF88E1AB676575junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2016 21:02:24.9868 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 21:02:29 -0000 --_000_D11AA63CE385450899AF88E1AB676575junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCj4gV2h5IGNhbid0IHlvdSB1c2UgYSB3aGVuLXN0bXQ/DQo+DQo+IDx0b3A+DQo+ICAgICA8 ZGlhZy1tb2RlPnN5c3RlbTwvZGlhZy1tb2RlPg0KPiAgICAgPHNlcnZpY2U+DQo+ICAgICAgICAg Li4uDQo+ICAgICAgICA8ZGlhZy1zdGF0cz4NCj4gICAgICAgICAgICAvLyBjb25maWcgZmFsc2UN Cj4gICAgICAgICAgICAvLyAgd2hlbiAgIi90b3AvZGlhZy1tb2RlID0gJ3N5c3RlbSciDQo+ICAg ICAgICA8L2RpYWctc3RhdHM+DQo+ICAgICA8L3NlcnZpY2U+DQo+IDwvdG9wPg0KDQoNCkNhbiB3 ZSBoYXZlIGEgc29sdXRpb24gdGhhdCBpcyBzZXNzaW9uLW9yaWVudGVkLCBsaWtlIHdpdGgtZGVm YXVsdHM/ICAgTWF5YmUgdGhlIOKAmHdoZW7igJkgZXhwcmVzc2lvbuKAmXMgY29udGV4dCBjb3Vs ZCBiZSBleHRlbmRlZCB0byB0aGUgY2xpZW504oCZcyByZXF1ZXN0LCBvciBvdGhlcndpc2UgYmUg dHJpZ2dlcmVkIGJ5IHNvbWV0aGluZyBpbiB0aGUgcmVxdWVzdD8NCg0KS2VudCAvLyBhcyBhIGNv bnRyaWJ1dG9yDQoNCg0K --_000_D11AA63CE385450899AF88E1AB676575junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <184227F9934AAD40B59CA3FBCD2CD84C@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJZm9udC12YXJpYW50Om5vcm1hbCAhaW1wb3J0YW50Ow0KCWNvbG9yOndpbmRvd3Rl eHQ7DQoJdGV4dC10cmFuc2Zvcm06bm9uZTsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lOw0K CXZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZn dDsgV2h5IGNhbid0IHlvdSB1c2UgYSB3aGVuLXN0bXQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7Jmx0O3RvcCZndDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtkaWFnLW1vZGUmZ3Q7c3lzdGVtJmx0Oy9kaWFnLW1vZGUm Z3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7c2VydmljZSZndDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Li4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtkaWFnLXN0 YXRzJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC8vIGNvbmZp ZyBmYWxzZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC8vICZuYnNw O3doZW4gJm5ic3A7JnF1b3Q7L3RvcC9kaWFnLW1vZGUgPSAnc3lzdGVtJyZxdW90OzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7L2RpYWctc3RhdHMmZ3Q7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsmbHQ7L3NlcnZpY2UmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7Jmx0Oy90b3AmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DYW4gd2UgaGF2ZSBhIHNvbHV0aW9uIHRoYXQg aXMgc2Vzc2lvbi1vcmllbnRlZCwgbGlrZSB3aXRoLWRlZmF1bHRzPyZuYnNwOyZuYnNwOyBNYXli ZSB0aGUg4oCYd2hlbuKAmSBleHByZXNzaW9u4oCZcyBjb250ZXh0IGNvdWxkIGJlIGV4dGVuZGVk IHRvIHRoZSBjbGllbnTigJlzIHJlcXVlc3QsIG9yIG90aGVyd2lzZSBiZSB0cmlnZ2VyZWQgYnkg c29tZXRoaW5nIGluIHRoZSByZXF1ZXN0PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LZW50IC8v IGFzIGEgY29udHJpYnV0b3I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D11AA63CE385450899AF88E1AB676575junipernet_-- From nobody Fri Dec 9 13:30:59 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A745129588 for ; Fri, 9 Dec 2016 13:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6azdx6CX7VQ for ; Fri, 9 Dec 2016 13:30:50 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41893129581 for ; Fri, 9 Dec 2016 13:30:50 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id w33so28069984qtc.3 for ; Fri, 09 Dec 2016 13:30:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=66/k+o1/qtXs0wgz1j7nId+p6c/o8bnK6uvNKRg6p6g=; b=Fml0xsa7ttrd+6gyLUKWoxh1k3MVZ9MLnoWyM2jG9731nfQLpn4Jzv/GCvnu8mw5+4 lKTV5mJATg1yl9kgnz2ytg/r7neenYuADo47yEZQA4VrCnUNSrdGaYqmlYjyz+iHferW OqKJMiDhW78RnVVQeAVehGgvY+LFONQSGcS2y/jlNp8UvzeLkZA1N/LNr73g2zL+LnRz 4QStfjTHyL6RMFzHhvbpN9T4PDevFb3pTxgdCwQoF1qQIuyyhyFt7rF0nYXlq7uIcmih cZnB0TY+7CBcezn6chmKr46P5iAUd0mGJfNYyBto+RGQBasg7JFG4BwL3BdniClcBDKi hURw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=66/k+o1/qtXs0wgz1j7nId+p6c/o8bnK6uvNKRg6p6g=; b=X3bmVRh5KVjE97cgFvbOYF/hGyNYILwYzAv9DnzqKeYsjnZso4mf8d4WeZ/OKrprMy MjU0bC+qZwM2D21m+Fld8IV5BMouw1aoqGZAxRAvZYN1vguBzdGtCcfUbWs0VvF5jPqk 7W8iTgDnZ4iA8dlt51mJxhVOAdbhiH4yF5YMsZpttKmw/pEVH4H63P26KcG0EBBckFxO 20bU+usHF2+VY/ZmM9rKRhJDlLsjCVzy2cc8cn8JsmmfCizv7b1USiMBplIzw4HXE6ab fiF7foMnxZyIlhzcg3c1nIc193zaJXutR0rCQD85YkQvsI59Ew50c8S4s+1MUh+9N+uM kh4A== X-Gm-Message-State: AKaTC02DLqJIqh22v6Thcco48os0YSTaY/zBGbllaDuXFldCHDGSfYHI843td3F0WfRgkuScfSq8HjqNFPejkw== X-Received: by 10.200.41.171 with SMTP id 40mr79178672qts.235.1481319049407; Fri, 09 Dec 2016 13:30:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Fri, 9 Dec 2016 13:30:48 -0800 (PST) In-Reply-To: References: <20161209120651.GA93531@elstar.local> <03ca5365-8640-5019-a9da-802ed248fb0f@cisco.com> <20161209.161712.2008691146816809010.mbj@tail-f.com> From: Andy Bierman Date: Fri, 9 Dec 2016 13:30:48 -0800 Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary=001a11406578bd449705434077d1 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 21:30:57 -0000 --001a11406578bd449705434077d1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 9, 2016 at 1:02 PM, Kent Watsen wrote: > > > > > > Why can't you use a when-stmt? > > > > > > > > > system > > > > > > ... > > > > > > // config false > > > // when "/top/diag-mode =3D 'system'" > > > > > > > > > > > > > > > Can we have a solution that is session-oriented, like with-defaults? > Maybe the =E2=80=98when=E2=80=99 expression=E2=80=99s context could be ex= tended to the client=E2=80=99s > request, or otherwise be triggered by something in the request? > > > I prefer not to use specialized operations. In the usage model that Rob described, the service tech will be setting diag-mode to 'system' then retrieving the extra 'diag-stats', then setting diag-mode back to 'user'. NACM is only needed on the leaf /top/diag-mode to prevent users from setting it to system mode. Kent // as a contributor > Andy > > > > --001a11406578bd449705434077d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Dec 9, 2016 at 1:02 PM, Kent Watsen <kwatsen@juniper.net= > wrote:

=C2=A0

=C2=A0

> Why can't you use a when-stmt?

>=C2=A0

>=C2=A0<top>

>=C2=A0 =C2=A0 =C2=A0<diag-mode>system</= diag-mode>

>=C2=A0 =C2=A0 =C2=A0<service>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...<= /u>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <diag-stats>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // con= fig false

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // =C2= =A0when =C2=A0"/top/diag-mode =3D 'system'"=

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </diag-stats><= u>

>=C2=A0 =C2=A0 =C2=A0</service>

>=C2=A0</top>

=C2=A0

=C2=A0

Can we have a solution that is session-oriented, lik= e with-defaults?=C2=A0=C2=A0 Maybe the =E2=80=98when=E2=80=99 expression=E2= =80=99s context could be extended to the client=E2=80=99s request, or other= wise be triggered by something in the request?

=C2=A0


<= /div>
I prefer not to use specialized <get-foo> operations.
=
In the usage model that Rob described, the service tech will be
<= div>setting diag-mode to 'system' =C2=A0then retrieving the extra &= #39;diag-stats',
then setting diag-mode back to 'user'= ;.

NACM is only needed on the leaf /top/diag-mode = to prevent users from
setting it to =C2=A0system mode.
=

Kent // as a contributor


Andy
=C2=A0

=C2=A0

=C2=A0


--001a11406578bd449705434077d1-- From nobody Fri Dec 9 16:59:13 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB891295B6 for ; Fri, 9 Dec 2016 16:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnBLOqiZkqOj for ; Fri, 9 Dec 2016 16:59:10 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0129.outbound.protection.outlook.com [104.47.40.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1187C1295B3 for ; Fri, 9 Dec 2016 16:59:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IbJkLpfqRNXAVa+wDwmurB2ghZnXTyOKdtLATByCxkA=; b=Byr0ByqN9fakFI0vcroYtaTouriBn9tS6nqqDimAMLaw2BNsC4iGnyIqnPbbhncN+k/0zoasiEh4E1A0/WXWAHqoO4nGscRWxn1bUW3OK0lgALSFy146hLwHF4URe21w0hep0v5eu8bDm1pE1UaXu+rr7HWgKp+0/UaG3le1jN0= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1451.namprd05.prod.outlook.com (10.160.149.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.4; Sat, 10 Dec 2016 00:59:08 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0771.010; Sat, 10 Dec 2016 00:59:08 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [netmod] Modelling different "levels" of data in YANG Thread-Index: AQHSTyLtAX7o6QMy50mp3fLqeP2npKD7BFBDgABltYCAARPHAIAAEzkAgAAabwCAAa0JgIABGL2AgAAEIQCAAAGPAIAAAzOAgAADBQCAAAKDgIAAC4qAgAAwiwCAAAShAIAAMHKAgAALEoD//9EdAIAAW8EA///mY4A= Date: Sat, 10 Dec 2016 00:59:08 +0000 Message-ID: <541638F1-53CC-4656-B0A1-3BE650F3DB3B@juniper.net> References: <20161209120651.GA93531@elstar.local> <03ca5365-8640-5019-a9da-802ed248fb0f@cisco.com> <20161209.161712.2008691146816809010.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1c.1.161117 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: 309fdc80-d2dc-452a-9cd6-08d42097bf46 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0501MB1451; x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1451; 7:bISnUs6bwJiWlu5DQmeQZlcVa9byd4826eZYr32OgbGLZ1NwLdSkiGQ8PGykyYAM7fRZe2FmMFgaVR0EIgQYLmwrr2oKd6YwBHaxo3vBeJjtT6hQ1T0TtM6kTy1MqGE/st4z0COyiG3LI9pswvUU68BbFkZP2YwcOOgiBjtKQVJ7FIC+2P0ObNX/PxyfEMteiQf1K2xlqKZDYK45YrMiq+bbGX4RAr4oHB34e28HHPGCYaVDQMI2UCDLhdq1guEUVxCi8ckVArZvKJqqHXpCA2g8bXDLOlqUb5FogWTrkOAD4p3tUrNxocGBHbJo9d/9/QHZI+UT7j9IA8L9yYezTjlBm5AxBz00PFEwuDm/XImzzq0FebM79pvQxj4PRPrTqQIeDrns2Zq1prCzsa9fEdqD7YSMkUKM1HkOnudKglOxXez2MgAK63+UB0Jw9zdKKr/ZyMDURTlL9M4S8deDsQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:CY1PR0501MB1451; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1451; x-forefront-prvs: 0152EBA40F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39410400002)(39450400003)(39860400002)(39850400002)(199003)(189002)(86362001)(122556002)(8936002)(106356001)(15395725005)(7736002)(68736007)(189998001)(97736004)(4001350100001)(54356999)(3846002)(50986999)(76176999)(102836003)(36756003)(6116002)(2906002)(4326007)(33656002)(2900100001)(83506001)(92566002)(77096006)(3280700002)(3660700001)(2950100002)(6512006)(6506006)(99286002)(110136003)(6436002)(82746002)(6916009)(38730400001)(83716003)(66066001)(81156014)(229853002)(6486002)(101416001)(105586002)(5660300001)(93886004)(8676002)(81166006)(106116001)(104396002)(562404015); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1451; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_541638F153CC4656B0A13BE650F3DB3Bjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2016 00:59:08.5137 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1451 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 00:59:12 -0000 --_000_541638F153CC4656B0A13BE650F3DB3Bjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQo+IEkgcHJlZmVyIG5vdCB0byB1c2Ugc3BlY2lhbGl6ZWQgPGdldC1mb28+IG9wZXJhdGlvbnMu DQoNCkFncmVlZCwgSSB3YXMgdGhpbmtpbmcgc29tZXRoaW5nIG1vcmUgYWxvbmcgdGhlIGxpbmVz IG9mOg0KDQogICA8Z2V0LWNvbmZpZz4NCiAgICAgIDxzb3VyY2U+DQogICAgICAgICA8b3BlcmF0 aW9uYWwtc3RhdGUvPg0KICAgICAgPC9zb3VyY2U+DQogICAgICA8d2l0aC1kaWFnbm9zdGljcy8+ ICAgICAgICAgICAgPC0tLSBub3RlIHRoaXMgZmxhZyBoZXJlDQogICAgICA8ZmlsdGVyIHR5cGU9 InN1YnRyZWUiPg0KICAgICAgICAgPHRvcCB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVt YS8xLjIvY29uZmlnIj4NCiAgICAgICAgICAgIDxmb28+DQogICAgICAgICAgICAgIDxiYXIvPg0K ICAgICAgICAgICAgPC9mb28+DQogICAgICAgICA8L3RvcD4NCiAgICAgIDwvZmlsdGVyPg0KICAg PC9nZXQtY29uZmlnPg0KDQpUaHVzIGV4cGxpY2l0bHkgcmVxdWVzdGluZyBhbGwgdGhlIGV4dHJh IHN0dWZmIGdldCByZXR1cm5lZC4uLg0KDQoNCj4gSW4gdGhlIHVzYWdlIG1vZGVsIHRoYXQgUm9i IGRlc2NyaWJlZCwgdGhlIHNlcnZpY2UgdGVjaCB3aWxsIGJlDQo+IHNldHRpbmcgZGlhZy1tb2Rl IHRvICdzeXN0ZW0nICB0aGVuIHJldHJpZXZpbmcgdGhlIGV4dHJhICdkaWFnLXN0YXRzJywNCj50 aGVuIHNldHRpbmcgZGlhZy1tb2RlIGJhY2sgdG8gJ3VzZXInLg0KDQpSaWdodCwgYnV0IHRoaXMg ZG9lcyBub3Qgc2VlbSBpZGVhbCBhcyB0aGUgZGlhZy1tb2RlIHRvZ2dsZSBpcyBhIGdsb2JhbCBz ZXR0aW5nIHRoYXQgd291bGQgYWZmZWN0IGFsbCBjbGllbnRzIGZvciBzb21lIHdpbmRvdyBvZiB0 aW1lLCBvciBkbyB3ZSBlbnZpc2lvbiBkaWFnLW1vZGUgZHJvcHBpbmcgdGhlIHN5c3RlbSBkb3du IHRvIHNpbmdsZS11c2VyIG1vZGU/DQoNCg0KS2VudCAgLy8gY29udHJpYnV0b3INCg0KDQoNCg0K DQoNCg== --_000_541638F153CC4656B0A13BE650F3DB3Bjunipernet_ 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+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mZ3Q7IEkgcHJlZmVyIG5vdCB0byB1c2Ugc3BlY2lhbGl6ZWQgJmx0O2dldC1mb28mZ3Q7IG9w ZXJhdGlvbnMuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ3JlZWQsIEkgd2FzIHRoaW5raW5nIHNvbWV0aGluZyBt b3JlIGFsb25nIHRoZSBsaW5lcyBvZjo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyAmbHQ7Z2V0 LWNvbmZpZyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7c291cmNlJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZsdDtvcGVyYXRpb25hbC1zdGF0ZS8mZ3Q7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy9zb3Vy Y2UmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZsdDt3aXRoLWRpYWdub3N0aWNzLyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0Oy0tLSBub3RlIHRo aXMgZmxhZyBoZXJlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2ZpbHRlciB0eXBlPSZxdW90O3N1YnRyZWUmcXVv dDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3RvcCB4bWxucz0mcXVvdDto dHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hLzEuMi9jb25maWcmcXVvdDsmZ3Q7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2ZvbyZndDs8L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2Jhci8mZ3Q7PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsvZm9vJmd0OzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZsdDsvdG9wJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsvZmlsdGVyJmd0Ozxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7ICZsdDsvZ2V0 LWNvbmZpZyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGh1cyBleHBsaWNpdGx5IHJlcXVl c3RpbmcgYWxsIHRoZSBleHRyYSBzdHVmZiBnZXQgcmV0dXJuZWQuLi48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBJbiB0aGUgdXNh Z2UgbW9kZWwgdGhhdCBSb2IgZGVzY3JpYmVkLCB0aGUgc2VydmljZSB0ZWNoIHdpbGwgYmU8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgc2V0dGluZyBkaWFnLW1vZGUg dG8gJ3N5c3RlbScgJm5ic3A7dGhlbiByZXRyaWV2aW5nIHRoZSBleHRyYSAnZGlhZy1zdGF0cycs PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7dGhlbiBzZXR0aW5nIGRp YWctbW9kZSBiYWNrIHRvICd1c2VyJy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmlnaHQsIGJ1 dCB0aGlzIGRvZXMgbm90IHNlZW0gaWRlYWwgYXMgdGhlIGRpYWctbW9kZSB0b2dnbGUgaXMgYSBn bG9iYWwgc2V0dGluZyB0aGF0IHdvdWxkIGFmZmVjdCBhbGwgY2xpZW50cyBmb3Igc29tZSB3aW5k b3cgb2YgdGltZSwgb3IgZG8gd2UgZW52aXNpb24gZGlhZy1tb2RlIGRyb3BwaW5nIHRoZSBzeXN0 ZW0gZG93biB0byBzaW5nbGUtdXNlciBtb2RlPzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LZW50Jm5ic3A7IC8vIGNvbnRyaWJ1dG9yPC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_541638F153CC4656B0A13BE650F3DB3Bjunipernet_-- From nobody Mon Dec 12 02:39:13 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437CF1295A4 for ; Mon, 12 Dec 2016 02:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0KztHfDlVuz for ; Mon, 12 Dec 2016 02:39:10 -0800 (PST) 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 D91B912007C for ; Mon, 12 Dec 2016 02:39:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8145; q=dns/txt; s=iport; t=1481539150; x=1482748750; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=Vi4QDvbcbmg1wpjgTbVXfta8TZev3cqAmj2yJSmPDLM=; b=LeShfOXBHVg6QfNsVbqrirq8SePhjhJ+6VZHTYh2+RYPrq5tZeTIE10I B2cilHkJZ58EF3Y0BiN8jlDMZk/ffklgYgqKH+1Xyoqj/omdM8ZMNz0tA jwsgbGQ6tpriY1yAGiS7MlJAKbupdxmBJCYTYPGMXmugLgo9xSvKqhulO M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAQCffU5Y/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAXkDK1iNSZcSj2GFI4IIHgEKhS5KAoIqFAECAQEBAQE?= =?us-ascii?q?BAWIohGgBAQEDAQEBIUsLEAkCGA0aAwICJx8RBg0GAgEBiF8IDo8AnUqCKC+KZ?= =?us-ascii?q?gEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhj6BfYJeh0yCXQWaa5EmgXOIJSOGC4o?= =?us-ascii?q?og2OEDx83fhMOJIMEgjQ+NIgbAQEB?= X-IronPort-AV: E=Sophos;i="5.33,335,1477958400"; d="scan'208,217";a="690381702" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2016 10:39:05 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uBCAd5A5015445; Mon, 12 Dec 2016 10:39:05 GMT To: Andy Bierman References: <20161209120651.GA93531@elstar.local> <03ca5365-8640-5019-a9da-802ed248fb0f@cisco.com> <20161209.161712.2008691146816809010.mbj@tail-f.com> From: Robert Wilton Message-ID: Date: Mon, 12 Dec 2016 10:39:04 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CEC43A1E9BBA55C17678E97B" Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 10:39:12 -0000 This is a multi-part message in MIME format. --------------CEC43A1E9BBA55C17678E97B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Andy, On 09/12/2016 18:50, Andy Bierman wrote: > > > > Why can't you use a when-stmt? > > > system > > ... > > // config false > // when "/top/diag-mode = 'system'" > > > A when statement has two problems: i) It affects all clients that are making requests to read the data (or potentially YANG push subscription requests). ii)) It turns on diagnostics everywhere. I don't believe that you can do either of these things safely on a large production system, since you could easily be increasing the amount of config false data being generated by the system by a factor of 10 or more. For the systems that I work on, using CLI based commands, there are 3 ways that diagnostics related information is commonly obtained today: 1) An operator knows that one physical interface (potentially out of a thousand) has a problem, and wants to obtain some additional diagnostics information for that specific interface, but not affect any other interface, or any other management client/request. I think that fetching the Ethernet clause 45 registers fits into this category. 2) For some other issues that need to be diagnosed it isn't immediately obvious which area of the system the problem is in. Hence, this second set of commands fetches a lot of general operational data and diagnostics information from a subset of the daemons in the system. The clause 45 registers could be included in this data set, or they may be omitted because they are slow to retrieve from the hardware. 3) The third category is debug that is enabled and then is streamed to the console, a telnet session, or a syslog buffer. For our systems, it would be less common to turn on the debug on a production device, and more generally this debug would be used during feature development. It is the data for (1) and (2) that I think could be best served if the diagnostics leaves were explicitly labelled in the model, and then if get requests/subscriptions could filter on that label. Perhaps putting these diagnostics into a separate operational datastore would be a cleanest way to handle this? Thanks, Rob > > > Thanks, > Rob > > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > --------------CEC43A1E9BBA55C17678E97B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Andy,


On 09/12/2016 18:50, Andy Bierman wrote:


<snip/>

Why can't you use a when-stmt?

 <top>
     <diag-mode>system</diag-mode>
     <service>
         ...
        <diag-stats>
            // config false
            //  when  "/top/diag-mode = 'system'"
        </diag-stats>
     </service>
 </top>
A when statement has two problems:
i) It affects all clients that are making requests to read the data (or potentially YANG push subscription requests).
ii)) It turns on diagnostics everywhere.

I don't believe that you can do either of these things safely on a large production system, since you could easily be increasing the amount of config false data being generated by the system by a factor of 10 or more.


For the systems that I work on, using CLI based commands, there are 3 ways that diagnostics related information is commonly obtained today:
1) An operator knows that one physical interface (potentially out of a thousand) has a problem, and wants to obtain some additional diagnostics information for that specific interface, but not affect any other interface, or any other management client/request.  I think that fetching the Ethernet clause 45 registers fits into this category.
2) For some other issues that need to be diagnosed it isn't immediately obvious which area of the system the problem is in.  Hence, this second set of commands fetches a lot of general operational data and diagnostics information from a subset of the daemons in the system.  The clause 45 registers could be included in this data set, or they may be omitted because they are slow to retrieve from the hardware.
3) The third category is debug that is enabled and then is streamed to the console, a telnet session, or a syslog buffer.  For our systems, it would be less common to turn on the debug on a production device, and more generally this debug would be used during feature development.

It is the data for (1) and (2) that I think could be best served if the diagnostics leaves were explicitly labelled in the model, and then if get requests/subscriptions could filter on that label.  Perhaps putting these diagnostics into a separate operational datastore would be a cleanest way to handle this?

Thanks,
Rob




Thanks,
Rob


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


--------------CEC43A1E9BBA55C17678E97B-- From nobody Mon Dec 12 03:10:46 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A761295DF for ; Mon, 12 Dec 2016 03:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YVZ6Q-mOy2B for ; Mon, 12 Dec 2016 03:10:43 -0800 (PST) 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 C5B951295DD for ; Mon, 12 Dec 2016 03:10:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7851; q=dns/txt; s=iport; t=1481541042; x=1482750642; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=FoIDfbCLt2anMtS0igLdr+VkEg8Dnq++Xz9adzeeg3A=; b=lpQgxs3+5WwryW8oZXHvE78ZoUH3zS55EDYkTl+wuaxvZ8AomkUzQkON WlwBrPb4uCZxBF1q5mZmnwkG+/Jwo9vnOMrfkF4QUTyJiQWm4tnCwZbk9 hXnYBIuv5gUYdPATddy3f4t9rTjmDvNgGqSr8lJuU75cpshjJjlINb1i9 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYAgDuhE5Y/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnNEAQEBAQF5AyulNI9hgxSCD4IIJYV8AoIqEwECAQEBAQEBAWI?= =?us-ascii?q?ohGgBAQEDASNWBQsJAg4KKgICVwYBDAgBAYhfCA6OfZ1KgigvimcBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEdhj6BfQiCVodMgl0FmmuGT4pXgkSHVIYuiiiDY4QPIQI?= =?us-ascii?q?zfhMOhVw+iE8BAQE?= X-IronPort-AV: E=Sophos;i="5.33,336,1477958400"; d="scan'208,217";a="647822251" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2016 11:10:38 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uBCBAcSf023762; Mon, 12 Dec 2016 11:10:38 GMT To: Kent Watsen , Andy Bierman References: <20161209120651.GA93531@elstar.local> <03ca5365-8640-5019-a9da-802ed248fb0f@cisco.com> <20161209.161712.2008691146816809010.mbj@tail-f.com> <541638F1-53CC-4656-B0A1-3BE650F3DB3B@juniper.net> From: Robert Wilton Message-ID: <870394e0-28c9-cf62-5268-fa1ddfec06a8@cisco.com> Date: Mon, 12 Dec 2016 11:10:36 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <541638F1-53CC-4656-B0A1-3BE650F3DB3B@juniper.net> Content-Type: multipart/alternative; boundary="------------83879C713B8EF25B882BA95C" Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 11:10:45 -0000 This is a multi-part message in MIME format. --------------83879C713B8EF25B882BA95C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Kent, On 10/12/2016 00:59, Kent Watsen wrote: > > > I prefer not to use specialized operations. > > Agreed, I was thinking something more along the lines of: > > > > > > > > > > <--- note this flag here > > > > > > > > > > > > > > > > > > Thus explicitly requesting all the extra stuff get returned... > Yes, that is roughly along the lines that I was thinking. Or building on draft-nmdsdt-netmod-revised-datastores: - presuming the existing of a operation to generically return the contents of any datastore, - defining a new datastore that contains the contents of the along with all config false schema nodes labelled as "diagnostics true". .... Thanks, Rob > > In the usage model that Rob described, the service tech will be > > > setting diag-mode to 'system' then retrieving the extra 'diag-stats', > > >then setting diag-mode back to 'user'. > > Right, but this does not seem ideal as the diag-mode toggle is a > global setting that would affect all clients for some window of time, > or do we envision diag-mode dropping the system down to single-user mode? > > Kent // contributor > --------------83879C713B8EF25B882BA95C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Kent,


On 10/12/2016 00:59, Kent Watsen wrote:

 

> I prefer not to use specialized <get-foo> operations.

 

Agreed, I was thinking something more along the lines of:

 

   <get-config>

      <source>

         <operational-state/>

      </source>

      <with-diagnostics/>            <--- note this flag here

      <filter type="subtree">

         <top xmlns="http://example.com/schema/1.2/config">

            <foo>

              <bar/>

            </foo>

         </top>

      </filter>

   </get-config>

 

Thus explicitly requesting all the extra stuff get returned...

Yes, that is roughly along the lines that I was thinking.

Or building on draft-nmdsdt-netmod-revised-datastores:
- presuming the existing of a <get-data/> operation to generically return the contents of any datastore,
- defining a new <diagnostics> datastore that contains the contents of the <operational-state> along with all config false schema nodes labelled as "diagnostics true".

   <get-data>

      <source>

         <diagnostics/>

      </source>

      <filter type="subtree">

        ....

  <get-data/>   


Thanks,
Rob


 

 

> In the usage model that Rob described, the service tech will be

> setting diag-mode to 'system'  then retrieving the extra 'diag-stats',

>then setting diag-mode back to 'user'.

 

Right, but this does not seem ideal as the diag-mode toggle is a global setting that would affect all clients for some window of time, or do we envision diag-mode dropping the system down to single-user mode?

 

 

Kent  // contributor

 

 

 

 

 

 


--------------83879C713B8EF25B882BA95C-- From nobody Mon Dec 12 07:04:12 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02FD8129C48 for ; Mon, 12 Dec 2016 07:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3bDQDRPTKqt for ; Mon, 12 Dec 2016 07:04:05 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65D6D129C42 for ; Mon, 12 Dec 2016 07:04:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1807; q=dns/txt; s=iport; t=1481555045; x=1482764645; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=gAjnH3X47XOcwu4AXaxCNf9EGWPeq/vQ3t3tbknHsPw=; b=Vw7HbdlHcBWzmd55C+tX1l3GUwlGcYzeBtvepds0HTOeTM7jycf6FzTV yWwSFUwne7tluvz2OQuWXFd41f8tmGGSzoU3zyrDGLUUCDkko8HmN3RIC ip9NzNfpLQsO2fdXJOX045MvXmd0gaI320qdOYLNOOIFe3wW2dbItYagM A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BjBQAOu05Y/4cNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzcBAQEBAR9agQYBBo1CqgmCD4IIHguHbT8UAQIBAQEBAQEBYh0LhG9?= =?us-ascii?q?OGCUBLFMBJwQPBRwEiEoOm1KSJosaAQEBAQEBAQMBAQEBAQEBAQEBHoY+gX2EL?= =?us-ascii?q?YYqgjAFmmsBhk6KV5BGkhkBHzcwbyQOAQGDLxyBXXMGhweBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,336,1477958400"; d="scan'208";a="182310793" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Dec 2016 15:04:04 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uBCF44te026558 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 12 Dec 2016 15:04:04 GMT Received: from xch-rtp-011.cisco.com (64.101.220.151) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 12 Dec 2016 10:04:03 -0500 Received: from xch-rtp-011.cisco.com ([64.101.220.151]) by XCH-RTP-011.cisco.com ([64.101.220.151]) with mapi id 15.00.1210.000; Mon, 12 Dec 2016 10:04:03 -0500 From: "Tim Jenkins (timjenki)" To: "netmod@ietf.org" Thread-Topic: Management Operations on YANG modelled operational data Thread-Index: AQHSVIj5OTfY7x+xRUC8C/jBy4OI0g== Date: Mon, 12 Dec 2016 15:04:03 +0000 Message-ID: <191C1364-38F4-4FE5-8A72-3D6772C8D564@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.82.238.240] Content-Type: text/plain; charset="utf-7" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [netmod] Management Operations on YANG modelled operational data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 15:04:11 -0000 Hi, I have a general question related to management operations on operational d= ata. The question is intended to be protocol agnostic, since as I understan= d it, the NETCONF management operations do not apply to data modelled in YA= NG where config is false. In other words, there is no generic NETCONF RPC t= hat will, for example, delete entries in a table of operational data. My question arises because we are implementing a feature that is defined us= ing YANG, and has custom NETCONF RPCs whose operations can create, modify a= nd delete rows of a YANG list that has entries that are both config is true= and config is false. The rows that are config is false are the only rows t= hat can be affected by the custom NETCONF RPCs+ADs- the other rows are affe= cted only by the standard NETCONF management RPCs. However, there is a need= for management operations to be able to remove the rows and the operations= associated with them for various reasons. So my question is this: what is the general approach to this problem? As mentioned above, for NETCONF, I believe the answer is that a custom RPC = has to be used. But is this intended to be the case for all protocols that = can deal with YANG modelled data? In case it matters, the specific case I'm dealing with is subscriptions as = per https://tools.ietf.org/html/draft-ietf-netconf-rfc5277bis-01 and https:= //tools.ietf.org/html/draft-ietf-netconf-yang-push-04. Thanks, Tim --=20 Cisco Systems Canada Co. 2000 Innovation Drive Kanata, ON, Canada, K2K 3E8 Preferences +ADw-http://www.cisco.com/offer/subscribe/?sid+AD0-000478326+AD= 4- Unsubscribe +ADw-http://www.cisco.com/offer/unsubscribe/?sid+AD0-000478327+= AD4- Privacy +ADw-http://www.cisco.com/web/siteassets/legal/privacy.html+AD4- From nobody Mon Dec 12 08:51:31 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAD6129DAF for ; Mon, 12 Dec 2016 08:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAIDNJh5z0_b for ; Mon, 12 Dec 2016 08:51:27 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0138.outbound.protection.outlook.com [104.47.33.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A06E3129D1C for ; Mon, 12 Dec 2016 08:47:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PMooeiXsjLmKDRg3j6zymTrKpP/fw7M/CEA1Vl1Fcy0=; b=kPm85FY5RplhPxf/5u9vLJDZ92Ix9nWG1a+5iXXmnjDfPLPnaOAehUydZ/5bvk5vtzc4cK4/fyEkAKUhnnngYL8VNxOohTR9ML6deyUXgEj9/50iO/PZMnkCpf1NvamcdAvXtfj0kx0GfTVfhwLe2gvQJD/lgPE8yeR9u2Sl1sk= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.5; Mon, 12 Dec 2016 16:47:42 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0789.007; Mon, 12 Dec 2016 16:47:42 +0000 From: Kent Watsen To: Robert Wilton , Andy Bierman Thread-Topic: [netmod] Modelling different "levels" of data in YANG Thread-Index: AQHSTyLtAX7o6QMy50mp3fLqeP2npKD7BFBDgABltYCAARPHAIAAEzkAgAAabwCAAa0JgIABGL2AgAAEIQCAAAGPAIAAAzOAgAADBQCAAAKDgIAAC4qAgAAwiwCAAAShAIAAMHKAgAALEoD//9EdAIAAW8EA///mY4CABCNUAIAAClyA Date: Mon, 12 Dec 2016 16:47:42 +0000 Message-ID: <4E091DC6-99B2-4B34-A35E-B16A97AD0E6E@juniper.net> References: <20161209120651.GA93531@elstar.local> <03ca5365-8640-5019-a9da-802ed248fb0f@cisco.com> <20161209.161712.2008691146816809010.mbj@tail-f.com> <541638F1-53CC-4656-B0A1-3BE650F3DB3B@juniper.net> <870394e0-28c9-cf62-5268-fa1ddfec06a8@cisco.com> In-Reply-To: <870394e0-28c9-cf62-5268-fa1ddfec06a8@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1c.1.161117 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: 66061600-6c70-4450-e683-08d422ae978e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1441; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:wfvygdJJHOf/0mtrK2qzTFpeh8n47GiJaMYqjLZ/7X9J8Q3xtmdQ9aplkumtiSy3LowHXYRUGe6Y1bcA/fCy/Vc2xkpCW4TQwXx61+3tyjl0sfeILLMvI53sdY8cbPYMQppsCBpXLHIBbvw1JrDjg7AcKXny3qMPPCiuF+mQIWe+Ym7veO36Jv1qkRWlZmAe38a7YieObRPG9hjNi4fPhGlu5T66Jc2lIbCg1Kfidu7NfsHoPvSABouPb0amTrTZJAQag9buKfSb4/K6zt4MR4ou9vCCMxOVRXIAb1i01SxgxRMmoYaaOWno10mZLbDMNJTNMCLixDqgr9YqHTu52E+NwJescjP/et71/FmH6qECk1RnJJ+EdYHDOezemX62zeHt8MKcqwlWCuKSHMHemY+opiBOMN5ySFwVpItD0FoDZumI8iCHMl8NwJLVmIjdHwizdD0zmPZ0k6toLrWyxw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 0154C61618 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39840400002)(39410400002)(39850400002)(39860400002)(377454003)(199003)(24454002)(51444003)(189002)(9326002)(106116001)(83506001)(6486002)(77096006)(93886004)(122556002)(8936002)(92566002)(4326007)(101416001)(3660700001)(3280700002)(7906003)(66066001)(54356999)(83716003)(229853002)(38730400001)(76176999)(50986999)(82746002)(81156014)(68736007)(606005)(81166006)(6436002)(86362001)(6506006)(6512006)(7736002)(8676002)(15395725005)(102836003)(189998001)(3846002)(36756003)(99286002)(2900100001)(2950100002)(97736004)(2906002)(5660300001)(33656002)(5001770100001)(6116002)(4001350100001)(106356001)(105586002)(104396002)(562404015); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_4E091DC699B24B34A35EB16A97AD0E6Ejunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2016 16:47:42.5909 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 16:51:30 -0000 --_000_4E091DC699B24B34A35EB16A97AD0E6Ejunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpZb3XigJlyZSByaWdodCwgaXQgc2hvdWxk4oCZdmUgYmVlbiB0aGUgPGdl dC1kYXRhPiAobm90IDxnZXQtY29uZmlnPikuICAgSG93ZXZlciwgSSB0aGluayB0aGF0IGl04oCZ cyBiZXR0ZXIgdG8gdXNlIGEgZmxhZyBvbiB0aGUgPG9wZXJhdGlvbmFsLXN0YXRlPiBkYXRhc3Rv cmUsIHJhdGhlciB0aGFuIHRvIGRlZmluZSBhIG5ldyBkYXRhc3RvcmUuICBOb3Qgb25seSB3b3Vs ZCBpdCBtaW1pYyBob3cgd2l0aC1kZWZhdWx0cyB3b3JrcywgYnV0IGl0IGFsc28gc2VlbXMgbW9y ZSBpbnR1aXRpdmUgZnJvbSBhIHJldHJpZXZhbCBwZXJzcGVjdGl2ZSwgYXMgdGhlIGRpYWdub3N0 aWNzIG5vZGVzIGNvdWxkIGJlIHNwcmlua2xlZCB0aHJvdWdob3V0IGEgZGF0YSBtb2RlbCwgYW5k IGEgc2luZ2xlIDxnZXQtZGF0YT4gY291bGQgcmV0dXJuIGFsbCBub2RlcyAobm90IGp1c3QgdGhl IGRpYWdub3N0aWNzKSBmb3IgYSBnaXZlbiBzdWJ0cmVlLiAgICBUaG91Z2h0cz8NCg0KU2VwYXJh dGVseSwgZnJvbSBhIG1vZGVsbGluZyBwZXJzcGVjdGl2ZSwgcHJlc3VtYWJseSB0aGVyZSB3b3Vs ZCBoYXZlIHRvIGJlIGFuIGFkZGl0aW9uYWwgZmxhZyB0byBnbyB3aXRoIHRoZSBjb25maWcgZmFs c2UgZmxhZywgc29tZXRoaW5nIGxpa2UgdGhlIGJlbG93LiAgSXMgdGhpcyB3aGF0IHlvdSB3ZXJl IGVudmlzaW9uaW5nPw0KDQogICAgY29udGFpbmVyIHRoZXJtb3N0YXQgew0KICAgICAgICBsZWFm IGNvbmZpZ3VyZWQtdGVtcGVyYXR1cmUgew0KICAgICAgICAgICAgdHlwZSBpbnQ4Ow0KICAgICAg ICB9DQogICAgICAgIGxlYWYgY3VycmVudC10ZW1wZXJhdHVyZSB7DQogICAgICAgICAgICBjb25m aWcgZmFsc2U7DQogICAgICAgICAgICB0eXBlIGludDg7DQogICAgICAgIH0NCiAgICAgICAgY29u dGFpbmVyIGRpYWdub3N0aWNzIHsNCiAgICAgICAgICAgIGNvbmZpZyBmYWxzZTsNCiAgICAgICAg ICAgIGRpYWdub3N0aWNzIHRydWU7ICAgIDwtLSBuZXcgZmxhZyBoZXJlDQogICAgICAgICAgICAu Li4NCiAgICAgICAgfQ0KDQoNCklzIGFsbCB0aGlzIGxlYWRpbmcgdXAgdG8gYSBkcmFmdD8gIDsp DQoNCktlbnQgIC8vIGNvbnRyaWJ1dG9yDQoNCg0KRnJvbTogUm9iZXJ0IFdpbHRvbiA8cndpbHRv bkBjaXNjby5jb20+DQpEYXRlOiBNb25kYXksIERlY2VtYmVyIDEyLCAyMDE2IGF0IDY6MTAgQU0N ClRvOiBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4sIEFuZHkgQmllcm1hbiA8YW5k eUB5dW1hd29ya3MuY29tPg0KQ2M6ICJuZXRtb2RAaWV0Zi5vcmciIDxuZXRtb2RAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gTW9kZWxsaW5nIGRpZmZlcmVudCAibGV2ZWxzIiBvZiBk YXRhIGluIFlBTkcNCg0KDQpIaSBLZW50LA0KDQpPbiAxMC8xMi8yMDE2IDAwOjU5LCBLZW50IFdh dHNlbiB3cm90ZToNCg0KPiBJIHByZWZlciBub3QgdG8gdXNlIHNwZWNpYWxpemVkIDxnZXQtZm9v PiBvcGVyYXRpb25zLg0KDQpBZ3JlZWQsIEkgd2FzIHRoaW5raW5nIHNvbWV0aGluZyBtb3JlIGFs b25nIHRoZSBsaW5lcyBvZjoNCg0KICAgPGdldC1jb25maWc+DQogICAgICA8c291cmNlPg0KICAg ICAgICAgPG9wZXJhdGlvbmFsLXN0YXRlLz4NCiAgICAgIDwvc291cmNlPg0KICAgICAgPHdpdGgt ZGlhZ25vc3RpY3MvPiAgICAgICAgICAgIDwtLS0gbm90ZSB0aGlzIGZsYWcgaGVyZQ0KICAgICAg PGZpbHRlciB0eXBlPSJzdWJ0cmVlIj4NCiAgICAgICAgIDx0b3AgeG1sbnM9Imh0dHA6Ly9leGFt cGxlLmNvbS9zY2hlbWEvMS4yL2NvbmZpZyI8aHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS8xLjIv Y29uZmlnPj4NCiAgICAgICAgICAgIDxmb28+DQogICAgICAgICAgICAgIDxiYXIvPg0KICAgICAg ICAgICAgPC9mb28+DQogICAgICAgICA8L3RvcD4NCiAgICAgIDwvZmlsdGVyPg0KICAgPC9nZXQt Y29uZmlnPg0KDQpUaHVzIGV4cGxpY2l0bHkgcmVxdWVzdGluZyBhbGwgdGhlIGV4dHJhIHN0dWZm IGdldCByZXR1cm5lZC4uLg0KWWVzLCB0aGF0IGlzIHJvdWdobHkgYWxvbmcgdGhlIGxpbmVzIHRo YXQgSSB3YXMgdGhpbmtpbmcuDQoNCk9yIGJ1aWxkaW5nIG9uIGRyYWZ0LW5tZHNkdC1uZXRtb2Qt cmV2aXNlZC1kYXRhc3RvcmVzOg0KLSBwcmVzdW1pbmcgdGhlIGV4aXN0aW5nIG9mIGEgPGdldC1k YXRhLz4gb3BlcmF0aW9uIHRvIGdlbmVyaWNhbGx5IHJldHVybiB0aGUgY29udGVudHMgb2YgYW55 IGRhdGFzdG9yZSwNCi0gZGVmaW5pbmcgYSBuZXcgPGRpYWdub3N0aWNzPiBkYXRhc3RvcmUgdGhh dCBjb250YWlucyB0aGUgY29udGVudHMgb2YgdGhlIDxvcGVyYXRpb25hbC1zdGF0ZT4gYWxvbmcg d2l0aCBhbGwgY29uZmlnIGZhbHNlIHNjaGVtYSBub2RlcyBsYWJlbGxlZCBhcyAiZGlhZ25vc3Rp Y3MgdHJ1ZSIuDQogICA8Z2V0LWRhdGE+DQogICAgICA8c291cmNlPg0KICAgICAgICAgPGRpYWdu b3N0aWNzLz4NCiAgICAgIDwvc291cmNlPg0KICAgICAgPGZpbHRlciB0eXBlPSJzdWJ0cmVlIj4N CiAgICAgICAgLi4uLg0KICA8Z2V0LWRhdGEvPg0KDQpUaGFua3MsDQpSb2INCg0KDQoNCg0KDQo+ IEluIHRoZSB1c2FnZSBtb2RlbCB0aGF0IFJvYiBkZXNjcmliZWQsIHRoZSBzZXJ2aWNlIHRlY2gg d2lsbCBiZQ0KPiBzZXR0aW5nIGRpYWctbW9kZSB0byAnc3lzdGVtJyAgdGhlbiByZXRyaWV2aW5n IHRoZSBleHRyYSAnZGlhZy1zdGF0cycsDQo+dGhlbiBzZXR0aW5nIGRpYWctbW9kZSBiYWNrIHRv ICd1c2VyJy4NCg0KUmlnaHQsIGJ1dCB0aGlzIGRvZXMgbm90IHNlZW0gaWRlYWwgYXMgdGhlIGRp YWctbW9kZSB0b2dnbGUgaXMgYSBnbG9iYWwgc2V0dGluZyB0aGF0IHdvdWxkIGFmZmVjdCBhbGwg Y2xpZW50cyBmb3Igc29tZSB3aW5kb3cgb2YgdGltZSwgb3IgZG8gd2UgZW52aXNpb24gZGlhZy1t b2RlIGRyb3BwaW5nIHRoZSBzeXN0ZW0gZG93biB0byBzaW5nbGUtdXNlciBtb2RlPw0KDQoNCktl bnQgIC8vIGNvbnRyaWJ1dG9yDQoNCg0KDQoNCg0KDQoNCg0K --_000_4E091DC699B24B34A35EB16A97AD0E6Ejunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <66BB4CD74F520740A12E70881E7C70F8@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJZm9udC12YXJpYW50Om5vcm1hbCAhaW1wb3J0YW50Ow0K CWNvbG9yOndpbmRvd3RleHQ7DQoJdGV4dC10cmFuc2Zvcm06bm9uZTsNCgl0ZXh0LWRlY29yYXRp b246bm9uZSBub25lOw0KCXZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO30NCnNwYW4uRW1haWxTdHls ZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGli cmk7DQoJZm9udC12YXJpYW50Om5vcm1hbCAhaW1wb3J0YW50Ow0KCWNvbG9yOndpbmRvd3RleHQ7 DQoJdGV4dC10cmFuc2Zvcm06bm9uZTsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lOw0KCXZl cnRpY2FsLWFsaWduOmJhc2VsaW5lO30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+SGkgUm9iZXJ0LDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD YWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+WW914oCZcmUgcmlnaHQsIGl0IHNo b3VsZOKAmXZlIGJlZW4gdGhlICZsdDtnZXQtZGF0YSZndDsgKG5vdCAmbHQ7Z2V0LWNvbmZpZyZn dDspLiZuYnNwOyZuYnNwOyBIb3dldmVyLCBJIHRoaW5rIHRoYXQgaXTigJlzIGJldHRlciB0byB1 c2UgYSBmbGFnIG9uIHRoZSAmbHQ7b3BlcmF0aW9uYWwtc3RhdGUmZ3Q7IGRhdGFzdG9yZSwgcmF0 aGVyIHRoYW4gdG8gZGVmaW5lIGEgbmV3IGRhdGFzdG9yZS4mbmJzcDsgTm90IG9ubHkNCiB3b3Vs ZCBpdCBtaW1pYyBob3cgd2l0aC1kZWZhdWx0cyB3b3JrcywgYnV0IGl0IGFsc28gc2VlbXMgbW9y ZSBpbnR1aXRpdmUgZnJvbSBhIHJldHJpZXZhbCBwZXJzcGVjdGl2ZSwgYXMgdGhlIGRpYWdub3N0 aWNzIG5vZGVzIGNvdWxkIGJlIHNwcmlua2xlZCB0aHJvdWdob3V0IGEgZGF0YSBtb2RlbCwgYW5k IGEgc2luZ2xlICZsdDtnZXQtZGF0YSZndDsgY291bGQgcmV0dXJuIGFsbCBub2RlcyAobm90IGp1 c3QgdGhlIGRpYWdub3N0aWNzKSBmb3IgYSBnaXZlbg0KIHN1YnRyZWUuJm5ic3A7ICZuYnNwOyZu YnNwO1Rob3VnaHRzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSI+U2VwYXJhdGVseSwgZnJvbSBhIG1vZGVsbGluZyBwZXJzcGVjdGl2ZSwgcHJlc3VtYWJs eSB0aGVyZSB3b3VsZCBoYXZlIHRvIGJlIGFuIGFkZGl0aW9uYWwgZmxhZyB0byBnbyB3aXRoIHRo ZSBjb25maWcgZmFsc2UgZmxhZywgc29tZXRoaW5nIGxpa2UgdGhlIGJlbG93LiZuYnNwOyBJcyB0 aGlzIHdoYXQgeW91IHdlcmUgZW52aXNpb25pbmc/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsgY29udGFpbmVyIHRoZXJt b3N0YXQgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgbGVhZiBjb25maWd1cmVkLXRlbXBlcmF0dXJlIHs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgaW50ODs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJy aSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgY3VycmVu dC10ZW1wZXJhdHVyZSB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb25maWcgZmFs c2U7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBlIGludDg7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBjb250YWluZXIgZGlhZ25vc3RpY3MgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgY29uZmlnIGZhbHNlOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGlhZ25vc3Rp Y3MgdHJ1ZTsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy0tIG5ldyBmbGFnIGhlcmU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPklz IGFsbCB0aGlzIGxlYWRpbmcgdXAgdG8gYSBkcmFmdD8mbmJzcDsgOyk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPktlbnQmbmJzcDsgLy8gY29udHJpYnV0 b3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9y OmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmk7Y29sb3I6YmxhY2siPlJvYmVydCBXaWx0b24gJmx0O3J3aWx0b25AY2lzY28uY29tJmd0Ozxi cj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIERlY2VtYmVyIDEyLCAyMDE2IGF0IDY6MTAgQU08YnI+ DQo8Yj5UbzogPC9iPktlbnQgV2F0c2VuICZsdDtrd2F0c2VuQGp1bmlwZXIubmV0Jmd0OywgQW5k eSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVv dDtuZXRtb2RAaWV0Zi5vcmcmcXVvdDsgJmx0O25ldG1vZEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0OiA8L2I+UmU6IFtuZXRtb2RdIE1vZGVsbGluZyBkaWZmZXJlbnQgJnF1b3Q7bGV2ZWxz JnF1b3Q7IG9mIGRhdGEgaW4gWUFORzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cD5IaSBLZW50LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTAvMTIvMjAxNiAw MDo1OSwgS2VudCBXYXRzZW4gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mZ3Q7IEkgcHJlZmVyIG5vdCB0byB1c2Ugc3BlY2lhbGl6ZWQgJmx0O2dldC1mb28mZ3Q7IG9w ZXJhdGlvbnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFncmVlZCwgSSB3YXMgdGhpbmtpbmcg c29tZXRoaW5nIG1vcmUgYWxvbmcgdGhlIGxpbmVzIG9mOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsmbmJzcDsgJmx0O2dldC1jb25maWcmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3NvdXJjZSZn dDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7b3BlcmF0aW9uYWwtc3RhdGUvJmd0 OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZsdDsvc291cmNlJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDt3aXRoLWRpYWdub3N0 aWNzLyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0Oy0tLSBub3RlIHRoaXMgZmxhZyBoZXJlPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmx0O2ZpbHRlciB0eXBlPSZxdW90O3N1YnRyZWUmcXVvdDsmZ3Q7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmx0O3RvcCB4bWxucz08YSBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20vc2No ZW1hLzEuMi9jb25maWciPiZxdW90O2h0dHA6Ly9leGFtcGxlLmNvbS9zY2hlbWEvMS4yL2NvbmZp ZyZxdW90OzwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmx0O2ZvbyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7YmFyLyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7L2ZvbyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmbHQ7L3RvcCZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7L2ZpbHRlciZndDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyAmbHQ7L2dldC1jb25maWcm Z3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRodXMgZXhwbGljaXRseSByZXF1ZXN0aW5nIGFs bCB0aGUgZXh0cmEgc3R1ZmYgZ2V0IHJldHVybmVkLi4uPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PlllcywgdGhhdCBpcyByb3VnaGx5IGFsb25nIHRoZSBsaW5lcyB0aGF0IEkgd2FzIHRoaW5raW5n Ljxicj4NCjxicj4NCk9yIGJ1aWxkaW5nIG9uIGRyYWZ0LW5tZHNkdC1uZXRtb2QtcmV2aXNlZC1k YXRhc3RvcmVzOjxicj4NCi0gcHJlc3VtaW5nIHRoZSBleGlzdGluZyBvZiBhICZsdDtnZXQtZGF0 YS8mZ3Q7IG9wZXJhdGlvbiB0byBnZW5lcmljYWxseSByZXR1cm4gdGhlIGNvbnRlbnRzIG9mIGFu eSBkYXRhc3RvcmUsPGJyPg0KLSBkZWZpbmluZyBhIG5ldyAmbHQ7ZGlhZ25vc3RpY3MmZ3Q7IGRh dGFzdG9yZSB0aGF0IGNvbnRhaW5zIHRoZSBjb250ZW50cyBvZiB0aGUgJmx0O29wZXJhdGlvbmFs LXN0YXRlJmd0OyBhbG9uZyB3aXRoIGFsbCBjb25maWcgZmFsc2Ugc2NoZW1hIG5vZGVzIGxhYmVs bGVkIGFzICZxdW90O2RpYWdub3N0aWNzIHRydWUmcXVvdDsuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgJmx0O2dldC1kYXRhJmd0OzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZsdDtzb3VyY2UmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2RpYWdub3N0 aWNzLyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7L3NvdXJjZSZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7ZmlsdGVy IHR5cGU9JnF1b3Q7c3VidHJlZSZxdW90OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAuLi4uPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJmx0O2dldC1kYXRhLyZndDsgJm5ic3A7Jm5i c3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVGhhbmtzLDxi cj4NClJvYjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBJbiB0aGUg dXNhZ2UgbW9kZWwgdGhhdCBSb2IgZGVzY3JpYmVkLCB0aGUgc2VydmljZSB0ZWNoIHdpbGwgYmU8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgc2V0dGluZyBkaWFnLW1v ZGUgdG8gJ3N5c3RlbScgJm5ic3A7dGhlbiByZXRyaWV2aW5nIHRoZSBleHRyYSAnZGlhZy1zdGF0 cycsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7dGhlbiBzZXR0aW5n IGRpYWctbW9kZSBiYWNrIHRvICd1c2VyJy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmlnaHQs IGJ1dCB0aGlzIGRvZXMgbm90IHNlZW0gaWRlYWwgYXMgdGhlIGRpYWctbW9kZSB0b2dnbGUgaXMg YSBnbG9iYWwgc2V0dGluZyB0aGF0IHdvdWxkIGFmZmVjdCBhbGwgY2xpZW50cyBmb3Igc29tZSB3 aW5kb3cgb2YgdGltZSwgb3IgZG8gd2UgZW52aXNpb24gZGlhZy1tb2RlIGRyb3BwaW5nIHRoZSBz eXN0ZW0gZG93biB0byBzaW5nbGUtdXNlciBtb2RlPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPktlbnQmbmJzcDsgLy8g Y29udHJpYnV0b3I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E091DC699B24B34A35EB16A97AD0E6Ejunipernet_-- From nobody Mon Dec 12 08:55:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7C512953E for ; Mon, 12 Dec 2016 08:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBNqOnv1K1P4 for ; Mon, 12 Dec 2016 08:55:53 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0094.outbound.protection.outlook.com [104.47.34.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D078129CC6 for ; Mon, 12 Dec 2016 08:54:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ae1dH5RwbrDqTdE/vy2ZoXDlkXcr809A6NmtQm/HqUY=; b=WdwV/2NZ7NLexa4FBcaQhKI4GJaCaIIQE2OMJd96Zq9YlehPImhpeWeE1tRtOHN9tBnKCCy5ZPoc0IuP4WiAwPFAD/1wVXA+Cdaxp732+uoNZLBqHrHujbK8khKVpTgUxB3JOW4SP5whe5/eGQs7BkwMnmu528+Jd77wBAozjZI= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.5; Mon, 12 Dec 2016 16:54:31 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0789.007; Mon, 12 Dec 2016 16:54:31 +0000 From: Kent Watsen To: "Tim Jenkins (timjenki)" , "netmod@ietf.org" Thread-Topic: [netmod] Management Operations on YANG modelled operational data Thread-Index: AQHSVJhoTPiiYH6N+ES2a0NLTclXBg== Date: Mon, 12 Dec 2016 16:54:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1c.1.161117 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: 61910b0b-d6eb-4d04-5f46-08d422af8af9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1442; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:51vbeJF6d2ztK2XFOQM/FB/ULtzaE73KoVEKPe1pm7UfNmZyBHghoXpa7IbK2up5DjACjxKq5hmDnZYt24etKHqOni5eaT5DHr17Hs9wT4aVaDjVPJqVzH5lFS0nJ+yTajwUuFHlLIAmVWYQXE4IqPlAhMNVYXylWiPpWI3Tq3a/kmnpHiwHfXFQiRSrYSRINwSMWQZIWTVlc88KpnpULJawXXq2ydUx36iRxMStP24EtThNi/oLWrwcbgOVqOBt/Qb9q64sCHJ3ulwwO8VdxsbUYTE9IGIfazRdk43AllbskYdaXtYJlxojiSiKLxky+5GACztmowIvH1SrjynQsImTeXWwIPwGmhspOa0VPwvpZn2LjI3k11vIVzY6p9vXCSWvwbola2RBa/aMBufA6C6rE3nt1Zg4TSemosWza9GEFp/BKekmeHM50d7H7nYiX4wR8SYOUYBknSthbXnJow== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(114627819485645)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0154C61618 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(7916002)(39410400002)(39840400002)(39850400002)(39860400002)(39450400003)(189002)(199003)(6512006)(6506006)(83716003)(3280700002)(107886002)(6436002)(81156014)(86362001)(99286002)(33656002)(106356001)(189998001)(101416001)(38730400001)(105586002)(54356999)(50986999)(102836003)(106116001)(68736007)(6116002)(7736002)(2900100001)(305945005)(229853002)(92566002)(3846002)(97736004)(5001770100001)(66066001)(4001350100001)(19273905006)(122556002)(6486002)(8936002)(5660300001)(36756003)(2906002)(81166006)(82746002)(8676002)(83506001)(77096006)(3660700001)(2501003)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <604D338212F0C54FA95B8FCC0C5F61F3@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2016 16:54:31.1301 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: Re: [netmod] Management Operations on YANG modelled operational data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 16:55:56 -0000 SGkgVGltLA0KDQpJIGRvbuKAmXQgdW5kZXJzdGFuZCB5b3VyIHByb2JsZW0uICBXaGljaCBwYXJ0 cyBpbiB0aGUgcmVmZXJlbmNlZCBkcmFmdHMgc2hvdWxkIHdlIGxvb2sgYXQsIG9yIGNhbiB5b3Ug cHJvdmlkZSBhbiBleGFtcGxlPw0KDQpUaGFua3MsDQpLZW50DQoNCg0KDQpIaSwNCg0KSSBoYXZl IGEgZ2VuZXJhbCBxdWVzdGlvbiByZWxhdGVkIHRvIG1hbmFnZW1lbnQgb3BlcmF0aW9ucyBvbiBv cGVyYXRpb25hbCBkYXRhLiBUaGUgcXVlc3Rpb24gaXMgaW50ZW5kZWQgdG8gYmUgcHJvdG9jb2wg YWdub3N0aWMsIHNpbmNlIGFzIEkgdW5kZXJzdGFuZCBpdCwgdGhlIE5FVENPTkYgbWFuYWdlbWVu dCBvcGVyYXRpb25zIGRvIG5vdCBhcHBseSB0byBkYXRhIG1vZGVsbGVkIGluIFlBTkcgd2hlcmUg Y29uZmlnIGlzIGZhbHNlLiBJbiBvdGhlciB3b3JkcywgdGhlcmUgaXMgbm8gZ2VuZXJpYyBORVRD T05GIFJQQyB0aGF0IHdpbGwsIGZvciBleGFtcGxlLCBkZWxldGUgZW50cmllcyBpbiBhIHRhYmxl IG9mIG9wZXJhdGlvbmFsIGRhdGEuDQoNCk15IHF1ZXN0aW9uIGFyaXNlcyBiZWNhdXNlIHdlIGFy ZSBpbXBsZW1lbnRpbmcgYSBmZWF0dXJlIHRoYXQgaXMgZGVmaW5lZCB1c2luZyBZQU5HLCBhbmQg aGFzIGN1c3RvbSBORVRDT05GIFJQQ3Mgd2hvc2Ugb3BlcmF0aW9ucyBjYW4gY3JlYXRlLCBtb2Rp ZnkgYW5kIGRlbGV0ZSByb3dzIG9mIGEgWUFORyBsaXN0IHRoYXQgaGFzIGVudHJpZXMgdGhhdCBh cmUgYm90aCBjb25maWcgaXMgdHJ1ZSBhbmQgY29uZmlnIGlzIGZhbHNlLiBUaGUgcm93cyB0aGF0 IGFyZSBjb25maWcgaXMgZmFsc2UgYXJlIHRoZSBvbmx5IHJvd3MgdGhhdCBjYW4gYmUgYWZmZWN0 ZWQgYnkgdGhlIGN1c3RvbSBORVRDT05GIFJQQ3M7IHRoZSBvdGhlciByb3dzIGFyZSBhZmZlY3Rl ZCBvbmx5IGJ5IHRoZSBzdGFuZGFyZCBORVRDT05GIG1hbmFnZW1lbnQgUlBDcy4gSG93ZXZlciwg dGhlcmUgaXMgYSBuZWVkIGZvciBtYW5hZ2VtZW50IG9wZXJhdGlvbnMgdG8gYmUgYWJsZSB0byBy ZW1vdmUgdGhlIHJvd3MgYW5kIHRoZSBvcGVyYXRpb25zIGFzc29jaWF0ZWQgd2l0aCB0aGVtIGZv ciB2YXJpb3VzIHJlYXNvbnMuDQoNClNvIG15IHF1ZXN0aW9uIGlzIHRoaXM6IHdoYXQgaXMgdGhl IGdlbmVyYWwgYXBwcm9hY2ggdG8gdGhpcyBwcm9ibGVtPw0KDQpBcyBtZW50aW9uZWQgYWJvdmUs IGZvciBORVRDT05GLCBJIGJlbGlldmUgdGhlIGFuc3dlciBpcyB0aGF0IGEgY3VzdG9tIFJQQyBo YXMgdG8gYmUgdXNlZC4gQnV0IGlzIHRoaXMgaW50ZW5kZWQgdG8gYmUgdGhlIGNhc2UgZm9yIGFs bCBwcm90b2NvbHMgdGhhdCBjYW4gZGVhbCB3aXRoIFlBTkcgbW9kZWxsZWQgZGF0YT8NCg0KSW4g Y2FzZSBpdCBtYXR0ZXJzLCB0aGUgc3BlY2lmaWMgY2FzZSBJJ20gZGVhbGluZyB3aXRoIGlzIHN1 YnNjcmlwdGlvbnMgYXMgcGVyIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW5ldGNvbmYtcmZjNTI3N2Jpcy0wMSBhbmQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMDQuDQoNClRoYW5rcywNCg0KVGltDQoNCi0tIA0K Q2lzY28gU3lzdGVtcyBDYW5hZGEgQ28uDQoyMDAwIElubm92YXRpb24gRHJpdmUNCkthbmF0YSwg T04sIENhbmFkYSwgSzJLIDNFOA0KUHJlZmVyZW5jZXMgPGh0dHA6Ly93d3cuY2lzY28uY29tL29m ZmVyL3N1YnNjcmliZS8/c2lkPTAwMDQ3ODMyNj4NClVuc3Vic2NyaWJlIDxodHRwOi8vd3d3LmNp c2NvLmNvbS9vZmZlci91bnN1YnNjcmliZS8/c2lkPTAwMDQ3ODMyNz4NClByaXZhY3kgPGh0dHA6 Ly93d3cuY2lzY28uY29tL3dlYi9zaXRlYXNzZXRzL2xlZ2FsL3ByaXZhY3kuaHRtbD4NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWls aW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRtb2QNCg0KDQo= From nobody Mon Dec 12 09:44:04 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFB4129477 for ; Mon, 12 Dec 2016 09:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aa4_1jLHe1SX for ; Mon, 12 Dec 2016 09:44:00 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A4A3129D85 for ; Mon, 12 Dec 2016 09:43:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4153; q=dns/txt; s=iport; t=1481564639; x=1482774239; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Rh+kD7fFDOIwxX1AzTVPtK8Q5+Mfr6dpyMRT5KVlm4w=; b=FDk2m1ic2Up5kAF7/cGmveLQQiQ/Wxx07tWPw2TplbQXJlQqBmowzUR4 OdBjYe6g9ODw0WkfC2WsboviBM7IkqUbEqQFkFwPovQjjHbO5oVbI2ES0 yVqlal1GiG47llQcXq3VG1p1JMzauvc4VuvyXtBJ7qR2S/HKFSJOvCTqE Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAQCP4U5Y/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAR9agQYHjUKsGIIIHguFLkoCgXY/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGkCBAEBTBgIGwIBCA4WASEnCgElAgQBDgUaAgSISg6tdYsOAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYY+gX2CXoFPgnmDMYIwBZprAYZOileQRo4LhA4BHzcwbyQ?= =?us-ascii?q?OAQGDLxyBXXIBBoZ8gQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,337,1477958400"; d="scan'208";a="359907508" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2016 17:43:58 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uBCHhvSa007670 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 12 Dec 2016 17:43:58 GMT Received: from xch-rtp-011.cisco.com (64.101.220.151) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 12 Dec 2016 12:43:57 -0500 Received: from xch-rtp-011.cisco.com ([64.101.220.151]) by XCH-RTP-011.cisco.com ([64.101.220.151]) with mapi id 15.00.1210.000; Mon, 12 Dec 2016 12:43:57 -0500 From: "Tim Jenkins (timjenki)" To: Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] Management Operations on YANG modelled operational data Thread-Index: AQHSVJhoTPiiYH6N+ES2a0NLTclXBqEElW4A Date: Mon, 12 Dec 2016 17:43:57 +0000 Message-ID: <2A9B1ADF-022D-4F47-BAB3-FBFB8E3A44EA@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.238.240] Content-Type: text/plain; charset="utf-7" Content-ID: <69F8A66CF3E38F45B4073C4B3D0B627D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Management Operations on YANG modelled operational data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 17:44:03 -0000 Hi, As an example, say a number of subscribers connect in to a system using NET= CONF, then issue the +ADw-establish-subscription+AD4- RPCs as defined by ht= tps://tools.ietf.org/html/draft-ietf-netconf-rfc5277bis-01. These appear as= entries in the ietf-event-notifications/subscriptions container, which is = +ACI-config false+ACI-. They don't appear in the ietf-event-notifications/s= ubscription-config container since they are not configured+ADs- they are dy= namic. A network manager is examining the system and observes the subscriptions in= the ietf-event-notifications/subscriptions container and decides that some= or all of them should be deleted. Since the network manager may be using a= tool that uses NETCONF (or perhaps some other tool) to remotely manage the= system, what underlying method would be used to delete these subscriptions= ? As mentioned below, as far as I can tell, a standard NETCONF management RPC= like +ADw-edit-config+AD4- cannot be directed at these subscriptions since= config is false. So I'm trying to understand if there is some other genera= l solution for this type of problem for other protocols, or perhaps even fo= r NETCONF other than a custom RPC such as those already defined for this ap= plication specific purpose. Hope this helps... Tim --=20 Cisco Systems Canada Co. 2000 Innovation Drive Kanata, ON, Canada, K2K 3E8 Preferences +ADw-http://www.cisco.com/offer/subscribe/?sid+AD0-000478326+AD= 4- Unsubscribe +ADw-http://www.cisco.com/offer/unsubscribe/?sid+AD0-000478327+= AD4- Privacy +ADw-http://www.cisco.com/web/siteassets/legal/privacy.html+AD4- On 2016-12-12, 11:54 AM, +ACI-Kent Watsen+ACI- +ADw-kwatsen+AEA-juniper.net= +AD4- wrote: Hi Tim, =20 I don+IBk-t understand your problem. Which parts in the referenced dra= fts should we look at, or can you provide an example? =20 Thanks, Kent =20 =20 =20 Hi, =20 I have a general question related to management operations on operation= al data. The question is intended to be protocol agnostic, since as I under= stand it, the NETCONF management operations do not apply to data modelled i= n YANG where config is false. In other words, there is no generic NETCONF R= PC that will, for example, delete entries in a table of operational data. =20 My question arises because we are implementing a feature that is define= d using YANG, and has custom NETCONF RPCs whose operations can create, modi= fy and delete rows of a YANG list that has entries that are both config is = true and config is false. The rows that are config is false are the only ro= ws that can be affected by the custom NETCONF RPCs+ADs- the other rows are = affected only by the standard NETCONF management RPCs. However, there is a = need for management operations to be able to remove the rows and the operat= ions associated with them for various reasons. =20 So my question is this: what is the general approach to this problem? =20 As mentioned above, for NETCONF, I believe the answer is that a custom = RPC has to be used. But is this intended to be the case for all protocols t= hat can deal with YANG modelled data? =20 In case it matters, the specific case I'm dealing with is subscriptions= as per https://tools.ietf.org/html/draft-ietf-netconf-rfc5277bis-01 and ht= tps://tools.ietf.org/html/draft-ietf-netconf-yang-push-04. =20 Thanks, =20 Tim =20 --=20 Cisco Systems Canada Co. 2000 Innovation Drive Kanata, ON, Canada, K2K 3E8 Preferences +ADw-http://www.cisco.com/offer/subscribe/?sid+AD0-00047832= 6+AD4- Unsubscribe +ADw-http://www.cisco.com/offer/unsubscribe/?sid+AD0-000478= 327+AD4- Privacy +ADw-http://www.cisco.com/web/siteassets/legal/privacy.html+AD4= - =20 +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw= BfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw- netmod mailing list netmod+AEA-ietf.org https://www.ietf.org/mailman/listinfo/netmod =20 =20 =20 From nobody Mon Dec 12 13:04:24 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450F11294EB for ; Mon, 12 Dec 2016 13:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oa6R4Qxva517 for ; Mon, 12 Dec 2016 13:04:19 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0098.outbound.protection.outlook.com [104.47.36.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2A9129483 for ; Mon, 12 Dec 2016 13:04:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rUwHAFVVu84LmljkuSEyKsPxcoJVtQZMt6WsSU5OmRc=; b=VP33CiGMSHkoE07WgayVsib6dryUEL4D7gpfEki0SsFMWqIl6CgHTeoNJ6XHgUiEbWcitekeelpE2edUZVJwFPgIMVLhZzwLvAwlDdIvM3kuYBzAqfqLEdgTJ+Q2XYp1Y/bFTEyVZnjwttUOvJoXcOnty/kPRYF9MJjYshgmCDE= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.5; Mon, 12 Dec 2016 21:04:18 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0789.007; Mon, 12 Dec 2016 21:04:18 +0000 From: Kent Watsen To: "Tim Jenkins (timjenki)" , "netmod@ietf.org" Thread-Topic: [netmod] Management Operations on YANG modelled operational data Thread-Index: AQHSVJhoTPiiYH6N+ES2a0NLTclXBqEElW4A///kKIA= Date: Mon, 12 Dec 2016 21:04:17 +0000 Message-ID: References: <2A9B1ADF-022D-4F47-BAB3-FBFB8E3A44EA@cisco.com> In-Reply-To: <2A9B1ADF-022D-4F47-BAB3-FBFB8E3A44EA@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1c.1.161117 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: 5cf77cbb-e47d-4df4-8367-08d422d26fdf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1442; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:Fys5B7phSkLbOuNCZOiLHsz7/JlaWOC8lpkkVgdg3yplNvH+E33+Sw/e7sHe21PdpKgPgXUXUIGptk0bfeyOubPxqWqG1FPCXAAqYMM3YbiGdaJnK9veejcUPme7LhZUUTY9qPWdSCZHXmQOgzRKiyrUj72R4XUTUfNeycCs4XEXLC/DmW1bJk2xDYDyf4QiYUEJhXPPNTmL1V5FPqrTxlX1M9WSQGxBAZyANKdQqHlz5DtoZoKWI06UqfgYRg70CMFws5vNOoAQ3qZZv79lN0C1MzkEf0F/JbzhfxliK1qO6Scuajt+1FfUl3D2QMY5hoAdilb0aDNQ/ddSGUY5d8281CO8ipc43v9HCbgFjujPys7iAlFzQL7lSFYpBc2/K2BgkXCanxvb4w1NP6LBFyE8CtEl1e50OIZHqMqZbO9o7r2q7uB20QNO0bG10GudIW2/t42nXtbrK6GCbgawzQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(114627819485645)(95692535739014)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0154C61618 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39850400002)(39450400003)(39410400002)(39860400002)(199003)(377454003)(24454002)(51914003)(377424004)(189002)(129404003)(66066001)(4001350100001)(4001150100001)(5001770100001)(97736004)(82746002)(83506001)(8676002)(81166006)(36756003)(2906002)(3660700001)(6486002)(77096006)(122556002)(19273905006)(2950100002)(5660300001)(8936002)(54356999)(76176999)(102836003)(50986999)(105586002)(68736007)(106116001)(107886002)(86362001)(6436002)(81156014)(6506006)(83716003)(6512006)(3280700002)(189998001)(38730400001)(101416001)(106356001)(99286002)(33656002)(2501003)(92566002)(229853002)(6116002)(3846002)(7736002)(2900100001)(305945005)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <075B8BDEE9CE0B47B0CF1B2D1031219C@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2016 21:04:17.9306 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: Re: [netmod] Management Operations on YANG modelled operational data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 21:04:22 -0000 SGkgVGltLA0KDQpUaGFua3MgZm9yIHRoZSBkZXRhaWxlZCBleGFtcGxlLiAgSeKAmWxsIGJlIGlu dGVyZXN0ZWQgdG8gc2VlIGlmIGFueW9uZSBlbHNlIGhhcyBhIGJldHRlciBzdWdnZXN0aW9uLCBi dXQgbXkgaW5jbGluYXRpb24gaXMgdG8gYWdyZWUgd2l0aCB5b3VyIGlkZWEgb2YgdXNpbmcgYW4g UlBDIChvciBhY3Rpb24pIHN0YXRlbWVudCB0byByZW1vdmUgdGhlc2UgZHluYW1pYyBlbnRyaWVz LiAgUmVtb3ZpbmcgZW50cmllcyB3aXRoIGFuIFJQQyB0aGF0IHdlcmUgY3JlYXRlZCB3aXRoIGFu IFJQQyBoYXMgYSBuaWNlIHN5bW1ldHJ5IHRvIGl0LiAgDQoNCknigJltIHVuc3VyZSBhYm91dCB5 b3VyIGNvbmNlcm4gZm9yIG90aGVyIHByb3RvY29sczsgcHJlc3VtYWJseSBhbGwgcHJvdG9jb2xz IHN1cHBvcnRpbmcgWUFORyBkYXRhIG1vZGVscyB3b3VsZCBzdXBwb3J0IHRoZSBSUEMvYWN0aW9u cyBzdGF0ZW1lbnRzIGFzIHdlbGwsIHJpZ2h0Pw0KDQpUaGFua3MsDQpLZW50DQoNCg0KDQpIaSwN Cg0KQXMgYW4gZXhhbXBsZSwgc2F5IGEgbnVtYmVyIG9mIHN1YnNjcmliZXJzIGNvbm5lY3QgaW4g dG8gYSBzeXN0ZW0gdXNpbmcgTkVUQ09ORiwgdGhlbiBpc3N1ZSB0aGUgPGVzdGFibGlzaC1zdWJz Y3JpcHRpb24+IFJQQ3MgYXMgZGVmaW5lZCBieSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzUyNzdiaXMtMDEuIFRoZXNlIGFwcGVhciBhcyBlbnRyaWVz IGluIHRoZSBpZXRmLWV2ZW50LW5vdGlmaWNhdGlvbnMvc3Vic2NyaXB0aW9ucyBjb250YWluZXIs IHdoaWNoIGlzICJjb25maWcgZmFsc2UiLiBUaGV5IGRvbid0IGFwcGVhciBpbiB0aGUgaWV0Zi1l dmVudC1ub3RpZmljYXRpb25zL3N1YnNjcmlwdGlvbi1jb25maWcgY29udGFpbmVyIHNpbmNlIHRo ZXkgYXJlIG5vdCBjb25maWd1cmVkOyB0aGV5IGFyZSBkeW5hbWljLg0KDQpBIG5ldHdvcmsgbWFu YWdlciBpcyBleGFtaW5pbmcgdGhlIHN5c3RlbSBhbmQgb2JzZXJ2ZXMgdGhlIHN1YnNjcmlwdGlv bnMgaW4gdGhlIGlldGYtZXZlbnQtbm90aWZpY2F0aW9ucy9zdWJzY3JpcHRpb25zIGNvbnRhaW5l ciBhbmQgZGVjaWRlcyB0aGF0IHNvbWUgb3IgYWxsIG9mIHRoZW0gc2hvdWxkIGJlIGRlbGV0ZWQu IFNpbmNlIHRoZSBuZXR3b3JrIG1hbmFnZXIgbWF5IGJlIHVzaW5nIGEgdG9vbCB0aGF0IHVzZXMg TkVUQ09ORiAob3IgcGVyaGFwcyBzb21lIG90aGVyIHRvb2wpIHRvIHJlbW90ZWx5IG1hbmFnZSB0 aGUgc3lzdGVtLCB3aGF0IHVuZGVybHlpbmcgbWV0aG9kIHdvdWxkIGJlIHVzZWQgdG8gZGVsZXRl IHRoZXNlIHN1YnNjcmlwdGlvbnM/DQoNCkFzIG1lbnRpb25lZCBiZWxvdywgYXMgZmFyIGFzIEkg Y2FuIHRlbGwsIGEgc3RhbmRhcmQgTkVUQ09ORiBtYW5hZ2VtZW50IFJQQyBsaWtlIDxlZGl0LWNv bmZpZz4gY2Fubm90IGJlIGRpcmVjdGVkIGF0IHRoZXNlIHN1YnNjcmlwdGlvbnMgc2luY2UgY29u ZmlnIGlzIGZhbHNlLiBTbyBJJ20gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgaWYgdGhlcmUgaXMgc29t ZSBvdGhlciBnZW5lcmFsIHNvbHV0aW9uIGZvciB0aGlzIHR5cGUgb2YgcHJvYmxlbSBmb3Igb3Ro ZXIgcHJvdG9jb2xzLCBvciBwZXJoYXBzIGV2ZW4gZm9yIE5FVENPTkYgb3RoZXIgdGhhbiBhIGN1 c3RvbSBSUEMgc3VjaCBhcyB0aG9zZSBhbHJlYWR5IGRlZmluZWQgZm9yIHRoaXMgYXBwbGljYXRp b24gc3BlY2lmaWMgcHVycG9zZS4NCg0KSG9wZSB0aGlzIGhlbHBzLi4uDQoNClRpbQ0KDQotLSAN CkNpc2NvIFN5c3RlbXMgQ2FuYWRhIENvLg0KMjAwMCBJbm5vdmF0aW9uIERyaXZlDQpLYW5hdGEs IE9OLCBDYW5hZGEsIEsySyAzRTgNClByZWZlcmVuY2VzIDxodHRwOi8vd3d3LmNpc2NvLmNvbS9v ZmZlci9zdWJzY3JpYmUvP3NpZD0wMDA0NzgzMjY+DQpVbnN1YnNjcmliZSA8aHR0cDovL3d3dy5j aXNjby5jb20vb2ZmZXIvdW5zdWJzY3JpYmUvP3NpZD0wMDA0NzgzMjc+DQpQcml2YWN5IDxodHRw Oi8vd3d3LmNpc2NvLmNvbS93ZWIvc2l0ZWFzc2V0cy9sZWdhbC9wcml2YWN5Lmh0bWw+DQoNCg0K DQoNCk9uIDIwMTYtMTItMTIsIDExOjU0IEFNLCAiS2VudCBXYXRzZW4iIDxrd2F0c2VuQGp1bmlw ZXIubmV0PiB3cm90ZToNCg0KICAgIEhpIFRpbSwNCiAgICANCiAgICBJIGRvbuKAmXQgdW5kZXJz dGFuZCB5b3VyIHByb2JsZW0uICBXaGljaCBwYXJ0cyBpbiB0aGUgcmVmZXJlbmNlZCBkcmFmdHMg c2hvdWxkIHdlIGxvb2sgYXQsIG9yIGNhbiB5b3UgcHJvdmlkZSBhbiBleGFtcGxlPw0KICAgIA0K ICAgIFRoYW5rcywNCiAgICBLZW50DQogICAgDQogICAgDQogICAgDQogICAgSGksDQogICAgDQog ICAgSSBoYXZlIGEgZ2VuZXJhbCBxdWVzdGlvbiByZWxhdGVkIHRvIG1hbmFnZW1lbnQgb3BlcmF0 aW9ucyBvbiBvcGVyYXRpb25hbCBkYXRhLiBUaGUgcXVlc3Rpb24gaXMgaW50ZW5kZWQgdG8gYmUg cHJvdG9jb2wgYWdub3N0aWMsIHNpbmNlIGFzIEkgdW5kZXJzdGFuZCBpdCwgdGhlIE5FVENPTkYg bWFuYWdlbWVudCBvcGVyYXRpb25zIGRvIG5vdCBhcHBseSB0byBkYXRhIG1vZGVsbGVkIGluIFlB Tkcgd2hlcmUgY29uZmlnIGlzIGZhbHNlLiBJbiBvdGhlciB3b3JkcywgdGhlcmUgaXMgbm8gZ2Vu ZXJpYyBORVRDT05GIFJQQyB0aGF0IHdpbGwsIGZvciBleGFtcGxlLCBkZWxldGUgZW50cmllcyBp biBhIHRhYmxlIG9mIG9wZXJhdGlvbmFsIGRhdGEuDQogICAgDQogICAgTXkgcXVlc3Rpb24gYXJp c2VzIGJlY2F1c2Ugd2UgYXJlIGltcGxlbWVudGluZyBhIGZlYXR1cmUgdGhhdCBpcyBkZWZpbmVk IHVzaW5nIFlBTkcsIGFuZCBoYXMgY3VzdG9tIE5FVENPTkYgUlBDcyB3aG9zZSBvcGVyYXRpb25z IGNhbiBjcmVhdGUsIG1vZGlmeSBhbmQgZGVsZXRlIHJvd3Mgb2YgYSBZQU5HIGxpc3QgdGhhdCBo YXMgZW50cmllcyB0aGF0IGFyZSBib3RoIGNvbmZpZyBpcyB0cnVlIGFuZCBjb25maWcgaXMgZmFs c2UuIFRoZSByb3dzIHRoYXQgYXJlIGNvbmZpZyBpcyBmYWxzZSBhcmUgdGhlIG9ubHkgcm93cyB0 aGF0IGNhbiBiZSBhZmZlY3RlZCBieSB0aGUgY3VzdG9tIE5FVENPTkYgUlBDczsgdGhlIG90aGVy IHJvd3MgYXJlIGFmZmVjdGVkIG9ubHkgYnkgdGhlIHN0YW5kYXJkIE5FVENPTkYgbWFuYWdlbWVu dCBSUENzLiBIb3dldmVyLCB0aGVyZSBpcyBhIG5lZWQgZm9yIG1hbmFnZW1lbnQgb3BlcmF0aW9u cyB0byBiZSBhYmxlIHRvIHJlbW92ZSB0aGUgcm93cyBhbmQgdGhlIG9wZXJhdGlvbnMgYXNzb2Np YXRlZCB3aXRoIHRoZW0gZm9yIHZhcmlvdXMgcmVhc29ucy4NCiAgICANCiAgICBTbyBteSBxdWVz dGlvbiBpcyB0aGlzOiB3aGF0IGlzIHRoZSBnZW5lcmFsIGFwcHJvYWNoIHRvIHRoaXMgcHJvYmxl bT8NCiAgICANCiAgICBBcyBtZW50aW9uZWQgYWJvdmUsIGZvciBORVRDT05GLCBJIGJlbGlldmUg dGhlIGFuc3dlciBpcyB0aGF0IGEgY3VzdG9tIFJQQyBoYXMgdG8gYmUgdXNlZC4gQnV0IGlzIHRo aXMgaW50ZW5kZWQgdG8gYmUgdGhlIGNhc2UgZm9yIGFsbCBwcm90b2NvbHMgdGhhdCBjYW4gZGVh bCB3aXRoIFlBTkcgbW9kZWxsZWQgZGF0YT8NCiAgICANCiAgICBJbiBjYXNlIGl0IG1hdHRlcnMs IHRoZSBzcGVjaWZpYyBjYXNlIEknbSBkZWFsaW5nIHdpdGggaXMgc3Vic2NyaXB0aW9ucyBhcyBw ZXIgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1yZmM1Mjc3 YmlzLTAxIGFuZCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25m LXlhbmctcHVzaC0wNC4NCiAgICANCiAgICBUaGFua3MsDQogICAgDQogICAgVGltDQogICAgDQog ICAgLS0gDQogICAgQ2lzY28gU3lzdGVtcyBDYW5hZGEgQ28uDQogICAgMjAwMCBJbm5vdmF0aW9u IERyaXZlDQogICAgS2FuYXRhLCBPTiwgQ2FuYWRhLCBLMksgM0U4DQogICAgUHJlZmVyZW5jZXMg PGh0dHA6Ly93d3cuY2lzY28uY29tL29mZmVyL3N1YnNjcmliZS8/c2lkPTAwMDQ3ODMyNj4NCiAg ICBVbnN1YnNjcmliZSA8aHR0cDovL3d3dy5jaXNjby5jb20vb2ZmZXIvdW5zdWJzY3JpYmUvP3Np ZD0wMDA0NzgzMjc+DQogICAgUHJpdmFjeSA8aHR0cDovL3d3dy5jaXNjby5jb20vd2ViL3NpdGVh c3NldHMvbGVnYWwvcHJpdmFjeS5odG1sPg0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgbmV0bW9kIG1haWxpbmcgbGlzdA0KICAg IG5ldG1vZEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kDQogICAgDQogICAgDQogICAgDQoNCg0KDQo= From nobody Mon Dec 12 13:23:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292F8129470 for ; Mon, 12 Dec 2016 13:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEHf32gaFDsY for ; Mon, 12 Dec 2016 13:23:24 -0800 (PST) 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 D026B126BF7 for ; Mon, 12 Dec 2016 13:23:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6273; q=dns/txt; s=iport; t=1481577803; x=1482787403; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=YVdnc10TjY7WilgbbZk5SnDBS9371FqRVOMfdRCXoIE=; b=GVDI0LAHipOrb4Ot+K6FDgMsaHS52ZzB1njHjCb5+IuESqm+qnv5rzLx 7FGBHXisfFZse0nRrofkmAqO3sxsuXdw77yNosyOfEJp2Nw2h6FCHvgAr RvRCklJcnfo22q5mm0ofFRFT3sTquU5GaEpoLu0G2WhnGqKK1+yIpsEec A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAQALFU9Y/49dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgywLAQEBAQEfWoEGB41CrBmCCB4LhS5KAoF4PxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRpAgQBAUwYCBsCAQgOFgEhJwoBJQIEAQ4FGgIEiEoOriiLEAEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR2GPoF9CIJWgU+CeYMxgjAFmmsBhk6KV5BGjguEDgEfN4E?= =?us-ascii?q?fJA4BAYMvHIFdcgEGhnyBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,338,1477958400"; d="scan'208";a="186097200" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2016 21:23:02 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id uBCLN1r3022367 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 12 Dec 2016 21:23:02 GMT Received: from xch-rtp-011.cisco.com (64.101.220.151) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 12 Dec 2016 16:23:01 -0500 Received: from xch-rtp-011.cisco.com ([64.101.220.151]) by XCH-RTP-011.cisco.com ([64.101.220.151]) with mapi id 15.00.1210.000; Mon, 12 Dec 2016 16:23:01 -0500 From: "Tim Jenkins (timjenki)" To: Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] Management Operations on YANG modelled operational data Thread-Index: AQHSVJhoTPiiYH6N+ES2a0NLTclXBqEElW4A///kKICAAFkNAA== Date: Mon, 12 Dec 2016 21:23:01 +0000 Message-ID: References: <2A9B1ADF-022D-4F47-BAB3-FBFB8E3A44EA@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.238.240] Content-Type: text/plain; charset="utf-7" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Management Operations on YANG modelled operational data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 21:23:26 -0000 Embedded +ADwAPA-Tim+AD4APg-. On 2016-12-12, 4:04 PM, +ACI-Kent Watsen+ACI- +ADw-kwatsen+AEA-juniper.net+= AD4- wrote: Hi Tim, =20 Thanks for the detailed example. I+IBk-ll be interested to see if anyo= ne else has a better suggestion, but my inclination is to agree with your i= dea of using an RPC (or action) statement to remove these dynamic entries. = Removing entries with an RPC that were created with an RPC has a nice symm= etry to it. =20 +ADwAPA-Tim+AD4APg- In this specific case, yes, and we already have an RPC = designed to delete a subscription, but it's intended use is by the entity t= hat established the subscription. So in that sense the symmetry is broken. = If we re-use it for management operations, we have some language changes th= at are needed. =20 I+IBk-m unsure about your concern for other protocols+ADs- presumably a= ll protocols supporting YANG data models would support the RPC/actions stat= ements as well, right? +ADwAPA-Tim+AD4APg- In general, I would assume yes, but it may be that othe= r protocols have different definitions of what the generic management opera= tions are permitted to do. They may be less strict for example in saying th= at edit/delete/modify operations cannot touch data that is marked as config= false. Presumably there's a greater risk of side effects, but those protoc= ols may choose to allow the operations and let the user beware. Perhaps if = I had more history with YANG and NETCONF I would know if the management pro= hibitions on config false modelled data comes from YANG modelling or if it = comes from NETCONF protocol definition, then it would be clearer. Maybe tha= t's the question that I'm actually asking. =20 Thanks, Kent =20 =20 =20 Hi, =20 As an example, say a number of subscribers connect in to a system using= NETCONF, then issue the +ADw-establish-subscription+AD4- RPCs as defined b= y https://tools.ietf.org/html/draft-ietf-netconf-rfc5277bis-01. These appea= r as entries in the ietf-event-notifications/subscriptions container, which= is +ACI-config false+ACI-. They don't appear in the ietf-event-notificatio= ns/subscription-config container since they are not configured+ADs- they ar= e dynamic. =20 A network manager is examining the system and observes the subscription= s in the ietf-event-notifications/subscriptions container and decides that = some or all of them should be deleted. Since the network manager may be usi= ng a tool that uses NETCONF (or perhaps some other tool) to remotely manage= the system, what underlying method would be used to delete these subscript= ions? =20 As mentioned below, as far as I can tell, a standard NETCONF management= RPC like +ADw-edit-config+AD4- cannot be directed at these subscriptions s= ince config is false. So I'm trying to understand if there is some other ge= neral solution for this type of problem for other protocols, or perhaps eve= n for NETCONF other than a custom RPC such as those already defined for thi= s application specific purpose. =20 Hope this helps... =20 Tim =20 --=20 Cisco Systems Canada Co. 2000 Innovation Drive Kanata, ON, Canada, K2K 3E8 Preferences +ADw-http://www.cisco.com/offer/subscribe/?sid+AD0-00047832= 6+AD4- Unsubscribe +ADw-http://www.cisco.com/offer/unsubscribe/?sid+AD0-000478= 327+AD4- Privacy +ADw-http://www.cisco.com/web/siteassets/legal/privacy.html+AD4= - =20 =20 =20 =20 On 2016-12-12, 11:54 AM, +ACI-Kent Watsen+ACI- +ADw-kwatsen+AEA-juniper= .net+AD4- wrote: =20 Hi Tim, =20 I don+IBk-t understand your problem. Which parts in the referenced= drafts should we look at, or can you provide an example? =20 Thanks, Kent =20 =20 =20 Hi, =20 I have a general question related to management operations on opera= tional data. The question is intended to be protocol agnostic, since as I u= nderstand it, the NETCONF management operations do not apply to data modell= ed in YANG where config is false. In other words, there is no generic NETCO= NF RPC that will, for example, delete entries in a table of operational dat= a. =20 My question arises because we are implementing a feature that is de= fined using YANG, and has custom NETCONF RPCs whose operations can create, = modify and delete rows of a YANG list that has entries that are both config= is true and config is false. The rows that are config is false are the onl= y rows that can be affected by the custom NETCONF RPCs+ADs- the other rows = are affected only by the standard NETCONF management RPCs. However, there i= s a need for management operations to be able to remove the rows and the op= erations associated with them for various reasons. =20 So my question is this: what is the general approach to this proble= m? =20 As mentioned above, for NETCONF, I believe the answer is that a cus= tom RPC has to be used. But is this intended to be the case for all protoco= ls that can deal with YANG modelled data? =20 In case it matters, the specific case I'm dealing with is subscript= ions as per https://tools.ietf.org/html/draft-ietf-netconf-rfc5277bis-01 an= d https://tools.ietf.org/html/draft-ietf-netconf-yang-push-04. =20 Thanks, =20 Tim =20 --=20 Cisco Systems Canada Co. 2000 Innovation Drive Kanata, ON, Canada, K2K 3E8 Preferences +ADw-http://www.cisco.com/offer/subscribe/?sid+AD0-0004= 78326+AD4- Unsubscribe +ADw-http://www.cisco.com/offer/unsubscribe/?sid+AD0-00= 0478327+AD4- Privacy +ADw-http://www.cisco.com/web/siteassets/legal/privacy.html= +AD4- =20 +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF= 8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw- netmod mailing list netmod+AEA-ietf.org https://www.ietf.org/mailman/listinfo/netmod =20 =20 =20 =20 =20 =20 =20 From nobody Mon Dec 12 15:13:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C702E129EE5 for ; Mon, 12 Dec 2016 15:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 6Rdi3I9ePjam for ; Mon, 12 Dec 2016 15:13:29 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB43129F77 for ; Mon, 12 Dec 2016 15:10:29 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D7E6FE74; Tue, 13 Dec 2016 00:10:27 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id KxGSOGNNT9P2; Tue, 13 Dec 2016 00:10:26 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 13 Dec 2016 00:10:27 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 32DAF20069; Tue, 13 Dec 2016 00:10:31 +0100 (CET) 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 amS_4QRr5-ue; Tue, 13 Dec 2016 00:10:26 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 848FB20067; Tue, 13 Dec 2016 00:10:30 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 414DB3DB59D1; Tue, 13 Dec 2016 00:10:26 +0100 (CET) Date: Tue, 13 Dec 2016 00:10:26 +0100 From: Juergen Schoenwaelder To: "Tim Jenkins (timjenki)" Message-ID: <20161212231026.GA153@elstar.local> Mail-Followup-To: "Tim Jenkins (timjenki)" , Kent Watsen , "netmod@ietf.org" References: <2A9B1ADF-022D-4F47-BAB3-FBFB8E3A44EA@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <2A9B1ADF-022D-4F47-BAB3-FBFB8E3A44EA@cisco.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Management Operations on YANG modelled operational data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 23:13:33 -0000 The proper action in this case may be to kill the NETCONF session. It can be debated whether simply deleting state created by some other system (the subscription in this case) is a proper management approach since it may lead to undefined or erratic behaviour of other systems or to loops where some systems create state that others delete and so on. /js On Mon, Dec 12, 2016 at 05:43:57PM +0000, Tim Jenkins (timjenki) wrote: > Hi, > > As an example, say a number of subscribers connect in to a system using NETCONF, then issue the RPCs as defined by https://tools.ietf.org/html/draft-ietf-netconf-rfc5277bis-01. These appear as entries in the ietf-event-notifications/subscriptions container, which is "config false". They don't appear in the ietf-event-notifications/subscription-config container since they are not configured; they are dynamic. > > A network manager is examining the system and observes the subscriptions in the ietf-event-notifications/subscriptions container and decides that some or all of them should be deleted. Since the network manager may be using a tool that uses NETCONF (or perhaps some other tool) to remotely manage the system, what underlying method would be used to delete these subscriptions? > > As mentioned below, as far as I can tell, a standard NETCONF management RPC like cannot be directed at these subscriptions since config is false. So I'm trying to understand if there is some other general solution for this type of problem for other protocols, or perhaps even for NETCONF other than a custom RPC such as those already defined for this application specific purpose. > > Hope this helps... > > Tim > > -- > Cisco Systems Canada Co. > 2000 Innovation Drive > Kanata, ON, Canada, K2K 3E8 > Preferences > Unsubscribe > Privacy > > > > > On 2016-12-12, 11:54 AM, "Kent Watsen" wrote: > > Hi Tim, > > I don’t understand your problem. Which parts in the referenced drafts should we look at, or can you provide an example? > > Thanks, > Kent > > > > Hi, > > I have a general question related to management operations on operational data. The question is intended to be protocol agnostic, since as I understand it, the NETCONF management operations do not apply to data modelled in YANG where config is false. In other words, there is no generic NETCONF RPC that will, for example, delete entries in a table of operational data. > > My question arises because we are implementing a feature that is defined using YANG, and has custom NETCONF RPCs whose operations can create, modify and delete rows of a YANG list that has entries that are both config is true and config is false. The rows that are config is false are the only rows that can be affected by the custom NETCONF RPCs; the other rows are affected only by the standard NETCONF management RPCs. However, there is a need for management operations to be able to remove the rows and the operations associated with them for various reasons. > > So my question is this: what is the general approach to this problem? > > As mentioned above, for NETCONF, I believe the answer is that a custom RPC has to be used. But is this intended to be the case for all protocols that can deal with YANG modelled data? > > In case it matters, the specific case I'm dealing with is subscriptions as per https://tools.ietf.org/html/draft-ietf-netconf-rfc5277bis-01 and https://tools.ietf.org/html/draft-ietf-netconf-yang-push-04. > > Thanks, > > Tim > > -- > Cisco Systems Canada Co. > 2000 Innovation Drive > Kanata, ON, Canada, K2K 3E8 > Preferences > Unsubscribe > Privacy > > _______________________________________________ > 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 Mon Dec 12 15:31:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728181297D6 for ; Mon, 12 Dec 2016 15:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qczR0yw99WCX for ; Mon, 12 Dec 2016 15:31:47 -0800 (PST) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 06920129EB8 for ; Mon, 12 Dec 2016 15:31:41 -0800 (PST) Received: (qmail 11186 invoked by uid 0); 12 Dec 2016 23:31:39 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy4.mail.unifiedlayer.com with SMTP; 12 Dec 2016 23:31:39 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id KBXb1u01A2SSUrH01BXeRk; Mon, 12 Dec 2016 16:31:39 -0700 X-Authority-Analysis: v=2.1 cv=DKocvU9b c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=S-Y1Hbe0nFAA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=n5n_aSjo0skA:10 a=p48BXsAlf3bYlEjPzqgA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Cc:To:Subject:From; bh=ag/05OXYA7VXrKxyazp2eDmMMXZPcZJUvWf+ScGEvJ4=; b=yUYlD+DtlWVatCqzYAMFm4Ttka ITelbWsMHmbbYA6QhOJgo/W9IwN4pdkEzKb05NsNB34Fu5fVcE6mkIQ5rHjfDqZ3FyNEka0Zev+vl rY/H8J7m3HJo3CUT2yH/Povhy; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:56935 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1cGa4F-0006uQ-QX; Mon, 12 Dec 2016 16:31:35 -0700 From: Lou Berger To: NetMod WG Message-ID: Date: Mon, 12 Dec 2016 18:31:33 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cGa4F-0006uQ-QX X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:56935 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: NetMod WG Chairs Subject: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 23:31:48 -0000 All, This is start of a two week* poll on making draft-wilton-netmod-intf-vlan-yang-04 a NetMod working group document. Please send email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your reservations with the document. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. * Given the holiday, the poll ends December 28. Thank you, NetMod WG Chairs From nobody Mon Dec 12 23:35:59 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C221299B6 for ; Mon, 12 Dec 2016 23:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 aCe3v7ruARCh for ; Mon, 12 Dec 2016 23:35:54 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB011299B4 for ; Mon, 12 Dec 2016 23:35:54 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 124951AE028C; Tue, 13 Dec 2016 08:35:52 +0100 (CET) Date: Tue, 13 Dec 2016 08:35:50 +0100 (CET) Message-Id: <20161213.083550.21127702219390850.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20161212231026.GA153@elstar.local> References: <2A9B1ADF-022D-4F47-BAB3-FBFB8E3A44EA@cisco.com> <20161212231026.GA153@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: timjenki@cisco.com, netmod@ietf.org Subject: Re: [netmod] Management Operations on YANG modelled operational data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 07:35:56 -0000 SnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku ZGU+IHdyb3RlOg0KPiBUaGUgcHJvcGVyIGFjdGlvbiBpbiB0aGlzIGNhc2UgbWF5IGJlIHRvIGtp bGwgdGhlIE5FVENPTkYgc2Vzc2lvbi4NCj4gDQo+IEl0IGNhbiBiZSBkZWJhdGVkIHdoZXRoZXIg c2ltcGx5IGRlbGV0aW5nIHN0YXRlIGNyZWF0ZWQgYnkgc29tZSBvdGhlcg0KPiBzeXN0ZW0gKHRo ZSBzdWJzY3JpcHRpb24gaW4gdGhpcyBjYXNlKSBpcyBhIHByb3BlciBtYW5hZ2VtZW50IGFwcHJv YWNoDQo+IHNpbmNlIGl0IG1heSBsZWFkIHRvIHVuZGVmaW5lZCBvciBlcnJhdGljIGJlaGF2aW91 ciBvZiBvdGhlciBzeXN0ZW1zDQo+IG9yIHRvIGxvb3BzIHdoZXJlIHNvbWUgc3lzdGVtcyBjcmVh dGUgc3RhdGUgdGhhdCBvdGhlcnMgZGVsZXRlIGFuZCBzbw0KPiBvbi4NCg0KKzENCg0KDQovbWFy dGluDQoNCj4gDQo+IC9qcw0KPiANCj4gT24gTW9uLCBEZWMgMTIsIDIwMTYgYXQgMDU6NDM6NTdQ TSArMDAwMCwgVGltIEplbmtpbnMgKHRpbWplbmtpKSB3cm90ZToNCj4gPiBIaSwNCj4gPiANCj4g PiBBcyBhbiBleGFtcGxlLCBzYXkgYSBudW1iZXIgb2Ygc3Vic2NyaWJlcnMgY29ubmVjdCBpbiB0 byBhIHN5c3RlbSB1c2luZyBORVRDT05GLCB0aGVuIGlzc3VlIHRoZSA8ZXN0YWJsaXNoLXN1YnNj cmlwdGlvbj4gUlBDcyBhcyBkZWZpbmVkIGJ5IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLW5ldGNvbmYtcmZjNTI3N2Jpcy0wMS4gVGhlc2UgYXBwZWFyIGFzIGVudHJpZXMg aW4gdGhlIGlldGYtZXZlbnQtbm90aWZpY2F0aW9ucy9zdWJzY3JpcHRpb25zIGNvbnRhaW5lciwg d2hpY2ggaXMgImNvbmZpZyBmYWxzZSIuIFRoZXkgZG9uJ3QgYXBwZWFyIGluIHRoZSBpZXRmLWV2 ZW50LW5vdGlmaWNhdGlvbnMvc3Vic2NyaXB0aW9uLWNvbmZpZyBjb250YWluZXIgc2luY2UgdGhl eSBhcmUgbm90IGNvbmZpZ3VyZWQ7IHRoZXkgYXJlIGR5bmFtaWMuDQo+ID4gDQo+ID4gQSBuZXR3 b3JrIG1hbmFnZXIgaXMgZXhhbWluaW5nIHRoZSBzeXN0ZW0gYW5kIG9ic2VydmVzIHRoZSBzdWJz Y3JpcHRpb25zIGluIHRoZSBpZXRmLWV2ZW50LW5vdGlmaWNhdGlvbnMvc3Vic2NyaXB0aW9ucyBj b250YWluZXIgYW5kIGRlY2lkZXMgdGhhdCBzb21lIG9yIGFsbCBvZiB0aGVtIHNob3VsZCBiZSBk ZWxldGVkLiBTaW5jZSB0aGUgbmV0d29yayBtYW5hZ2VyIG1heSBiZSB1c2luZyBhIHRvb2wgdGhh dCB1c2VzIE5FVENPTkYgKG9yIHBlcmhhcHMgc29tZSBvdGhlciB0b29sKSB0byByZW1vdGVseSBt YW5hZ2UgdGhlIHN5c3RlbSwgd2hhdCB1bmRlcmx5aW5nIG1ldGhvZCB3b3VsZCBiZSB1c2VkIHRv IGRlbGV0ZSB0aGVzZSBzdWJzY3JpcHRpb25zPw0KPiA+IA0KPiA+IEFzIG1lbnRpb25lZCBiZWxv dywgYXMgZmFyIGFzIEkgY2FuIHRlbGwsIGEgc3RhbmRhcmQgTkVUQ09ORiBtYW5hZ2VtZW50IFJQ QyBsaWtlIDxlZGl0LWNvbmZpZz4gY2Fubm90IGJlIGRpcmVjdGVkIGF0IHRoZXNlIHN1YnNjcmlw dGlvbnMgc2luY2UgY29uZmlnIGlzIGZhbHNlLiBTbyBJJ20gdHJ5aW5nIHRvIHVuZGVyc3RhbmQg aWYgdGhlcmUgaXMgc29tZSBvdGhlciBnZW5lcmFsIHNvbHV0aW9uIGZvciB0aGlzIHR5cGUgb2Yg cHJvYmxlbSBmb3Igb3RoZXIgcHJvdG9jb2xzLCBvciBwZXJoYXBzIGV2ZW4gZm9yIE5FVENPTkYg b3RoZXIgdGhhbiBhIGN1c3RvbSBSUEMgc3VjaCBhcyB0aG9zZSBhbHJlYWR5IGRlZmluZWQgZm9y IHRoaXMgYXBwbGljYXRpb24gc3BlY2lmaWMgcHVycG9zZS4NCj4gPiANCj4gPiBIb3BlIHRoaXMg aGVscHMuLi4NCj4gPiANCj4gPiBUaW0NCj4gPiANCj4gPiAtLSANCj4gPiBDaXNjbyBTeXN0ZW1z IENhbmFkYSBDby4NCj4gPiAyMDAwIElubm92YXRpb24gRHJpdmUNCj4gPiBLYW5hdGEsIE9OLCBD YW5hZGEsIEsySyAzRTgNCj4gPiBQcmVmZXJlbmNlcyA8aHR0cDovL3d3dy5jaXNjby5jb20vb2Zm ZXIvc3Vic2NyaWJlLz9zaWQ9MDAwNDc4MzI2Pg0KPiA+IFVuc3Vic2NyaWJlIDxodHRwOi8vd3d3 LmNpc2NvLmNvbS9vZmZlci91bnN1YnNjcmliZS8/c2lkPTAwMDQ3ODMyNz4NCj4gPiBQcml2YWN5 IDxodHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvc2l0ZWFzc2V0cy9sZWdhbC9wcml2YWN5Lmh0bWw+ DQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gT24gMjAxNi0xMi0xMiwgMTE6NTQgQU0sICJL ZW50IFdhdHNlbiIgPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KPiA+IA0KPiA+ICAgICBI aSBUaW0sDQo+ID4gICAgIA0KPiA+ICAgICBJIGRvbuKAmXQgdW5kZXJzdGFuZCB5b3VyIHByb2Js ZW0uICBXaGljaCBwYXJ0cyBpbiB0aGUgcmVmZXJlbmNlZCBkcmFmdHMgc2hvdWxkIHdlIGxvb2sg YXQsIG9yIGNhbiB5b3UgcHJvdmlkZSBhbiBleGFtcGxlPw0KPiA+ICAgICANCj4gPiAgICAgVGhh bmtzLA0KPiA+ICAgICBLZW50DQo+ID4gICAgIA0KPiA+ICAgICANCj4gPiAgICAgDQo+ID4gICAg IEhpLA0KPiA+ICAgICANCj4gPiAgICAgSSBoYXZlIGEgZ2VuZXJhbCBxdWVzdGlvbiByZWxhdGVk IHRvIG1hbmFnZW1lbnQgb3BlcmF0aW9ucyBvbiBvcGVyYXRpb25hbCBkYXRhLiBUaGUgcXVlc3Rp b24gaXMgaW50ZW5kZWQgdG8gYmUgcHJvdG9jb2wgYWdub3N0aWMsIHNpbmNlIGFzIEkgdW5kZXJz dGFuZCBpdCwgdGhlIE5FVENPTkYgbWFuYWdlbWVudCBvcGVyYXRpb25zIGRvIG5vdCBhcHBseSB0 byBkYXRhIG1vZGVsbGVkIGluIFlBTkcgd2hlcmUgY29uZmlnIGlzIGZhbHNlLiBJbiBvdGhlciB3 b3JkcywgdGhlcmUgaXMgbm8gZ2VuZXJpYyBORVRDT05GIFJQQyB0aGF0IHdpbGwsIGZvciBleGFt cGxlLCBkZWxldGUgZW50cmllcyBpbiBhIHRhYmxlIG9mIG9wZXJhdGlvbmFsIGRhdGEuDQo+ID4g ICAgIA0KPiA+ICAgICBNeSBxdWVzdGlvbiBhcmlzZXMgYmVjYXVzZSB3ZSBhcmUgaW1wbGVtZW50 aW5nIGEgZmVhdHVyZSB0aGF0IGlzIGRlZmluZWQgdXNpbmcgWUFORywgYW5kIGhhcyBjdXN0b20g TkVUQ09ORiBSUENzIHdob3NlIG9wZXJhdGlvbnMgY2FuIGNyZWF0ZSwgbW9kaWZ5IGFuZCBkZWxl dGUgcm93cyBvZiBhIFlBTkcgbGlzdCB0aGF0IGhhcyBlbnRyaWVzIHRoYXQgYXJlIGJvdGggY29u ZmlnIGlzIHRydWUgYW5kIGNvbmZpZyBpcyBmYWxzZS4gVGhlIHJvd3MgdGhhdCBhcmUgY29uZmln IGlzIGZhbHNlIGFyZSB0aGUgb25seSByb3dzIHRoYXQgY2FuIGJlIGFmZmVjdGVkIGJ5IHRoZSBj dXN0b20gTkVUQ09ORiBSUENzOyB0aGUgb3RoZXIgcm93cyBhcmUgYWZmZWN0ZWQgb25seSBieSB0 aGUgc3RhbmRhcmQgTkVUQ09ORiBtYW5hZ2VtZW50IFJQQ3MuIEhvd2V2ZXIsIHRoZXJlIGlzIGEg bmVlZCBmb3IgbWFuYWdlbWVudCBvcGVyYXRpb25zIHRvIGJlIGFibGUgdG8gcmVtb3ZlIHRoZSBy b3dzIGFuZCB0aGUgb3BlcmF0aW9ucyBhc3NvY2lhdGVkIHdpdGggdGhlbSBmb3IgdmFyaW91cyBy ZWFzb25zLg0KPiA+ICAgICANCj4gPiAgICAgU28gbXkgcXVlc3Rpb24gaXMgdGhpczogd2hhdCBp cyB0aGUgZ2VuZXJhbCBhcHByb2FjaCB0byB0aGlzIHByb2JsZW0/DQo+ID4gICAgIA0KPiA+ICAg ICBBcyBtZW50aW9uZWQgYWJvdmUsIGZvciBORVRDT05GLCBJIGJlbGlldmUgdGhlIGFuc3dlciBp cyB0aGF0IGEgY3VzdG9tIFJQQyBoYXMgdG8gYmUgdXNlZC4gQnV0IGlzIHRoaXMgaW50ZW5kZWQg dG8gYmUgdGhlIGNhc2UgZm9yIGFsbCBwcm90b2NvbHMgdGhhdCBjYW4gZGVhbCB3aXRoIFlBTkcg bW9kZWxsZWQgZGF0YT8NCj4gPiAgICAgDQo+ID4gICAgIEluIGNhc2UgaXQgbWF0dGVycywgdGhl IHNwZWNpZmljIGNhc2UgSSdtIGRlYWxpbmcgd2l0aCBpcyBzdWJzY3JpcHRpb25zIGFzIHBlciBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzUyNzdiaXMt MDEgYW5kIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYteWFu Zy1wdXNoLTA0Lg0KPiA+ICAgICANCj4gPiAgICAgVGhhbmtzLA0KPiA+ICAgICANCj4gPiAgICAg VGltDQo+ID4gICAgIA0KPiA+ICAgICAtLSANCj4gPiAgICAgQ2lzY28gU3lzdGVtcyBDYW5hZGEg Q28uDQo+ID4gICAgIDIwMDAgSW5ub3ZhdGlvbiBEcml2ZQ0KPiA+ICAgICBLYW5hdGEsIE9OLCBD YW5hZGEsIEsySyAzRTgNCj4gPiAgICAgUHJlZmVyZW5jZXMgPGh0dHA6Ly93d3cuY2lzY28uY29t L29mZmVyL3N1YnNjcmliZS8/c2lkPTAwMDQ3ODMyNj4NCj4gPiAgICAgVW5zdWJzY3JpYmUgPGh0 dHA6Ly93d3cuY2lzY28uY29tL29mZmVyL3Vuc3Vic2NyaWJlLz9zaWQ9MDAwNDc4MzI3Pg0KPiA+ ICAgICBQcml2YWN5IDxodHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvc2l0ZWFzc2V0cy9sZWdhbC9w cml2YWN5Lmh0bWw+DQo+ID4gICAgIA0KPiA+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+ICAgICBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4g ICAgIG5ldG1vZEBpZXRmLm9yZw0KPiA+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldG1vZA0KPiA+ICAgICANCj4gPiAgICAgDQo+ID4gICAgIA0KPiA+IA0KPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbmV0 bW9kIG1haWxpbmcgbGlzdA0KPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+IA0KPiAtLSANCj4gSnVlcmdlbiBTY2hv ZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gUGhv bmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVu IHwgR2VybWFueQ0KPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3 LmphY29icy11bml2ZXJzaXR5LmRlLz4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= From nobody Tue Dec 13 01:50:47 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F08B129A31; Tue, 13 Dec 2016 01:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 lFeNsBBMZ1j3; Tue, 13 Dec 2016 01:50:43 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E0BB129A2E; Tue, 13 Dec 2016 01:50:42 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:f0d2:75d1:8bca:d2e9] (unknown [IPv6:2001:718:1a02:1:f0d2:75d1:8bca:d2e9]) by mail.nic.cz (Postfix) with ESMTPSA id 994C560CC5; Tue, 13 Dec 2016 10:50:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1481622640; bh=pxFfraCxBt57w6h+9mgfp7xqC/abCWfZ4tIP1fDTLHc=; h=From:Date:To; b=t7Eu1Da8h8Dlp3NdjQ6vZqOJHjwHxQ74lb8Y9vi4CizLBm9TxdetPxt4nxhz6lz3O b1Y+FzrGjY0ANMjeZPm+Xz2THI3kO3Gb75jR+ipQTB5zao/ZD5WjYkt3/KlW7AW1eU GBeyGisjFn1J42rkQh7M5/+ii+wy02GAJcWuIHw4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 13 Dec 2016 10:50:40 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: To: Lou Berger X-Mailer: Apple Mail (2.3251) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG Chairs , NetMod WG Subject: Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 09:50:45 -0000 Support. Lada > On 13 Dec 2016, at 00:31, Lou Berger wrote: > > All, > > This is start of a two week* poll on making > draft-wilton-netmod-intf-vlan-yang-04 a NetMod working group > document. > > Please send email to the list indicating "yes/support" or "no/do not > support". If indicating no, please state your reservations with the > document. If yes, please also feel free to provide comments you'd like > to see addressed once the document is a WG document. > > * Given the holiday, the poll ends December 28. > > Thank you, > NetMod WG Chairs > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Dec 13 01:57:52 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD1C129A3E; Tue, 13 Dec 2016 01:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.117 X-Spam-Level: X-Spam-Status: No, score=-7.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, 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 s1HluITYDNAS; Tue, 13 Dec 2016 01:57:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BF9E129A25; Tue, 13 Dec 2016 01:57:48 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CXA11454; Tue, 13 Dec 2016 09:57:43 +0000 (GMT) Received: from SZXEML430-HUB.china.huawei.com (10.82.67.185) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 13 Dec 2016 09:57:39 +0000 Received: from SZXEML501-MBX.china.huawei.com ([169.254.1.5]) by szxeml430-hub.china.huawei.com ([10.82.67.185]) with mapi id 14.03.0235.001; Tue, 13 Dec 2016 17:57:35 +0800 From: wangzitao To: Lou Berger , NetMod WG Thread-Topic: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04 Thread-Index: AQHSVM/zsAyTC0tUNkO0ucDD8z6+v6EFpMTA Date: Tue, 13 Dec 2016 09:57:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.198] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.584FC61A.00AF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.5, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 531d1c47f1897faa784b8c83d81107b9 Archived-At: Cc: NetMod WG Chairs Subject: Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 09:57:51 -0000 SSBoYXZlIHJlYWQgdGhpcyBkb2N1bWVudCwgYW5kIEkgc3VwcG9ydCB0byBhZG9wdCBpdC4NCg0K QmVzdCBSZWdhcmRzIQ0KLU1pY2hhZWwNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IG5l dG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSC0+rHtIExvdSBCZXJnZXINCrei y83KsbzkOiAyMDE2xOoxMtTCMTPI1SA3OjMyDQrK1bz+yMs6IE5ldE1vZCBXRw0Ks63LzTogTmV0 TW9kIFdHIENoYWlycw0K1vfM4jogW25ldG1vZF0gV0cgYWRvcHRpb24gcG9sbCBkcmFmdC13aWx0 b24tbmV0bW9kLWludGYtdmxhbi15YW5nLTA0DQoNCkFsbCwNCg0KVGhpcyBpcyBzdGFydCBvZiBh IHR3byB3ZWVrKiBwb2xsIG9uIG1ha2luZw0KZHJhZnQtd2lsdG9uLW5ldG1vZC1pbnRmLXZsYW4t eWFuZy0wNCBhIE5ldE1vZCB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KDQpQbGVhc2Ugc2VuZCBl bWFpbCB0byB0aGUgbGlzdCBpbmRpY2F0aW5nICJ5ZXMvc3VwcG9ydCIgb3IgIm5vL2RvIG5vdCBz dXBwb3J0Ii4gIElmIGluZGljYXRpbmcgbm8sIHBsZWFzZSBzdGF0ZSB5b3VyIHJlc2VydmF0aW9u cyB3aXRoIHRoZSBkb2N1bWVudC4gIElmIHllcywgcGxlYXNlIGFsc28gZmVlbCBmcmVlIHRvIHBy b3ZpZGUgY29tbWVudHMgeW91J2QgbGlrZSB0byBzZWUgYWRkcmVzc2VkIG9uY2UgdGhlIGRvY3Vt ZW50IGlzIGEgV0cgZG9jdW1lbnQuDQoNCiogR2l2ZW4gdGhlIGhvbGlkYXksIHRoZSBwb2xsIGVu ZHMgRGVjZW1iZXIgMjguDQoNClRoYW5rIHlvdSwNCk5ldE1vZCBXRyBDaGFpcnMNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5n IGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2QNCg== From nobody Tue Dec 13 04:52:17 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D5B129694; Tue, 13 Dec 2016 04:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJYrLxjpVC-Q; Tue, 13 Dec 2016 04:52:14 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CEB6129673; Tue, 13 Dec 2016 04:52:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=785; q=dns/txt; s=iport; t=1481633534; x=1482843134; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=p2bfpfWcx7u8PRGmdnTZW93cOhXO5BUYCph8JuWKix4=; b=fbPObU3xOkE4caJCcSv0gW0wiv2AdX0WzbCIATANbeCy6svGdiOUNuUG iqEUNAWw0uor6mSV6coA4LxlxGFUvJ+Lmvh++iCMB+EDe1QGgZJxhTjM8 ZFQpwuaNVm/4JwSMLl0mHOumJkb9IJ+4BOX4QOevcz+4zpNg92pl9Qv/3 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQDv7U9Y/5FdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAR9agQYHjUOsHYIJAhwLhS5KAoFzPxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRpAgQBATg0CxACAQgOKBAnCyUCBAENBYhrDqk0AYNSixQBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBTKKZ4QaEQGFfQWaawGRKoF0hQGJU5IgAR83Yz4nhUVyhj+?= =?us-ascii?q?BIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,341,1477958400"; d="scan'208";a="184923932" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2016 12:52:12 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id uBDCqBhG005852 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 13 Dec 2016 12:52:12 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 13 Dec 2016 07:52:11 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 13 Dec 2016 07:52:11 -0500 From: "Acee Lindem (acee)" To: Lou Berger , NetMod WG Thread-Topic: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04 Thread-Index: AQHSVM/v5Ea61Zvi/kiWrDmsKtVvM6EF1cgA Date: Tue, 13 Dec 2016 12:52:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.204] Content-Type: text/plain; charset="us-ascii" Content-ID: <2BC867FA94769044BFD2B23F40F9818B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: NetMod WG Chairs Subject: Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 12:52:16 -0000 Support.=20 Thanks, Acee On 12/12/16, 6:31 PM, "netmod on behalf of Lou Berger" wrote: >All, > >This is start of a two week* poll on making >draft-wilton-netmod-intf-vlan-yang-04 a NetMod working group >document. > >Please send email to the list indicating "yes/support" or "no/do not >support". If indicating no, please state your reservations with the >document. If yes, please also feel free to provide comments you'd like >to see addressed once the document is a WG document. > >* Given the holiday, the poll ends December 28. > >Thank you, >NetMod WG Chairs > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Dec 13 05:37:37 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2911296B7; Tue, 13 Dec 2016 05:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rA_eNBk7qyNS; Tue, 13 Dec 2016 05:37:34 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E5641293FC; Tue, 13 Dec 2016 05:37:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6729; q=dns/txt; s=iport; t=1481636254; x=1482845854; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7FjQPDUU51toszccJrS6iY4RreYwOStXyrSDPWeKM4A=; b=SWHUb90zdCJ19pGIoGTt4f116oHgbF+z8HCcrH5oSOOM8LWTLibPsfyA Dyfd2/98tXCzhGEo8wdroa2W1QGXD4pcoc5bPzyCn5zdqQ+fHTMYhoXEU 3Z8aDDF/SYEnALb+9mFvsx8xH5LhMXLYLjcj0eQXhH3AEN03Uwxz6T3oU o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQAW+U9Y/5tdJa1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM3AQEBAQEfWoEGB41DlxiHdY0RggkeC4UuSgKBdD8UAQIBAQE?= =?us-ascii?q?BAQEBYiiEaAEBAQMBAQE4NAsFCQICAQgQBQMeEBsGBgslAgQBDQUIE4g2Aw8ID?= =?us-ascii?q?q0QhzQNg1IBAQEBAQEBAQEBAQEBAQEBAQEBAQEdBYY5hFuCSIIhJoUaBY8BizU?= =?us-ascii?q?1AY0/g2KBfY5Uh2uBcIQ3hA4BHzeBISeDTBwYgUVyh2CBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,341,1477958400"; d="scan'208";a="360108719" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2016 13:37:33 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uBDDbWrF029048 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 13 Dec 2016 13:37:33 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 13 Dec 2016 08:37:32 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Tue, 13 Dec 2016 08:37:32 -0500 From: "Eric Voit (evoit)" To: Ladislav Lhotka , MehmetErsue Thread-Topic: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 Thread-Index: AQHSUhqXeTJ8fMsU6k2pIJNbJLJAMKEF49Ew Date: Tue, 13 Dec 2016 13:37:32 +0000 Message-ID: <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 13:37:36 -0000 I support adoption, and like Mehmet's thinking as well. Also worth focusing on is transport protocol independent yang filtering. S= o along with how to frame get operations against one of the datastores, how= do you know which subtrees/nodes should be included/excluded. Eric > From: Netconf, December 9, 2016 7:49 AM >=20 > Hi Mehmet, >=20 > I think I could just sign your text at the bottom. >=20 > Lada >=20 > > On 9 Dec 2016, at 13:25, MehmetErsue wrote: > > > > Hi All, > > > > I think the adoption of the DT draft is fine. We agreed in IETF 97 to a= dopt and > finalize the DT draft in NETMOD WG, which I still support. > > > > I believe the bigger issue is to agree on a plan concerning the related= work > and the re-organization of existing standards. As a matter of fact this p= lan will > lead to updating the charter of two WGs and the work we are going to star= t. > > > > I see the DT document as a datastore solution proposal. There are diffe= rent > gaps and issues which still need to be addressed and the solution proposa= l > needs yet to be discussed and finalized. The document is providing inform= ation > on the history, explaining the need for a generic solution as well as is = discussing > different scenarios. As such I believe the datastore solution proposal fr= om the > DT should be published with the intended status Informational RFC. > > > > Based on the finalized and agreed datastore solution we should do diffe= rent > updates to existing documents in NETCONF and NETMOD WGs. With this > action we can also fix well-known issues. > > > > Concerning the NETCONF WG I would see it as valuable if we develop: > > - a RFC6241bis draft removing the current datasore concept > > specification, and getting rid of well-known issues e.g. with the > > operation, > > - a new protocol- and language-independent standard document (RFC XYZ) > > defining the generic datastore concept and framework and describing > > its use (based on and following the DT solution draft), > > - adding potential extensions to RFC6241bis (following the DT draft > > and with a normative reference to RFC XYZ), > > - adding potential extensions to a RESTCONF-bis RFC (following the DT > > draft and with a normative reference to RFC XYZ), > > > > Concerning the NETMOD WG I would see it as valuable if we develop: > > - RFC7950bis deleting protocol-dependent details and specifying the > > datastore usage with YANG on a generic level (with a normative > > reference to RFC XYZ), > > - adding potential extensions to RFC7950bis, e.g. concerning the > > proposed element, > > - possibly an RFC 6244bis to describe architectural aspects. However RF= C6244 > is Informational and a RFC6244bis would be still Informational. I'm not s= ure > whether this is really necessary. The DT proposal does already describe s= uch a > solution and can be seen as an update to RFC 6244. > > - RFC6087bis giving guidelines on how to use YANG with the new datastor= e > concept. > > > > Referring to Lada's proposal concerning the spin off document from > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be > provided in the corresponding protocol RFCs, i.e. > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. > > > > Hope this helps as a starting point on the way to a good plan. > > > > PS: As Benoit suggested some time ago we might also consider to rename > NETCONF WG as it is not only on NETCONF protocol anymore. > > > > Regards, > > Mehmet > > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman > wrote: > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder > wrote: > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: > > > > > > > > > > > I disagree that the datastore model is a protocol specific aspect. > > > > I consider datastores an architectural component binding data > > > > models and protocols together. In fact, the 'traditional' > > > > datastore model > > > > > > I would agree with this if datastores were a general concept in YANG,= but > the revised-datastores draft explicitly introduces the "intended" and "ap= plied" > datastores that may be irrelevant to other protocols using YANG, and even > needn't be used in all NETCONF implementations. I wouldn't call this "an > architectural component" of YANG. > > > > > > > An architectural component of this new management framework (that does > > not have a name). The fact that not all protocols may expose all > > datastores is IMHO not a reason that the datastore model is not an > > architectural framework. > > > > > If you are saying that it will have nontrivial impact on YANG, I woul= d like to > see it explained in sec. 6.3. Without this information I am quite relucta= nt to > agree with the adoption. > > > > An operational state datastore has implications how one writes data > > models. It may not directly affect YANG itself but surely the usage of > > YANG. > > > > > See above - architectural aspects need to be relevant to all protocol= s. > > > > Yes, but relevant to all protocols does not mean every protocol needs > > to expose say all datastores. But every protocol should be clear about > > how what it exposes relates to the architectural framework. > > > > > > > > There is a "current solution" consisting of hard-wired object > > semantics (e.g., ifAdminStatus and ifOperStatus). This solution does > > not require special protocols or datastores, but it is being replaced b= y a > generic solution. > > > > If the "generic" solution requires special procedures which differ on > > each protocol, then it might end up be worse than the hard-wired soluti= on > that works on every protocol. > > So I agree with Juergen that this is primarily an architectural issue. > > > > > > /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 > > -- > > Cheers, > > Mehmet >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Dec 13 06:08:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652571296E8 for ; Tue, 13 Dec 2016 06:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4eQXKnuDAo0 for ; Tue, 13 Dec 2016 06:08:47 -0800 (PST) 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 0A6441293E0 for ; Tue, 13 Dec 2016 06:08:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7588; q=dns/txt; s=iport; t=1481638127; x=1482847727; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GeWW0OQlxU5iT1mz/1ib5mBbQz/R0SxOsIgOvCTbD5s=; b=fqjiXuNmd9/ZI0m2E9DpIeUYlhyvKoHZ+zCN1O/ii/Tj7VhdksWD1f7J im0yMeBxyaHXOVfTHB6KSXNkY/Im9tXJmBj84Owkh0x7/i1vWju4KZh3A 69NHrX8ELCV1rlxQrmtQX/EfJJiqi16Zcjq3LWDju7itiocE3wsVDpscA k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQCi/09Y/4ENJK1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM3AQEBAQEfWoEGB41DlxqVBoIJHguFLkoCGoFaPxQBAgEBAQE?= =?us-ascii?q?BAQFiKIRoAQEBAwEBASERGhgICwUJAgIBCA4CBQMCAggBHQICAhkMCgEVEAIEA?= =?us-ascii?q?Q0BBAEHEwIEiEIIDqpsgiiLFAEBAQEBAQEBAQEBAQEBAQEBAQEBAR0FgQaFM4R?= =?us-ascii?q?bgU+BPIFUCiaCPYJdBZprAYZPilKQUY4ShA4BHzeBISeDTByBXXIBBodZgQ0BA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.33,341,1477958400"; d="scan'208";a="180928252" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Dec 2016 14:08:45 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id uBDE8jk4025181 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 13 Dec 2016 14:08:45 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 13 Dec 2016 09:08:44 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Tue, 13 Dec 2016 09:08:44 -0500 From: "Eric Voit (evoit)" To: Juergen Schoenwaelder , "Tim Jenkins (timjenki)" Thread-Topic: [netmod] Management Operations on YANG modelled operational data Thread-Index: AQHSVM1iwLltXQLlf0W2zz/D0KshQ6EF5vTA Date: Tue, 13 Dec 2016 14:08:44 +0000 Message-ID: <71a9389cd78b4054b08a86c1b047e507@XCH-RTP-013.cisco.com> References: <2A9B1ADF-022D-4F47-BAB3-FBFB8E3A44EA@cisco.com> <20161212231026.GA153@elstar.local> In-Reply-To: <20161212231026.GA153@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Management Operations on YANG modelled operational data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 14:08:49 -0000 PiBGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXI6IE1vbmRheSwgRGVjZW1iZXIgMTIsIDIwMTYg NjoxMCBQTQ0KPiANCj4gVGhlIHByb3BlciBhY3Rpb24gaW4gdGhpcyBjYXNlIG1heSBiZSB0byBr aWxsIHRoZSBORVRDT05GIHNlc3Npb24uDQo+IA0KPiBJdCBjYW4gYmUgZGViYXRlZCB3aGV0aGVy IHNpbXBseSBkZWxldGluZyBzdGF0ZSBjcmVhdGVkIGJ5IHNvbWUgb3RoZXIgc3lzdGVtDQo+ICh0 aGUgc3Vic2NyaXB0aW9uIGluIHRoaXMgY2FzZSkgaXMgYSBwcm9wZXIgbWFuYWdlbWVudCBhcHBy b2FjaCBzaW5jZSBpdCBtYXkNCj4gbGVhZCB0byB1bmRlZmluZWQgb3IgZXJyYXRpYyBiZWhhdmlv dXIgb2Ygb3RoZXIgc3lzdGVtcyBvciB0byBsb29wcyB3aGVyZSBzb21lDQo+IHN5c3RlbXMgY3Jl YXRlIHN0YXRlIHRoYXQgb3RoZXJzIGRlbGV0ZSBhbmQgc28gb24uDQoNCldvdWxkbid0IHRoaXMg aGF2ZSBpbXBsaWNhdGlvbnMgdG8gSTJSUyBvciBPcFN0YXRlPyAgIEhvdyB3b3VsZCBhbiBPcGVy YXRvciBiZSBhYmxlIHRvIGZvY3VzIG9ubHkgb24gdGhlIHN1YnNldCBvZiBkeW5hbWljIHN0YXRl IHdoaWNoIGlzIGN1cnJlbnRseSBpbXBhY3RlZD8gICANCg0KQW4gYW5hbG9neSBtaWdodCBiZSBz b21lb25lIHdpdGggcGhvbmUgYW5kIGZhdWx0eSB2aWRlbyBzZXJ2aWNlIGNvbm5lY3RlZCBvdmVy IHRoZWlyIGJyb2FkYmFuZCBjb25uZWN0aW9uLiAgVGhleSBnZXQgb24gdGhlIHBob25lIHdpdGgg YW4gb3BlcmF0b3IgdG8gdHJvdWJsZXNob290IHRoZWlyIHZpZGVvLCBidXQgdGhlIG9wZXJhdG9y IGNhbid0IHJlc2V0IHRoZSB2aWRlbyBDUEUgc2Vzc2lvbiB3aXRob3V0IHRha2luZyBvdXQgdGhl IHBob25lIHNlcnZpY2UgYXMgd2VsbC4NCg0KRXJpYw0KDQo+IC9qcw0KPiANCj4gT24gTW9uLCBE ZWMgMTIsIDIwMTYgYXQgMDU6NDM6NTdQTSArMDAwMCwgVGltIEplbmtpbnMgKHRpbWplbmtpKSB3 cm90ZToNCj4gPiBIaSwNCj4gPg0KPiA+IEFzIGFuIGV4YW1wbGUsIHNheSBhIG51bWJlciBvZiBz dWJzY3JpYmVycyBjb25uZWN0IGluIHRvIGEgc3lzdGVtIHVzaW5nDQo+IE5FVENPTkYsIHRoZW4g aXNzdWUgdGhlIDxlc3RhYmxpc2gtc3Vic2NyaXB0aW9uPiBSUENzIGFzIGRlZmluZWQgYnkNCj4g aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1yZmM1Mjc3Ymlz LTAxLiBUaGVzZSBhcHBlYXIgYXMNCj4gZW50cmllcyBpbiB0aGUgaWV0Zi1ldmVudC1ub3RpZmlj YXRpb25zL3N1YnNjcmlwdGlvbnMgY29udGFpbmVyLCB3aGljaCBpcyAiY29uZmlnDQo+IGZhbHNl Ii4gVGhleSBkb24ndCBhcHBlYXIgaW4gdGhlIGlldGYtZXZlbnQtbm90aWZpY2F0aW9ucy9zdWJz Y3JpcHRpb24tY29uZmlnDQo+IGNvbnRhaW5lciBzaW5jZSB0aGV5IGFyZSBub3QgY29uZmlndXJl ZDsgdGhleSBhcmUgZHluYW1pYy4NCj4gPg0KPiA+IEEgbmV0d29yayBtYW5hZ2VyIGlzIGV4YW1p bmluZyB0aGUgc3lzdGVtIGFuZCBvYnNlcnZlcyB0aGUgc3Vic2NyaXB0aW9ucyBpbg0KPiB0aGUg aWV0Zi1ldmVudC1ub3RpZmljYXRpb25zL3N1YnNjcmlwdGlvbnMgY29udGFpbmVyIGFuZCBkZWNp ZGVzIHRoYXQgc29tZSBvciBhbGwNCj4gb2YgdGhlbSBzaG91bGQgYmUgZGVsZXRlZC4gU2luY2Ug dGhlIG5ldHdvcmsgbWFuYWdlciBtYXkgYmUgdXNpbmcgYSB0b29sIHRoYXQNCj4gdXNlcyBORVRD T05GIChvciBwZXJoYXBzIHNvbWUgb3RoZXIgdG9vbCkgdG8gcmVtb3RlbHkgbWFuYWdlIHRoZSBz eXN0ZW0sDQo+IHdoYXQgdW5kZXJseWluZyBtZXRob2Qgd291bGQgYmUgdXNlZCB0byBkZWxldGUg dGhlc2Ugc3Vic2NyaXB0aW9ucz8NCj4gPg0KPiA+IEFzIG1lbnRpb25lZCBiZWxvdywgYXMgZmFy IGFzIEkgY2FuIHRlbGwsIGEgc3RhbmRhcmQgTkVUQ09ORiBtYW5hZ2VtZW50DQo+IFJQQyBsaWtl IDxlZGl0LWNvbmZpZz4gY2Fubm90IGJlIGRpcmVjdGVkIGF0IHRoZXNlIHN1YnNjcmlwdGlvbnMg c2luY2UgY29uZmlnIGlzDQo+IGZhbHNlLiBTbyBJJ20gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgaWYg dGhlcmUgaXMgc29tZSBvdGhlciBnZW5lcmFsIHNvbHV0aW9uIGZvciB0aGlzDQo+IHR5cGUgb2Yg cHJvYmxlbSBmb3Igb3RoZXIgcHJvdG9jb2xzLCBvciBwZXJoYXBzIGV2ZW4gZm9yIE5FVENPTkYg b3RoZXIgdGhhbiBhDQo+IGN1c3RvbSBSUEMgc3VjaCBhcyB0aG9zZSBhbHJlYWR5IGRlZmluZWQg Zm9yIHRoaXMgYXBwbGljYXRpb24gc3BlY2lmaWMgcHVycG9zZS4NCj4gPg0KPiA+IEhvcGUgdGhp cyBoZWxwcy4uLg0KPiA+DQo+ID4gVGltDQo+ID4NCj4gPiAtLQ0KPiA+IENpc2NvIFN5c3RlbXMg Q2FuYWRhIENvLg0KPiA+IDIwMDAgSW5ub3ZhdGlvbiBEcml2ZQ0KPiA+IEthbmF0YSwgT04sIENh bmFkYSwgSzJLIDNFOA0KPiA+IFByZWZlcmVuY2VzIDxodHRwOi8vd3d3LmNpc2NvLmNvbS9vZmZl ci9zdWJzY3JpYmUvP3NpZD0wMDA0NzgzMjY+DQo+ID4gVW5zdWJzY3JpYmUgPGh0dHA6Ly93d3cu Y2lzY28uY29tL29mZmVyL3Vuc3Vic2NyaWJlLz9zaWQ9MDAwNDc4MzI3Pg0KPiA+IFByaXZhY3kg PGh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9zaXRlYXNzZXRzL2xlZ2FsL3ByaXZhY3kuaHRtbD4N Cj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IE9uIDIwMTYtMTItMTIsIDExOjU0IEFNLCAiS2VudCBX YXRzZW4iIDxrd2F0c2VuQGp1bmlwZXIubmV0PiB3cm90ZToNCj4gPg0KPiA+ICAgICBIaSBUaW0s DQo+ID4NCj4gPiAgICAgSSBkb27igJl0IHVuZGVyc3RhbmQgeW91ciBwcm9ibGVtLiAgV2hpY2gg cGFydHMgaW4gdGhlIHJlZmVyZW5jZWQgZHJhZnRzDQo+IHNob3VsZCB3ZSBsb29rIGF0LCBvciBj YW4geW91IHByb3ZpZGUgYW4gZXhhbXBsZT8NCj4gPg0KPiA+ICAgICBUaGFua3MsDQo+ID4gICAg IEtlbnQNCj4gPg0KPiA+DQo+ID4NCj4gPiAgICAgSGksDQo+ID4NCj4gPiAgICAgSSBoYXZlIGEg Z2VuZXJhbCBxdWVzdGlvbiByZWxhdGVkIHRvIG1hbmFnZW1lbnQgb3BlcmF0aW9ucyBvbg0KPiBv cGVyYXRpb25hbCBkYXRhLiBUaGUgcXVlc3Rpb24gaXMgaW50ZW5kZWQgdG8gYmUgcHJvdG9jb2wg YWdub3N0aWMsIHNpbmNlIGFzIEkNCj4gdW5kZXJzdGFuZCBpdCwgdGhlIE5FVENPTkYgbWFuYWdl bWVudCBvcGVyYXRpb25zIGRvIG5vdCBhcHBseSB0byBkYXRhDQo+IG1vZGVsbGVkIGluIFlBTkcg d2hlcmUgY29uZmlnIGlzIGZhbHNlLiBJbiBvdGhlciB3b3JkcywgdGhlcmUgaXMgbm8gZ2VuZXJp Yw0KPiBORVRDT05GIFJQQyB0aGF0IHdpbGwsIGZvciBleGFtcGxlLCBkZWxldGUgZW50cmllcyBp biBhIHRhYmxlIG9mIG9wZXJhdGlvbmFsDQo+IGRhdGEuDQo+ID4NCj4gPiAgICAgTXkgcXVlc3Rp b24gYXJpc2VzIGJlY2F1c2Ugd2UgYXJlIGltcGxlbWVudGluZyBhIGZlYXR1cmUgdGhhdCBpcyBk ZWZpbmVkDQo+IHVzaW5nIFlBTkcsIGFuZCBoYXMgY3VzdG9tIE5FVENPTkYgUlBDcyB3aG9zZSBv cGVyYXRpb25zIGNhbiBjcmVhdGUsDQo+IG1vZGlmeSBhbmQgZGVsZXRlIHJvd3Mgb2YgYSBZQU5H IGxpc3QgdGhhdCBoYXMgZW50cmllcyB0aGF0IGFyZSBib3RoIGNvbmZpZyBpcw0KPiB0cnVlIGFu ZCBjb25maWcgaXMgZmFsc2UuIFRoZSByb3dzIHRoYXQgYXJlIGNvbmZpZyBpcyBmYWxzZSBhcmUg dGhlIG9ubHkgcm93cyB0aGF0DQo+IGNhbiBiZSBhZmZlY3RlZCBieSB0aGUgY3VzdG9tIE5FVENP TkYgUlBDczsgdGhlIG90aGVyIHJvd3MgYXJlIGFmZmVjdGVkIG9ubHkNCj4gYnkgdGhlIHN0YW5k YXJkIE5FVENPTkYgbWFuYWdlbWVudCBSUENzLiBIb3dldmVyLCB0aGVyZSBpcyBhIG5lZWQgZm9y DQo+IG1hbmFnZW1lbnQgb3BlcmF0aW9ucyB0byBiZSBhYmxlIHRvIHJlbW92ZSB0aGUgcm93cyBh bmQgdGhlIG9wZXJhdGlvbnMNCj4gYXNzb2NpYXRlZCB3aXRoIHRoZW0gZm9yIHZhcmlvdXMgcmVh c29ucy4NCj4gPg0KPiA+ICAgICBTbyBteSBxdWVzdGlvbiBpcyB0aGlzOiB3aGF0IGlzIHRoZSBn ZW5lcmFsIGFwcHJvYWNoIHRvIHRoaXMgcHJvYmxlbT8NCj4gPg0KPiA+ICAgICBBcyBtZW50aW9u ZWQgYWJvdmUsIGZvciBORVRDT05GLCBJIGJlbGlldmUgdGhlIGFuc3dlciBpcyB0aGF0IGEgY3Vz dG9tDQo+IFJQQyBoYXMgdG8gYmUgdXNlZC4gQnV0IGlzIHRoaXMgaW50ZW5kZWQgdG8gYmUgdGhl IGNhc2UgZm9yIGFsbCBwcm90b2NvbHMgdGhhdCBjYW4NCj4gZGVhbCB3aXRoIFlBTkcgbW9kZWxs ZWQgZGF0YT8NCj4gPg0KPiA+ICAgICBJbiBjYXNlIGl0IG1hdHRlcnMsIHRoZSBzcGVjaWZpYyBj YXNlIEknbSBkZWFsaW5nIHdpdGggaXMgc3Vic2NyaXB0aW9ucyBhcyBwZXINCj4gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1yZmM1Mjc3YmlzLTAxIGFuZA0K PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVz aC0wNC4NCj4gPg0KPiA+ICAgICBUaGFua3MsDQo+ID4NCj4gPiAgICAgVGltDQo+ID4NCj4gPiAg ICAgLS0NCj4gPiAgICAgQ2lzY28gU3lzdGVtcyBDYW5hZGEgQ28uDQo+ID4gICAgIDIwMDAgSW5u b3ZhdGlvbiBEcml2ZQ0KPiA+ICAgICBLYW5hdGEsIE9OLCBDYW5hZGEsIEsySyAzRTgNCj4gPiAg ICAgUHJlZmVyZW5jZXMgPGh0dHA6Ly93d3cuY2lzY28uY29tL29mZmVyL3N1YnNjcmliZS8/c2lk PTAwMDQ3ODMyNj4NCj4gPiAgICAgVW5zdWJzY3JpYmUgPGh0dHA6Ly93d3cuY2lzY28uY29tL29m ZmVyL3Vuc3Vic2NyaWJlLz9zaWQ9MDAwNDc4MzI3Pg0KPiA+ICAgICBQcml2YWN5IDxodHRwOi8v d3d3LmNpc2NvLmNvbS93ZWIvc2l0ZWFzc2V0cy9sZWdhbC9wcml2YWN5Lmh0bWw+DQo+ID4NCj4g PiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiAgICAgbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ICAgICBuZXRtb2RAaWV0Zi5vcmcNCj4gPiAg ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPg0KPiA+ DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+IA0KPiAtLQ0K PiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1l biBnR21iSA0KPiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEg fCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQo+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAg ICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlz dA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2QNCg== From nobody Tue Dec 13 06:59:59 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72610129B5C for ; Tue, 13 Dec 2016 06:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 vFup0QYSM_TE for ; Tue, 13 Dec 2016 06:59:56 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4AD129B57 for ; Tue, 13 Dec 2016 06:59:40 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id D3C421AE028C; Tue, 13 Dec 2016 15:59:37 +0100 (CET) Date: Tue, 13 Dec 2016 15:59:36 +0100 (CET) Message-Id: <20161213.155936.28821946219169552.mbj@tail-f.com> To: evoit@cisco.com From: Martin Bjorklund In-Reply-To: <71a9389cd78b4054b08a86c1b047e507@XCH-RTP-013.cisco.com> References: <2A9B1ADF-022D-4F47-BAB3-FBFB8E3A44EA@cisco.com> <20161212231026.GA153@elstar.local> <71a9389cd78b4054b08a86c1b047e507@XCH-RTP-013.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: Cc: timjenki@cisco.com, netmod@ietf.org Subject: Re: [netmod] Management Operations on YANG modelled operational data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 14:59:58 -0000 "Eric Voit (evoit)" wrote: > > From: Juergen Schoenwaelder: Monday, December 12, 2016 6:10 PM > > > > The proper action in this case may be to kill the NETCONF session. > > > > It can be debated whether simply deleting state created by some other > > system > > (the subscription in this case) is a proper management approach since > > it may > > lead to undefined or erratic behaviour of other systems or to loops > > where some > > systems create state that others delete and so on. > > Wouldn't this have implications to I2RS or OpState? I don't know about i2rs, but it doesn't impact "opstate". > How would an > Operator be able to focus only on the subset of dynamic state which is > currently impacted? > > An analogy might be someone with phone and faulty video service > connected over their broadband connection. They get on the phone with > an operator to troubleshoot their video, but the operator can't reset > the video CPE session without taking out the phone service as well. Maybe this is a good reason for using separate sessions, and not try to do too much in one. The problem is how you expect the client (and maybe server) to recover after a forced termination of an ongoing request. Note that there's no equivalent operation to kill an ongoing for example. /martin From nobody Tue Dec 13 08:49:06 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61464129432; Tue, 13 Dec 2016 08:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ae3h6cQztjwR; Tue, 13 Dec 2016 08:49:01 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B331E12944C; Tue, 13 Dec 2016 08:49:00 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id i88so19195354pfk.2; Tue, 13 Dec 2016 08:49:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=opoAqM86rBaKKJzdqnU05HH3ZXrnjMZlQS+EAwsy47s=; b=itH8umoeNXj5UHo1GVoyBqEx29PQ6um8q4V0vtP8t2tBtDMRLqDrmPgYSyNDc5h/lf C/iW2X0ZzbOxMOuv3I3XuJN2UYQ09iVYIlykkxgg4wOhT0j+u38WD3f54/OO7L+3reb6 Z+qP/Ifs0J42Qj+fmcxgKOsCA8U5kJPT6nQnWkeDljGAGif7hrSvDfIUR2hi7sm5opeh FUl/momRUVPjee3NVxscvctvQQBvp/mN6SXcxEhqqlS+YXBGLUqvn8/dCChxtdCfyxQd ARiPn65nBTAChAUn2ltdIe3hshvEeryo4ffPsq3X3TGREpPMuhoXG/o83MQzDFQr4xmu Aazg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=opoAqM86rBaKKJzdqnU05HH3ZXrnjMZlQS+EAwsy47s=; b=E/BRjWJtBaznP6h2GT0yF4H/MZM5vOohlMr0OshRHlr+fCAE+aAxTOSLVAcY94nlyy sCnKSC1rhDUFI+OlFtlQ8Ov5q2kYKIvM8ajtlaJqHv8nYf3mViSAixoxswWRIodP2euB qeadzDE3l60xU5t9SiMMSDxTeKDIoAIxFIYbC069c+bEZZXyfwqGJ5h6qR2bFgx8o5Cs V1ez+r5X6unVWqWvrKhwy/mBy280WloGOgU0Lcm37WEgxLfPeLt5MseMHpO8/AY0mx4/ z1GfYQk2n7R0aq0Nq7FG5xHwnigA+3pjblPqfsNdhsvOM4HLvU6jtxH84U/1+aZhfcm2 q1Wg== X-Gm-Message-State: AKaTC00rn96lzyeMEnl8yKsvS8E5ITkjHnYr3AXxImAtoJgsp6ICkI4ImES1MkznYEKWcw== X-Received: by 10.99.160.1 with SMTP id r1mr176409302pge.107.1481647740370; Tue, 13 Dec 2016 08:49:00 -0800 (PST) Received: from sjc-mahesh-nitro1.cisco.com ([128.107.241.185]) by smtp.gmail.com with ESMTPSA id o126sm81656840pga.34.2016.12.13.08.48.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 13 Dec 2016 08:48:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: Date: Tue, 13 Dec 2016 08:48:59 -0800 Content-Transfer-Encoding: 7bit Message-Id: <010D4ABC-8218-4743-A2CD-AF8DAAEDF858@gmail.com> References: To: Lou Berger X-Mailer: Apple Mail (2.3124) Archived-At: Cc: NetMod WG Chairs , NetMod WG Subject: Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 16:49:05 -0000 Support. > On Dec 12, 2016, at 3:31 PM, Lou Berger wrote: > > All, > > This is start of a two week* poll on making > draft-wilton-netmod-intf-vlan-yang-04 a NetMod working group > document. > > Please send email to the list indicating "yes/support" or "no/do not > support". If indicating no, please state your reservations with the > document. If yes, please also feel free to provide comments you'd like > to see addressed once the document is a WG document. > > * Given the holiday, the poll ends December 28. > > Thank you, > NetMod WG Chairs > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanandani@gmail.com From andy@yumaworks.com Tue Dec 13 09:38:02 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37E6129454 for ; Tue, 13 Dec 2016 09:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nknp7-TD_hGP for ; Tue, 13 Dec 2016 09:37:59 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 511721293DF for ; Tue, 13 Dec 2016 09:37:59 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id q130so123771213qke.1 for ; Tue, 13 Dec 2016 09:37:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o8GQdzKNgzVj0wKzC+hgr6hgoXi7jC29Sblz00PiYGA=; b=oN37K1QuJxv3hotWr/zN6D8FJKzX2EQjwLDG4FGZB/M49teCwPqWI29EMTSsjPsblZ LWSOarqXvw75q8klCuHoE7eDMAyvnb/500ZDnptIFwQpfUpaajdxQU7vDN3Es5CGpCAW jg7ib7VSZ5hZ+q66eKoyCMVl8GqJxMqDeewT1NENk4lMKIphVCBJ5ACvBGi3do46atpE NKTxfwbWSY3amIlDLjab41ZudbX6qu1ZFKMPp0PPAYqqPPnQxEpxTR1a9Sn0M79o0r7I SGTzIMQhh/SRMCeU4KEttQLhihIMwLcFfCf7V0ZKQglwHmlt2vfWAzgwxrX2+eDWJSNF u9Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o8GQdzKNgzVj0wKzC+hgr6hgoXi7jC29Sblz00PiYGA=; b=U5amaRQa16d6wSR27xUawd7rf/S4ot06a7+qjYop4aVDBJHz9ljYDVQs7fGtbdvdV0 F/LsVGpSQhbUwXrLydsovB2KOZ1HeZIpHwFXZFQKHwk+DZP3UnV/gWt5feR4J5s5dU5U fYPV+PcZKGbZBF+J3JFwEwt1AasBXN80l1qBwXSQerlxhYJz/eRcLP3MyAu+/U5huEqK rfm/DWG2li9R0acMnNE7axdn7soKD7qrYaDKihf8D9ASm+2ZcbCUyIoWmLQTYzVi99fl 2TpZ9QoDGHHMaNXhDfsVxpWL4tZ9ey7CsPMb2Vj1yebO1zl9KRpdVeARzEGtZcv55xMA GZxg== X-Gm-Message-State: AKaTC00DbrUcUU/zvXmF3wAS67lxK66XQi912DvF4dZNWQaqX0NqKCUmQVIWmu1aG8ZGyspPkasOUGxlcWne7g== X-Received: by 10.55.21.81 with SMTP id f78mr93471414qkh.210.1481650678417; Tue, 13 Dec 2016 09:37:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Tue, 13 Dec 2016 09:37:57 -0800 (PST) In-Reply-To: <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> From: Andy Bierman Date: Tue, 13 Dec 2016 09:37:57 -0800 Message-ID: To: "Eric Voit (evoit)" Content-Type: multipart/alternative; boundary=001a114626ea5e792d05438daed5 Cc: NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 17:38:02 -0000 --001a114626ea5e792d05438daed5 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) wrote: > I support adoption, and like Mehmet's thinking as well. > > Also worth focusing on is transport protocol independent yang filtering. > So along with how to frame get operations against one of the datastores, > how do you know which subtrees/nodes should be included/excluded. > > This architectural change needs to be implemented in various protocols. I am not sure a 6241bis is the best approach because it is not clear which servers really need to implement the revised datastores. Since RD is purely optional to implement, it should not obsolete 6241 in any way. It should be possible to add new operations and/or new parameters to existing operations without needing to redefine what is already there. The new protocol features need to explain how to include/exclude subtrees. IMO we should only support YANG defined data. This allows the solutions to be generalized and reusable across protocols (e.g., using YANG extensions). Eric > Andy > > > From: Netconf, December 9, 2016 7:49 AM > > > > Hi Mehmet, > > > > I think I could just sign your text at the bottom. > > > > Lada > > > > > On 9 Dec 2016, at 13:25, MehmetErsue wrote: > > > > > > Hi All, > > > > > > I think the adoption of the DT draft is fine. We agreed in IETF 97 to > adopt and > > finalize the DT draft in NETMOD WG, which I still support. > > > > > > I believe the bigger issue is to agree on a plan concerning the > related work > > and the re-organization of existing standards. As a matter of fact this > plan will > > lead to updating the charter of two WGs and the work we are going to > start. > > > > > > I see the DT document as a datastore solution proposal. There are > different > > gaps and issues which still need to be addressed and the solution > proposal > > needs yet to be discussed and finalized. The document is providing > information > > on the history, explaining the need for a generic solution as well as is > discussing > > different scenarios. As such I believe the datastore solution proposal > from the > > DT should be published with the intended status Informational RFC. > > > > > > Based on the finalized and agreed datastore solution we should do > different > > updates to existing documents in NETCONF and NETMOD WGs. With this > > action we can also fix well-known issues. > > > > > > Concerning the NETCONF WG I would see it as valuable if we develop: > > > - a RFC6241bis draft removing the current datasore concept > > > specification, and getting rid of well-known issues e.g. with the > > > operation, > > > - a new protocol- and language-independent standard document (RFC XYZ) > > > defining the generic datastore concept and framework and describing > > > its use (based on and following the DT solution draft), > > > - adding potential extensions to RFC6241bis (following the DT draft > > > and with a normative reference to RFC XYZ), > > > - adding potential extensions to a RESTCONF-bis RFC (following the DT > > > draft and with a normative reference to RFC XYZ), > > > > > > Concerning the NETMOD WG I would see it as valuable if we develop: > > > - RFC7950bis deleting protocol-dependent details and specifying the > > > datastore usage with YANG on a generic level (with a normative > > > reference to RFC XYZ), > > > - adding potential extensions to RFC7950bis, e.g. concerning the > > > proposed element, > > > - possibly an RFC 6244bis to describe architectural aspects. However > RFC6244 > > is Informational and a RFC6244bis would be still Informational. I'm not > sure > > whether this is really necessary. The DT proposal does already describe > such a > > solution and can be seen as an update to RFC 6244. > > > - RFC6087bis giving guidelines on how to use YANG with the new > datastore > > concept. > > > > > > Referring to Lada's proposal concerning the spin off document from > > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be > > provided in the corresponding protocol RFCs, i.e. > > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and > > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. > > > > > > Hope this helps as a starting point on the way to a good plan. > > > > > > PS: As Benoit suggested some time ago we might also consider to rename > > NETCONF WG as it is not only on NETCONF protocol anymore. > > > > > > Regards, > > > Mehmet > > > > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman > > wrote: > > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder > > wrote: > > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: > > > > > > > > > > > > > > I disagree that the datastore model is a protocol specific aspect. > > > > > I consider datastores an architectural component binding data > > > > > models and protocols together. In fact, the 'traditional' > > > > > datastore model > > > > > > > > I would agree with this if datastores were a general concept in > YANG, but > > the revised-datastores draft explicitly introduces the "intended" and > "applied" > > datastores that may be irrelevant to other protocols using YANG, and even > > needn't be used in all NETCONF implementations. I wouldn't call this "an > > architectural component" of YANG. > > > > > > > > > > An architectural component of this new management framework (that does > > > not have a name). The fact that not all protocols may expose all > > > datastores is IMHO not a reason that the datastore model is not an > > > architectural framework. > > > > > > > If you are saying that it will have nontrivial impact on YANG, I > would like to > > see it explained in sec. 6.3. Without this information I am quite > reluctant to > > agree with the adoption. > > > > > > An operational state datastore has implications how one writes data > > > models. It may not directly affect YANG itself but surely the usage of > > > YANG. > > > > > > > See above - architectural aspects need to be relevant to all > protocols. > > > > > > Yes, but relevant to all protocols does not mean every protocol needs > > > to expose say all datastores. But every protocol should be clear about > > > how what it exposes relates to the architectural framework. > > > > > > > > > > > > There is a "current solution" consisting of hard-wired object > > > semantics (e.g., ifAdminStatus and ifOperStatus). This solution does > > > not require special protocols or datastores, but it is being replaced > by a > > generic solution. > > > > > > If the "generic" solution requires special procedures which differ on > > > each protocol, then it might end up be worse than the hard-wired > solution > > that works on every protocol. > > > So I agree with Juergen that this is primarily an architectural issue. > > > > > > > > > /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 > > > -- > > > Cheers, > > > Mehmet > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a114626ea5e792d05438daed5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) &l= t;evoit@cisco.com&= gt; wrote:
I support adoption, and= like Mehmet's thinking as well.

Also worth focusing on is transport protocol independent yang filtering.=C2= =A0 So along with how to frame get operations against one of the datastores= , how do you know which subtrees/nodes should be included/excluded.



This architectural chan= ge needs to be implemented in various protocols.
I am not sure a = 6241bis is the best approach because it is not clear which
server= s really need to implement the revised datastores.=C2=A0 Since RD is purely= optional
to implement, it should not obsolete 6241 in any way.= =C2=A0 It should be possible
to add new operations and/or new par= ameters to existing operations without
needing to redefine what i= s already there.

The new protocol features need to= explain how to include/exclude subtrees.
IMO we should only supp= ort YANG defined data.=C2=A0 This allows the solutions
to be gene= ralized and reusable across protocols (e.g., using YANG extensions).
<= div>

Eric


Andy
=C2= =A0

> From: Netconf, December 9, 2016 7:49 AM
>
> Hi Mehmet,
>
> I think I could just sign your text at the bottom.
>
> Lada
>
> > On 9 Dec 2016, at 13:25, MehmetErsue <mersue@gmail.com> wrote:
> >
> > Hi All,
> >
> > I think the adoption of the DT draft is fine. We agreed in IETF 9= 7 to adopt and
> finalize the DT draft in NETMOD WG, which I still support.
> >
> > I believe the bigger issue is to agree on a plan concerning the r= elated work
> and the re-organization of existing standards. As a matter of fact thi= s plan will
> lead to updating the charter of two WGs and the work we are going to s= tart.
> >
> > I see the DT document as a datastore solution proposal. There are= different
> gaps and issues which still need to be addressed and the solution prop= osal
> needs yet to be discussed and finalized. The document is providing inf= ormation
> on the history, explaining the need for a generic solution as well as = is discussing
> different scenarios. As such I believe the datastore solution proposal= from the
> DT should be published with the intended status Informational RFC.
> >
> > Based on the finalized and agreed datastore solution we should do= different
> updates to existing documents in NETCONF and NETMOD WGs. With this
> action we can also fix well-known issues.
> >
> > Concerning the NETCONF WG I would see it as valuable if we develo= p:
> > - a RFC6241bis draft removing the current datasore concept
> > specification, and getting rid of well-known issues e.g. with the=
> > <get> operation,
> > - a new protocol- and language-independent standard document (RFC= XYZ)
> > defining the generic datastore concept and framework and describi= ng
> > its use (based on and following the DT solution draft),
> > - adding potential extensions to RFC6241bis (following the DT dra= ft
> > and with a normative reference to RFC XYZ),
> > - adding potential extensions to a RESTCONF-bis RFC (following th= e DT
> > draft and with a normative reference to RFC XYZ),
> >
> > Concerning the NETMOD WG I would see it as valuable if we develop= :
> > - RFC7950bis deleting protocol-dependent details and specifying t= he
> > datastore usage with YANG on a generic level (with a normative > > reference to RFC XYZ),
> > - adding potential extensions to RFC7950bis, e.g. concerning the<= br> > > proposed <notification> element,
> > - possibly an RFC 6244bis to describe architectural aspects. Howe= ver RFC6244
> is Informational and a RFC6244bis would be still Informational. I'= m not sure
> whether this is really necessary. The DT proposal does already describ= e such a
> solution and can be seen as an update to RFC 6244.
> > - RFC6087bis giving guidelines on how to use YANG with the new da= tastore
> concept.
> >
> > Referring to Lada's proposal concerning the spin off document= from
> > RFC7950 ("Adapting NETCONF for use with YANG"), I think= this can be
> provided in the corresponding protocol RFCs, i.e.
> > for NETCONF a section on "Using NETCONF with YANG" in R= FC6241bis and
> for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC.=
> >
> > Hope this helps as a starting point on the way to a good plan. > >
> > PS: As Benoit suggested some time ago we might also consider to r= ename
> NETCONF WG as it is not only on NETCONF protocol anymore.
> >
> > Regards,
> > Mehmet
> >
> > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman <andy@yumaworks.com>
> wrote:
> > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder
> <j.schoenwa= elder@jacobs-university.de> wrote:
> > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote:<= br> > > >
> > > >
> > > > I disagree that the datastore model is a protocol speci= fic aspect.
> > > > I consider datastores an architectural component bindin= g data
> > > > models and protocols together. In fact, the 'tradit= ional'
> > > > datastore model
> > >
> > > I would agree with this if datastores were a general concept= in YANG, but
> the revised-datastores draft explicitly introduces the "intended&= quot; and "applied"
> datastores that may be irrelevant to other protocols using YANG, and e= ven
> needn't be used in all NETCONF implementations. I wouldn't cal= l this "an
> architectural component" of YANG.
> > >
> >
> > An architectural component of this new management framework (that= does
> > not have a name). The fact that not all protocols may expose all<= br> > > datastores is IMHO not a reason that the datastore model is not a= n
> > architectural framework.
> >
> > > If you are saying that it will have nontrivial impact on YAN= G, I would like to
> see it explained in sec. 6.3. Without this information I am quite relu= ctant to
> agree with the adoption.
> >
> > An operational state datastore has implications how one writes da= ta
> > models. It may not directly affect YANG itself but surely the usa= ge of
> > YANG.
> >
> > > See above - architectural aspects need to be relevant to all= protocols.
> >
> > Yes, but relevant to all protocols does not mean every protocol n= eeds
> > to expose say all datastores. But every protocol should be clear = about
> > how what it exposes relates to the architectural framework.
> >
> >
> >
> > There is a "current solution" consisting of hard-wired = object
> > semantics (e.g., ifAdminStatus and ifOperStatus).=C2=A0 This solu= tion does
> > not require special protocols or datastores, but it is being repl= aced by a
> generic solution.
> >
> > If the "generic" solution requires special procedures w= hich differ on
> > each protocol, then it might end up be worse than the hard-wired = solution
> that works on every protocol.
> > So I agree with Juergen that this is primarily an architectural i= ssue.
> >
> >
> > /js
> >
> > Andy
> >
> >
> >
> > --
> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac= obs University Bremen gGmbH
> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R= ing 1 | 28759 Bremen | Germany
> > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<http://www.jacobs-university.de/>
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/net= mod
> > --
> > Cheers,
> > Mehmet
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf=

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

--001a114626ea5e792d05438daed5-- From nobody Tue Dec 13 13:39:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F746129B9E for ; Tue, 13 Dec 2016 13:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18RQo7wM5ftF for ; Tue, 13 Dec 2016 13:39:36 -0800 (PST) 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 CABC9129B8B for ; Tue, 13 Dec 2016 13:39:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=152; q=dns/txt; s=iport; t=1481665166; x=1482874766; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=9SRFNFSdxCfaEolPefZPBv3x3Z7QRwgjAyfQMwCCLi4=; b=CWJhL1pT6xc6TlH+aqXWx382jO5z9k4i4Fw2c9CwlC6f5EUjXJeSjDOt IIqeP/d7DqvVSHoQy8UC6YNLkKsbBMWXFY4fvtm37h/lOdJDQc+H6CDG8 k5VsRRODlTC75/mdJMVxf6LLBKf60DAdmAl5/nsXppuJIBllMZwhOtMy1 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+CwBuaVBY/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzcBAQEBAYEnuDKEGIhiEQECAQEBAQEBAWIohRIVdgImAl8NCAEBiGe?= =?us-ascii?q?bH49+giiLFAEBCAImgQuFM4F9iiqCXQWaa5ErgV0BFoUBgyWEfoEwii2HdDUhg?= =?us-ascii?q?QATDoVtPYZmK4IQAQEB?= X-IronPort-AV: E=Sophos;i="5.33,342,1477958400"; d="scan'208";a="648881229" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2016 21:39:23 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uBDLdNcX005117 for ; Tue, 13 Dec 2016 21:39:23 GMT To: NETMOD Working Group From: Benoit Claise Message-ID: <1003ac93-ba9f-fdee-aacb-5c5f75e72139@cisco.com> Date: Tue, 13 Dec 2016 22:39:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] latest confd 6.3 for YANG validation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 21:39:38 -0000 Dear all, With the latest confd 6.3, some bug fixes are incorporated. Please check the validation errors for your YANG modules. Regards, Benoit From nobody Tue Dec 13 13:41:55 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C109129BD9; Tue, 13 Dec 2016 13:41:49 -0800 (PST) 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 wC7IknuGrHVS; Tue, 13 Dec 2016 13:41:46 -0800 (PST) Received: from mail-wj0-x242.google.com (mail-wj0-x242.google.com [IPv6:2a00:1450:400c:c01::242]) (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 C526F129BCB; Tue, 13 Dec 2016 13:41:18 -0800 (PST) Received: by mail-wj0-x242.google.com with SMTP id xy5so41933wjc.1; Tue, 13 Dec 2016 13:41:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=BHwDmOr+18ufj1k4c3zM3JF+0WtS7uKdJzrUDKc3dfI=; b=gUbzxNmJ1m+F3ubAiRoKGOB+NEBqO6H1BvYn+uRVhl90atCT6AJLg+aar3REsVCzNL h9P7SKKIVI8Rtj8UU2GcWmclDI76uk4CizshSMo8vYXDZdQ6Fi+hycsH4vXNY+P1cCrH 4U2QPMljGtoC6SErycZ9yoQ67mXxmFFykQcOUmkaCZM+ILNGJcZ/ndp3mDQV3BE4xEcB Kzvm/mOj1mNDmAGNWPUus9dgmxNAjKExtWt1LGA+REc71C+GnpNyBIc7zCXzRjsrQQac gNrtkRbd1aJb67tzKLCoCteBU0f/iy8XTBHiWpfYOOqfJXvTmUcXFgs4bHTGbeShtn0I yz4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=BHwDmOr+18ufj1k4c3zM3JF+0WtS7uKdJzrUDKc3dfI=; b=kGXrq/XdTRU+QwxGoSh4JQqzlUVNDxLjcIjDTn2H3Gnzp3zngo8hrPRDA9Kgxq+Aj0 kyP4Rnu+0Mr6wqt80dmoDrZRssU7SoSHObcxz5u7JtNr5EFI+PzgnyxEeaimNKcYVSxq U4TIw5L5tG4HkEjRdwHZFAGLLuiezCVjF7VnNVsPyOq8GZQnpt79uGnR2loVQuaWv5HK 9/Qyv0aFkg8ZbO/ZA32gXCGoMv4c2cCAJy7fJH9DS3NmlaMr7U1LskM29rpAwqoE88NG DgULPy2vzOc+7qCnPxDefEPet79657v6l5yloPrJ2sJpWbCvahEMexOLzj3TU8eoPuVb Nttg== X-Gm-Message-State: AKaTC01Yg3Fg2ttV2q32Re/XIe9prWT24Lbsva12aLORaECi0HxYW8qyjqS/VyjqNkudsg== X-Received: by 10.194.157.165 with SMTP id wn5mr27147599wjb.8.1481665277117; Tue, 13 Dec 2016 13:41:17 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5DCC6EDC.dip0.t-ipconnect.de. [93.204.110.220]) by smtp.gmail.com with ESMTPSA id cl6sm64077712wjc.10.2016.12.13.13.41.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Dec 2016 13:41:16 -0800 (PST) From: "Mehmet Ersue" To: "'Andy Bierman'" , "'Eric Voit \(evoit\)'" References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> In-Reply-To: Date: Tue, 13 Dec 2016 22:41:12 +0100 Message-ID: <004101d25589$a0cd5f20$e2681d60$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01D25592.02974560" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJvIdnLcbPhtZVe/ZwhlJOAl849fwFrVtQ3AezV2tIA+5xlnwL4zh2sAk77YEwCCFzmZgJIVCHNAgcLeowB7aW4Zp89xbsQ Content-Language: de X-AVK-Virus-Check: AVA 25.9511;155A1E2 X-AVK-Spam-Check: 1; str=0001.0A0C0206.58506AFB.016A,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; F1206 Archived-At: Cc: 'NetMod WG Chairs' , 'Netconf' , 'NetMod WG' , 'NetConf WG Chairs' Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 21:41:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0042_01D25592.02974560 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Andy, =20 > This architectural change needs to be implemented in various = protocols. > I am not sure a 6241bis is the best approach because it is not clear = which > servers really need to implement the revised datastores. =20 =20 I agree fully. This is the reason why I wrote in my mail: =20 >> - a new protocol- and language-independent standard document (RFC = XYZ) defining the generic datastore concept and framework and describing = its use (based on and following the DT solution draft), >> - a RFC6241bis draft removing the current datasore concept = specification, and getting rid of well-known issues e.g. with the = operation, Mehmet =20 From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Dienstag, 13. Dezember 2016 18:38 To: Eric Voit (evoit) Cc: Ladislav Lhotka ; MehmetErsue ; = NetMod WG Chairs ; NetConf WG Chairs = ; NetMod WG ; Netconf = Subject: Re: [netmod] [Netconf] WG adoption poll = draft-nmdsdt-netmod-revised-datastores-00 =20 =20 =20 On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) > wrote: I support adoption, and like Mehmet's thinking as well. Also worth focusing on is transport protocol independent yang filtering. = So along with how to frame get operations against one of the = datastores, how do you know which subtrees/nodes should be = included/excluded. =20 =20 This architectural change needs to be implemented in various protocols. I am not sure a 6241bis is the best approach because it is not clear = which servers really need to implement the revised datastores. Since RD is = purely optional to implement, it should not obsolete 6241 in any way. It should be = possible to add new operations and/or new parameters to existing operations = without needing to redefine what is already there. =20 The new protocol features need to explain how to include/exclude = subtrees. IMO we should only support YANG defined data. This allows the solutions to be generalized and reusable across protocols (e.g., using YANG = extensions). =20 =20 Eric =20 =20 Andy =20 > From: Netconf, December 9, 2016 7:49 AM > > Hi Mehmet, > > I think I could just sign your text at the bottom. > > Lada > > > On 9 Dec 2016, at 13:25, MehmetErsue > wrote: > > > > Hi All, > > > > I think the adoption of the DT draft is fine. We agreed in IETF 97 = to adopt and > finalize the DT draft in NETMOD WG, which I still support. > > > > I believe the bigger issue is to agree on a plan concerning the = related work > and the re-organization of existing standards. As a matter of fact = this plan will > lead to updating the charter of two WGs and the work we are going to = start. > > > > I see the DT document as a datastore solution proposal. There are = different > gaps and issues which still need to be addressed and the solution = proposal > needs yet to be discussed and finalized. The document is providing = information > on the history, explaining the need for a generic solution as well as = is discussing > different scenarios. As such I believe the datastore solution proposal = from the > DT should be published with the intended status Informational RFC. > > > > Based on the finalized and agreed datastore solution we should do = different > updates to existing documents in NETCONF and NETMOD WGs. With this > action we can also fix well-known issues. > > > > Concerning the NETCONF WG I would see it as valuable if we develop: > > - a RFC6241bis draft removing the current datasore concept > > specification, and getting rid of well-known issues e.g. with the > > operation, > > - a new protocol- and language-independent standard document (RFC = XYZ) > > defining the generic datastore concept and framework and describing > > its use (based on and following the DT solution draft), > > - adding potential extensions to RFC6241bis (following the DT draft > > and with a normative reference to RFC XYZ), > > - adding potential extensions to a RESTCONF-bis RFC (following the = DT > > draft and with a normative reference to RFC XYZ), > > > > Concerning the NETMOD WG I would see it as valuable if we develop: > > - RFC7950bis deleting protocol-dependent details and specifying the > > datastore usage with YANG on a generic level (with a normative > > reference to RFC XYZ), > > - adding potential extensions to RFC7950bis, e.g. concerning the > > proposed element, > > - possibly an RFC 6244bis to describe architectural aspects. However = RFC6244 > is Informational and a RFC6244bis would be still Informational. I'm = not sure > whether this is really necessary. The DT proposal does already = describe such a > solution and can be seen as an update to RFC 6244. > > - RFC6087bis giving guidelines on how to use YANG with the new = datastore > concept. > > > > Referring to Lada's proposal concerning the spin off document from > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be > provided in the corresponding protocol RFCs, i.e. > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. > > > > Hope this helps as a starting point on the way to a good plan. > > > > PS: As Benoit suggested some time ago we might also consider to = rename > NETCONF WG as it is not only on NETCONF protocol anymore. > > > > Regards, > > Mehmet > > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman > > wrote: > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder > > wrote: > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: > > > > > > > > > > > I disagree that the datastore model is a protocol specific = aspect. > > > > I consider datastores an architectural component binding data > > > > models and protocols together. In fact, the 'traditional' > > > > datastore model > > > > > > I would agree with this if datastores were a general concept in = YANG, but > the revised-datastores draft explicitly introduces the "intended" and = "applied" > datastores that may be irrelevant to other protocols using YANG, and = even > needn't be used in all NETCONF implementations. I wouldn't call this = "an > architectural component" of YANG. > > > > > > > An architectural component of this new management framework (that = does > > not have a name). The fact that not all protocols may expose all > > datastores is IMHO not a reason that the datastore model is not an > > architectural framework. > > > > > If you are saying that it will have nontrivial impact on YANG, I = would like to > see it explained in sec. 6.3. Without this information I am quite = reluctant to > agree with the adoption. > > > > An operational state datastore has implications how one writes data > > models. It may not directly affect YANG itself but surely the usage = of > > YANG. > > > > > See above - architectural aspects need to be relevant to all = protocols. > > > > Yes, but relevant to all protocols does not mean every protocol = needs > > to expose say all datastores. But every protocol should be clear = about > > how what it exposes relates to the architectural framework. > > > > > > > > There is a "current solution" consisting of hard-wired object > > semantics (e.g., ifAdminStatus and ifOperStatus). This solution = does > > not require special protocols or datastores, but it is being = replaced by a > generic solution. > > > > If the "generic" solution requires special procedures which differ = on > > each protocol, then it might end up be worse than the hard-wired = solution > that works on every protocol. > > So I agree with Juergen that this is primarily an architectural = issue. > > > > > > /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 =20 > > https://www.ietf.org/mailman/listinfo/netmod > > -- > > Cheers, > > Mehmet > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org =20 > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ netmod mailing list netmod@ietf.org =20 https://www.ietf.org/mailman/listinfo/netmod =20 ------=_NextPart_000_0042_01D25592.02974560 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Andy,

 

> This architectural change needs to be implemented in = various protocols.

> I am not sure a 6241bis is the best approach because = it is not clear which

> servers really need to implement the revised = datastores. 

 

I agree fully. This is the reason why I wrote in my = mail:

 

>> - a new protocol- and language-independent = standard document (RFC XYZ) defining the generic datastore concept and = framework and describing its use (based on and following the DT solution = draft),

>> - a RFC6241bis draft removing the current = datasore concept specification, and getting rid of well-known issues = e.g. with the <get> operation,

Mehmet

 

From:<= /b> Andy = Bierman [mailto:andy@yumaworks.com]
Sent: Dienstag, 13. = Dezember 2016 18:38
To: Eric Voit (evoit) = <evoit@cisco.com>
Cc: Ladislav Lhotka = <lhotka@nic.cz>; MehmetErsue <mersue@gmail.com>; NetMod WG = Chairs <netmod-chairs@ietf.org>; NetConf WG Chairs = <netconf-chairs@ietf.org>; NetMod WG <netmod@ietf.org>; = Netconf <netconf@ietf.org>
Subject: Re: [netmod] = [Netconf] WG adoption poll = draft-nmdsdt-netmod-revised-datastores-00

 

 

 

On Tue, = Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) <evoit@cisco.com> = wrote:

I support adoption, and like Mehmet's = thinking as well.

Also worth focusing on is transport protocol = independent yang filtering.  So along with how to frame get = operations against one of the datastores, how do you know which = subtrees/nodes should be = included/excluded.

 

 

This architectural change needs to be implemented in = various protocols.

I am = not sure a 6241bis is the best approach because it is not clear = which

servers really need = to implement the revised datastores.  Since RD is purely = optional

to implement, it = should not obsolete 6241 in any way.  It should be = possible

to add new = operations and/or new parameters to existing operations = without

needing to = redefine what is already there.

 

The new protocol features need to explain how to = include/exclude subtrees.

IMO we should only support YANG defined data.  = This allows the solutions

to be generalized and reusable across protocols (e.g., = using YANG extensions).

 

 

Eric

 

 

Andy

 


> = From: Netconf, December 9, 2016 7:49 AM
>
> Hi = Mehmet,
>
> I think I could just sign your text at the = bottom.
>
> Lada
>
> > On 9 Dec 2016, at = 13:25, MehmetErsue <mersue@gmail.com> wrote:
> = >
> > Hi All,
> >
> > I think the adoption = of the DT draft is fine. We agreed in IETF 97 to adopt and
> = finalize the DT draft in NETMOD WG, which I still support.
> = >
> > I believe the bigger issue is to agree on a plan = concerning the related work
> and the re-organization of existing = standards. As a matter of fact this plan will
> lead to updating = the charter of two WGs and the work we are going to start.
> = >
> > I see the DT document as a datastore solution = proposal. There are different
> gaps and issues which still need = to be addressed and the solution proposal
> needs yet to be = discussed and finalized. The document is providing information
> = on the history, explaining the need for a generic solution as well as is = discussing
> different scenarios. As such I believe the datastore = solution proposal from the
> DT should be published with the = intended status Informational RFC.
> >
> > Based on = the finalized and agreed datastore solution we should do = different
> updates to existing documents in NETCONF and NETMOD = WGs. With this
> action we can also fix well-known issues.
> = >
> > Concerning the NETCONF WG I would see it as valuable = if we develop:
> > - a RFC6241bis draft removing the current = datasore concept
> > specification, and getting rid of = well-known issues e.g. with the
> > <get> = operation,
> > - a new protocol- and language-independent = standard document (RFC XYZ)
> > defining the generic datastore = concept and framework and describing
> > its use (based on and = following the DT solution draft),
> > - adding potential = extensions to RFC6241bis (following the DT draft
> > and with a = normative reference to RFC XYZ),
> > - adding potential = extensions to a RESTCONF-bis RFC (following the DT
> > draft = and with a normative reference to RFC XYZ),
> >
> > = Concerning the NETMOD WG I would see it as valuable if we = develop:
> > - RFC7950bis deleting protocol-dependent details = and specifying the
> > datastore usage with YANG on a generic = level (with a normative
> > reference to RFC XYZ),
> > = - adding potential extensions to RFC7950bis, e.g. concerning the
> = > proposed <notification> element,
> > - possibly an = RFC 6244bis to describe architectural aspects. However RFC6244
> = is Informational and a RFC6244bis would be still Informational. I'm not = sure
> whether this is really necessary. The DT proposal does = already describe such a
> solution and can be seen as an update to = RFC 6244.
> > - RFC6087bis giving guidelines on how to use YANG = with the new datastore
> concept.
> >
> > = Referring to Lada's proposal concerning the spin off document = from
> > RFC7950 ("Adapting NETCONF for use with = YANG"), I think this can be
> provided in the corresponding = protocol RFCs, i.e.
> > for NETCONF a section on "Using = NETCONF with YANG" in RFC6241bis and
> for RESTCONF = "Using RESTCONF with YANG" in RESTCONF-bis RFC.
> = >
> > Hope this helps as a starting point on the way to a = good plan.
> >
> > PS: As Benoit suggested some time = ago we might also consider to rename
> NETCONF WG as it is not = only on NETCONF protocol anymore.
> >
> > = Regards,
> > Mehmet
> >
> > On Mon, Dec 5, = 2016 at 6:19 PM Andy Bierman <andy@yumaworks.com>
> = wrote:
> > On Mon, Dec 5, 2016 at 4:02 AM, Juergen = Schoenwaelder
> <j.schoenwaelder@jaco= bs-university.de> wrote:
> > On Mon, Dec 05, 2016 at = 11:36:11AM +0100, Ladislav Lhotka wrote:
> > >
> > = > >
> > > > I disagree that the datastore model is = a protocol specific aspect.
> > > > I consider datastores = an architectural component binding data
> > > > models = and protocols together. In fact, the 'traditional'
> > > = > datastore model
> > >
> > > I would agree = with this if datastores were a general concept in YANG, but
> the = revised-datastores draft explicitly introduces the "intended" = and "applied"
> datastores that may be irrelevant to = other protocols using YANG, and even
> needn't be used in all = NETCONF implementations. I wouldn't call this "an
> = architectural component" of YANG.
> > >
> = >
> > An architectural component of this new management = framework (that does
> > not have a name). The fact that not = all protocols may expose all
> > datastores is IMHO not a = reason that the datastore model is not an
> > architectural = framework.
> >
> > > If you are saying that it will = have nontrivial impact on YANG, I would like to
> see it explained = in sec. 6.3. Without this information I am quite reluctant to
> = agree with the adoption.
> >
> > An operational state = datastore has implications how one writes data
> > models. It = may not directly affect YANG itself but surely the usage of
> > = YANG.
> >
> > > See above - architectural aspects = need to be relevant to all protocols.
> >
> > Yes, but = relevant to all protocols does not mean every protocol needs
> = > to expose say all datastores. But every protocol should be clear = about
> > how what it exposes relates to the architectural = framework.
> >
> >
> >
> > There is = a "current solution" consisting of hard-wired object
> = > semantics (e.g., ifAdminStatus and ifOperStatus).  This = solution does
> > not require special protocols or datastores, = but it is being replaced by a
> generic solution.
> = >
> > If the "generic" solution requires special = procedures which differ on
> > each protocol, then it might end = up be worse than the hard-wired solution
> that works on every = protocol.
> > So I agree with Juergen that this is primarily an = architectural issue.
> >
> >
> > /js
> = >
> > Andy
> >
> >
> >
> = > --
> > Juergen Schoenwaelder        =    Jacobs University Bremen gGmbH
> > Phone: +49 421 = 200 3587         Campus Ring 1 | 28759 Bremen | = Germany
> > Fax:   +49 421 200 3103    =      <http://www.jacobs-university.de/>
> = >
> > = _______________________________________________
> > netmod = mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>= ; > --
> > Cheers,
> > Mehmet
>
> = --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: = E74E8C0C
>
>
>
>
> = _______________________________________________
> Netconf mailing = list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
_______________________________________________
netmod mailing = list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

 

------=_NextPart_000_0042_01D25592.02974560-- From nobody Tue Dec 13 13:52:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BDA129AA2 for ; Tue, 13 Dec 2016 13:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyMtHws-6DDW for ; Tue, 13 Dec 2016 13:51:56 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 7F1BB129AD4 for ; Tue, 13 Dec 2016 13:51:52 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id p16so503545qta.0 for ; Tue, 13 Dec 2016 13:51:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XmoRGMREoULTnILlYwqDFlZQFrc004c7jeFUNQJbjnU=; b=k0ueKacfxMM/fb18Bmdz1nT7qHcevK8DTPw4ieHgF0JSokmDo4Gq5C7PUA+yZH3EO7 9iptUe1CLFaKoC4cStptvrARdFUK3VthIye8a+sE4jjc2gX3K1LbeGQeMHjXUQmm/yEQ 3k0wpKQRFhHWFoKYwUjiHoJKa1xrN6RtKbcp3zn66eU4bh4aKRq3qnp9JrZRMQEBL6kM xSHckFTYKjO9DYuEie13XxqJLgNnhVJ1uJ0ylsF3CRsFFyT3F+7s19Q0qVapFeAkSS+Y AKg5b0MzT1GfJlJn7h1mvUeziyslTseHEdvkg+y1EbqLB4vlFg4Op76IugRx7f0bk7NE xfcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XmoRGMREoULTnILlYwqDFlZQFrc004c7jeFUNQJbjnU=; b=W6nVzH+0m79irT0bm1kfx4YUYJQHKksfObHimtd7mFSFcVpsxyG3McbI7P/rCVLMPT jE3fefQk8vg6oma9L8QSeY6yWXhBohitZlezRAOGBDmNBfDefk4I1UJ3ajSHV9y01sqO mTb18e/6swXD7BSqpIScCFSUsWtyHF+++CeUazzXsAEStGRICDfZjztdmOdbVB1yY26Q WD6NGuXHat5C9B//+bULDcKqcd5ZBdyTvAvKuas2iSSI6YHWOU89ELTr1dV15kH+eUUG NBoPF/j2WU8d8ofvC/er15w1r8LlrvPP58XlTTYZen+v3u6hYFt6k0qtS7iCC6L3PI++ xj6g== X-Gm-Message-State: AKaTC01FLbH58Nkl293Sn8frqNhhROkfjkVfPDQrlUPTbbEDjINfz3ai/zRJ2bQdvJA8TE0RjoXmI2vysNTV8w== X-Received: by 10.200.41.171 with SMTP id 40mr94780054qts.235.1481665911557; Tue, 13 Dec 2016 13:51:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Tue, 13 Dec 2016 13:51:50 -0800 (PST) In-Reply-To: <004101d25589$a0cd5f20$e2681d60$@gmail.com> References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> From: Andy Bierman Date: Tue, 13 Dec 2016 13:51:50 -0800 Message-ID: To: Mehmet Ersue Content-Type: multipart/alternative; boundary=001a1140657855a4ad0543913a0c Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 21:51:58 -0000 --001a1140657855a4ad0543913a0c Content-Type: text/plain; charset=UTF-8 On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue wrote: > Hi Andy, > > > > > This architectural change needs to be implemented in various protocols. > > > I am not sure a 6241bis is the best approach because it is not clear > which > > > servers really need to implement the revised datastores. > > > > I agree fully. This is the reason why I wrote in my mail: > > > > >> - a new protocol- and language-independent standard document (RFC XYZ) > defining the generic datastore concept and framework and describing its use > (based on and following the DT solution draft), > > >> - a RFC6241bis draft removing the current datasore concept > specification, and getting rid of well-known issues e.g. with the > operation, > > I do not agree with the text you wrote. I do not want to remove candidate, running, and startup from RFC 6241. IMO the new datastores can be defined in a new document that does not redefine the existing datastores. I also do not want to get rid of , It works as intended. It is not a problem on small devices. It is not a problem on large devices if sufficient filtering is used. It does not differentiate between intended and applied config or understand different types of config=false nodes. Use a new operation to add these features. > Mehmet > Andy > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Dienstag, 13. Dezember 2016 18:38 > *To:* Eric Voit (evoit) > *Cc:* Ladislav Lhotka ; MehmetErsue ; > NetMod WG Chairs ; NetConf WG Chairs < > netconf-chairs@ietf.org>; NetMod WG ; Netconf < > netconf@ietf.org> > *Subject:* Re: [netmod] [Netconf] WG adoption poll > draft-nmdsdt-netmod-revised-datastores-00 > > > > > > > > On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) > wrote: > > I support adoption, and like Mehmet's thinking as well. > > Also worth focusing on is transport protocol independent yang filtering. > So along with how to frame get operations against one of the datastores, > how do you know which subtrees/nodes should be included/excluded. > > > > > > This architectural change needs to be implemented in various protocols. > > I am not sure a 6241bis is the best approach because it is not clear which > > servers really need to implement the revised datastores. Since RD is > purely optional > > to implement, it should not obsolete 6241 in any way. It should be > possible > > to add new operations and/or new parameters to existing operations without > > needing to redefine what is already there. > > > > The new protocol features need to explain how to include/exclude subtrees. > > IMO we should only support YANG defined data. This allows the solutions > > to be generalized and reusable across protocols (e.g., using YANG > extensions). > > > > > > Eric > > > > > > Andy > > > > > > From: Netconf, December 9, 2016 7:49 AM > > > > Hi Mehmet, > > > > I think I could just sign your text at the bottom. > > > > Lada > > > > > On 9 Dec 2016, at 13:25, MehmetErsue wrote: > > > > > > Hi All, > > > > > > I think the adoption of the DT draft is fine. We agreed in IETF 97 to > adopt and > > finalize the DT draft in NETMOD WG, which I still support. > > > > > > I believe the bigger issue is to agree on a plan concerning the > related work > > and the re-organization of existing standards. As a matter of fact this > plan will > > lead to updating the charter of two WGs and the work we are going to > start. > > > > > > I see the DT document as a datastore solution proposal. There are > different > > gaps and issues which still need to be addressed and the solution > proposal > > needs yet to be discussed and finalized. The document is providing > information > > on the history, explaining the need for a generic solution as well as is > discussing > > different scenarios. As such I believe the datastore solution proposal > from the > > DT should be published with the intended status Informational RFC. > > > > > > Based on the finalized and agreed datastore solution we should do > different > > updates to existing documents in NETCONF and NETMOD WGs. With this > > action we can also fix well-known issues. > > > > > > Concerning the NETCONF WG I would see it as valuable if we develop: > > > - a RFC6241bis draft removing the current datasore concept > > > specification, and getting rid of well-known issues e.g. with the > > > operation, > > > - a new protocol- and language-independent standard document (RFC XYZ) > > > defining the generic datastore concept and framework and describing > > > its use (based on and following the DT solution draft), > > > - adding potential extensions to RFC6241bis (following the DT draft > > > and with a normative reference to RFC XYZ), > > > - adding potential extensions to a RESTCONF-bis RFC (following the DT > > > draft and with a normative reference to RFC XYZ), > > > > > > Concerning the NETMOD WG I would see it as valuable if we develop: > > > - RFC7950bis deleting protocol-dependent details and specifying the > > > datastore usage with YANG on a generic level (with a normative > > > reference to RFC XYZ), > > > - adding potential extensions to RFC7950bis, e.g. concerning the > > > proposed element, > > > - possibly an RFC 6244bis to describe architectural aspects. However > RFC6244 > > is Informational and a RFC6244bis would be still Informational. I'm not > sure > > whether this is really necessary. The DT proposal does already describe > such a > > solution and can be seen as an update to RFC 6244. > > > - RFC6087bis giving guidelines on how to use YANG with the new > datastore > > concept. > > > > > > Referring to Lada's proposal concerning the spin off document from > > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be > > provided in the corresponding protocol RFCs, i.e. > > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and > > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. > > > > > > Hope this helps as a starting point on the way to a good plan. > > > > > > PS: As Benoit suggested some time ago we might also consider to rename > > NETCONF WG as it is not only on NETCONF protocol anymore. > > > > > > Regards, > > > Mehmet > > > > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman > > wrote: > > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder > > wrote: > > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: > > > > > > > > > > > > > > I disagree that the datastore model is a protocol specific aspect. > > > > > I consider datastores an architectural component binding data > > > > > models and protocols together. In fact, the 'traditional' > > > > > datastore model > > > > > > > > I would agree with this if datastores were a general concept in > YANG, but > > the revised-datastores draft explicitly introduces the "intended" and > "applied" > > datastores that may be irrelevant to other protocols using YANG, and even > > needn't be used in all NETCONF implementations. I wouldn't call this "an > > architectural component" of YANG. > > > > > > > > > > An architectural component of this new management framework (that does > > > not have a name). The fact that not all protocols may expose all > > > datastores is IMHO not a reason that the datastore model is not an > > > architectural framework. > > > > > > > If you are saying that it will have nontrivial impact on YANG, I > would like to > > see it explained in sec. 6.3. Without this information I am quite > reluctant to > > agree with the adoption. > > > > > > An operational state datastore has implications how one writes data > > > models. It may not directly affect YANG itself but surely the usage of > > > YANG. > > > > > > > See above - architectural aspects need to be relevant to all > protocols. > > > > > > Yes, but relevant to all protocols does not mean every protocol needs > > > to expose say all datastores. But every protocol should be clear about > > > how what it exposes relates to the architectural framework. > > > > > > > > > > > > There is a "current solution" consisting of hard-wired object > > > semantics (e.g., ifAdminStatus and ifOperStatus). This solution does > > > not require special protocols or datastores, but it is being replaced > by a > > generic solution. > > > > > > If the "generic" solution requires special procedures which differ on > > > each protocol, then it might end up be worse than the hard-wired > solution > > that works on every protocol. > > > So I agree with Juergen that this is primarily an architectural issue. > > > > > > > > > /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 > > > -- > > > Cheers, > > > Mehmet > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > --001a1140657855a4ad0543913a0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
--001a1140657855a4ad0543913a0c-- From nobody Tue Dec 13 14:47:19 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46103129C23; Tue, 13 Dec 2016 14:47:15 -0800 (PST) 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 JRLPzOgl8ijb; Tue, 13 Dec 2016 14:47:12 -0800 (PST) Received: from mail-wj0-x243.google.com (mail-wj0-x243.google.com [IPv6:2a00:1450:400c:c01::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 93598129C10; Tue, 13 Dec 2016 14:47:11 -0800 (PST) Received: by mail-wj0-x243.google.com with SMTP id he10so395197wjc.2; Tue, 13 Dec 2016 14:47:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language :disposition-notification-to; bh=FkK1cTPTIgGhmsjdyuS1NjFj9Eeka4K9/uhUvaHz9lE=; b=iN6XTcuWlq9ojexjFICmdagbj6uxyIusi38A3ri7PSjR5poRqBoCcLZKYC2oVkpH/6 VJUVw/FD1mWfFkjxaN3Kn6D+TV/nZBQCHwrhbAD+2Wch6RXVrKxHu/skki6AEIZVOhau osgBvA9OvHw7+A3eneA6SP8G8LJjz5KlD3TiX8ugoWXjV6W2ywccdR3RaO9XyEkD6GiA PcQ7pLCBuyPTtqatctMnSNrD8pSSgns9rccSNvn3I9S5GYnjx3TklIwPb66IlHJ50wp8 J7B9cGCzgXly74FqN4gV7RObRJxv/7xkJltn+Z+DNptWeURZsLwBVJShqHNinUeiAzPw f0qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language :disposition-notification-to; bh=FkK1cTPTIgGhmsjdyuS1NjFj9Eeka4K9/uhUvaHz9lE=; b=FXogPukfdvLZIWgivByDYTStkc/lHuddwlDDMUCHw2ib7TORZ4lx1Cv8Jx8mL2p3vs +jhtz0bcdBOSFNgS/597PZnTVb2Ov+jJo0hpBeJ82ru2+pu+9Y7KjjkA/Y3rW/2vtQ6C CiK0f4LAjUy7PcMrLE9mLmcRF0X5g+Fdh+uw1ElB0s1UCgMoyfRZQ/narZoJQHO9F8WU IuJXwGG+ipzcqlI+daAbaJWNRFGGR+pB6C9KFE6lgggUc8EcZIaAyI4Mv/aVfaETxzMr otBWq7rJlVOE79pacjbfHxFuyeIlVQ9SQGTq5+5ln2tyS7m1tU9Fvm2f270Yle2oI388 afMg== X-Gm-Message-State: AKaTC03dB8f+ReBn7/InnAYyhULc65NiDu/KGLxMMRIBmOS2JDEo45TDyoTihRZu72BW2A== X-Received: by 10.194.201.103 with SMTP id jz7mr95774289wjc.70.1481669229893; Tue, 13 Dec 2016 14:47:09 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5DCC6EDC.dip0.t-ipconnect.de. [93.204.110.220]) by smtp.gmail.com with ESMTPSA id vr9sm64232555wjc.35.2016.12.13.14.47.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Dec 2016 14:47:08 -0800 (PST) From: "Mehmet Ersue" To: "'Andy Bierman'" References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> In-Reply-To: Date: Tue, 13 Dec 2016 23:47:05 +0100 Message-ID: <00ae01d25592$d46ee7f0$7d4cb7d0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AF_01D2559B.36399180" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJvIdnLcbPhtZVe/ZwhlJOAl849fwFrVtQ3AezV2tIA+5xlnwL4zh2sAk77YEwCCFzmZgJIVCHNAgcLeowB7aW4ZgFJbBpLAgSx2bCfI2eN8A== Content-Language: de X-AVK-Virus-Check: AVA 25.9511;155A1E2 X-AVK-Spam-Check: 1; str=0001.0A0C0205.58507A6C.00F0,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; F1206 Archived-At: Cc: 'NetMod WG Chairs' , 'NetConf WG Chairs' , 'NetMod WG' , 'Netconf' Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 22:47:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00AF_01D2559B.36399180 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Technically spoken actually both options work for me:=20 Keeping current concept in 6241 or having everything in one document. I prefer the latter. =20 We actually don=E2=80=99t want to remove , only solve issues. Any change to is for sure subject to WG decision. =20 Mehmet =20 From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Tuesday, December 13, 2016 10:52 PM To: Mehmet Ersue Cc: Eric Voit (evoit) ; Ladislav Lhotka = ; NetMod WG Chairs ; NetConf WG = Chairs ; NetMod WG ; Netconf = Subject: Re: [netmod] [Netconf] WG adoption poll = draft-nmdsdt-netmod-revised-datastores-00 =20 =20 =20 On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue > wrote: Hi Andy, =20 > This architectural change needs to be implemented in various = protocols. > I am not sure a 6241bis is the best approach because it is not clear = which > servers really need to implement the revised datastores. =20 =20 I agree fully. This is the reason why I wrote in my mail: =20 >> - a new protocol- and language-independent standard document (RFC = XYZ) defining the generic datastore concept and framework and describing = its use (based on and following the DT solution draft), >> - a RFC6241bis draft removing the current datasore concept = specification, and getting rid of well-known issues e.g. with the = operation, =20 I do not agree with the text you wrote. I do not want to remove candidate, running, and startup from RFC 6241. IMO the new datastores can be defined in a new document that does not = redefine the existing datastores. =20 I also do not want to get rid of , It works as intended. It is not a problem on small devices. It is not a problem on large = devices if sufficient filtering is used. It does not differentiate between = intended and applied config or understand different types of config=3Dfalse nodes. Use a new = operation to add these features. =20 =20 =20 =20 =20 Mehmet =20 =20 Andy =20 =20 =20 From: Andy Bierman [mailto:andy@yumaworks.com = ]=20 Sent: Dienstag, 13. Dezember 2016 18:38 To: Eric Voit (evoit) > Cc: Ladislav Lhotka >; MehmetErsue = >; NetMod WG Chairs = >; NetConf WG = Chairs >; = NetMod WG >; Netconf = > Subject: Re: [netmod] [Netconf] WG adoption poll = draft-nmdsdt-netmod-revised-datastores-00 =20 =20 =20 On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) > wrote: I support adoption, and like Mehmet's thinking as well. Also worth focusing on is transport protocol independent yang filtering. = So along with how to frame get operations against one of the = datastores, how do you know which subtrees/nodes should be = included/excluded. =20 =20 This architectural change needs to be implemented in various protocols. I am not sure a 6241bis is the best approach because it is not clear = which servers really need to implement the revised datastores. Since RD is = purely optional to implement, it should not obsolete 6241 in any way. It should be = possible to add new operations and/or new parameters to existing operations = without needing to redefine what is already there. =20 The new protocol features need to explain how to include/exclude = subtrees. IMO we should only support YANG defined data. This allows the solutions to be generalized and reusable across protocols (e.g., using YANG = extensions). =20 =20 Eric =20 =20 Andy =20 > From: Netconf, December 9, 2016 7:49 AM > > Hi Mehmet, > > I think I could just sign your text at the bottom. > > Lada > > > On 9 Dec 2016, at 13:25, MehmetErsue > wrote: > > > > Hi All, > > > > I think the adoption of the DT draft is fine. We agreed in IETF 97 = to adopt and > finalize the DT draft in NETMOD WG, which I still support. > > > > I believe the bigger issue is to agree on a plan concerning the = related work > and the re-organization of existing standards. As a matter of fact = this plan will > lead to updating the charter of two WGs and the work we are going to = start. > > > > I see the DT document as a datastore solution proposal. There are = different > gaps and issues which still need to be addressed and the solution = proposal > needs yet to be discussed and finalized. The document is providing = information > on the history, explaining the need for a generic solution as well as = is discussing > different scenarios. As such I believe the datastore solution proposal = from the > DT should be published with the intended status Informational RFC. > > > > Based on the finalized and agreed datastore solution we should do = different > updates to existing documents in NETCONF and NETMOD WGs. With this > action we can also fix well-known issues. > > > > Concerning the NETCONF WG I would see it as valuable if we develop: > > - a RFC6241bis draft removing the current datasore concept > > specification, and getting rid of well-known issues e.g. with the > > operation, > > - a new protocol- and language-independent standard document (RFC = XYZ) > > defining the generic datastore concept and framework and describing > > its use (based on and following the DT solution draft), > > - adding potential extensions to RFC6241bis (following the DT draft > > and with a normative reference to RFC XYZ), > > - adding potential extensions to a RESTCONF-bis RFC (following the = DT > > draft and with a normative reference to RFC XYZ), > > > > Concerning the NETMOD WG I would see it as valuable if we develop: > > - RFC7950bis deleting protocol-dependent details and specifying the > > datastore usage with YANG on a generic level (with a normative > > reference to RFC XYZ), > > - adding potential extensions to RFC7950bis, e.g. concerning the > > proposed element, > > - possibly an RFC 6244bis to describe architectural aspects. However = RFC6244 > is Informational and a RFC6244bis would be still Informational. I'm = not sure > whether this is really necessary. The DT proposal does already = describe such a > solution and can be seen as an update to RFC 6244. > > - RFC6087bis giving guidelines on how to use YANG with the new = datastore > concept. > > > > Referring to Lada's proposal concerning the spin off document from > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be > provided in the corresponding protocol RFCs, i.e. > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. > > > > Hope this helps as a starting point on the way to a good plan. > > > > PS: As Benoit suggested some time ago we might also consider to = rename > NETCONF WG as it is not only on NETCONF protocol anymore. > > > > Regards, > > Mehmet > > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman > > wrote: > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder > > wrote: > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: > > > > > > > > > > > I disagree that the datastore model is a protocol specific = aspect. > > > > I consider datastores an architectural component binding data > > > > models and protocols together. In fact, the 'traditional' > > > > datastore model > > > > > > I would agree with this if datastores were a general concept in = YANG, but > the revised-datastores draft explicitly introduces the "intended" and = "applied" > datastores that may be irrelevant to other protocols using YANG, and = even > needn't be used in all NETCONF implementations. I wouldn't call this = "an > architectural component" of YANG. > > > > > > > An architectural component of this new management framework (that = does > > not have a name). The fact that not all protocols may expose all > > datastores is IMHO not a reason that the datastore model is not an > > architectural framework. > > > > > If you are saying that it will have nontrivial impact on YANG, I = would like to > see it explained in sec. 6.3. Without this information I am quite = reluctant to > agree with the adoption. > > > > An operational state datastore has implications how one writes data > > models. It may not directly affect YANG itself but surely the usage = of > > YANG. > > > > > See above - architectural aspects need to be relevant to all = protocols. > > > > Yes, but relevant to all protocols does not mean every protocol = needs > > to expose say all datastores. But every protocol should be clear = about > > how what it exposes relates to the architectural framework. > > > > > > > > There is a "current solution" consisting of hard-wired object > > semantics (e.g., ifAdminStatus and ifOperStatus). This solution = does > > not require special protocols or datastores, but it is being = replaced by a > generic solution. > > > > If the "generic" solution requires special procedures which differ = on > > each protocol, then it might end up be worse than the hard-wired = solution > that works on every protocol. > > So I agree with Juergen that this is primarily an architectural = issue. > > > > > > /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 =20 > > https://www.ietf.org/mailman/listinfo/netmod > > -- > > Cheers, > > Mehmet > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org =20 > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ netmod mailing list netmod@ietf.org =20 https://www.ietf.org/mailman/listinfo/netmod =20 =20 ------=_NextPart_000_00AF_01D2559B.36399180 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Technically = spoken actually both options work for me:

Keeping = current concept in 6241 or having everything in one = document.

I prefer the = latter.

 

We actually = don=E2=80=99t want to = remove <get>, only solve issues.

Any change = to <get> is for sure subject to WG = decision.

 

Mehmet

 

From:<= /b> = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Tuesday, = December 13, 2016 10:52 PM
To: Mehmet Ersue = <mersue@gmail.com>
Cc: Eric Voit (evoit) = <evoit@cisco.com>; Ladislav Lhotka <lhotka@nic.cz>; NetMod = WG Chairs <netmod-chairs@ietf.org>; NetConf WG Chairs = <netconf-chairs@ietf.org>; NetMod WG <netmod@ietf.org>; = Netconf <netconf@ietf.org>
Subject: Re: [netmod] = [Netconf] WG adoption poll = draft-nmdsdt-netmod-revised-datastores-00

 

 

 

On Tue, = Dec 13, 2016 at 1:41 PM, Mehmet Ersue <mersue@gmail.com> = wrote:

Hi = Andy,

 =

> This = architectural change needs to be implemented in various = protocols.

> I am = not sure a 6241bis is the best approach because it is not clear = which

> servers = really need to implement the revised datastores. 

 =

I agree = fully. This is the reason why I wrote in my mail:

 =

>> - a = new protocol- and language-independent standard document (RFC XYZ) = defining the generic datastore concept and framework and describing its = use (based on and following the DT solution draft),

>> - a = RFC6241bis draft removing the current datasore concept specification, = and getting rid of well-known issues e.g. with the <get> = operation,

 

I = do not agree with the text you wrote.

I do not want to remove candidate, running, and = startup from RFC 6241.

IMO = the new datastores can be defined in a new document that does not = redefine the existing datastores.

 

I = also do not want to get rid of <get>,  It works as = intended.

It is not a = problem on small devices.  It is not a problem on large devices = if

sufficient filtering is = used.  It does not differentiate between intended and applied = config

or understand = different types of config=3Dfalse nodes.  Use a new operation = to

add these = features.

 

 

 

 

 

Mehmet=

 

 

Andy

 

 

 =

From:<= /b> = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Dienstag, 13. = Dezember 2016 18:38
To: Eric Voit (evoit) <evoit@cisco.com>
Cc: Ladislav Lhotka = <lhotka@nic.cz>; MehmetErsue <mersue@gmail.com>; NetMod WG Chairs <netmod-chairs@ietf.org>; NetConf WG Chairs = <netconf-chairs@ietf.org>; NetMod WG <netmod@ietf.org>; Netconf <netconf@ietf.org>
Subject: Re: = [netmod] [Netconf] WG adoption poll = draft-nmdsdt-netmod-revised-datastores-00

 

 

 

On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) <evoit@cisco.com> = wrote:

I = support adoption, and like Mehmet's thinking as well.

Also worth = focusing on is transport protocol independent yang filtering.  So = along with how to frame get operations against one of the datastores, = how do you know which subtrees/nodes should be = included/excluded.

 

 

This architectural change needs to be implemented in various = protocols.

I am not sure a 6241bis is the best approach because it is not = clear which

servers really need to implement the revised datastores.  = Since RD is purely optional

to implement, it should not obsolete 6241 in any way.  It = should be possible

to add new operations and/or new parameters to existing = operations without

needing to redefine what is already = there.

 

The new protocol features need to explain how to = include/exclude subtrees.

IMO we should only support YANG defined data.  This = allows the solutions

to be generalized and reusable across protocols (e.g., using = YANG extensions).

 

 

Eric

 

 

Andy

 


> From: Netconf, December 9, 2016 7:49 = AM
>
> Hi Mehmet,
>
> I think I could just sign = your text at the bottom.
>
> Lada
>
> > On 9 = Dec 2016, at 13:25, MehmetErsue <mersue@gmail.com> wrote:
> >
> = > Hi All,
> >
> > I think the adoption of the DT = draft is fine. We agreed in IETF 97 to adopt and
> finalize the DT = draft in NETMOD WG, which I still support.
> >
> > I = believe the bigger issue is to agree on a plan concerning the related = work
> and the re-organization of existing standards. As a matter = of fact this plan will
> lead to updating the charter of two WGs = and the work we are going to start.
> >
> > I see the = DT document as a datastore solution proposal. There are = different
> gaps and issues which still need to be addressed and = the solution proposal
> needs yet to be discussed and finalized. = The document is providing information
> on the history, explaining = the need for a generic solution as well as is discussing
> = different scenarios. As such I believe the datastore solution proposal = from the
> DT should be published with the intended status = Informational RFC.
> >
> > Based on the finalized and = agreed datastore solution we should do different
> updates to = existing documents in NETCONF and NETMOD WGs. With this
> action = we can also fix well-known issues.
> >
> > Concerning = the NETCONF WG I would see it as valuable if we develop:
> > - = a RFC6241bis draft removing the current datasore concept
> > = specification, and getting rid of well-known issues e.g. with = the
> > <get> operation,
> > - a new protocol- = and language-independent standard document (RFC XYZ)
> > = defining the generic datastore concept and framework and = describing
> > its use (based on and following the DT solution = draft),
> > - adding potential extensions to RFC6241bis = (following the DT draft
> > and with a normative reference to = RFC XYZ),
> > - adding potential extensions to a RESTCONF-bis = RFC (following the DT
> > draft and with a normative reference = to RFC XYZ),
> >
> > Concerning the NETMOD WG I would = see it as valuable if we develop:
> > - RFC7950bis deleting = protocol-dependent details and specifying the
> > datastore = usage with YANG on a generic level (with a normative
> > = reference to RFC XYZ),
> > - adding potential extensions to = RFC7950bis, e.g. concerning the
> > proposed = <notification> element,
> > - possibly an RFC 6244bis to = describe architectural aspects. However RFC6244
> is Informational = and a RFC6244bis would be still Informational. I'm not sure
> = whether this is really necessary. The DT proposal does already describe = such a
> solution and can be seen as an update to RFC = 6244.
> > - RFC6087bis giving guidelines on how to use YANG = with the new datastore
> concept.
> >
> > = Referring to Lada's proposal concerning the spin off document = from
> > RFC7950 ("Adapting NETCONF for use with = YANG"), I think this can be
> provided in the corresponding = protocol RFCs, i.e.
> > for NETCONF a section on "Using = NETCONF with YANG" in RFC6241bis and
> for RESTCONF = "Using RESTCONF with YANG" in RESTCONF-bis RFC.
> = >
> > Hope this helps as a starting point on the way to a = good plan.
> >
> > PS: As Benoit suggested some time = ago we might also consider to rename
> NETCONF WG as it is not = only on NETCONF protocol anymore.
> >
> > = Regards,
> > Mehmet
> >
> > On Mon, Dec 5, = 2016 at 6:19 PM Andy Bierman <andy@yumaworks.com>
> wrote:
> > = On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder
> <j.schoenwaelder@jacobs-university.de> = wrote:
> > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav = Lhotka wrote:
> > >
> > > >
> > > = > I disagree that the datastore model is a protocol specific = aspect.
> > > > I consider datastores an architectural = component binding data
> > > > models and protocols = together. In fact, the 'traditional'
> > > > datastore = model
> > >
> > > I would agree with this if = datastores were a general concept in YANG, but
> the = revised-datastores draft explicitly introduces the "intended" = and "applied"
> datastores that may be irrelevant to = other protocols using YANG, and even
> needn't be used in all = NETCONF implementations. I wouldn't call this "an
> = architectural component" of YANG.
> > >
> = >
> > An architectural component of this new management = framework (that does
> > not have a name). The fact that not = all protocols may expose all
> > datastores is IMHO not a = reason that the datastore model is not an
> > architectural = framework.
> >
> > > If you are saying that it will = have nontrivial impact on YANG, I would like to
> see it explained = in sec. 6.3. Without this information I am quite reluctant to
> = agree with the adoption.
> >
> > An operational state = datastore has implications how one writes data
> > models. It = may not directly affect YANG itself but surely the usage of
> > = YANG.
> >
> > > See above - architectural aspects = need to be relevant to all protocols.
> >
> > Yes, but = relevant to all protocols does not mean every protocol needs
> = > to expose say all datastores. But every protocol should be clear = about
> > how what it exposes relates to the architectural = framework.
> >
> >
> >
> > There is = a "current solution" consisting of hard-wired object
> = > semantics (e.g., ifAdminStatus and ifOperStatus).  This = solution does
> > not require special protocols or datastores, = but it is being replaced by a
> generic solution.
> = >
> > If the "generic" solution requires special = procedures which differ on
> > each protocol, then it might end = up be worse than the hard-wired solution
> that works on every = protocol.
> > So I agree with Juergen that this is primarily an = architectural issue.
> >
> >
> > /js
> = >
> > Andy
> >
> >
> >
> = > --
> > Juergen Schoenwaelder        =    Jacobs University Bremen gGmbH
> > Phone: +49 421 = 200 3587         Campus Ring 1 | 28759 Bremen | = Germany
> > Fax:   +49 421 200 3103    =      <http://www.jacobs-university.de/>
> = >
> > = _______________________________________________
> > netmod = mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>= ; > --
> > Cheers,
> > Mehmet
>
> = --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: = E74E8C0C
>
>
>
>
> = _______________________________________________
> Netconf mailing = list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
_______________________________________________
netmod mailing = list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

 

 

------=_NextPart_000_00AF_01D2559B.36399180-- From nobody Tue Dec 13 16:15:24 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27891296E7; Tue, 13 Dec 2016 16:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBEkoXxjnJ4D; Tue, 13 Dec 2016 16:15:15 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0093.outbound.protection.outlook.com [104.47.41.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609761299F5; Tue, 13 Dec 2016 16:15:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Sa5VfkiMUxMKEn3Pn9iKQNOocWY0qZLP3v6lXuMKtqY=; b=V0DkSWQ/cg/eoQHciB/ZKb770J/0N8NrvodfN+nCCQEF/zrtle5CAyH6teiZAZY2sH7Q2iAv8BTgqiq6YEr/RyzX478a5mQfVzKDoQxLwsF+sOAdvEXRjW1u9dPmbCVtjKvejnhEUjnfqBDZ+7k62wPjM4/8yOEXlXfqae9gG/U= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.4; Wed, 14 Dec 2016 00:15:14 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0771.014; Wed, 14 Dec 2016 00:15:14 +0000 From: Kent Watsen To: "cwildes@cisco.com" , "kkoushik@cisco.com" Thread-Topic: Regarding IPR on draft-ietf-netmod-syslog-model-11 Thread-Index: AQHSVZ8j9uY1Zmk6CkqyieS0rGKapQ== Date: Wed, 14 Dec 2016 00:15:13 +0000 Message-ID: <643A2244-1260-4B86-8D4E-E69C46C20745@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1c.1.161117 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: 68ca9bd6-fe9a-40ef-d6a2-08d423b6469b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0501MB1450; x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1450; 7:+YPglcttdrlr/Wbk3NGwfF+MKKDPQHNtOEn46f7+HWQQGlQDW+tDNQRl9SPoFJAEl+8M0teK9TqxOgfJ2sWnmMoxnumEEVl0pmhIxV83II+M8XCxkb1pRUj7iQnqRlnoS/92aKjNMBOcpU39ntSJES6bCDK+MS6AZhEB6vCIEpnVWSuxssLSDPUotVxU6VhMBb7Y/6UFgM2mJhZ5l95tzZkShCkL+1kT/VatolcYKdHeKSAfhkp8BhgoKI6bjVZ5FJAV0ll/ZmoH1+sJ52May1rNn758bJFFZyOA2sR2eHs57KQeZbAVitsvDFJVprE5W2U56iHdGG8arWfYZmDEb+Sww8WGB2Ct/l9/0fIc3YeGWcze2HYM527kiYe+BvGfawwNAqiZTbJkdm6fgs6P9c70vTuEPVXp7Fm0rdypRDTDIX/52dzmFkmLtin5+xUqTsT8hdwgthNIkK+ScOnbpA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:CY1PR0501MB1450; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1450; x-forefront-prvs: 01565FED4C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39860400002)(39850400002)(39840400002)(39410400002)(189002)(199003)(5001770100001)(82746002)(230783001)(83506001)(189998001)(6436002)(3280700002)(68736007)(6506006)(5660300001)(2900100001)(6512006)(83716003)(81166006)(8676002)(3660700001)(8936002)(92566002)(81156014)(6116002)(2906002)(101416001)(305945005)(7736002)(102836003)(86362001)(54356999)(4326007)(122556002)(106116001)(4001350100001)(36756003)(2501003)(99286002)(50986999)(77096006)(38730400001)(105586002)(66066001)(6486002)(33656002)(97736004)(3846002)(106356001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1450; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <6387CCD376263847AB7936A4C505AD50@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2016 00:15:13.9979 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1450 Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: [netmod] Regarding IPR on draft-ietf-netmod-syslog-model-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 00:15:23 -0000 DQpBdXRob3JzLCBDb250cmlidXRvcnMsIFdHLA0KIA0KVGhpcyBJUFIgZGlzY2xvc3VyZSByZXF1 ZXN0cyBpcyBiZWluZyBtYWRlIGFzIHBhcnQgb2YgdGhlIHByZXBhcmF0aW9uDQpmb3IgV0cgTGFz dCBDYWxsIG9mIGRyYWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbC0xMS4NCg0KQXJlIHlvdSBh d2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdCBpZGVudGlmaWVkIGFib3ZlPyAN Cg0KUGxlYXNlIHN0YXRlIGVpdGhlcjoNCiAgICAiTm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQ UiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCm9yDQogICAgIlllcywgSSdtIGF3YXJlIG9m IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCiANCklmIHNvLCBoYXMgdGhpcyBJUFIg YmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzDQooc2VlIFJG Q3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8NCg0KSWYgeWVz IHRvIHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjoNCiAgICAiWWVzLCB0aGUgSVBSIGhh cyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMiDQpvcg0K ICAgICJObywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlzY2xvc2VkIg0KIA0KIA0KSWYgeW91IGFu c3dlciBubywgcGxlYXNlIHByb3ZpZGUgYW55IGFkZGl0aW9uYWwgZGV0YWlscyB5b3UgdGhpbmsN CmFwcHJvcHJpYXRlLg0KIA0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Ig b3IgY29udHJpYnV0b3IsIHBsZWFzZSBhbnN3ZXIgdGhlDQphYm92ZSBieSByZXNwb25kaW5nIHRv IHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlDQphd2FyZSBv ZiBhbnkgcmVsZXZhbnQgSVBSLiBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhl IG5leHQNCnN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNo IGF1dGhvciBhbmQgbGlzdGVkDQpjb250cmlidXRvci4gTk9URTogVEhJUyBBUFBMSUVTIFRPIEFM TCBPRiBZT1UgTElTVEVEIElOIFRISVMNCk1FU1NBR0UnUyBUTyBMSU5FUy4NCiANCklmIHlvdSBh cmUgb24gdGhlIFdHIGVtYWlsIGxpc3Qgb3IgYXR0ZW5kIFdHIG1lZXRpbmdzIGJ1dCBhcmUgbm90 IGxpc3RlZA0KYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQgeW91IG9mIHlv dXIgb2JsaWdhdGlvbnMgdW5kZXIgdGhlDQpJRVRGIElQUiBydWxlcyB3aGljaCBlbmNvdXJhZ2Vz IHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZSBhd2FyZQ0Kb2YgSVBSIG9mIG90aGVy cyBvbiBhbiBJRVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8gcmVmcmFpbiBmcm9tIHBhcnRpY2lwYXRp bmcNCmluIGFueSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lvbiByZWxhdGVkIHRvIHlvdXIgdW5k aXNjbG9zZWQgSVBSLiBGb3INCm1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3Mg bGlzdGVkIGFib3ZlIGFuZA0KaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaWVzZy90 cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHkuDQogDQpUaGFuayB5b3UsDQpORVRNT0QgV0cg Q2hhaXJzDQogDQpQUyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9m IHRoaXMgbWVzc2FnZSBpbiB5b3VyIHJlc3BvbnNlLg0KIA0KDQoNCg== From nobody Tue Dec 13 16:16:37 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296491294EC; Tue, 13 Dec 2016 16:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CdqcW6YMfWI; Tue, 13 Dec 2016 16:16:34 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE86F129407; Tue, 13 Dec 2016 16:16:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2878; q=dns/txt; s=iport; t=1481674593; x=1482884193; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JwePI5F0eKf78EEah33G2QNVi+WaXsfhAto+CnT8k8A=; b=Dm89pe3Q8mAyGSd2iTcWuO/0fHV/CJTC/rn2KFPRkr2L+fVvQWihqPoz 3KqzXF84O1uCPPiq0BNLwLBxagr0VI9UArKUR4LcLrZ02n3ej03DLUMJm jDI0hx6tYBjRYrk5qqJzw7kJ4IBT0fZC6C6IWM+trt5yx3pUYr8b1QBdD M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQDgjlBY/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAR9agQYHjUSsIYIJKYV4AhqBYz8UAQIBAQEBAQEBYii?= =?us-ascii?q?EaQYjEUAFEAIBCA4MAiYCAgIwFRACBAENBYhrDqpngiiLFQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2BC4UzgX0IglaEGhEBHBeCbS2CMAEEmmsBhk+KW4F0UYQwiVO?= =?us-ascii?q?SIAEfN2M+Jw4BAYU1cgGGMoEhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,343,1477958400"; d="scan'208";a="185964731" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Dec 2016 00:16:13 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id uBE0GD5m022802 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Dec 2016 00:16:13 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 13 Dec 2016 18:16:12 -0600 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1210.000; Tue, 13 Dec 2016 18:16:12 -0600 From: "Clyde Wildes (cwildes)" To: Kent Watsen , "kkoushik@cisco.com" Thread-Topic: Regarding IPR on draft-ietf-netmod-syslog-model-11 Thread-Index: AQHSVZ8j9uY1Zmk6CkqyieS0rGKapaEGcccA Date: Wed, 14 Dec 2016 00:16:12 +0000 Message-ID: References: <643A2244-1260-4B86-8D4E-E69C46C20745@juniper.net> In-Reply-To: <643A2244-1260-4B86-8D4E-E69C46C20745@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.27.7.182] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Regarding IPR on draft-ietf-netmod-syslog-model-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 00:16:36 -0000 S2VudCwNCg0KTm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhp cyBkcmFmdA0KDQpUaGFua3MsDQoNCkNseWRlDQoNCk9uIDEyLzEzLzE2LCA0OjE1IFBNLCAiS2Vu dCBXYXRzZW4iIDxrd2F0c2VuQGp1bmlwZXIubmV0PiB3cm90ZToNCg0KICAgIA0KICAgIEF1dGhv cnMsIENvbnRyaWJ1dG9ycywgV0csDQogICAgIA0KICAgIFRoaXMgSVBSIGRpc2Nsb3N1cmUgcmVx dWVzdHMgaXMgYmVpbmcgbWFkZSBhcyBwYXJ0IG9mIHRoZSBwcmVwYXJhdGlvbg0KICAgIGZvciBX RyBMYXN0IENhbGwgb2YgZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsLTExLg0KICAgIA0K ICAgIEFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQgaWRlbnRp ZmllZCBhYm92ZT8gDQogICAgDQogICAgUGxlYXNlIHN0YXRlIGVpdGhlcjoNCiAgICAgICAgIk5v LCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQog ICAgb3INCiAgICAgICAgIlllcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8gdGhp cyBkcmFmdCINCiAgICAgDQogICAgSWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBp biBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMNCiAgICAoc2VlIFJGQ3MgMzk3OSwgNDg3 OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8NCiAgICANCiAgICBJZiB5ZXMgdG8g dGhlIGFib3ZlLCBwbGVhc2Ugc3RhdGUgZWl0aGVyOg0KICAgICAgICAiWWVzLCB0aGUgSVBSIGhh cyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMiDQogICAg b3INCiAgICAgICAgIk5vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQiDQogICAgIA0K ICAgICANCiAgICBJZiB5b3UgYW5zd2VyIG5vLCBwbGVhc2UgcHJvdmlkZSBhbnkgYWRkaXRpb25h bCBkZXRhaWxzIHlvdSB0aGluaw0KICAgIGFwcHJvcHJpYXRlLg0KICAgICANCiAgICBJZiB5b3Ug YXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciwgcGxlYXNlIGFu c3dlciB0aGUNCiAgICBhYm92ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVz cyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlDQogICAgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQ Ui4gVGhpcyBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0DQogICAgc3RhZ2Ug dW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBs aXN0ZWQNCiAgICBjb250cmlidXRvci4gTk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZT1Ug TElTVEVEIElOIFRISVMNCiAgICBNRVNTQUdFJ1MgVE8gTElORVMuDQogICAgIA0KICAgIElmIHlv dSBhcmUgb24gdGhlIFdHIGVtYWlsIGxpc3Qgb3IgYXR0ZW5kIFdHIG1lZXRpbmdzIGJ1dCBhcmUg bm90IGxpc3RlZA0KICAgIGFzIGFuIGF1dGhvciBvciBjb250cmlidXRvciwgd2UgcmVtaW5kIHlv dSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyIHRoZQ0KICAgIElFVEYgSVBSIHJ1bGVzIHdoaWNo IGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJlIGF3YXJlDQogICAg b2YgSVBSIG9mIG90aGVycyBvbiBhbiBJRVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8gcmVmcmFpbiBm cm9tIHBhcnRpY2lwYXRpbmcNCiAgICBpbiBhbnkgY29udHJpYnV0aW9uIG9yIGRpc2N1c3Npb24g cmVsYXRlZCB0byB5b3VyIHVuZGlzY2xvc2VkIElQUi4gRm9yDQogICAgbW9yZSBpbmZvcm1hdGlv biwgcGxlYXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJvdmUgYW5kDQogICAgaHR0cDovL3RyYWMu dG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHku DQogICAgIA0KICAgIFRoYW5rIHlvdSwNCiAgICBORVRNT0QgV0cgQ2hhaXJzDQogICAgIA0KICAg IFBTIFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0ZWQgaW4gdGhlIGhlYWRlcnMgb2YgdGhpcyBtZXNz YWdlIGluIHlvdXIgcmVzcG9uc2UuDQogICAgIA0KICAgIA0KICAgIA0KICAgIA0KDQo= From nobody Tue Dec 13 16:25:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DEB12952B; Tue, 13 Dec 2016 16:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJGDEl-c5PQN; Tue, 13 Dec 2016 16:25:54 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0123.outbound.protection.outlook.com [104.47.33.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A6A1293E1; Tue, 13 Dec 2016 16:25:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OU4T5pvCMJ9PghbUrPQXaZyd08p5j2lUK7whWXQfj/M=; b=Qd8P/1aVWe0SwWjMlRJaI97RIFAkh06R52ZCz7RGGyZqtxNe1/VHDg8DmAmqAw9dwh6l3RhNkihEeWfn8fvQzVofTeGEujzEK1c04k3uUJG8VD/xhWlllSCb8ImuE8GpGXCbL6GBE3ShoUgy/DYQztSbydYFBEHc/urImxds0hI= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1451.namprd05.prod.outlook.com (10.160.149.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.4; Wed, 14 Dec 2016 00:25:51 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0771.014; Wed, 14 Dec 2016 00:25:51 +0000 From: Kent Watsen To: "Clyde Wildes (cwildes)" , "kk@employees.org" Thread-Topic: Regarding IPR on draft-ietf-netmod-syslog-model-11 Thread-Index: AQHSVZ8j9uY1Zmk6CkqyieS0rGKapaEGcccA///QZwA= Date: Wed, 14 Dec 2016 00:25:51 +0000 Message-ID: References: <643A2244-1260-4B86-8D4E-E69C46C20745@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1c.1.161117 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: 3c82ecac-7c0b-4d1f-0719-08d423b7c268 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0501MB1451; x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1451; 7:fP0BuUCocP8CrWs9XuDyMBqVZMmEG5UJRnHabmcTs5DCtNcOECwQfZBKOgykdYTz81zCtNg0IadwjGvdDrQqfcD2PEHBG1DcxS4texV77zt+t+LQYOHaI0F86ySFkwaVtvCLy4RP5AV60dM6MAKGwXcCElXsUxfuEPq0HJ2/AoLmQZ4uIC2+YqsP+VoU72SOxYRxFXxqjFvouVB28YxEK9wuOjwZReURwEmR3FDT8VE8DBAp0QesPpfNbjb+zMFR71M9893e5To2W4vhzUDKpq26GAMx0EK7dbI958y55aQKsyOmKgbHvkRqzMIxrrr12oLPWP0W5I72YCxbat1x/1KaAirwM3vdrwFCpQgpptcFLXJ/9oaGU6P4p9s/fsUC2rFxASEPk7tfqMVIflbJO625Erp+ARq3d6MsclTkaHrXnreMdlh34cdkacKS+U7sxUu91JTNgZQ5A3brUvNvHw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148); SRVR:CY1PR0501MB1451; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1451; x-forefront-prvs: 01565FED4C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39850400002)(39410400002)(39840400002)(39450400003)(24454002)(189002)(199003)(377454003)(106356001)(229853002)(2906002)(305945005)(6486002)(38730400001)(4326007)(66066001)(33656002)(2900100001)(92566002)(6436002)(101416001)(77096006)(189998001)(6512006)(6506006)(68736007)(7736002)(76176999)(83716003)(3846002)(8936002)(54356999)(50986999)(81166006)(5660300001)(2950100002)(81156014)(122556002)(36756003)(82746002)(83506001)(86362001)(105586002)(2501003)(99286002)(6116002)(8676002)(5001770100001)(3660700001)(4001350100001)(106116001)(97736004)(230783001)(102836003)(3280700002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1451; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <3F01C8FABB73D34FB0C7A045ED89763E@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2016 00:25:51.2606 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1451 Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Regarding IPR on draft-ietf-netmod-syslog-model-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 00:25:56 -0000 DQpbUmVzZW5kaW5nIHRvIEtpcmFu4oCZcyBuZXcgZW1haWwgYWRkcmVzc10NCg0KDQoNCktlbnQs DQoNCk5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJh ZnQNCg0KVGhhbmtzLA0KQ2x5ZGUNCg0KDQpPbiAxMi8xMy8xNiwgNDoxNSBQTSwgIktlbnQgV2F0 c2VuIiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6DQoNCiAgICANCiAgICBBdXRob3JzLCBD b250cmlidXRvcnMsIFdHLA0KICAgICANCiAgICBUaGlzIElQUiBkaXNjbG9zdXJlIHJlcXVlc3Rz IGlzIGJlaW5nIG1hZGUgYXMgcGFydCBvZiB0aGUgcHJlcGFyYXRpb24NCiAgICBmb3IgV0cgTGFz dCBDYWxsIG9mIGRyYWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbC0xMS4NCiAgICANCiAgICBB cmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0IGlkZW50aWZpZWQg YWJvdmU/IA0KICAgIA0KICAgIFBsZWFzZSBzdGF0ZSBlaXRoZXI6DQogICAgICAgICJObywgSSdt IG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KICAgIG9y DQogICAgICAgICJZZXMsIEknbSBhd2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJh ZnQiDQogICAgIA0KICAgIElmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29t cGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzDQogICAgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2 NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscyk/DQogICAgDQogICAgSWYgeWVzIHRvIHRoZSBh Ym92ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjoNCiAgICAgICAgIlllcywgdGhlIElQUiBoYXMgYmVl biBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIg0KICAgIG9yDQog ICAgICAgICJObywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlzY2xvc2VkIg0KICAgICANCiAgICAg DQogICAgSWYgeW91IGFuc3dlciBubywgcGxlYXNlIHByb3ZpZGUgYW55IGFkZGl0aW9uYWwgZGV0 YWlscyB5b3UgdGhpbmsNCiAgICBhcHByb3ByaWF0ZS4NCiAgICAgDQogICAgSWYgeW91IGFyZSBs aXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IsIHBsZWFzZSBhbnN3ZXIg dGhlDQogICAgYWJvdmUgYnkgcmVzcG9uZGluZyB0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Yg d2hldGhlciBvciBub3QgeW91IGFyZQ0KICAgIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuIFRo aXMgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dA0KICAgIHN0YWdlIHVudGls IGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlzdGVk DQogICAgY29udHJpYnV0b3IuIE5PVEU6IFRISVMgQVBQTElFUyBUTyBBTEwgT0YgWU9VIExJU1RF RCBJTiBUSElTDQogICAgTUVTU0FHRSdTIFRPIExJTkVTLg0KICAgICANCiAgICBJZiB5b3UgYXJl IG9uIHRoZSBXRyBlbWFpbCBsaXN0IG9yIGF0dGVuZCBXRyBtZWV0aW5ncyBidXQgYXJlIG5vdCBs aXN0ZWQNCiAgICBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ugb2Yg eW91ciBvYmxpZ2F0aW9ucyB1bmRlciB0aGUNCiAgICBJRVRGIElQUiBydWxlcyB3aGljaCBlbmNv dXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZSBhd2FyZQ0KICAgIG9mIElQ UiBvZiBvdGhlcnMgb24gYW4gSUVURiBjb250cmlidXRpb24sIG9yIHRvIHJlZnJhaW4gZnJvbSBw YXJ0aWNpcGF0aW5nDQogICAgaW4gYW55IGNvbnRyaWJ1dGlvbiBvciBkaXNjdXNzaW9uIHJlbGF0 ZWQgdG8geW91ciB1bmRpc2Nsb3NlZCBJUFIuIEZvcg0KICAgIG1vcmUgaW5mb3JtYXRpb24sIHBs ZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlIGFuZA0KICAgIGh0dHA6Ly90cmFjLnRvb2xz LmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5Lg0KICAg ICANCiAgICBUaGFuayB5b3UsDQogICAgTkVUTU9EIFdHIENoYWlycw0KICAgICANCiAgICBQUyBQ bGVhc2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBp biB5b3VyIHJlc3BvbnNlLg0KICAgICANCiAgICANCiAgICANCiAgICANCg0KDQoNCg== From nobody Tue Dec 13 17:01:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745A612955F for ; Tue, 13 Dec 2016 17:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I96IVbMRiS1z for ; Tue, 13 Dec 2016 17:01:40 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0104.outbound.protection.outlook.com [104.47.33.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5386712952D for ; Tue, 13 Dec 2016 17:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nB2aGXz2N58KtWVEoNV4DNP16RP7EQR0FxrG+9fJT/4=; b=CAxDrsC4AH1jvxRZOPYWpSaYwlvS1ukEtnfDYo6jGFQ2uu2F3rK7i9BIoAVq9Tzd0h77hTFkV3HFfx9RCi1ljjH/+/9w5V6TWOXtd1mORGuhpAw9xGprckgyVdh0sWfiuvEhiDxkFyXZ7778uI1sH54EBxg0zsOs3tBY2lu3+QI= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.4; Wed, 14 Dec 2016 01:01:38 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0771.014; Wed, 14 Dec 2016 01:01:38 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: WG Last Call for draft-ietf-netmod-syslog-model-11 Thread-Index: AQHSVaWfIiJK4a4BSkqW0KAWiGRnmg== Date: Wed, 14 Dec 2016 01:01:38 +0000 Message-ID: <19039254-973A-461A-8749-95F74C33DAD1@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1c.1.161117 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: c8523881-efd2-4441-d702-08d423bcc245 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0501MB1450; x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1450; 7:qlZysDMeAG60kYiUyCAsgb8nkp7Tt14UO2CDB1HS8z3/1xrFQsr214EKHEEjJS2gXkxYpjqGMQthN7UIaZt1agcq72CR6iyjw+fs1qlupTf6n8iO/vm0zdzbEsyIpC6du0L3eXi8QaXMamk6MNNtNIoaykA6IlhN8OF4xHqR5kKA/4EjLEEw4nha+IpEiC4puBHxr1kbgvLa+wXTOh3HPMTslJvrhX4GlCPOwWAqzAkTFzDTlGl1Isg+Y9piTZ35ZHFlHKf1qtQQaSrYIgrM3WfHip+1QSVqOT17LbbQqB6v6N2yd0yBV7JROnDvlV0tKZfM0Dp1udUX9Zomkd7AknnvPzMvWPl/AfvkT/D5Os9+baJ+fbPxTwFoAUxwqixt+169FzuNhitwevbqNoC29QP1nD0f7cMDwrBZZtyBNzMKtBpIdvXH54gJ7vnaZo3OExpP7hPTdeNfX79CeKCf+A== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:CY1PR0501MB1450; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1450; x-forefront-prvs: 01565FED4C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39850400002)(39410400002)(39860400002)(39450400003)(189002)(199003)(86362001)(54356999)(102836003)(6916009)(2351001)(6116002)(305945005)(7736002)(2906002)(101416001)(105586002)(38730400001)(450100001)(33656002)(97736004)(3846002)(6486002)(66066001)(106116001)(122556002)(50986999)(99286002)(77096006)(4001350100001)(36756003)(2501003)(83506001)(82746002)(106356001)(107886002)(230783001)(81166006)(83716003)(1730700003)(81156014)(3660700001)(92566002)(8936002)(8676002)(3280700002)(5640700002)(6506006)(68736007)(110136003)(6436002)(189998001)(2900100001)(6512006)(5660300001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1450; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2016 01:01:38.5002 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1450 Archived-At: Subject: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 01:01:42 -0000 DQpUaGlzIGlzIGEgbm90aWNlIHRvIHN0YXJ0IGEgdHdvLXdlZWsgTkVUTU9EIFdHIGxhc3QgY2Fs bCBmb3IgdGhlIGRvY3VtZW50Og0KIA0KICAgIEEgWUFORyBEYXRhIE1vZGVsIGZvciBTeXNsb2cg Q29uZmlndXJhdGlvbg0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW5ldG1vZC1zeXNsb2ctbW9kZWwtMTENCiANClBsZWFzZSBpbmRpY2F0ZSB5b3VyIHN1cHBvcnQg b3IgY29uY2VybnMgYnkgVHVlc2RheSwgRGVjZW1iZXIgMjcsIDIwMTYuDQogDQpXZSBhcmUgcGFy dGljdWxhcmx5IGludGVyZXN0ZWQgaW4gc3RhdGVtZW50cyBvZiB0aGUgZm9ybToNCiAgKiBJIGhh dmUgcmV2aWV3ZWQgdGhpcyBkcmFmdCBhbmQgZm91bmQgbm8gaXNzdWVzLg0KICAqIEkgaGF2ZSBy ZXZpZXdlZCB0aGlzIGRyYWZ0IGFuZCBmb3VuZCB0aGUgZm9sbG93aW5nIGlzc3VlczogLi4uDQog DQpBcyB3ZWxsIGFzOg0KICAqIEkgaGF2ZSBpbXBsZW1lbnRlZCB0aGUgZGF0YSBtb2RlbCBpbiB0 aGlzIGRyYWZ0Lg0KICAqIEkgYW0gaW1wbGVtZW50aW5nIHRoZSBkYXRhIG1vZGVsIGluIHRoaXMg ZHJhZnQuDQogICogSSBhbSBjb25zaWRlcmluZyB0byBpbXBsZW1lbnQgdGhlIGRhdGEgbW9kZWwg aW4gdGhpcyBkcmFmdC4NCiAgKiBJIGFtIG5vdCBjb25zaWRlcmluZyB0byBpbXBsZW1lbnQgdGhl IGRhdGEgbW9kZWwgaW4gdGhpcyBkcmFmdC4NCiANClRoYW5rIHlvdSwNCk5FVE1PRCBXRyBDaGFp cnMNCiANCg0KDQo= From nobody Tue Dec 13 20:17:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB10E129554 for ; Tue, 13 Dec 2016 20:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.896, 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 Zg-ZwXVlt_tm for ; Tue, 13 Dec 2016 20:17:00 -0800 (PST) Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0764212948E for ; Tue, 13 Dec 2016 20:16:59 -0800 (PST) From: Alex Campbell To: Kent Watsen , "netmod@ietf.org" Thread-Topic: WG Last Call for draft-ietf-netmod-syslog-model-11 Thread-Index: AQHSVaWfIiJK4a4BSkqW0KAWiGRnmqEGzUbW Date: Wed, 14 Dec 2016 04:16:57 +0000 Message-ID: <1481689016940.22442@Aviatnet.com> References: <19039254-973A-461A-8749-95F74C33DAD1@juniper.net> In-Reply-To: <19039254-973A-461A-8749-95F74C33DAD1@juniper.net> Accept-Language: en-NZ, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.15.6.10] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 04:17:02 -0000 I am considering to implement the data model in this draft.=0A= =0A= I have reviewed this draft and found the following issues. In approximately= decreasing order of severity:=0A= =0A= * In the "selector-facility" choice statement the cases have misleading nam= es - the case where no facility is matched is named "facility", and the cas= e where specific facilities are matched is named "name". I suggest "no-faci= lities" and "specified-facilities", or similar.=0A= =0A= * I disagree with the premise of the "no-facilities" case, which is that it= can be used to disable a log action, according to the description:=0A= =0A= description=0A= "This case specifies no facilities will match when=0A= comparing the syslog message facility. This is a=0A= method that can be used to effectively disable a=0A= particular log-action (buffer, file, etc).";=0A= =0A= If an administrator wants to disable a log action they should do it by ei= ther removing it from the configuration, or by setting an "enabled" leaf to= false.=0A= With that in mind, there is no reason for the "no-facilities" case to exi= st.=0A= =0A= * What is the behaviour of a selector if neither "no-facilities" nor "facil= ity-list" is present?=0A= * In the "selector" grouping it is not clear how the facility and pattern c= onditions are combined to decide whether a message is selected.=0A= Must they both match the message, or is it sufficient for either one to m= atch the message?=0A= * Not all servers have a console; there should be a feature to indicate whe= ther logging to the console is supported.=0A= * Likewise, not all servers may support logging to user sessions.=0A= * Likewise, not all servers may support a user-accessible filesystem.=0A= * RFC 5424 states that the severity and protocol values are not normative. = =0A= * It's not clear to me why this needs to be split into two modules. Is it s= o that other modules can define logging parameters but still be usable on a= device without syslog?=0A= * "log-severity" defines a severity filter, not a severity, so its name is = misleading.=0A= * Perhaps the "severity" type and the facility identities should have "refe= rence" statements referring to RFC 5424, rather than referring to it in the= description.=0A= * In section "8.2", "admisintrator" is a typo.=0A= =0A= I assume that the means of accessing the memory buffer and log files are ou= t of scope of this data model.=0A= =0A= Alex=0A= =0A= ________________________________________=0A= From: netmod on behalf of Kent Watsen =0A= Sent: Wednesday, 14 December 2016 2:01 p.m.=0A= To: netmod@ietf.org=0A= Subject: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11=0A= =0A= This is a notice to start a two-week NETMOD WG last call for the document:= =0A= =0A= A YANG Data Model for Syslog Configuration=0A= https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-11=0A= =0A= Please indicate your support or concerns by Tuesday, December 27, 2016.=0A= =0A= We are particularly interested in statements of the form:=0A= * I have reviewed this draft and found no issues.=0A= * I have reviewed this draft and found the following issues: ...=0A= =0A= As well as:=0A= * I have implemented the data model in this draft.=0A= * I am implementing the data model in this draft.=0A= * I am considering to implement the data model in this draft.=0A= * I am not considering to implement the data model in this draft.=0A= =0A= Thank you,=0A= NETMOD WG Chairs=0A= =0A= =0A= =0A= _______________________________________________=0A= netmod mailing list=0A= netmod@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netmod=0A= From nobody Wed Dec 14 03:08:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E038F129D69; Wed, 14 Dec 2016 03:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 NqSSoyTw5SPQ; Wed, 14 Dec 2016 03:08:09 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8612D129D53; Wed, 14 Dec 2016 03:07:56 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 6459B1AE0457; Wed, 14 Dec 2016 12:07:55 +0100 (CET) Date: Wed, 14 Dec 2016 12:07:54 +0100 (CET) Message-Id: <20161214.120754.915451205380944115.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <004101d25589$a0cd5f20$e2681d60$@gmail.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod-chairs@ietf.org, netmod@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 11:08:16 -0000 Andy Bierman wrote: > On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue wrote: > > > Hi Andy, > > > > > > > > > This architectural change needs to be implemented in various protocols. > > > > > I am not sure a 6241bis is the best approach because it is not clear > > which > > > > > servers really need to implement the revised datastores. > > > > > > > > I agree fully. This is the reason why I wrote in my mail: > > > > > > > > >> - a new protocol- and language-independent standard document (RFC XYZ) > > defining the generic datastore concept and framework and describing its use > > (based on and following the DT solution draft), > > > > >> - a RFC6241bis draft removing the current datasore concept > > specification, and getting rid of well-known issues e.g. with the > > operation, > > > > > I do not agree with the text you wrote. > I do not want to remove candidate, running, and startup from RFC 6241. > IMO the new datastores can be defined in a new document that does not > redefine the existing datastores. > > I also do not want to get rid of , It works as intended. > It is not a problem on small devices. Andy, the problem with has nothing to do with the size of the device. The problem is that returns two things (running config + operational state) in one merged output document. This forces people to split data models so that config and state are mutually exclusive (/interfaces and /interfaces-state). This draft proposes a fix for this, which makes less useful. /martin > It is not a problem on large devices > if > sufficient filtering is used. It does not differentiate between intended > and applied config > or understand different types of config=false nodes. Use a new operation to > add these features. > > > > > > > > Mehmet > > > > > Andy > > > > > > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > > *Sent:* Dienstag, 13. Dezember 2016 18:38 > > *To:* Eric Voit (evoit) > > *Cc:* Ladislav Lhotka ; MehmetErsue ; > > NetMod WG Chairs ; NetConf WG Chairs < > > netconf-chairs@ietf.org>; NetMod WG ; Netconf < > > netconf@ietf.org> > > *Subject:* Re: [netmod] [Netconf] WG adoption poll > > draft-nmdsdt-netmod-revised-datastores-00 > > > > > > > > > > > > > > > > On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) > > wrote: > > > > I support adoption, and like Mehmet's thinking as well. > > > > Also worth focusing on is transport protocol independent yang filtering. > > So along with how to frame get operations against one of the datastores, > > how do you know which subtrees/nodes should be included/excluded. > > > > > > > > > > > > This architectural change needs to be implemented in various protocols. > > > > I am not sure a 6241bis is the best approach because it is not clear which > > > > servers really need to implement the revised datastores. Since RD is > > purely optional > > > > to implement, it should not obsolete 6241 in any way. It should be > > possible > > > > to add new operations and/or new parameters to existing operations without > > > > needing to redefine what is already there. > > > > > > > > The new protocol features need to explain how to include/exclude subtrees. > > > > IMO we should only support YANG defined data. This allows the solutions > > > > to be generalized and reusable across protocols (e.g., using YANG > > extensions). > > > > > > > > > > > > Eric > > > > > > > > > > > > Andy > > > > > > > > > > > From: Netconf, December 9, 2016 7:49 AM > > > > > > Hi Mehmet, > > > > > > I think I could just sign your text at the bottom. > > > > > > Lada > > > > > > > On 9 Dec 2016, at 13:25, MehmetErsue wrote: > > > > > > > > Hi All, > > > > > > > > I think the adoption of the DT draft is fine. We agreed in IETF 97 to > > adopt and > > > finalize the DT draft in NETMOD WG, which I still support. > > > > > > > > I believe the bigger issue is to agree on a plan concerning the > > related work > > > and the re-organization of existing standards. As a matter of fact this > > plan will > > > lead to updating the charter of two WGs and the work we are going to > > start. > > > > > > > > I see the DT document as a datastore solution proposal. There are > > different > > > gaps and issues which still need to be addressed and the solution > > proposal > > > needs yet to be discussed and finalized. The document is providing > > information > > > on the history, explaining the need for a generic solution as well as is > > discussing > > > different scenarios. As such I believe the datastore solution proposal > > from the > > > DT should be published with the intended status Informational RFC. > > > > > > > > Based on the finalized and agreed datastore solution we should do > > different > > > updates to existing documents in NETCONF and NETMOD WGs. With this > > > action we can also fix well-known issues. > > > > > > > > Concerning the NETCONF WG I would see it as valuable if we develop: > > > > - a RFC6241bis draft removing the current datasore concept > > > > specification, and getting rid of well-known issues e.g. with the > > > > operation, > > > > - a new protocol- and language-independent standard document (RFC XYZ) > > > > defining the generic datastore concept and framework and describing > > > > its use (based on and following the DT solution draft), > > > > - adding potential extensions to RFC6241bis (following the DT draft > > > > and with a normative reference to RFC XYZ), > > > > - adding potential extensions to a RESTCONF-bis RFC (following the DT > > > > draft and with a normative reference to RFC XYZ), > > > > > > > > Concerning the NETMOD WG I would see it as valuable if we develop: > > > > - RFC7950bis deleting protocol-dependent details and specifying the > > > > datastore usage with YANG on a generic level (with a normative > > > > reference to RFC XYZ), > > > > - adding potential extensions to RFC7950bis, e.g. concerning the > > > > proposed element, > > > > - possibly an RFC 6244bis to describe architectural aspects. However > > RFC6244 > > > is Informational and a RFC6244bis would be still Informational. I'm not > > sure > > > whether this is really necessary. The DT proposal does already describe > > such a > > > solution and can be seen as an update to RFC 6244. > > > > - RFC6087bis giving guidelines on how to use YANG with the new > > datastore > > > concept. > > > > > > > > Referring to Lada's proposal concerning the spin off document from > > > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be > > > provided in the corresponding protocol RFCs, i.e. > > > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and > > > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. > > > > > > > > Hope this helps as a starting point on the way to a good plan. > > > > > > > > PS: As Benoit suggested some time ago we might also consider to rename > > > NETCONF WG as it is not only on NETCONF protocol anymore. > > > > > > > > Regards, > > > > Mehmet > > > > > > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman > > > wrote: > > > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder > > > wrote: > > > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: > > > > > > > > > > > > > > > > > I disagree that the datastore model is a protocol specific aspect. > > > > > > I consider datastores an architectural component binding data > > > > > > models and protocols together. In fact, the 'traditional' > > > > > > datastore model > > > > > > > > > > I would agree with this if datastores were a general concept in > > YANG, but > > > the revised-datastores draft explicitly introduces the "intended" and > > "applied" > > > datastores that may be irrelevant to other protocols using YANG, and even > > > needn't be used in all NETCONF implementations. I wouldn't call this "an > > > architectural component" of YANG. > > > > > > > > > > > > > An architectural component of this new management framework (that does > > > > not have a name). The fact that not all protocols may expose all > > > > datastores is IMHO not a reason that the datastore model is not an > > > > architectural framework. > > > > > > > > > If you are saying that it will have nontrivial impact on YANG, I > > would like to > > > see it explained in sec. 6.3. Without this information I am quite > > reluctant to > > > agree with the adoption. > > > > > > > > An operational state datastore has implications how one writes data > > > > models. It may not directly affect YANG itself but surely the usage of > > > > YANG. > > > > > > > > > See above - architectural aspects need to be relevant to all > > protocols. > > > > > > > > Yes, but relevant to all protocols does not mean every protocol needs > > > > to expose say all datastores. But every protocol should be clear about > > > > how what it exposes relates to the architectural framework. > > > > > > > > > > > > > > > > There is a "current solution" consisting of hard-wired object > > > > semantics (e.g., ifAdminStatus and ifOperStatus). This solution does > > > > not require special protocols or datastores, but it is being replaced > > by a > > > generic solution. > > > > > > > > If the "generic" solution requires special procedures which differ on > > > > each protocol, then it might end up be worse than the hard-wired > > solution > > > that works on every protocol. > > > > So I agree with Juergen that this is primarily an architectural issue. > > > > > > > > > > > > /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 > > > > -- > > > > Cheers, > > > > Mehmet > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > > > > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > From nobody Wed Dec 14 06:09:25 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86616129692 for ; Wed, 14 Dec 2016 06:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRRr9EYoEwLh for ; Wed, 14 Dec 2016 06:09:18 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A52912969E for ; Wed, 14 Dec 2016 06:09:13 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id w33so23805683qtc.3 for ; Wed, 14 Dec 2016 06:09:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L5VlPjZ9QV78j/ZwMfb+EayVzFvhy2co8v24/eN+ZdE=; b=c6AQHQgAHKyRAGxaaXejvLOBSwFL0vLPdkv5xTkEJ4kKVxqxf4fT4ayjWuDV0iGh/K rLgbn04ef90vBGH0NlvxAP3aW60DvLycqQuRFC8cfVKXocyMxt6q+PVuj3LZWqFqid+y U2GSGvWSMT10NazEXe2kvgx2S4Flfuc5joBioflU26vcF1j/0BFEE+XMgiieLxfT+H+Y fVwDDRQD8wfleEqYPheH83/OxGMIqKDTVGK+EeI09SGFR4imCUE6F5wwJuwOecit+GN0 01oOZDMDCSaIDNS7tJJ3s/LxC0u6DHTq6tV0Qdtn5OmTroTCuPv3eS8BEGS0no1hWQZF P2oA== 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=L5VlPjZ9QV78j/ZwMfb+EayVzFvhy2co8v24/eN+ZdE=; b=NCnhvDGQMRMnq+BVxE+UPJ8K9q685f/3V/lcYA//5+Qd1zY6Hto0V6szD4Cgoh276r ftp8ZmD9sj/Lgew9wjSAfJ+IqyGQaGru1+aB99MKuJlZvqViIGpwg/nCw1pbFiPWSXC5 1U32Mb0c+WpqATB/Sl91lJIy8CWhvsjQ+5T/HKE7SBTdjU88FXSy9KjlO/Nfq1WabimV xJloEU2zmQgyJONM1ecMUmquYh2sVPxJOHoueuay0yFixn4oJYDnhxEDqIwPvpuvQEse qpuwQ7LjlOVb03OX6l0AxsB7YccdR+LPTl3FjwUFD+67rYSV/kIhPyQPaFibIMrs0bpT 7zag== X-Gm-Message-State: AKaTC00SUyXFbbOmKA8Aou9YHeKZQKeCkzEotEDviJu8ZwsZL47qg/nnHQrEFGw2r6ZPg0GWmbZKOh/Rqv9BGw== X-Received: by 10.237.48.139 with SMTP id 11mr87043764qtf.219.1481724552333; Wed, 14 Dec 2016 06:09:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Wed, 14 Dec 2016 06:09:11 -0800 (PST) In-Reply-To: <20161214.120754.915451205380944115.mbj@tail-f.com> References: <004101d25589$a0cd5f20$e2681d60$@gmail.com> <20161214.120754.915451205380944115.mbj@tail-f.com> From: Andy Bierman Date: Wed, 14 Dec 2016 06:09:11 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=94eb2c0c865a9903a305439ee1e1 Archived-At: Cc: NetMod WG Chairs , "netmod@ietf.org" , NETCONF Working Group , Netconf Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 14:09:20 -0000 --94eb2c0c865a9903a305439ee1e1 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue wrote: > > > > > Hi Andy, > > > > > > > > > > > > > This architectural change needs to be implemented in various > protocols. > > > > > > > I am not sure a 6241bis is the best approach because it is not clear > > > which > > > > > > > servers really need to implement the revised datastores. > > > > > > > > > > > > I agree fully. This is the reason why I wrote in my mail: > > > > > > > > > > > > >> - a new protocol- and language-independent standard document (RFC > XYZ) > > > defining the generic datastore concept and framework and describing > its use > > > (based on and following the DT solution draft), > > > > > > >> - a RFC6241bis draft removing the current datasore concept > > > specification, and getting rid of well-known issues e.g. with the > > > operation, > > > > > > > > I do not agree with the text you wrote. > > I do not want to remove candidate, running, and startup from RFC 6241. > > IMO the new datastores can be defined in a new document that does not > > redefine the existing datastores. > > > > I also do not want to get rid of , It works as intended. > > It is not a problem on small devices. > > Andy, the problem with has nothing to do with the size of the > device. The problem is that returns two things (running config > + operational state) in one merged output document. This forces > people to split data models so that config and state are mutually > exclusive (/interfaces and /interfaces-state). This draft proposes a > fix for this, which makes less useful. > > This "problem" exists for some new overloaded use of that did not exist before. The operation only mixes config=true and config=false. It never had anything to do with intended vs. applied. IMO your proposed solution is not very backward compatible with simple systems that do not have delays between intended and applied. > > /martin > Andy > > > > > It is not a problem on large devices > > if > > sufficient filtering is used. It does not differentiate between intended > > and applied config > > or understand different types of config=false nodes. Use a new > operation to > > add these features. > > > > > > > > > > > > > > > Mehmet > > > > > > > > > Andy > > > > > > > > > > > > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > > > *Sent:* Dienstag, 13. Dezember 2016 18:38 > > > *To:* Eric Voit (evoit) > > > *Cc:* Ladislav Lhotka ; MehmetErsue ; > > > NetMod WG Chairs ; NetConf WG Chairs < > > > netconf-chairs@ietf.org>; NetMod WG ; Netconf < > > > netconf@ietf.org> > > > *Subject:* Re: [netmod] [Netconf] WG adoption poll > > > draft-nmdsdt-netmod-revised-datastores-00 > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) > > > wrote: > > > > > > I support adoption, and like Mehmet's thinking as well. > > > > > > Also worth focusing on is transport protocol independent yang > filtering. > > > So along with how to frame get operations against one of the > datastores, > > > how do you know which subtrees/nodes should be included/excluded. > > > > > > > > > > > > > > > > > > This architectural change needs to be implemented in various protocols. > > > > > > I am not sure a 6241bis is the best approach because it is not clear > which > > > > > > servers really need to implement the revised datastores. Since RD is > > > purely optional > > > > > > to implement, it should not obsolete 6241 in any way. It should be > > > possible > > > > > > to add new operations and/or new parameters to existing operations > without > > > > > > needing to redefine what is already there. > > > > > > > > > > > > The new protocol features need to explain how to include/exclude > subtrees. > > > > > > IMO we should only support YANG defined data. This allows the > solutions > > > > > > to be generalized and reusable across protocols (e.g., using YANG > > > extensions). > > > > > > > > > > > > > > > > > > Eric > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > From: Netconf, December 9, 2016 7:49 AM > > > > > > > > Hi Mehmet, > > > > > > > > I think I could just sign your text at the bottom. > > > > > > > > Lada > > > > > > > > > On 9 Dec 2016, at 13:25, MehmetErsue wrote: > > > > > > > > > > Hi All, > > > > > > > > > > I think the adoption of the DT draft is fine. We agreed in IETF 97 > to > > > adopt and > > > > finalize the DT draft in NETMOD WG, which I still support. > > > > > > > > > > I believe the bigger issue is to agree on a plan concerning the > > > related work > > > > and the re-organization of existing standards. As a matter of fact > this > > > plan will > > > > lead to updating the charter of two WGs and the work we are going to > > > start. > > > > > > > > > > I see the DT document as a datastore solution proposal. There are > > > different > > > > gaps and issues which still need to be addressed and the solution > > > proposal > > > > needs yet to be discussed and finalized. The document is providing > > > information > > > > on the history, explaining the need for a generic solution as well > as is > > > discussing > > > > different scenarios. As such I believe the datastore solution > proposal > > > from the > > > > DT should be published with the intended status Informational RFC. > > > > > > > > > > Based on the finalized and agreed datastore solution we should do > > > different > > > > updates to existing documents in NETCONF and NETMOD WGs. With this > > > > action we can also fix well-known issues. > > > > > > > > > > Concerning the NETCONF WG I would see it as valuable if we develop: > > > > > - a RFC6241bis draft removing the current datasore concept > > > > > specification, and getting rid of well-known issues e.g. with the > > > > > operation, > > > > > - a new protocol- and language-independent standard document (RFC > XYZ) > > > > > defining the generic datastore concept and framework and describing > > > > > its use (based on and following the DT solution draft), > > > > > - adding potential extensions to RFC6241bis (following the DT draft > > > > > and with a normative reference to RFC XYZ), > > > > > - adding potential extensions to a RESTCONF-bis RFC (following the > DT > > > > > draft and with a normative reference to RFC XYZ), > > > > > > > > > > Concerning the NETMOD WG I would see it as valuable if we develop: > > > > > - RFC7950bis deleting protocol-dependent details and specifying the > > > > > datastore usage with YANG on a generic level (with a normative > > > > > reference to RFC XYZ), > > > > > - adding potential extensions to RFC7950bis, e.g. concerning the > > > > > proposed element, > > > > > - possibly an RFC 6244bis to describe architectural aspects. > However > > > RFC6244 > > > > is Informational and a RFC6244bis would be still Informational. I'm > not > > > sure > > > > whether this is really necessary. The DT proposal does already > describe > > > such a > > > > solution and can be seen as an update to RFC 6244. > > > > > - RFC6087bis giving guidelines on how to use YANG with the new > > > datastore > > > > concept. > > > > > > > > > > Referring to Lada's proposal concerning the spin off document from > > > > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be > > > > provided in the corresponding protocol RFCs, i.e. > > > > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis > and > > > > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. > > > > > > > > > > Hope this helps as a starting point on the way to a good plan. > > > > > > > > > > PS: As Benoit suggested some time ago we might also consider to > rename > > > > NETCONF WG as it is not only on NETCONF protocol anymore. > > > > > > > > > > Regards, > > > > > Mehmet > > > > > > > > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman > > > > wrote: > > > > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder > > > > wrote: > > > > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: > > > > > > > > > > > > > > > > > > > > I disagree that the datastore model is a protocol specific > aspect. > > > > > > > I consider datastores an architectural component binding data > > > > > > > models and protocols together. In fact, the 'traditional' > > > > > > > datastore model > > > > > > > > > > > > I would agree with this if datastores were a general concept in > > > YANG, but > > > > the revised-datastores draft explicitly introduces the "intended" and > > > "applied" > > > > datastores that may be irrelevant to other protocols using YANG, and > even > > > > needn't be used in all NETCONF implementations. I wouldn't call this > "an > > > > architectural component" of YANG. > > > > > > > > > > > > > > > > An architectural component of this new management framework (that > does > > > > > not have a name). The fact that not all protocols may expose all > > > > > datastores is IMHO not a reason that the datastore model is not an > > > > > architectural framework. > > > > > > > > > > > If you are saying that it will have nontrivial impact on YANG, I > > > would like to > > > > see it explained in sec. 6.3. Without this information I am quite > > > reluctant to > > > > agree with the adoption. > > > > > > > > > > An operational state datastore has implications how one writes data > > > > > models. It may not directly affect YANG itself but surely the > usage of > > > > > YANG. > > > > > > > > > > > See above - architectural aspects need to be relevant to all > > > protocols. > > > > > > > > > > Yes, but relevant to all protocols does not mean every protocol > needs > > > > > to expose say all datastores. But every protocol should be clear > about > > > > > how what it exposes relates to the architectural framework. > > > > > > > > > > > > > > > > > > > > There is a "current solution" consisting of hard-wired object > > > > > semantics (e.g., ifAdminStatus and ifOperStatus). This solution > does > > > > > not require special protocols or datastores, but it is being > replaced > > > by a > > > > generic solution. > > > > > > > > > > If the "generic" solution requires special procedures which differ > on > > > > > each protocol, then it might end up be worse than the hard-wired > > > solution > > > > that works on every protocol. > > > > > So I agree with Juergen that this is primarily an architectural > issue. > > > > > > > > > > > > > > > /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 > > > > > -- > > > > > Cheers, > > > > > Mehmet > > > > > > > > -- > > > > Ladislav Lhotka, CZ.NIC Labs > > > > PGP Key ID: E74E8C0C > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Netconf mailing list > > > > Netconf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > --94eb2c0c865a9903a305439ee1e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue <mersue@gmail.com> wrote:
>
> > Hi Andy,
> >
> >
> >
> > > This architectural change needs to be implemented in various= protocols.
> >
> > > I am not sure a 6241bis is the best approach because it is n= ot clear
> > which
> >
> > > servers really need to implement the revised datastores.
> >
> >
> >
> > I agree fully. This is the reason why I wrote in my mail:
> >
> >
> >
> > >> - a new protocol- and language-independent standard docu= ment (RFC XYZ)
> > defining the generic datastore concept and framework and describi= ng its use
> > (based on and following the DT solution draft),
> >
> > >> - a RFC6241bis draft removing the current datasore conce= pt
> > specification, and getting rid of well-known issues e.g. with the= <get>
> > operation,
> >
> >
> I do not agree with the text you wrote.
> I do not want to remove candidate, running, and startup from RFC 6241.=
> IMO the new datastores can be defined in a new document that does not<= br> > redefine the existing datastores.
>
> I also do not want to get rid of <get>,=C2=A0 It works as intend= ed.
> It is not a problem on small devices.

Andy, the problem with <get> has nothing to do with the size of the device.=C2=A0 The problem is that <get> returns two things (running c= onfig
+ operational state) in one merged output document.=C2=A0 This forces
people to split data models so that config and state are mutually
exclusive (/interfaces and /interfaces-state).=C2=A0 This draft proposes a<= br> fix for this, which makes <get> less useful.


This "problem" exists for so= me new overloaded use of <get> that did not exist before.
T= he <get> operation only mixes config=3Dtrue and config=3Dfalse. It ne= ver had anything
to do with intended vs. applied.=C2=A0 IMO your = proposed solution is not very backward compatible
with simple sys= tems that do not have delays between intended and applied.

=C2=A0

/martin


Andy
= =C2=A0



> It is not a problem on large devices
> if
> sufficient filtering is used.=C2=A0 It does not differentiate between = intended
> and applied config
> or understand different types of config=3Dfalse nodes.=C2=A0 Use a new= operation to
> add these features.
>
>
>
>
>
>
> > Mehmet
> >
>
>
> Andy
>
>
>
> >
> >
> > *From:* Andy Bierman [mailto:andy@yumaworks.com]
> > *Sent:* Dienstag, 13. Dezember 2016 18:38
> > *To:* Eric Voit (evoit) <ev= oit@cisco.com>
> > *Cc:* Ladislav Lhotka <lhotka= @nic.cz>; MehmetErsue <mersue= @gmail.com>;
> > NetMod WG Chairs <ne= tmod-chairs@ietf.org>; NetConf WG Chairs <
> > netconf-chairs@ietf.or= g>; NetMod WG <netmod@ietf.org= >; Netconf <
> > netconf@ietf.org>
> > *Subject:* Re: [netmod] [Netconf] WG adoption poll
> > draft-nmdsdt-netmod-revised-datastores-00
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) <evoit@cisco.com>
> > wrote:
> >
> > I support adoption, and like Mehmet's thinking as well.
> >
> > Also worth focusing on is transport protocol independent yang fil= tering.
> > So along with how to frame get operations against one of the data= stores,
> > how do you know which subtrees/nodes should be included/excluded.=
> >
> >
> >
> >
> >
> > This architectural change needs to be implemented in various prot= ocols.
> >
> > I am not sure a 6241bis is the best approach because it is not cl= ear which
> >
> > servers really need to implement the revised datastores.=C2=A0 Si= nce RD is
> > purely optional
> >
> > to implement, it should not obsolete 6241 in any way.=C2=A0 It sh= ould be
> > possible
> >
> > to add new operations and/or new parameters to existing operation= s without
> >
> > needing to redefine what is already there.
> >
> >
> >
> > The new protocol features need to explain how to include/exclude = subtrees.
> >
> > IMO we should only support YANG defined data.=C2=A0 This allows t= he solutions
> >
> > to be generalized and reusable across protocols (e.g., using YANG=
> > extensions).
> >
> >
> >
> >
> >
> > Eric
> >
> >
> >
> >
> >
> > Andy
> >
> >
> >
> >
> > > From: Netconf, December 9, 2016 7:49 AM
> > >
> > > Hi Mehmet,
> > >
> > > I think I could just sign your text at the bottom.
> > >
> > > Lada
> > >
> > > > On 9 Dec 2016, at 13:25, MehmetErsue <mersue@gmail.com> wrote:
> > > >
> > > > Hi All,
> > > >
> > > > I think the adoption of the DT draft is fine. We agreed= in IETF 97 to
> > adopt and
> > > finalize the DT draft in NETMOD WG, which I still support. > > > >
> > > > I believe the bigger issue is to agree on a plan concer= ning the
> > related work
> > > and the re-organization of existing standards. As a matter o= f fact this
> > plan will
> > > lead to updating the charter of two WGs and the work we are = going to
> > start.
> > > >
> > > > I see the DT document as a datastore solution proposal.= There are
> > different
> > > gaps and issues which still need to be addressed and the sol= ution
> > proposal
> > > needs yet to be discussed and finalized. The document is pro= viding
> > information
> > > on the history, explaining the need for a generic solution a= s well as is
> > discussing
> > > different scenarios. As such I believe the datastore solutio= n proposal
> > from the
> > > DT should be published with the intended status Informationa= l RFC.
> > > >
> > > > Based on the finalized and agreed datastore solution we= should do
> > different
> > > updates to existing documents in NETCONF and NETMOD WGs. Wit= h this
> > > action we can also fix well-known issues.
> > > >
> > > > Concerning the NETCONF WG I would see it as valuable if= we develop:
> > > > - a RFC6241bis draft removing the current datasore conc= ept
> > > > specification, and getting rid of well-known issues e.g= . with the
> > > > <get> operation,
> > > > - a new protocol- and language-independent standard doc= ument (RFC XYZ)
> > > > defining the generic datastore concept and framework an= d describing
> > > > its use (based on and following the DT solution draft),=
> > > > - adding potential extensions to RFC6241bis (following = the DT draft
> > > > and with a normative reference to RFC XYZ),
> > > > - adding potential extensions to a RESTCONF-bis RFC (fo= llowing the DT
> > > > draft and with a normative reference to RFC XYZ),
> > > >
> > > > Concerning the NETMOD WG I would see it as valuable if = we develop:
> > > > - RFC7950bis deleting protocol-dependent details and sp= ecifying the
> > > > datastore usage with YANG on a generic level (with a no= rmative
> > > > reference to RFC XYZ),
> > > > - adding potential extensions to RFC7950bis, e.g. conce= rning the
> > > > proposed <notification> element,
> > > > - possibly an RFC 6244bis to describe architectural asp= ects. However
> > RFC6244
> > > is Informational and a RFC6244bis would be still Information= al. I'm not
> > sure
> > > whether this is really necessary. The DT proposal does alrea= dy describe
> > such a
> > > solution and can be seen as an update to RFC 6244.
> > > > - RFC6087bis giving guidelines on how to use YANG with = the new
> > datastore
> > > concept.
> > > >
> > > > Referring to Lada's proposal concerning the spin of= f document from
> > > > RFC7950 ("Adapting NETCONF for use with YANG"= ), I think this can be
> > > provided in the corresponding protocol RFCs, i.e.
> > > > for NETCONF a section on "Using NETCONF with YANG&= quot; in RFC6241bis and
> > > for RESTCONF "Using RESTCONF with YANG" in RESTCON= F-bis RFC.
> > > >
> > > > Hope this helps as a starting point on the way to a goo= d plan.
> > > >
> > > > PS: As Benoit suggested some time ago we might also con= sider to rename
> > > NETCONF WG as it is not only on NETCONF protocol anymore. > > > >
> > > > Regards,
> > > > Mehmet
> > > >
> > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman <andy@yumaworks.com>
> > > wrote:
> > > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder > > > <= j.schoenwaelder@jacobs-university.de> wrote:
> > > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhot= ka wrote:
> > > > >
> > > > > >
> > > > > > I disagree that the datastore model is a prot= ocol specific aspect.
> > > > > > I consider datastores an architectural compon= ent binding data
> > > > > > models and protocols together. In fact, the &= #39;traditional'
> > > > > > datastore model
> > > > >
> > > > > I would agree with this if datastores were a gener= al concept in
> > YANG, but
> > > the revised-datastores draft explicitly introduces the "= ;intended" and
> > "applied"
> > > datastores that may be irrelevant to other protocols using Y= ANG, and even
> > > needn't be used in all NETCONF implementations. I wouldn= 't call this "an
> > > architectural component" of YANG.
> > > > >
> > > >
> > > > An architectural component of this new management frame= work (that does
> > > > not have a name). The fact that not all protocols may e= xpose all
> > > > datastores is IMHO not a reason that the datastore mode= l is not an
> > > > architectural framework.
> > > >
> > > > > If you are saying that it will have nontrivial imp= act on YANG, I
> > would like to
> > > see it explained in sec. 6.3. Without this information I am = quite
> > reluctant to
> > > agree with the adoption.
> > > >
> > > > An operational state datastore has implications how one= writes data
> > > > models. It may not directly affect YANG itself but sure= ly the usage of
> > > > YANG.
> > > >
> > > > > See above - architectural aspects need to be relev= ant to all
> > protocols.
> > > >
> > > > Yes, but relevant to all protocols does not mean every = protocol needs
> > > > to expose say all datastores. But every protocol should= be clear about
> > > > how what it exposes relates to the architectural framew= ork.
> > > >
> > > >
> > > >
> > > > There is a "current solution" consisting of h= ard-wired object
> > > > semantics (e.g., ifAdminStatus and ifOperStatus).=C2=A0= This solution does
> > > > not require special protocols or datastores, but it is = being replaced
> > by a
> > > generic solution.
> > > >
> > > > If the "generic" solution requires special pr= ocedures which differ on
> > > > each protocol, then it might end up be worse than the h= ard-wired
> > solution
> > > that works on every protocol.
> > > > So I agree with Juergen that this is primarily an archi= tectural issue.
> > > >
> > > >
> > > > /js
> > > >
> > > > Andy
> > > >
> > > >
> > > >
> > > > --
> > > > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Jacobs University Bremen gGmbH
> > > > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Campus Ring 1 | 28759 Bremen | Germany
> > > > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0<http://www.jacobs-university.de/>
> > > >
> > > > _______________________________________________ > > > > netmod mailing list
> > > > netmod@ietf.org<= br> > > > > https://www.ietf.org/mailman/li= stinfo/netmod
> > > > --
> > > > Cheers,
> > > > Mehmet
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Netconf mailing list
> > > Netconf@ietf.org
> > > https://www.ietf.org/mailman/listin= fo/netconf
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/net= mod
> >
> >
> >

--94eb2c0c865a9903a305439ee1e1-- From nobody Wed Dec 14 06:25:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB758129A65; Wed, 14 Dec 2016 06:25:34 -0800 (PST) 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 JRMZMaw9SbB5; Wed, 14 Dec 2016 06:25:32 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B02641296DE; Wed, 14 Dec 2016 06:25:30 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 2FFC51CC02AA; Wed, 14 Dec 2016 15:25:30 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman , Mehmet Ersue In-Reply-To: References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> Date: Wed, 14 Dec 2016 15:25:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 14:25:35 -0000 Andy Bierman writes: > On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue wrote: > >> Hi Andy, >> >> >> >> > This architectural change needs to be implemented in various protocols. >> >> > I am not sure a 6241bis is the best approach because it is not clear >> which >> >> > servers really need to implement the revised datastores. >> >> >> >> I agree fully. This is the reason why I wrote in my mail: >> >> >> >> >> - a new protocol- and language-independent standard document (RFC XYZ) >> defining the generic datastore concept and framework and describing its use >> (based on and following the DT solution draft), >> >> >> - a RFC6241bis draft removing the current datasore concept >> specification, and getting rid of well-known issues e.g. with the >> operation, >> >> > I do not agree with the text you wrote. > I do not want to remove candidate, running, and startup from RFC 6241. > IMO the new datastores can be defined in a new document that does not > redefine the existing datastores. As for candidate, it is optional and we all know that it is quite problematic if concurrent access of multiple clients is possible. Therefore, it would IMO be a good riddance. Lada > > I also do not want to get rid of , It works as intended. > It is not a problem on small devices. It is not a problem on large devices > if > sufficient filtering is used. It does not differentiate between intended > and applied config > or understand different types of config=false nodes. Use a new operation to > add these features. > > > > > > >> Mehmet >> > > > Andy > > > >> >> >> *From:* Andy Bierman [mailto:andy@yumaworks.com] >> *Sent:* Dienstag, 13. Dezember 2016 18:38 >> *To:* Eric Voit (evoit) >> *Cc:* Ladislav Lhotka ; MehmetErsue ; >> NetMod WG Chairs ; NetConf WG Chairs < >> netconf-chairs@ietf.org>; NetMod WG ; Netconf < >> netconf@ietf.org> >> *Subject:* Re: [netmod] [Netconf] WG adoption poll >> draft-nmdsdt-netmod-revised-datastores-00 >> >> >> >> >> >> >> >> On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) >> wrote: >> >> I support adoption, and like Mehmet's thinking as well. >> >> Also worth focusing on is transport protocol independent yang filtering. >> So along with how to frame get operations against one of the datastores, >> how do you know which subtrees/nodes should be included/excluded. >> >> >> >> >> >> This architectural change needs to be implemented in various protocols. >> >> I am not sure a 6241bis is the best approach because it is not clear which >> >> servers really need to implement the revised datastores. Since RD is >> purely optional >> >> to implement, it should not obsolete 6241 in any way. It should be >> possible >> >> to add new operations and/or new parameters to existing operations without >> >> needing to redefine what is already there. >> >> >> >> The new protocol features need to explain how to include/exclude subtrees. >> >> IMO we should only support YANG defined data. This allows the solutions >> >> to be generalized and reusable across protocols (e.g., using YANG >> extensions). >> >> >> >> >> >> Eric >> >> >> >> >> >> Andy >> >> >> >> >> > From: Netconf, December 9, 2016 7:49 AM >> > >> > Hi Mehmet, >> > >> > I think I could just sign your text at the bottom. >> > >> > Lada >> > >> > > On 9 Dec 2016, at 13:25, MehmetErsue wrote: >> > > >> > > Hi All, >> > > >> > > I think the adoption of the DT draft is fine. We agreed in IETF 97 to >> adopt and >> > finalize the DT draft in NETMOD WG, which I still support. >> > > >> > > I believe the bigger issue is to agree on a plan concerning the >> related work >> > and the re-organization of existing standards. As a matter of fact this >> plan will >> > lead to updating the charter of two WGs and the work we are going to >> start. >> > > >> > > I see the DT document as a datastore solution proposal. There are >> different >> > gaps and issues which still need to be addressed and the solution >> proposal >> > needs yet to be discussed and finalized. The document is providing >> information >> > on the history, explaining the need for a generic solution as well as is >> discussing >> > different scenarios. As such I believe the datastore solution proposal >> from the >> > DT should be published with the intended status Informational RFC. >> > > >> > > Based on the finalized and agreed datastore solution we should do >> different >> > updates to existing documents in NETCONF and NETMOD WGs. With this >> > action we can also fix well-known issues. >> > > >> > > Concerning the NETCONF WG I would see it as valuable if we develop: >> > > - a RFC6241bis draft removing the current datasore concept >> > > specification, and getting rid of well-known issues e.g. with the >> > > operation, >> > > - a new protocol- and language-independent standard document (RFC XYZ) >> > > defining the generic datastore concept and framework and describing >> > > its use (based on and following the DT solution draft), >> > > - adding potential extensions to RFC6241bis (following the DT draft >> > > and with a normative reference to RFC XYZ), >> > > - adding potential extensions to a RESTCONF-bis RFC (following the DT >> > > draft and with a normative reference to RFC XYZ), >> > > >> > > Concerning the NETMOD WG I would see it as valuable if we develop: >> > > - RFC7950bis deleting protocol-dependent details and specifying the >> > > datastore usage with YANG on a generic level (with a normative >> > > reference to RFC XYZ), >> > > - adding potential extensions to RFC7950bis, e.g. concerning the >> > > proposed element, >> > > - possibly an RFC 6244bis to describe architectural aspects. However >> RFC6244 >> > is Informational and a RFC6244bis would be still Informational. I'm not >> sure >> > whether this is really necessary. The DT proposal does already describe >> such a >> > solution and can be seen as an update to RFC 6244. >> > > - RFC6087bis giving guidelines on how to use YANG with the new >> datastore >> > concept. >> > > >> > > Referring to Lada's proposal concerning the spin off document from >> > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be >> > provided in the corresponding protocol RFCs, i.e. >> > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and >> > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. >> > > >> > > Hope this helps as a starting point on the way to a good plan. >> > > >> > > PS: As Benoit suggested some time ago we might also consider to rename >> > NETCONF WG as it is not only on NETCONF protocol anymore. >> > > >> > > Regards, >> > > Mehmet >> > > >> > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman >> > wrote: >> > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder >> > wrote: >> > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: >> > > > >> > > > > >> > > > > I disagree that the datastore model is a protocol specific aspect. >> > > > > I consider datastores an architectural component binding data >> > > > > models and protocols together. In fact, the 'traditional' >> > > > > datastore model >> > > > >> > > > I would agree with this if datastores were a general concept in >> YANG, but >> > the revised-datastores draft explicitly introduces the "intended" and >> "applied" >> > datastores that may be irrelevant to other protocols using YANG, and even >> > needn't be used in all NETCONF implementations. I wouldn't call this "an >> > architectural component" of YANG. >> > > > >> > > >> > > An architectural component of this new management framework (that does >> > > not have a name). The fact that not all protocols may expose all >> > > datastores is IMHO not a reason that the datastore model is not an >> > > architectural framework. >> > > >> > > > If you are saying that it will have nontrivial impact on YANG, I >> would like to >> > see it explained in sec. 6.3. Without this information I am quite >> reluctant to >> > agree with the adoption. >> > > >> > > An operational state datastore has implications how one writes data >> > > models. It may not directly affect YANG itself but surely the usage of >> > > YANG. >> > > >> > > > See above - architectural aspects need to be relevant to all >> protocols. >> > > >> > > Yes, but relevant to all protocols does not mean every protocol needs >> > > to expose say all datastores. But every protocol should be clear about >> > > how what it exposes relates to the architectural framework. >> > > >> > > >> > > >> > > There is a "current solution" consisting of hard-wired object >> > > semantics (e.g., ifAdminStatus and ifOperStatus). This solution does >> > > not require special protocols or datastores, but it is being replaced >> by a >> > generic solution. >> > > >> > > If the "generic" solution requires special procedures which differ on >> > > each protocol, then it might end up be worse than the hard-wired >> solution >> > that works on every protocol. >> > > So I agree with Juergen that this is primarily an architectural issue. >> > > >> > > >> > > /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 >> > > -- >> > > Cheers, >> > > Mehmet >> > >> > -- >> > Ladislav Lhotka, CZ.NIC Labs >> > PGP Key ID: E74E8C0C >> > >> > >> > >> > >> > _______________________________________________ >> > Netconf mailing list >> > Netconf@ietf.org >> > https://www.ietf.org/mailman/listinfo/netconf >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Dec 14 06:42:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398011295C8; Wed, 14 Dec 2016 06:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogPmve6bAAa7; Wed, 14 Dec 2016 06:42:18 -0800 (PST) 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 BF0B6128B37; Wed, 14 Dec 2016 06:42:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43713; q=dns/txt; s=iport; t=1481726535; x=1482936135; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=zsy9nV5xv0zeVjgctAiqGuqGS5mpveme+wyY/K1pOCI=; b=LFwO1c1eJPNx8tpwLaPnGijW6ig0WMU0Z4pIz1LPl2IgHyIkTktTmsw5 mg6E4KuacGo+rrkofySUrztxbpb7lEoWZdPQdgCitEW7DKjTzfX1q5rxj 3U60dZgiPlMkbi0dlBPEB1lttOUm1b3qyBCU8xBVAHguvuzIL0e+sG9Od E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CHAwAnWVFY/xbLJq1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM3AQEBAQF5LgRUjU5ylimHdo0RggYDHwEKhB6BEEoCgjEUAQI?= =?us-ascii?q?BAQEBAQEBYiiEaAEBAQMBAQEYVAsFCQILEAEEAQEBIAEGBxsGBh8JCAYBDAYCA?= =?us-ascii?q?QEXiDYDDwgOrBkvhwcNg0kBAQEBAQEBAQEBAQEBAQEBAQEBAQEdBYY5gX2CXoJ?= =?us-ascii?q?IgVNOJoUaBY8BizU1jUCDbYF0iCiGL4dsgXFSg2WEDx83gQETDimDFTscGIFFP?= =?us-ascii?q?jSFdYI8AQEB?= X-IronPort-AV: E=Sophos;i="5.33,347,1477958400"; d="scan'208,217";a="690441376" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2016 14:42:09 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uBEEg8XY009786; Wed, 14 Dec 2016 14:42:09 GMT To: Andy Bierman , Martin Bjorklund References: <004101d25589$a0cd5f20$e2681d60$@gmail.com> <20161214.120754.915451205380944115.mbj@tail-f.com> From: Robert Wilton Message-ID: <372fdb96-295c-1a3e-de12-6693d3560de7@cisco.com> Date: Wed, 14 Dec 2016 14:42:09 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------587EAFBEBDEDB7D855C9762D" Archived-At: Cc: NetMod WG Chairs , NETCONF Working Group , "netmod@ietf.org" , Netconf Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 14:42:22 -0000 This is a multi-part message in MIME format. --------------587EAFBEBDEDB7D855C9762D Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 14/12/2016 14:09, Andy Bierman wrote: > > > On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund > wrote: > > Andy Bierman > wrote: > > On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue > wrote: > > > > > Hi Andy, > > > > > > > > > > > > > This architectural change needs to be implemented in various > protocols. > > > > > > > I am not sure a 6241bis is the best approach because it is > not clear > > > which > > > > > > > servers really need to implement the revised datastores. > > > > > > > > > > > > I agree fully. This is the reason why I wrote in my mail: > > > > > > > > > > > > >> - a new protocol- and language-independent standard > document (RFC XYZ) > > > defining the generic datastore concept and framework and > describing its use > > > (based on and following the DT solution draft), > > > > > > >> - a RFC6241bis draft removing the current datasore concept > > > specification, and getting rid of well-known issues e.g. with > the > > > operation, > > > > > > > > I do not agree with the text you wrote. > > I do not want to remove candidate, running, and startup from RFC > 6241. > > IMO the new datastores can be defined in a new document that > does not > > redefine the existing datastores. > > > > I also do not want to get rid of , It works as intended. > > It is not a problem on small devices. > > Andy, the problem with has nothing to do with the size of the > device. The problem is that returns two things (running config > + operational state) in one merged output document. This forces > people to split data models so that config and state are mutually > exclusive (/interfaces and /interfaces-state). This draft proposes a > fix for this, which makes less useful. > > > This "problem" exists for some new overloaded use of that did > not exist before. > The operation only mixes config=true and config=false. It never > had anything > to do with intended vs. applied. IMO your proposed solution is not > very backward compatible > with simple systems that do not have delays between intended and applied. I've been informed (repeatedly ;-) that has always only ever meant intended configuration. I.e. that it is reasonable behaviour for a system to accept config into and then fail to apply that configuration for some reason (daemon is unavailable, linecards is down, resources have been exceeded, programming error, etc). If this interpretation is correct then the NETCONF operation is poorly defined because it is mixing "intended configuration of the system" along with "actual running state". What NETCONF should really be providing is "actual configuration in use by the system" along with "actual running state". Of course this is effectively what the new operational state datastore is defined as containing. If I understand it correctly, I think that Andy's point is that for lots of systems "intended configuration of the system" and "actual configuration of the system" are effectively one and the same thing. If this is the case then it should be easy for clients/servers to migrate from an existing request to a request that just returns the data from the operational state datastore. It sounds like the actual data returned in both cases should be the same? Thanks, Rob > > > > /martin > > > > Andy > > > > > > It is not a problem on large devices > > if > > sufficient filtering is used. It does not differentiate between > intended > > and applied config > > or understand different types of config=false nodes. Use a new > operation to > > add these features. > > > > > > > > > > > > > > > Mehmet > > > > > > > > > Andy > > > > > > > > > > > > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com > ] > > > *Sent:* Dienstag, 13. Dezember 2016 18:38 > > > *To:* Eric Voit (evoit) > > > > *Cc:* Ladislav Lhotka >; > MehmetErsue >; > > > NetMod WG Chairs >; NetConf WG Chairs < > > > netconf-chairs@ietf.org >; > NetMod WG >; Netconf < > > > netconf@ietf.org > > > > *Subject:* Re: [netmod] [Netconf] WG adoption poll > > > draft-nmdsdt-netmod-revised-datastores-00 > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) > > > > > wrote: > > > > > > I support adoption, and like Mehmet's thinking as well. > > > > > > Also worth focusing on is transport protocol independent yang > filtering. > > > So along with how to frame get operations against one of the > datastores, > > > how do you know which subtrees/nodes should be included/excluded. > > > > > > > > > > > > > > > > > > This architectural change needs to be implemented in various > protocols. > > > > > > I am not sure a 6241bis is the best approach because it is not > clear which > > > > > > servers really need to implement the revised datastores. > Since RD is > > > purely optional > > > > > > to implement, it should not obsolete 6241 in any way. It > should be > > > possible > > > > > > to add new operations and/or new parameters to existing > operations without > > > > > > needing to redefine what is already there. > > > > > > > > > > > > The new protocol features need to explain how to > include/exclude subtrees. > > > > > > IMO we should only support YANG defined data. This allows the > solutions > > > > > > to be generalized and reusable across protocols (e.g., using YANG > > > extensions). > > > > > > > > > > > > > > > > > > Eric > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > From: Netconf, December 9, 2016 7:49 AM > > > > > > > > Hi Mehmet, > > > > > > > > I think I could just sign your text at the bottom. > > > > > > > > Lada > > > > > > > > > On 9 Dec 2016, at 13:25, MehmetErsue > wrote: > > > > > > > > > > Hi All, > > > > > > > > > > I think the adoption of the DT draft is fine. We agreed in > IETF 97 to > > > adopt and > > > > finalize the DT draft in NETMOD WG, which I still support. > > > > > > > > > > I believe the bigger issue is to agree on a plan > concerning the > > > related work > > > > and the re-organization of existing standards. As a matter > of fact this > > > plan will > > > > lead to updating the charter of two WGs and the work we are > going to > > > start. > > > > > > > > > > I see the DT document as a datastore solution proposal. > There are > > > different > > > > gaps and issues which still need to be addressed and the > solution > > > proposal > > > > needs yet to be discussed and finalized. The document is > providing > > > information > > > > on the history, explaining the need for a generic solution > as well as is > > > discussing > > > > different scenarios. As such I believe the datastore > solution proposal > > > from the > > > > DT should be published with the intended status > Informational RFC. > > > > > > > > > > Based on the finalized and agreed datastore solution we > should do > > > different > > > > updates to existing documents in NETCONF and NETMOD WGs. > With this > > > > action we can also fix well-known issues. > > > > > > > > > > Concerning the NETCONF WG I would see it as valuable if we > develop: > > > > > - a RFC6241bis draft removing the current datasore concept > > > > > specification, and getting rid of well-known issues e.g. > with the > > > > > operation, > > > > > - a new protocol- and language-independent standard > document (RFC XYZ) > > > > > defining the generic datastore concept and framework and > describing > > > > > its use (based on and following the DT solution draft), > > > > > - adding potential extensions to RFC6241bis (following the > DT draft > > > > > and with a normative reference to RFC XYZ), > > > > > - adding potential extensions to a RESTCONF-bis RFC > (following the DT > > > > > draft and with a normative reference to RFC XYZ), > > > > > > > > > > Concerning the NETMOD WG I would see it as valuable if we > develop: > > > > > - RFC7950bis deleting protocol-dependent details and > specifying the > > > > > datastore usage with YANG on a generic level (with a normative > > > > > reference to RFC XYZ), > > > > > - adding potential extensions to RFC7950bis, e.g. > concerning the > > > > > proposed element, > > > > > - possibly an RFC 6244bis to describe architectural > aspects. However > > > RFC6244 > > > > is Informational and a RFC6244bis would be still > Informational. I'm not > > > sure > > > > whether this is really necessary. The DT proposal does > already describe > > > such a > > > > solution and can be seen as an update to RFC 6244. > > > > > - RFC6087bis giving guidelines on how to use YANG with the new > > > datastore > > > > concept. > > > > > > > > > > Referring to Lada's proposal concerning the spin off > document from > > > > > RFC7950 ("Adapting NETCONF for use with YANG"), I think > this can be > > > > provided in the corresponding protocol RFCs, i.e. > > > > > for NETCONF a section on "Using NETCONF with YANG" in > RFC6241bis and > > > > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. > > > > > > > > > > Hope this helps as a starting point on the way to a good plan. > > > > > > > > > > PS: As Benoit suggested some time ago we might also > consider to rename > > > > NETCONF WG as it is not only on NETCONF protocol anymore. > > > > > > > > > > Regards, > > > > > Mehmet > > > > > > > > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman > > > > > > wrote: > > > > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder > > > > > wrote: > > > > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka > wrote: > > > > > > > > > > > > > > > > > > > > I disagree that the datastore model is a protocol > specific aspect. > > > > > > > I consider datastores an architectural component > binding data > > > > > > > models and protocols together. In fact, the 'traditional' > > > > > > > datastore model > > > > > > > > > > > > I would agree with this if datastores were a general > concept in > > > YANG, but > > > > the revised-datastores draft explicitly introduces the > "intended" and > > > "applied" > > > > datastores that may be irrelevant to other protocols using > YANG, and even > > > > needn't be used in all NETCONF implementations. I wouldn't > call this "an > > > > architectural component" of YANG. > > > > > > > > > > > > > > > > An architectural component of this new management > framework (that does > > > > > not have a name). The fact that not all protocols may > expose all > > > > > datastores is IMHO not a reason that the datastore model > is not an > > > > > architectural framework. > > > > > > > > > > > If you are saying that it will have nontrivial impact on > YANG, I > > > would like to > > > > see it explained in sec. 6.3. Without this information I am > quite > > > reluctant to > > > > agree with the adoption. > > > > > > > > > > An operational state datastore has implications how one > writes data > > > > > models. It may not directly affect YANG itself but surely > the usage of > > > > > YANG. > > > > > > > > > > > See above - architectural aspects need to be relevant to all > > > protocols. > > > > > > > > > > Yes, but relevant to all protocols does not mean every > protocol needs > > > > > to expose say all datastores. But every protocol should be > clear about > > > > > how what it exposes relates to the architectural framework. > > > > > > > > > > > > > > > > > > > > There is a "current solution" consisting of hard-wired object > > > > > semantics (e.g., ifAdminStatus and ifOperStatus). This > solution does > > > > > not require special protocols or datastores, but it is > being replaced > > > by a > > > > generic solution. > > > > > > > > > > If the "generic" solution requires special procedures > which differ on > > > > > each protocol, then it might end up be worse than the > hard-wired > > > solution > > > > that works on every protocol. > > > > > So I agree with Juergen that this is primarily an > architectural issue. > > > > > > > > > > > > > > > /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 > > > > > > -- > > > > > Cheers, > > > > > Mehmet > > > > > > > > -- > > > > Ladislav Lhotka, CZ.NIC Labs > > > > PGP Key ID: E74E8C0C > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Netconf mailing list > > > > Netconf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > _______________________________________________ > > > 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 --------------587EAFBEBDEDB7D855C9762D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 14/12/2016 14:09, Andy Bierman wrote:


On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue <mersue@gmail.com> wrote:
>
> > Hi Andy,
> >
> >
> >
> > > This architectural change needs to be implemented in various protocols.
> >
> > > I am not sure a 6241bis is the best approach because it is not clear
> > which
> >
> > > servers really need to implement the revised datastores.
> >
> >
> >
> > I agree fully. This is the reason why I wrote in my mail:
> >
> >
> >
> > >> - a new protocol- and language-independent standard document (RFC XYZ)
> > defining the generic datastore concept and framework and describing its use
> > (based on and following the DT solution draft),
> >
> > >> - a RFC6241bis draft removing the current datasore concept
> > specification, and getting rid of well-known issues e.g. with the <get>
> > operation,
> >
> >
> I do not agree with the text you wrote.
> I do not want to remove candidate, running, and startup from RFC 6241.
> IMO the new datastores can be defined in a new document that does not
> redefine the existing datastores.
>
> I also do not want to get rid of <get>, It works as intended.
> It is not a problem on small devices.

Andy, the problem with <get> has nothing to do with the size of the
device. The problem is that <get> returns two things (running config
+ operational state) in one merged output document. This forces
people to split data models so that config and state are mutually
exclusive (/interfaces and /interfaces-state). This draft proposes a
fix for this, which makes <get> less useful.


This "problem" exists for some new overloaded use of <get> that did not exist before.
The <get> operation only mixes config=true and config=false. It never had anything
to do with intended vs. applied. IMO your proposed solution is not very backward compatible
with simple systems that do not have delays between intended and applied.

I've been informed (repeatedly ;-) that <running> has always only ever meant intended configuration. I.e. that it is reasonable behaviour for a system to accept config into <running> and then fail to apply that configuration for some reason (daemon is unavailable, linecards is down, resources have been exceeded, programming error, etc). If this interpretation is correct then the NETCONF <get> operation is poorly defined because it is mixing "intended configuration of the system" along with "actual running state".

What NETCONF <get> should really be providing is "actual configuration in use by the system" along with "actual running state". Of course this is effectively what the new operational state datastore is defined as containing.

If I understand it correctly, I think that Andy's point is that for lots of systems "intended configuration of the system" and "actual configuration of the system" are effectively one and the same thing. If this is the case then it should be easy for clients/servers to migrate from an existing <get> request to a <get-data> request that just returns the data from the operational state datastore. It sounds like the actual data returned in both cases should be the same?

Thanks,
Rob





/martin


Andy



> It is not a problem on large devices
> if
> sufficient filtering is used. It does not differentiate between intended
> and applied config
> or understand different types of config=false nodes. Use a new operation to
> add these features.
>
>
>
>
>
>
> > Mehmet
> >
>
>
> Andy
>
>
>
> >
> >
> > *From:* Andy Bierman [mailto:andy@yumaworks.com]
> > *Sent:* Dienstag, 13. Dezember 2016 18:38
> > *To:* Eric Voit (evoit) <evoit@cisco.com>
> > *Cc:* Ladislav Lhotka <lhotka@nic.cz>; MehmetErsue <mersue@gmail.com>;
> > NetMod WG Chairs <netmod-chairs@ietf.org>; NetConf WG Chairs <
> > netconf-chairs@ietf.org>; NetMod WG <netmod@ietf.org>; Netconf <
> > netconf@ietf.org>
> > *Subject:* Re: [netmod] [Netconf] WG adoption poll
> > draft-nmdsdt-netmod-revised-datastores-00
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) <evoit@cisco.com>
> > wrote:
> >
> > I support adoption, and like Mehmet's thinking as well.
> >
> > Also worth focusing on is transport protocol independent yang filtering.
> > So along with how to frame get operations against one of the datastores,
> > how do you know which subtrees/nodes should be included/excluded.
> >
> >
> >
> >
> >
> > This architectural change needs to be implemented in various protocols.
> >
> > I am not sure a 6241bis is the best approach because it is not clear which
> >
> > servers really need to implement the revised datastores. Since RD is
> > purely optional
> >
> > to implement, it should not obsolete 6241 in any way. It should be
> > possible
> >
> > to add new operations and/or new parameters to existing operations without
> >
> > needing to redefine what is already there.
> >
> >
> >
> > The new protocol features need to explain how to include/exclude subtrees.
> >
> > IMO we should only support YANG defined data. This allows the solutions
> >
> > to be generalized and reusable across protocols (e.g., using YANG
> > extensions).
> >
> >
> >
> >
> >
> > Eric
> >
> >
> >
> >
> >
> > Andy
> >
> >
> >
> >
> > > From: Netconf, December 9, 2016 7:49 AM
> > >
> > > Hi Mehmet,
> > >
> > > I think I could just sign your text at the bottom.
> > >
> > > Lada
> > >
> > > > On 9 Dec 2016, at 13:25, MehmetErsue <mersue@gmail.com> wrote:
> > > >
> > > > Hi All,
> > > >
> > > > I think the adoption of the DT draft is fine. We agreed in IETF 97 to
> > adopt and
> > > finalize the DT draft in NETMOD WG, which I still support.
> > > >
> > > > I believe the bigger issue is to agree on a plan concerning the
> > related work
> > > and the re-organization of existing standards. As a matter of fact this
> > plan will
> > > lead to updating the charter of two WGs and the work we are going to
> > start.
> > > >
> > > > I see the DT document as a datastore solution proposal. There are
> > different
> > > gaps and issues which still need to be addressed and the solution
> > proposal
> > > needs yet to be discussed and finalized. The document is providing
> > information
> > > on the history, explaining the need for a generic solution as well as is
> > discussing
> > > different scenarios. As such I believe the datastore solution proposal
> > from the
> > > DT should be published with the intended status Informational RFC.
> > > >
> > > > Based on the finalized and agreed datastore solution we should do
> > different
> > > updates to existing documents in NETCONF and NETMOD WGs. With this
> > > action we can also fix well-known issues.
> > > >
> > > > Concerning the NETCONF WG I would see it as valuable if we develop:
> > > > - a RFC6241bis draft removing the current datasore concept
> > > > specification, and getting rid of well-known issues e.g. with the
> > > > <get> operation,
> > > > - a new protocol- and language-independent standard document (RFC XYZ)
> > > > defining the generic datastore concept and framework and describing
> > > > its use (based on and following the DT solution draft),
> > > > - adding potential extensions to RFC6241bis (following the DT draft
> > > > and with a normative reference to RFC XYZ),
> > > > - adding potential extensions to a RESTCONF-bis RFC (following the DT
> > > > draft and with a normative reference to RFC XYZ),
> > > >
> > > > Concerning the NETMOD WG I would see it as valuable if we develop:
> > > > - RFC7950bis deleting protocol-dependent details and specifying the
> > > > datastore usage with YANG on a generic level (with a normative
> > > > reference to RFC XYZ),
> > > > - adding potential extensions to RFC7950bis, e.g. concerning the
> > > > proposed <notification> element,
> > > > - possibly an RFC 6244bis to describe architectural aspects. However
> > RFC6244
> > > is Informational and a RFC6244bis would be still Informational. I'm not
> > sure
> > > whether this is really necessary. The DT proposal does already describe
> > such a
> > > solution and can be seen as an update to RFC 6244.
> > > > - RFC6087bis giving guidelines on how to use YANG with the new
> > datastore
> > > concept.
> > > >
> > > > Referring to Lada's proposal concerning the spin off document from
> > > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be
> > > provided in the corresponding protocol RFCs, i.e.
> > > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and
> > > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC.
> > > >
> > > > Hope this helps as a starting point on the way to a good plan.
> > > >
> > > > PS: As Benoit suggested some time ago we might also consider to rename
> > > NETCONF WG as it is not only on NETCONF protocol anymore.
> > > >
> > > > Regards,
> > > > Mehmet
> > > >
> > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman <andy@yumaworks.com>
> > > wrote:
> > > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder
> > > <j.schoenwaelder@jacobs-university.de> wrote:
> > > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote:
> > > > >
> > > > > >
> > > > > > I disagree that the datastore model is a protocol specific aspect.
> > > > > > I consider datastores an architectural component binding data
> > > > > > models and protocols together. In fact, the 'traditional'
> > > > > > datastore model
> > > > >
> > > > > I would agree with this if datastores were a general concept in
> > YANG, but
> > > the revised-datastores draft explicitly introduces the "intended" and
> > "applied"
> > > datastores that may be irrelevant to other protocols using YANG, and even
> > > needn't be used in all NETCONF implementations. I wouldn't call this "an
> > > architectural component" of YANG.
> > > > >
> > > >
> > > > An architectural component of this new management framework (that does
> > > > not have a name). The fact that not all protocols may expose all
> > > > datastores is IMHO not a reason that the datastore model is not an
> > > > architectural framework.
> > > >
> > > > > If you are saying that it will have nontrivial impact on YANG, I
> > would like to
> > > see it explained in sec. 6.3. Without this information I am quite
> > reluctant to
> > > agree with the adoption.
> > > >
> > > > An operational state datastore has implications how one writes data
> > > > models. It may not directly affect YANG itself but surely the usage of
> > > > YANG.
> > > >
> > > > > See above - architectural aspects need to be relevant to all
> > protocols.
> > > >
> > > > Yes, but relevant to all protocols does not mean every protocol needs
> > > > to expose say all datastores. But every protocol should be clear about
> > > > how what it exposes relates to the architectural framework.
> > > >
> > > >
> > > >
> > > > There is a "current solution" consisting of hard-wired object
> > > > semantics (e.g., ifAdminStatus and ifOperStatus). This solution does
> > > > not require special protocols or datastores, but it is being replaced
> > by a
> > > generic solution.
> > > >
> > > > If the "generic" solution requires special procedures which differ on
> > > > each protocol, then it might end up be worse than the hard-wired
> > solution
> > > that works on every protocol.
> > > > So I agree with Juergen that this is primarily an architectural issue.
> > > >
> > > >
> > > > /js
> > > >
> > > > Andy
> > > >
> > > >
> > > >
> > > > --
> > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH
> > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > > > Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > --
> > > > Cheers,
> > > > Mehmet
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Netconf mailing list
> > > Netconf@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netconf
> >
> > _______________________________________________
> > 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

--------------587EAFBEBDEDB7D855C9762D-- From nobody Wed Dec 14 07:42:07 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617B0129AA3 for ; Wed, 14 Dec 2016 07:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEjXb8youFZH for ; Wed, 14 Dec 2016 07:41:59 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29E74129591 for ; Wed, 14 Dec 2016 07:41:55 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id x190so25433039qkb.0 for ; Wed, 14 Dec 2016 07:41:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ORFyVo7zn1xzYc126MoJrMw/JhG9tFeq4CqbhU8RCH4=; b=QoJgp/JyFJRnj5/lE/QiDyx+S4yl8HhBbAC9RSEcx/T7xP+dJ9CkTz2dvGM+sZRLgA E5pFXUTHyH5kBGhMsMeyw6mCvcXOC9Qh1oTTj+sTzRHenb9YgG1syJt5B983LuYacaY1 OT98aIDTl6ePIpOEbr/oCXYPwSmCbqvNYrG2Ee2aJcaHBowZBMg2usylcx5g2D3xW7VX vbslXHokplByRZh2kuUTHXZGM3iUbCehUSIVo/zdJKgXPxLc9cwyQygJmAVV6Kz29/rS 0WiM5tLNp//78htueOI7pIaZxPS972kBr4+cFCMFrw/15fCIkkfgOkpB1EHPxaCw0hoz KHBQ== 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=ORFyVo7zn1xzYc126MoJrMw/JhG9tFeq4CqbhU8RCH4=; b=TYUprwTiLnTG7oKSheYt/9eH02y08e+u+UBSXq4VZ15j8Lown2nMeCEFOXKogI/tUp irQxNwocKS9Q03c6k25jlMw1R6P9O9k3fAlrw/NO8Uujp47VGZ33qTHGQpVUBFTHBu38 kCPQMVjjYmGv10h3mclY9Z6c7dNRCuDGhPBJFZOYjV0Q3Q5OhZ/PWKs/nz/KAeSl85Jh 4MBk0tw4mJS98xKncEPZGQJxpSFI/R/k6oCm2a2IS4kEKI2PxHQpMrUeAZTzvrHb1Eta wtYGaxIMlZuph8Py/YvcP51ytoSifIoJMsBWZfwMS2TvNdtyBpp63tP+SPM5C9N+uG3r zOrg== X-Gm-Message-State: AKaTC0087yllgBy17ProFfYF1bvK9VsOX43qb+EnAc1VpNmdiN0XNH5I3BAZ39ACnJ6GA1aszCpZ0YjfAZHLLw== X-Received: by 10.55.72.22 with SMTP id v22mr83429022qka.50.1481730114012; Wed, 14 Dec 2016 07:41:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Wed, 14 Dec 2016 07:41:53 -0800 (PST) In-Reply-To: <372fdb96-295c-1a3e-de12-6693d3560de7@cisco.com> References: <004101d25589$a0cd5f20$e2681d60$@gmail.com> <20161214.120754.915451205380944115.mbj@tail-f.com> <372fdb96-295c-1a3e-de12-6693d3560de7@cisco.com> From: Andy Bierman Date: Wed, 14 Dec 2016 07:41:53 -0800 Message-ID: To: Robert Wilton Content-Type: multipart/alternative; boundary=001a114a893c1962270543a02d31 Archived-At: Cc: NetMod WG Chairs , NETCONF Working Group , "netmod@ietf.org" , Netconf Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 15:42:03 -0000 --001a114a893c1962270543a02d31 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 14, 2016 at 6:42 AM, Robert Wilton wrote: > > > On 14/12/2016 14:09, Andy Bierman wrote: > > > > On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund wrote: > >> Andy Bierman wrote: >> > On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue wrote: >> > >> > > Hi Andy, >> > > >> > > >> > > >> > > > This architectural change needs to be implemented in various >> protocols. >> > > >> > > > I am not sure a 6241bis is the best approach because it is not clear >> > > which >> > > >> > > > servers really need to implement the revised datastores. >> > > >> > > >> > > >> > > I agree fully. This is the reason why I wrote in my mail: >> > > >> > > >> > > >> > > >> - a new protocol- and language-independent standard document (RFC >> XYZ) >> > > defining the generic datastore concept and framework and describing >> its use >> > > (based on and following the DT solution draft), >> > > >> > > >> - a RFC6241bis draft removing the current datasore concept >> > > specification, and getting rid of well-known issues e.g. with the >> >> > > operation, >> > > >> > > >> > I do not agree with the text you wrote. >> > I do not want to remove candidate, running, and startup from RFC 6241. >> > IMO the new datastores can be defined in a new document that does not >> > redefine the existing datastores. >> > >> > I also do not want to get rid of , It works as intended. >> > It is not a problem on small devices. >> >> Andy, the problem with has nothing to do with the size of the >> device. The problem is that returns two things (running config >> + operational state) in one merged output document. This forces >> people to split data models so that config and state are mutually >> exclusive (/interfaces and /interfaces-state). This draft proposes a >> fix for this, which makes less useful. >> >> > This "problem" exists for some new overloaded use of that did not > exist before. > The operation only mixes config=true and config=false. It never had > anything > to do with intended vs. applied. IMO your proposed solution is not very > backward compatible > with simple systems that do not have delays between intended and applied. > > > I've been informed (repeatedly ;-) that has always only ever > meant intended configuration. I.e. that it is reasonable behaviour for a > system to accept config into and then fail to apply that > configuration for some reason (daemon is unavailable, linecards is down, > resources have been exceeded, programming error, etc). If this > interpretation is correct then the NETCONF operation is poorly > defined because it is mixing "intended configuration of the system" along > with "actual running state". > > What NETCONF should really be providing is "actual configuration in > use by the system" along with "actual running state". Of course this is > effectively what the new operational state datastore is defined as > containing. > > If I understand it correctly, I think that Andy's point is that for lots > of systems "intended configuration of the system" and "actual configuration > of the system" are effectively one and the same thing. If this is the case > then it should be easy for clients/servers to migrate from an existing > request to a request that just returns the data from the > operational state datastore. It sounds like the actual data returned in > both cases should be the same? > > I do not understand the new solution because it has not been well-defined. In the old solution, I have 2 leafs /foo and /foo-state. I can retrieve both of these leafs at once with . I can decide if /foo and /foo-state are the values I expect. But if I overload /foo such that it represents different semantics in different datastores, now a retrieval operation can only get 1 at a time. If I set /foo, then get-state(/foo), how do I know the config value for /foo has not changed in the meantime? If the server returns 2 /foo leafs in the same message body, then it is no longer YANG schema-valid (only 1 /foo node is allowed) The operation does not overload objects with different semantics. Only a new server that eliminates /foo-state is overloading the semantics of /foo. The ability to retrieve /foo-state is lost for a client that only knows (and not is broken. It just means the ability to access /foo-state is removed. Thanks, > Rob > > Andy > > > > >> >> /martin >> > > > Andy > > >> >> >> >> > It is not a problem on large devices >> > if >> > sufficient filtering is used. It does not differentiate between >> intended >> > and applied config >> > or understand different types of config=false nodes. Use a new >> operation to >> > add these features. >> > >> > >> > >> > >> > >> > >> > > Mehmet >> > > >> > >> > >> > Andy >> > >> > >> > >> > > >> > > >> > > *From:* Andy Bierman [mailto:andy@yumaworks.com] >> > > *Sent:* Dienstag, 13. Dezember 2016 18:38 >> > > *To:* Eric Voit (evoit) >> > > *Cc:* Ladislav Lhotka ; MehmetErsue > >; >> > > NetMod WG Chairs ; NetConf WG Chairs < >> > > netconf-chairs@ietf.org>; NetMod WG ; Netconf < >> > > netconf@ietf.org> >> > > *Subject:* Re: [netmod] [Netconf] WG adoption poll >> > > draft-nmdsdt-netmod-revised-datastores-00 >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) >> > > wrote: >> > > >> > > I support adoption, and like Mehmet's thinking as well. >> > > >> > > Also worth focusing on is transport protocol independent yang >> filtering. >> > > So along with how to frame get operations against one of the >> datastores, >> > > how do you know which subtrees/nodes should be included/excluded. >> > > >> > > >> > > >> > > >> > > >> > > This architectural change needs to be implemented in various >> protocols. >> > > >> > > I am not sure a 6241bis is the best approach because it is not clear >> which >> > > >> > > servers really need to implement the revised datastores. Since RD is >> > > purely optional >> > > >> > > to implement, it should not obsolete 6241 in any way. It should be >> > > possible >> > > >> > > to add new operations and/or new parameters to existing operations >> without >> > > >> > > needing to redefine what is already there. >> > > >> > > >> > > >> > > The new protocol features need to explain how to include/exclude >> subtrees. >> > > >> > > IMO we should only support YANG defined data. This allows the >> solutions >> > > >> > > to be generalized and reusable across protocols (e.g., using YANG >> > > extensions). >> > > >> > > >> > > >> > > >> > > >> > > Eric >> > > >> > > >> > > >> > > >> > > >> > > Andy >> > > >> > > >> > > >> > > >> > > > From: Netconf, December 9, 2016 7:49 AM >> > > > >> > > > Hi Mehmet, >> > > > >> > > > I think I could just sign your text at the bottom. >> > > > >> > > > Lada >> > > > >> > > > > On 9 Dec 2016, at 13:25, MehmetErsue wrote: >> > > > > >> > > > > Hi All, >> > > > > >> > > > > I think the adoption of the DT draft is fine. We agreed in IETF >> 97 to >> > > adopt and >> > > > finalize the DT draft in NETMOD WG, which I still support. >> > > > > >> > > > > I believe the bigger issue is to agree on a plan concerning the >> > > related work >> > > > and the re-organization of existing standards. As a matter of fact >> this >> > > plan will >> > > > lead to updating the charter of two WGs and the work we are going to >> > > start. >> > > > > >> > > > > I see the DT document as a datastore solution proposal. There are >> > > different >> > > > gaps and issues which still need to be addressed and the solution >> > > proposal >> > > > needs yet to be discussed and finalized. The document is providing >> > > information >> > > > on the history, explaining the need for a generic solution as well >> as is >> > > discussing >> > > > different scenarios. As such I believe the datastore solution >> proposal >> > > from the >> > > > DT should be published with the intended status Informational RFC. >> > > > > >> > > > > Based on the finalized and agreed datastore solution we should do >> > > different >> > > > updates to existing documents in NETCONF and NETMOD WGs. With this >> > > > action we can also fix well-known issues. >> > > > > >> > > > > Concerning the NETCONF WG I would see it as valuable if we >> develop: >> > > > > - a RFC6241bis draft removing the current datasore concept >> > > > > specification, and getting rid of well-known issues e.g. with the >> > > > > operation, >> > > > > - a new protocol- and language-independent standard document (RFC >> XYZ) >> > > > > defining the generic datastore concept and framework and >> describing >> > > > > its use (based on and following the DT solution draft), >> > > > > - adding potential extensions to RFC6241bis (following the DT >> draft >> > > > > and with a normative reference to RFC XYZ), >> > > > > - adding potential extensions to a RESTCONF-bis RFC (following >> the DT >> > > > > draft and with a normative reference to RFC XYZ), >> > > > > >> > > > > Concerning the NETMOD WG I would see it as valuable if we develop: >> > > > > - RFC7950bis deleting protocol-dependent details and specifying >> the >> > > > > datastore usage with YANG on a generic level (with a normative >> > > > > reference to RFC XYZ), >> > > > > - adding potential extensions to RFC7950bis, e.g. concerning the >> > > > > proposed element, >> > > > > - possibly an RFC 6244bis to describe architectural aspects. >> However >> > > RFC6244 >> > > > is Informational and a RFC6244bis would be still Informational. I'm >> not >> > > sure >> > > > whether this is really necessary. The DT proposal does already >> describe >> > > such a >> > > > solution and can be seen as an update to RFC 6244. >> > > > > - RFC6087bis giving guidelines on how to use YANG with the new >> > > datastore >> > > > concept. >> > > > > >> > > > > Referring to Lada's proposal concerning the spin off document from >> > > > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can >> be >> > > > provided in the corresponding protocol RFCs, i.e. >> > > > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis >> and >> > > > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. >> > > > > >> > > > > Hope this helps as a starting point on the way to a good plan. >> > > > > >> > > > > PS: As Benoit suggested some time ago we might also consider to >> rename >> > > > NETCONF WG as it is not only on NETCONF protocol anymore. >> > > > > >> > > > > Regards, >> > > > > Mehmet >> > > > > >> > > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman >> > > > wrote: >> > > > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder >> > > > wrote: >> > > > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: >> > > > > > >> > > > > > > >> > > > > > > I disagree that the datastore model is a protocol specific >> aspect. >> > > > > > > I consider datastores an architectural component binding data >> > > > > > > models and protocols together. In fact, the 'traditional' >> > > > > > > datastore model >> > > > > > >> > > > > > I would agree with this if datastores were a general concept in >> > > YANG, but >> > > > the revised-datastores draft explicitly introduces the "intended" >> and >> > > "applied" >> > > > datastores that may be irrelevant to other protocols using YANG, >> and even >> > > > needn't be used in all NETCONF implementations. I wouldn't call >> this "an >> > > > architectural component" of YANG. >> > > > > > >> > > > > >> > > > > An architectural component of this new management framework (that >> does >> > > > > not have a name). The fact that not all protocols may expose all >> > > > > datastores is IMHO not a reason that the datastore model is not an >> > > > > architectural framework. >> > > > > >> > > > > > If you are saying that it will have nontrivial impact on YANG, I >> > > would like to >> > > > see it explained in sec. 6.3. Without this information I am quite >> > > reluctant to >> > > > agree with the adoption. >> > > > > >> > > > > An operational state datastore has implications how one writes >> data >> > > > > models. It may not directly affect YANG itself but surely the >> usage of >> > > > > YANG. >> > > > > >> > > > > > See above - architectural aspects need to be relevant to all >> > > protocols. >> > > > > >> > > > > Yes, but relevant to all protocols does not mean every protocol >> needs >> > > > > to expose say all datastores. But every protocol should be clear >> about >> > > > > how what it exposes relates to the architectural framework. >> > > > > >> > > > > >> > > > > >> > > > > There is a "current solution" consisting of hard-wired object >> > > > > semantics (e.g., ifAdminStatus and ifOperStatus). This solution >> does >> > > > > not require special protocols or datastores, but it is being >> replaced >> > > by a >> > > > generic solution. >> > > > > >> > > > > If the "generic" solution requires special procedures which >> differ on >> > > > > each protocol, then it might end up be worse than the hard-wired >> > > solution >> > > > that works on every protocol. >> > > > > So I agree with Juergen that this is primarily an architectural >> issue. >> > > > > >> > > > > >> > > > > /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 >> > > > > -- >> > > > > Cheers, >> > > > > Mehmet >> > > > >> > > > -- >> > > > Ladislav Lhotka, CZ.NIC Labs >> > > > PGP Key ID: E74E8C0C >> > > > >> > > > >> > > > >> > > > >> > > > _______________________________________________ >> > > > Netconf mailing list >> > > > Netconf@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/netconf >> > > >> > > _______________________________________________ >> > > netmod mailing list >> > > netmod@ietf.org >> > > https://www.ietf.org/mailman/listinfo/netmod >> > > >> > > >> > > >> > > > > _______________________________________________ > netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod > > > --001a114a893c1962270543a02d31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 14, 2016 at 6:42 AM, Robert Wilton <rwilton@cisco.com&= gt; wrote:
=20 =20 =20



On 14/12/2016 14:09,= Andy Bierman wrote:
=20


On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue <mersue@gmail.com> wrote:
>
> > Hi Andy,
> >
> >
> >
> > > This architectural change needs to be implemented in various protocols.
> >
> > > I am not sure a 6241bis is the best approach because it is not clear
> > which
> >
> > > servers really need to implement the revised datastores.
> >
> >
> >
> > I agree fully. This is the reason why I wrote in my mail:
> >
> >
> >
> > >> - a new protocol- and language-independent standard document (RFC XYZ)
> > defining the generic datastore concept and framework and describing its use
> > (based on and following the DT solution draft),
> >
> > >> - a RFC6241bis draft removing the current datasore concept
> > specification, and getting rid of well-known issues e.g. with the <get>
> > operation,
> >
> >
> I do not agree with the text you wrote.
> I do not want to remove candidate, running, and startup from RFC 6241.
> IMO the new datastores can be defined in a new document that does not
> redefine the existing datastores.
>
> I also do not want to get rid of <get>,=C2=A0 It works as intended.
> It is not a problem on small devices.

Andy, the problem with <get> has nothing to do with the size of the
device.=C2=A0 The problem is that <get> returns two things (running config
+ operational state) in one merged output document.=C2=A0 Thi= s forces
people to split data models so that config and state are mutually
exclusive (/interfaces and /interfaces-state).=C2=A0 This dra= ft proposes a
fix for this, which makes <get> less useful.


This "problem" exists for some new overloaded us= e of <get> that did not exist before.
The <get> operation only mixes config=3Dtrue and config=3Dfalse. It never had anything
to do with intended vs. applied.=C2=A0 IMO your proposed solution is not very backward compatible
with simple systems that do not have delays between intended and applied.

I've been informed (repeatedly ;-) that <running> has always only ever meant intended configuration.=C2=A0 I.e. that it is reasonabl= e behaviour for a system to accept config into <running> and then fail to apply that configuration for some reason (daemon is unavailable, linecards is down, resources have been exceeded, programming error, etc).=C2=A0 If this interpretation is correct then t= he NETCONF <get> operation is poorly defined because it is mixing "intended configuration of the system" along with "actua= l running state".

What NETCONF <get> should really be providing is "actual configuration in use by the system" along with "actual runnin= g state".=C2=A0 Of course this is effectively what the new operation= al state datastore is defined as containing.

If I understand it correctly, I think that Andy's point is that for lots of systems "intended configuration of the system" and &q= uot;actual configuration of the system" are effectively one and the same thing.=C2=A0 If this is the case then it should be easy for clients/servers to migrate from an existing <get> request to a <get-data> request that just returns the data from the operational state datastore.=C2=A0 It sounds like the actual data returned in both cases should be the same?



I do not unde= rstand the new solution because it has not been well-defined.
In the old solution, I have 2 leafs /foo and /foo-state.
<= div>I can retrieve both of these leafs at once with <get>.
= I can decide if /foo and /foo-state are the values I expect.

=
But if I overload /foo such that it represents different semanti= cs in
different datastores, now a retrieval operation can only ge= t 1 at a time.
If I set /foo, then get-state(/foo), how do I know= the config value for /foo
has not changed in the meantime?=C2=A0= If the server returns 2 /foo leafs in the same
message body, the= n it is no longer YANG schema-valid (only 1 /foo node is allowed)

The =C2=A0<get> operation does not overload objects w= ith different semantics.
Only a new server that eliminates /foo-s= tate is overloading the semantics of /foo.
The ability to retriev= e /foo-state is lost for a client that only knows <get> (and not <= get-state).
This does not mean <get> is broken.=C2=A0 It ju= st means the ability to access /foo-state is removed.

<= div>
Thanks,
Rob


Andy
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">


=C2=A0

/martin


Andy
=C2=A0



> It is not a problem on large devices
> if
> sufficient filtering is used.=C2=A0 It does not differentiate between intended
> and applied config
> or understand different types of config=3Dfalse nodes.= =C2=A0 Use a new operation to
> add these features.
>
>
>
>
>
>
> > Mehmet
> >
>
>
> Andy
>
>
>
> >
> >
> > *From:* Andy Bierman [mailto:andy@yumaworks.com]
> > *Sent:* Dienstag, 13. Dezember 2016 18:38
> > *To:* Eric Voit (evoit) <evoit@cisco.com>
> > *Cc:* Ladislav Lhotka <lhotka@nic.cz>; MehmetErsue <mersue@gmail.com>;
> > NetMod WG Chairs <netmod-chairs@ietf.org>; NetConf WG Chairs <
> > netconf-chairs@ietf.org>; NetMod WG <netmod@ietf.org>; Netconf <
> > netconf@ietf.org>
> > *Subject:* Re: [netmod] [Netconf] WG adoption poll
> > draft-nmdsdt-netmod-revised-datastores-00
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) <evoit@cisco.com>
> > wrote:
> >
> > I support adoption, and like Mehmet's thinking as well.
> >
> > Also worth focusing on is transport protocol independent yang filtering.
> > So along with how to frame get operations against one of the datastores,
> > how do you know which subtrees/nodes should be included/excluded.
> >
> >
> >
> >
> >
> > This architectural change needs to be implemented in various protocols.
> >
> > I am not sure a 6241bis is the best approach because it is not clear which
> >
> > servers really need to implement the revised datastores.=C2=A0 Since RD is
> > purely optional
> >
> > to implement, it should not obsolete 6241 in any way.=C2=A0 It should be
> > possible
> >
> > to add new operations and/or new parameters to existing operations without
> >
> > needing to redefine what is already there.
> >
> >
> >
> > The new protocol features need to explain how to include/exclude subtrees.
> >
> > IMO we should only support YANG defined data.=C2=A0 This allows the solutions
> >
> > to be generalized and reusable across protocols (e.g., using YANG
> > extensions).
> >
> >
> >
> >
> >
> > Eric
> >
> >
> >
> >
> >
> > Andy
> >
> >
> >
> >
> > > From: Netconf, December 9, 2016 7:49 AM
> > >
> > > Hi Mehmet,
> > >
> > > I think I could just sign your text at the bottom.
> > >
> > > Lada
> > >
> > > > On 9 Dec 2016, at 13:25, MehmetErsue <mer= sue@gmail.com> wrote:
> > > >
> > > > Hi All,
> > > >
> > > > I think the adoption of the DT draft is fine. We agreed in IETF 97 to
> > adopt and
> > > finalize the DT draft in NETMOD WG, which I still support.
> > > >
> > > > I believe the bigger issue is to agree on a plan concerning the
> > related work
> > > and the re-organization of existing standards. As a matter of fact this
> > plan will
> > > lead to updating the charter of two WGs and the work we are going to
> > start.
> > > >
> > > > I see the DT document as a datastore solution proposal. There are
> > different
> > > gaps and issues which still need to be addressed and the solution
> > proposal
> > > needs yet to be discussed and finalized. The document is providing
> > information
> > > on the history, explaining the need for a generic solution as well as is
> > discussing
> > > different scenarios. As such I believe the datastore solution proposal
> > from the
> > > DT should be published with the intended status Informational RFC.
> > > >
> > > > Based on the finalized and agreed datastore solution we should do
> > different
> > > updates to existing documents in NETCONF and NETMOD WGs. With this
> > > action we can also fix well-known issues.
> > > >
> > > > Concerning the NETCONF WG I would see it as valuable if we develop:
> > > > - a RFC6241bis draft removing the current datasore concept
> > > > specification, and getting rid of well-known issues e.g. with the
> > > > <get> operation,
> > > > - a new protocol- and language-independent standard document (RFC XYZ)
> > > > defining the generic datastore concept and framework and describing
> > > > its use (based on and following the DT solution draft),
> > > > - adding potential extensions to RFC6241bis (following the DT draft
> > > > and with a normative reference to RFC XYZ),
> > > > - adding potential extensions to a RESTCONF-bis RFC (following the DT
> > > > draft and with a normative reference to RFC XYZ),
> > > >
> > > > Concerning the NETMOD WG I would see it as valuable if we develop:
> > > > - RFC7950bis deleting protocol-dependent details and specifying the
> > > > datastore usage with YANG on a generic level (with a normative
> > > > reference to RFC XYZ),
> > > > - adding potential extensions to RFC7950bis, e.g. concerning the
> > > > proposed <notification> element, > > > > - possibly an RFC 6244bis to describe architectural aspects. However
> > RFC6244
> > > is Informational and a RFC6244bis would be still Informational. I'm not
> > sure
> > > whether this is really necessary. The DT proposal does already describe
> > such a
> > > solution and can be seen as an update to RFC 6244.
> > > > - RFC6087bis giving guidelines on how to use YANG with the new
> > datastore
> > > concept.
> > > >
> > > > Referring to Lada's proposal concerning the spin off document from
> > > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be
> > > provided in the corresponding protocol RFCs, i.e.
> > > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and
> > > for RESTCONF "Using RESTCONF with YANG&qu= ot; in RESTCONF-bis RFC.
> > > >
> > > > Hope this helps as a starting point on the way to a good plan.
> > > >
> > > > PS: As Benoit suggested some time ago we might also consider to rename
> > > NETCONF WG as it is not only on NETCONF protocol anymore.
> > > >
> > > > Regards,
> > > > Mehmet
> > > >
> > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman <andy@yumaworks.com>
> > > wrote:
> > > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder
> > > <j.schoenwaelder@jacobs-university.de> wrote:
> > > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote:
> > > > >
> > > > > >
> > > > > > I disagree that the datastore model is a protocol specific aspect.
> > > > > > I consider datastores an architectural component binding data
> > > > > > models and protocols together. In fact, the 'traditional'
> > > > > > datastore model
> > > > >
> > > > > I would agree with this if datastores were a general concept in
> > YANG, but
> > > the revised-datastores draft explicitly introduces the "intended" and
> > "applied"
> > > datastores that may be irrelevant to other protocols using YANG, and even
> > > needn't be used in all NETCONF implementations. I wouldn't call this "an
> > > architectural component" of YANG.
> > > > >
> > > >
> > > > An architectural component of this new management framework (that does
> > > > not have a name). The fact that not all protocols may expose all
> > > > datastores is IMHO not a reason that the datastore model is not an
> > > > architectural framework.
> > > >
> > > > > If you are saying that it will have nontrivial impact on YANG, I
> > would like to
> > > see it explained in sec. 6.3. Without this information I am quite
> > reluctant to
> > > agree with the adoption.
> > > >
> > > > An operational state datastore has implications how one writes data
> > > > models. It may not directly affect YANG itself but surely the usage of
> > > > YANG.
> > > >
> > > > > See above - architectural aspects need to be relevant to all
> > protocols.
> > > >
> > > > Yes, but relevant to all protocols does not mean every protocol needs
> > > > to expose say all datastores. But every protocol should be clear about
> > > > how what it exposes relates to the architectural framework.
> > > >
> > > >
> > > >
> > > > There is a "current solution" consisting of hard-wired object
> > > > semantics (e.g., ifAdminStatus and ifOperStatus).=C2=A0 This solution does
> > > > not require special protocols or datastores, but it is being replaced
> > by a
> > > generic solution.
> > > >
> > > > If the "generic" solution requi= res special procedures which differ on
> > > > each protocol, then it might end up be worse than the hard-wired
> > solution
> > > that works on every protocol.
> > > > So I agree with Juergen that this is primarily an architectural issue.
> > > >
> > > >
> > > > /js
> > > >
> > > > Andy
> > > >
> > > >
> > > >
> > > > --
> > > > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0Jacobs University Bremen gGmbH
> > > > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen | Germany
> > > > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/= >
> > > >
> > > > ____________________________________= ___________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/m= ailman/listinfo/netmod
> > > > --
> > > > Cheers,
> > > > Mehmet
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> > >
> > >
> > >
> > > _________________________________________= ______
> > > Netconf mailing list
> > > Netconf@ietf.org
> > > https://www.ietf.org/mailm= an/listinfo/netconf
> >
> > ______________________________________________= _
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> >
> >



_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/netmod


--001a114a893c1962270543a02d31-- From nobody Wed Dec 14 08:27:02 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F8E129EB8; Wed, 14 Dec 2016 08:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N07g-Y1jFznD; Wed, 14 Dec 2016 08:26:58 -0800 (PST) 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 5C61D129EC9; Wed, 14 Dec 2016 08:25:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22753; q=dns/txt; s=iport; t=1481732721; x=1482942321; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=morGy4Zph6ezyjwWbqptsIhHCq62mCO8tx+9xRTRA74=; b=b/jgFG/LbTK/AT024gPyJamzsjzNxgnFzo/rPzP0LgrnGPccWcPQj3rx KrmWwtly0pbqRsv0yE1Liitn23t5sdAejTpzHWPF7/B0Td4QHpKGug88c k1F9D0gqYn8tTFNW7aTeBL+vFX6kKwfuPSXQ1HrwSqs4VUr/ERP0ri5Qq w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CBAwABclFY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAYEnBFSNTnKWKYd2jRGCCYYiAoI1FAECAQEBAQEBAWI?= =?us-ascii?q?ohGgBAQEDASNWBQsLGCcDAgIhJREGDQYCAQEXiDYDDwiqJYIoL4cLDYNJAQEBA?= =?us-ascii?q?QEBAQECAQEBAQEBAQEBAR6GPoF9CIJWgkiBUxeDGoJdBZo2NY1Ag22BdIUBgyc?= =?us-ascii?q?jhgyJXVKDZYQPHzeBARMOg3kcGIFFPjSFdYI8AQEB?= X-IronPort-AV: E=Sophos;i="5.33,347,1477958400"; d="scan'208,217";a="648903740" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2016 16:25:13 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uBEGPDsb032166; Wed, 14 Dec 2016 16:25:13 GMT To: Andy Bierman References: <004101d25589$a0cd5f20$e2681d60$@gmail.com> <20161214.120754.915451205380944115.mbj@tail-f.com> <372fdb96-295c-1a3e-de12-6693d3560de7@cisco.com> From: Robert Wilton Message-ID: Date: Wed, 14 Dec 2016 16:25:13 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------07658C88751289A7C49D0F14" Archived-At: Cc: NetMod WG Chairs , NETCONF Working Group , "netmod@ietf.org" , Netconf Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 16:27:01 -0000 This is a multi-part message in MIME format. --------------07658C88751289A7C49D0F14 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Andy, Thanks for you comments, please see inline. On 14/12/2016 15:41, Andy Bierman wrote: > > > On Wed, Dec 14, 2016 at 6:42 AM, Robert Wilton > wrote: > > > > On 14/12/2016 14:09, Andy Bierman wrote: >> >> >> On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund > > wrote: >> >> Andy Bierman > >> wrote: >> > On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue >> > wrote: >> > >> > > Hi Andy, >> > > >> > > >> > > >> > > > This architectural change needs to be implemented in >> various protocols. >> > > >> > > > I am not sure a 6241bis is the best approach because it >> is not clear >> > > which >> > > >> > > > servers really need to implement the revised datastores. >> > > >> > > >> > > >> > > I agree fully. This is the reason why I wrote in my mail: >> > > >> > > >> > > >> > > >> - a new protocol- and language-independent standard >> document (RFC XYZ) >> > > defining the generic datastore concept and framework and >> describing its use >> > > (based on and following the DT solution draft), >> > > >> > > >> - a RFC6241bis draft removing the current datasore concept >> > > specification, and getting rid of well-known issues e.g. >> with the >> > > operation, >> > > >> > > >> > I do not agree with the text you wrote. >> > I do not want to remove candidate, running, and startup >> from RFC 6241. >> > IMO the new datastores can be defined in a new document >> that does not >> > redefine the existing datastores. >> > >> > I also do not want to get rid of , It works as intended. >> > It is not a problem on small devices. >> >> Andy, the problem with has nothing to do with the size >> of the >> device. The problem is that returns two things >> (running config >> + operational state) in one merged output document. This forces >> people to split data models so that config and state are mutually >> exclusive (/interfaces and /interfaces-state). This draft >> proposes a >> fix for this, which makes less useful. >> >> >> This "problem" exists for some new overloaded use of that >> did not exist before. >> The operation only mixes config=true and config=false. It >> never had anything >> to do with intended vs. applied. IMO your proposed solution is >> not very backward compatible >> with simple systems that do not have delays between intended and >> applied. > > I've been informed (repeatedly ;-) that has always only > ever meant intended configuration. I.e. that it is reasonable > behaviour for a system to accept config into and then > fail to apply that configuration for some reason (daemon is > unavailable, linecards is down, resources have been exceeded, > programming error, etc). If this interpretation is correct then > the NETCONF operation is poorly defined because it is mixing > "intended configuration of the system" along with "actual running > state". > > What NETCONF should really be providing is "actual > configuration in use by the system" along with "actual running > state". Of course this is effectively what the new operational > state datastore is defined as containing. > > If I understand it correctly, I think that Andy's point is that > for lots of systems "intended configuration of the system" and > "actual configuration of the system" are effectively one and the > same thing. If this is the case then it should be easy for > clients/servers to migrate from an existing request to a > request that just returns the data from the operational > state datastore. It sounds like the actual data returned in both > cases should be the same? > > > > I do not understand the new solution because it has not been well-defined. > > In the old solution, I have 2 leafs /foo and /foo-state. > I can retrieve both of these leafs at once with . > I can decide if /foo and /foo-state are the values I expect. Yes, this is true. But to be a programmatically easily consumable solution it requires that the structure under /foo is also exactly replicated under /foo-state. This probably means that most config needs to be put into groupings, and IMO, I think that it makes the models hard to read, and also harder to maintain. > > But if I overload /foo such that it represents different semantics in > different datastores, now a retrieval operation can only get 1 at a time. Yes, this is true. Although it should be possible to define RPC operations that fetch more than one datastore in the same message if required, although I'm not convinced that is truly needed. > If I set /foo, then get-state(/foo), how do I know the config value > for /foo > has not changed in the meantime? You don't, unless you also do a get on the running config datastore as well. But I also don't see why this is a problem. Either the client knows what the config should be, in which case it probably doesn't need to explicitly ask the device, but can infer it from the operational state. Alternatively, if another client may also be modifying the configuration at the same time then the client needs to be designed to expect and handle this. Even with the existing request, I don't think that any non trivial device can guarantee that all the data returned in that get request is atomically consistent with itself. > If the server returns 2 /foo leafs in the same > message body, then it is no longer YANG schema-valid (only 1 /foo node > is allowed) The message body would need to return two separate data trees, one for each datastore that is being returned. > > The operation does not overload objects with different semantics. > Only a new server that eliminates /foo-state is overloading the > semantics of /foo. The new server doesn't overload the same object with different semantics, it is really just saying that the value of an object depends on what datastore it is being read from, which is true in NETCONF even today. I.e. the value for a given config leaf could already differ between candidate, running, startup. What is being proposed doesn't seem to fundamentally change the meaning of the config leaves in a new and different way, it is just defining new datastores with associated more tightly specified semantics. > The ability to retrieve /foo-state is lost for a client that only > knows (and not This does not mean is broken. It just means the ability to > access /foo-state is removed. I think that is broken in the sense that it is combining together two sets of data that cannot always be combined in a meaningful way. For me the bigger problem is that it is only under rare conditions that the problem scenarios arise, meaning that clients may not be coded to be robust under those scenarios devaluing the YANG automation proposition. Thanks, Rob --------------07658C88751289A7C49D0F14 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Andy,

Thanks for you comments, please see inline.


On 14/12/2016 15:41, Andy Bierman wrote:


On Wed, Dec 14, 2016 at 6:42 AM, Robert Wilton <rwilton@cisco.com> wrote:



On 14/12/2016 14:09, Andy Bierman wrote:


On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue <mersue@gmail.com> wrote:
>
> > Hi Andy,
> >
> >
> >
> > > This architectural change needs to be implemented in various protocols.
> >
> > > I am not sure a 6241bis is the best approach because it is not clear
> > which
> >
> > > servers really need to implement the revised datastores.
> >
> >
> >
> > I agree fully. This is the reason why I wrote in my mail:
> >
> >
> >
> > >> - a new protocol- and language-independent standard document (RFC XYZ)
> > defining the generic datastore concept and framework and describing its use
> > (based on and following the DT solution draft),
> >
> > >> - a RFC6241bis draft removing the current datasore concept
> > specification, and getting rid of well-known issues e.g. with the <get>
> > operation,
> >
> >
> I do not agree with the text you wrote.
> I do not want to remove candidate, running, and startup from RFC 6241.
> IMO the new datastores can be defined in a new document that does not
> redefine the existing datastores.
>
> I also do not want to get rid of <get>,  It works as intended.
> It is not a problem on small devices.

Andy, the problem with <get> has nothing to do with the size of the
device.  The problem is that <get> returns two things (running config
+ operational state) in one merged output document.  This forces
people to split data models so that config and state are mutually
exclusive (/interfaces and /interfaces-state).  This draft proposes a
fix for this, which makes <get> less useful.


This "problem" exists for some new overloaded use of <get> that did not exist before.
The <get> operation only mixes config=true and config=false. It never had anything
to do with intended vs. applied.  IMO your proposed solution is not very backward compatible
with simple systems that do not have delays between intended and applied.

I've been informed (repeatedly ;-) that <running> has always only ever meant intended configuration.  I.e. that it is reasonable behaviour for a system to accept config into <running> and then fail to apply that configuration for some reason (daemon is unavailable, linecards is down, resources have been exceeded, programming error, etc).  If this interpretation is correct then the NETCONF <get> operation is poorly defined because it is mixing "intended configuration of the system" along with "actual running state".

What NETCONF <get> should really be providing is "actual configuration in use by the system" along with "actual running state".  Of course this is effectively what the new operational state datastore is defined as containing.

If I understand it correctly, I think that Andy's point is that for lots of systems "intended configuration of the system" and "actual configuration of the system" are effectively one and the same thing.  If this is the case then it should be easy for clients/servers to migrate from an existing <get> request to a <get-data> request that just returns the data from the operational state datastore.  It sounds like the actual data returned in both cases should be the same?



I do not understand the new solution because it has not been well-defined.

In the old solution, I have 2 leafs /foo and /foo-state.
I can retrieve both of these leafs at once with <get>.
I can decide if /foo and /foo-state are the values I expect.
Yes, this is true. But to be a programmatically easily consumable solution it requires that the structure under /foo is also exactly replicated under /foo-state.  This probably means that most config needs to be put into groupings, and IMO, I think that it makes the models hard to read, and also harder to maintain.



But if I overload /foo such that it represents different semantics in
different datastores, now a retrieval operation can only get 1 at a time.
Yes, this is true.  Although it should be possible to define RPC operations that fetch more than one datastore in the same message if required, although I'm not convinced that is truly needed.


If I set /foo, then get-state(/foo), how do I know the config value for /foo
has not changed in the meantime?
You don't, unless you also do a get on the running config datastore as well.

But I also don't see why this is a problem.  Either the client knows what the config should be, in which case it probably doesn't need to explicitly ask the device, but can infer it from the operational state.  Alternatively, if another client may also be modifying the configuration at the same time then the client needs to be designed to expect and handle this.

Even with the existing <get> request, I don't think that any non trivial device can guarantee that all the data returned in that get request is atomically consistent with itself.


  If the server returns 2 /foo leafs in the same
message body, then it is no longer YANG schema-valid (only 1 /foo node is allowed)
The message body would need to return two separate data trees, one for each datastore that is being returned.


The  <get> operation does not overload objects with different semantics.
Only a new server that eliminates /foo-state is overloading the semantics of /foo.
The new server doesn't overload the same object with different semantics, it is really just saying that the value of an object depends on what datastore it is being read from, which is true in NETCONF even today.  I.e. the value for a given config leaf could already differ between candidate, running, startup.  What is being proposed doesn't seem to fundamentally change the meaning of the config leaves in a new and different way, it is just defining new datastores with associated more tightly specified semantics.


The ability to retrieve /foo-state is lost for a client that only knows <get> (and not <get-state).
This does not mean <get> is broken.  It just means the ability to access /foo-state is removed.
I think that <get> is broken in the sense that it is combining together two sets of data that cannot always be combined in a meaningful way.  For me the bigger problem is that it is only under rare conditions that the problem scenarios arise, meaning that clients may not be coded to be robust under those scenarios devaluing the YANG automation proposition.

Thanks,
Rob

--------------07658C88751289A7C49D0F14-- From nobody Wed Dec 14 16:19:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7296129C4C for ; Wed, 14 Dec 2016 16:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxw2sthoG4hA for ; Wed, 14 Dec 2016 16:19:25 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0097.outbound.protection.outlook.com [104.47.36.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFE85129C3D for ; Wed, 14 Dec 2016 16:19:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZV11unDZpwgj8yKOUOemsP227n8PrlYoqRVJr2v1hTc=; b=iHO8Znqr/7YimvOAqMccH7lDowyUTd9/klIEjYz8w+uWVYHWubeIqo7eJ6kMm03yhnet2cKcx8dVJ5d5vs/akpCurI7VNcC+wxbSyK7QIRxFz64HNn87g+opZ1KMeemZs+vkTdiMaKNfeEJFYiYZAWVk+0HTKUmBxcOJ/84Ljvw= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.5; Thu, 15 Dec 2016 00:19:23 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0789.009; Thu, 15 Dec 2016 00:19:23 +0000 From: Kent Watsen To: Eliot Lear , David Bannister , "Acee Lindem (acee)" , Dean Bogdanovic Thread-Topic: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016) Thread-Index: AQHSMU27zgnn1uVptUusjkVo/6zCsqDTa8aAgAOS7wCAAJs4gIABvJGAgAV84ICAABKsgIAAAYmAgAAEowCAB6EOAIAhjhKA Date: Thu, 15 Dec 2016 00:19:23 +0000 Message-ID: <7635AD99-C245-41FA-8622-4ABA220DEF47@juniper.net> References: <3B8DC570-FB2D-4EE9-98BA-EEED20F2DBC0@gmail.com> <1061F93A-2D1F-41FB-9A21-A3D92188E7E2@gmail.com> <179f5eb2-0de9-42cb-f291-738f16dab568@cisco.com> <4ab7ace4-e6aa-1fc5-a259-ad196a8b882c@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1c.1.161117 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: 06d8c7b9-e9dc-4dc4-42a4-08d42480058b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1442; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:FsUAHQRB0MueFEoBbtkcfV2qdqvfQtgsN6mxHiGJyIJyAmWbLVDrvOjcCwDthCsnzvIuDQfq17LV9LJLvxttWy8wF56CI4Vq7C7AIUqr1Jlg671BerSj1Kjoj+D4pHQ6fTibyjfFxiv43tNEqP6r9il4Ba1NAa89BTmwOsh3kFcVW137vHdId8npycGgYrc/P0jO6pS99viZuIrcfIjOC6z2+VeR+ENedsvT4hkxPaUpGg5D9t6zPVMYdt99oxyST7LbFJBWKi0tOHjlfwGgoEpJn/ViPQqR3cWWEEA5j8KKGuXG71GPiincJdGqFX0YJiCs9/clhc3B3kNi9wDdDJgBHC3RC2ZSmEqYIxfr0XQqWG69EhUFl9K+b3vbgkmAVc16jB3Xg5S4cqPwCexGq/VaILkoxobLwU24cH+WXbN7mBEKwKPrefgCt9m+rSOZJ0cyx6+nrQrMrsIDznCAsQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(100405760836317)(95692535739014)(177428888720325)(21748063052155)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0157DEB61B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39840400002)(39450400003)(39410400002)(39860400002)(199003)(24454002)(53754006)(377454003)(189002)(6436002)(36756003)(122556002)(102836003)(6116002)(82746002)(4001350100001)(2950100002)(83716003)(7906003)(54356999)(83506001)(76176999)(86362001)(92566002)(189998001)(7736002)(3846002)(2900100001)(39060400001)(4326007)(38730400001)(3660700001)(5890100001)(106116001)(106356001)(93886004)(3280700002)(50986999)(6486002)(77096006)(6512006)(6506006)(68736007)(345774005)(229853002)(230783001)(33656002)(97736004)(5660300001)(81166006)(99286002)(81156014)(101416001)(105586002)(9326002)(606005)(66066001)(8676002)(5001770100001)(2906002)(8936002)(25786008)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_7635AD99C24541FA86224ABA220DEF47junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2016 00:19:23.1307 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 00:19:28 -0000 --_000_7635AD99C24541FA86224ABA220DEF47junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpUaGUgZXh0ZW5kZWQgTGFzdCBDYWxsIHBlcmlvZCBpcyBub3cgY2xvc2VkOyBu byBuZXcgaXNzdWVzIGNhbiBiZSByYWlzZWQgbm93LiAgSSBiZWxpZXZlIGlzc3VlcyB3ZXJlIHJh aXNlZCBieSBEYXZpZCwgTWFoZXNoLCBhbmQgb25lIGZyb20gRGVhbiBoaW1zZWxmIChob3BlZnVs bHkgSSBkaWRu4oCZdCBtaXNzIGFueW9uZSkuICBUaGUgYXV0aG9ycyBzaG91bGQgbm93IHdvcmsg dG93YXJkcyByZXNvbHZpbmcgKG9uIGxpc3QsIG9mIGNvdXJzZSkgYWxsIHRoZSBpc3N1ZXMgcmFp c2VkIGR1cmluZyB0aGUgTGFzdCBDYWxsIHBlcmlvZCwgYW5kIHVsdGltYXRlbHkgcG9zdCBhbiB1 cGRhdGVkIGRyYWZ0IGNhcHR1cmluZyB0aGUgV0cgY29uc2Vuc3VzLg0KDQpUaGFua3MsDQpLZW50 IC8vIGFzIHNoZXBoZXJkDQoNCkZyb206IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+ IG9uIGJlaGFsZiBvZiBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4NCkRhdGU6IFdl ZG5lc2RheSwgTm92ZW1iZXIgMjMsIDIwMTYgYXQgMTA6NTQgQU0NClRvOiBFbGlvdCBMZWFyIDxs ZWFyQGNpc2NvLmNvbT4sIERhdmlkIEJhbm5pc3RlciA8ZHBiQG5ldGZsaXguY29tPiwgIkFjZWUg TGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiwgRGVhbiBCb2dkYW5vdmljIDxpdmFuZGVh bkBnbWFpbC5jb20+DQpDYzogIm5ldG1vZEBpZXRmLm9yZyIgPG5ldG1vZEBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbbmV0bW9kXSBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtbmV0bW9kLWFj bC1tb2RlbC0wOSAodW50aWwgT2N0IDI3LCAyMDE2KQ0KDQoNClllcywgdGhpcyBkcmFmdCBpcyBj dXJyZW50bHkgcGFzdCBsYXN0LWNhbGwsIGFuZCBub3QgZm9yIHRoZSBmaXJzdCB0aW1lLCBhbmQg dGhlcmUgYmVpbmcgdHdvIGltcGxlbWVudGF0aW9ucyB3YXMgaGlnaGx5IGVuY291cmFnaW5nLiAg IFN0aWxsLCBhcyBzaGVwaGVyZCBhbmQgY2hhaXIsIEkgbmVlZCB0byBrbm93IHdlIGhhdmUgV0cg Y29uc2Vuc3VzIG9uIG5leHQgc3RlcHMgYW5kIHRoZXJlZm9yZSB3YW50IHRvIGVjaG8gRWxpb3Ti gJlzIHJlcXVlc3QgZm9yIGFsbCBhbmQgYW55IHJlbWFpbmluZyBpc3N1ZXMgdG8gYmUgYnJvdWdo dCBmb3J3YXJkIG5vdywgb3IgbGV04oCZcyBzYXkgd2l0aGluIHRoZSBuZXh0IGNvdXBsZSB3ZWVr cywgc28gd2UgY2FuIGRpc2N1c3Mgd2hpY2ggY2hhbmdlcyB0byBhY2NlcHQgb3Igbm90LiAgVG8g YmUgY2xlYXIsIEnigJltIGluIGVmZmVjdCBleHRlbmRpbmcgdGhlIGxhc3QtY2FsbCBwZXJpb2Qg Zm9yIHRoaXMgZHJhZnQgdW50aWwgRGVjZW1iZXIgNy4NCg0KRldJVywgdGhlIGlzc3VlIEkgcmFp c2VkIHJlZ2FyZGluZyBpZiB0aGVyZSB3YXMgYSBuZWVkIHRvIHN1cHBvcnQgc3lzdGVtLWdlbmVy YXRlZCBBQ0xzIHJlc29sdmVkIGFzIGEgbm8tb3AgdG8gdGhlIGRyYWZ0LiAgRGVhbuKAmXMgaXNz dWUgcmVnYXJkaW5nIGNoYW5naW5nIGEgbGVhZiB0byBhIGxlYWYtbGlzdCBzZWVtZWQgaW5ub2N1 b3VzIGVub3VnaCwgYnV0IEFjZWXigJlzIHF1ZXN0aW9uIHJlbWFpbnMgdW5hbnN3ZXJlZC4gIEFk ZGl0aW9uYWxseSwgZnJvbSBhIHByZS0gQml0cy1OLUJpdGVzIG1lZXRpbmcgSSBoYWQsIEnigJlt IGF3YXJlIHRoYXQgb3RoZXIgY29uY2VybnMgbGluZ2VyLCB3aGljaCBJIGhvcGUgdG8gc2VlIGRp c2N1c3NlZCBub3cgaW4gdGhpcyBleHRlbmRlZCBsYXN0LWNhbGwgcGVyaW9kLg0KDQpLZW50ICAv LyBhcyBzaGVwaGVyZCBhbmQgY28tY2hhaXINCg0KDQpGcm9tOiBFbGlvdCBMZWFyIDxsZWFyQGNp c2NvLmNvbT4NCkRhdGU6IEZyaWRheSwgTm92ZW1iZXIgMTgsIDIwMTYgYXQgOToyNCBBTQ0KVG86 IERhdmlkIEJhbm5pc3RlciA8ZHBiQG5ldGZsaXguY29tPiwgIkFjZWUgTGluZGVtIChhY2VlKSIg PGFjZWVAY2lzY28uY29tPiwgRGVhbiBCb2dkYW5vdmljIDxpdmFuZGVhbkBnbWFpbC5jb20+LCBL ZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4NCkNjOiAibmV0bW9kQGlldGYub3JnIiA8 bmV0bW9kQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtuZXRtb2RdIFdHIExhc3QgQ2FsbCBmb3Ig ZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTA5ICh1bnRpbCBPY3QgMjcsIDIwMTYpDQoNCg0K SXQncyBhbHJlYWR5IHVzZWZ1bCB0byBtZS4gIEFuZCB3ZSd2ZSBzZWVuIG90aGVyIHBlb3BsZSBz YXkgaXQgaXMgdXNlZnVsIHRvIHRoZW0uICBJZiB5b3UgbmVlZCBzb21ldGhpbmcgc3BlY2lmaWMs IHNheSBzbyBub3cgcGxlYXNlLCBidXQgb3RoZXJ3aXNlIGxldCdzIHBsZWFzZSBtb3ZlIGFsb25n Lg0KDQpFbGlvdA0KDQpPbiAxMS8xOC8xNiAzOjA3IFBNLCBEYXZpZCBCYW5uaXN0ZXIgd3JvdGU6 DQpUaGlzIGRyYWZ0IHNob3VsZCBub3QgbW92ZSBmb3J3YXJkLCBpdCBuZWVkcyBtb3JlIHdvcmsg dG8gYmUgdXNlZnVsLiBXaWxsIGJlIHdvcmtpbmcgd2l0aCBEZWFuIG5leHQgd2VlayB0byBmaXgg dGhpbmdzIHVwLg0KDQpPbiBGcmksIE5vdiAxOCwgMjAxNiBhdCAxMTowMiBQTSBFbGlvdCBMZWFy IDxsZWFyQGNpc2NvLmNvbTxtYWlsdG86bGVhckBjaXNjby5jb20+PiB3cm90ZToNCg0KRGVhbiBh bmQgZnJpZW5kcywNCg0KSSdkIGp1c3QgbGlrZSB0byBhZGQgb25lIGFkZGl0aW9uYWwgcG9pbnQu ICBUaGlzIGRyYWZ0IGhhcyBiZWVuIGluIG51bWVyb3VzIGZvcm1zIG9mIFdHTEMgZm9yIGEgd2hp bGUgbm93LiAgIENhbiB3ZSBwbGVhc2UgYWdyZWUgdGhhdCBhcyBhIHByb3Bvc2VkIHN0YW5kYXJk IHdlIGhhdmUgcGFzc2VkIHRoZSBwb2ludCB3aGVyZSBwZXJmZWN0IGlzIHRoZSBlbmVteSBvZiBn b29kPyAgU29tZSBvZiB1cyBuZWVkIHRoaXMgd29yayBmaW5pc2hlZC4NCg0KVGhhbmtzLA0KDQpF bGlvdA0KDQoNCg0KDQoNCg0KDQpPbiAxMS8xOC8xNiAxOjU1IFBNLCBBY2VlIExpbmRlbSAoYWNl ZSkgd3JvdGU6DQpIaSBEZWFuLA0KSWYgeW91IG1ha2UgdGhpcyBhIGxpc3Qgb2YgaGV0ZXJvZ2Vu ZW91cyBJUHY0IGhlYWRlciBmaWVsZHMsIGhvdyB3aWxsIHlvdSBjb25zdHJhaW4gc3BlY2lmaWNh dGlvbiB0byBvbmx5IG9uZSBmaWVsZCBvZiBlYWNoIHR5cGU/IEZvciBleGFtcGxlLCBvbmUgc291 cmNlIGFkZHJlc3M/IEV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBkbyBub3Qgc3VwcG9ydCBtdWx0 aXBsZXMgYW5kIGdlbmVyYXRlIGFsbCBwZXJtdXRhdGlvbnMgKGdpdmVuIG11bHRpcGxlIHNwZWNp ZmljYXRpb25zIG9mIGVhY2ggZmllbGQpIGNvdWxkIGJlIGNvbXBsZXguDQpUaGFua3MsDQpBY2Vl DQoNCg0KRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9k LWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgRGVhbiBCb2dkYW5vdmljIDxpdmFuZGVh bkBnbWFpbC5jb208bWFpbHRvOml2YW5kZWFuQGdtYWlsLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBO b3ZlbWJlciAxNSwgMjAxNiBhdCAxMDowNiBBTQ0KVG86IEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1 bmlwZXIubmV0PG1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0Pj4NCkNjOiAibmV0bW9kQGlldGYu b3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+IiA8bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRt b2RAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtuZXRtb2RdIFdHIExhc3QgQ2FsbCBmb3IgZHJh ZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTA5ICh1bnRpbCBPY3QgMjcsIDIwMTYpDQoNCkkgaGF2 ZSBzb21ldGhpbmcgdGhhdCBtaWdodCBkZWxheSBXR0xDLCBidXQgZm91bmQgb3V0IGFuIG9wdGlt aXphdGlvbiB3aGljaCB3b3VsZCBoZWxwIGluIHRoZSBmdXR1cmUNCg0KSW4gaWV0Zi1wYWNrZXQt ZmllbGRzLnlhbmcsIGV4YW1wbGUgYmVsb3cNCg0KZ3JvdXBpbmcgYWNsLWlwdjQtaGVhZGVyLWZp ZWxkcyB7DQogICBkZXNjcmlwdGlvbg0KICAgICAiRmllbGRzIGluIElQdjQgaGVhZGVyLiI7DQog ICBsZWFmIGRlc3RpbmF0aW9uLWlwdjQtbmV0d29yayB7DQogICAgIHR5cGUgaW5ldDppcHY0LXBy ZWZpeDsNCiAgICAgZGVzY3JpcHRpb24NCiAgICAgICAiRGVzdGluYXRpb24gSVB2NCBhZGRyZXNz IHByZWZpeC4iOw0KICAgfQ0KICAgbGVhZiBzb3VyY2UtaXB2NC1uZXR3b3JrIHsNCiAgICAgdHlw ZSBpbmV0OmlwdjQtcHJlZml4Ow0KICAgICBkZXNjcmlwdGlvbg0KICAgICAgICJTb3VyY2UgSVB2 NCBhZGRyZXNzIHByZWZpeC4iOw0KICAgfQ0KIH0NCg0KSW5zdGVhZCBvZiB1c2luZyAibGVhZiIg Zm9yICJkZXN0aW5hdGlvbi1pcHY0LW5ldHdvcmsiIGFuZCAic291cmNlLWlwdjQtbmV0d29yayIs ICJsZWFmLWxpc3QiIHJlZHVjZXMgdGhlIG51bWJlciBvZiB0ZXJtcy9hY2UgbmVlZGVkLg0KDQpJ ZiB3ZSB3b3VsZCBhZ3JlZSB3aXRoIHRoaXMgY2hhbmdlLCB0aGVuIHdvdWxkIHByb3Bvc2Ugb25l IG1vcmUNCg0KZm9yIG1hYy1hZGRyZXNzZXMsIGhhdmluZyB0aGUgbWFzayB1bmRlciB0aGUgYWRk cmVzcyBpdHNlbGYgbG9vayBiZXR0ZXIgaW4gdGhlIGRhdGEgaXRzZWxmOg0KDQogIDxkZXN0aW5h dGlvbi1tYWMtYWRkcmVzcz4NCiAgICA8YWRkcmVzcz4wMTowMTowMTowMDowMDowMDwvYWRkcmVz cz4NCiAgICA8bWFzaz5mZjpmZjpmZjowMDowMDowMDwvbWFzaz4NCiAgPC9kZXN0aW5hdGlvbi1t YWMtYWRkcmVzcz4NCg0KICBPciBjcmVhdGUgYSBuZXcgdHlwZSAnbWFjLWFkZHJlc3MtcHJlZml4 Jy4NCg0KICBUaGlzIGFsbG93cyBoYXZpbmcgbWF0Y2hpbmcgbXVsdGlwbGUgZGVzdGluYXRpb25z IHRvIDEgc291cmNlLCBvciBtdWx0aXBsZSBzb3VyY2VzIHRvIDEgZGVzdGluYXRpb24sIGlmIHRo ZXkgY2Fubm90IGJlIGVhc2lseSBjb21iaW5lZCBpbnRvIDEgZW50cnkuDQoNCiAgPGRlc3RpbmF0 aW9uLW1hYy1hZGRyZXNzPg0KICAgIDxhZGRyZXNzPjAxOjAxOjAxOjAwOjAwOjAwPC9hZGRyZXNz Pg0KICAgIDxtYXNrPmZmOmZmOmZmOjAwOjAwOjAwPC9tYXNrPg0KICA8L2Rlc3RpbmF0aW9uLW1h Yy1hZGRyZXNzPg0KICA8ZGVzdGluYXRpb24tbWFjLWFkZHJlc3M+DQogICAgPGFkZHJlc3M+MDE6 MDQ6MDE6MDA6MDA6MDA8L2FkZHJlc3M+DQogICAgPG1hc2s+ZmY6ZmY6ZmY6MDA6MDA6MDA8L21h c2s+DQogIDwvZGVzdGluYXRpb24tbWFjLWFkZHJlc3M+DQogIDxzb3VyY2UtbWFjLWFkZHJlc3M+ DQogICAgLi4uLg0KICA8L3NvdXJjZS1tYWMtYWRkcmVzcz4NCk9uIE5vdiAxNCwgMjAxNiwgYXQg NzozNSBBTSwgRGVhbiBCb2dkYW5vdmljIDxpdmFuZGVhbkBnbWFpbC5jb208bWFpbHRvOml2YW5k ZWFuQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpLZW50LA0KDQpUaGFuayB5b3UgZm9yIHRoZSBhbnN3 ZXINCk9uIE5vdiAxMywgMjAxNiwgYXQgMToyMCBQTSwgS2VudCBXYXRzZW4gPGt3YXRzZW5AanVu aXBlci5uZXQ8bWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQ+PiB3cm90ZToNCg0KSGkgRGVhbiwN Cg0KPiBEb27igJl0IHVuZGVyc3RhbmQgeW91ciBxdWVzdGlvbi4gV2hhdCBpcyB0aGUgZGlmZmVy ZW5jZSBiZXR3ZWVuIHN5c3RlbSBhbmQgdXNlciBnZW5lcmF0ZWQgYWNscz8NCg0KVXNlci1nZW5l cmF0ZWQgd291bGQgYmUsIGZvciBpbnN0YW5jZSwgY29uZmlndXJlZCB2aWEgTkVUQ09ORiBvciBS RVNUQ09ORiwgd2hlcmVhcyBzeXN0ZW0tZ2VuZXJhdGVkIHdvdWxkIGJlIEFDTHMgdGhhdCBnZXQg Y3JlYXRlZCBieSBkZWZhdWx0LiAgRm9yIGV4YW1wbGUsIFJGQyA3MjIzIGhhcyB0aGUgdG9wLWxl dmVsIC9pbnRlcmZhY2VzLXN0YXRlIHRvIHN1cHBvcnQgc3lzdGVtLWdlbmVyYXRlZCBpbnRlcmZh Y2VzIChlLmcuLCBsbykgc28sIHdoZW4gcnVubmluZyBgc2hvd3MgaW50ZXJmYWNlc2AsIHRoZSBy ZXN1bHQgaW5jbHVkZXMgYm90aCBjb25maWd1cmVkIGFuZCBzeXN0ZW0tZ2VuZXJhdGVkIGludGVy ZmFjZXMuICAgTWFrZXMgc2Vuc2U/DQoNCkkgdW5kZXJzdGFuZCBub3cgd2hhdCB5b3UgbWVhbnQu IFdoZXJlIEkgY2FuIHNlZSBmb3IgdGhlIGludGVyZmFjZXMgdGhlIHVzZSBjYXNlIHlvdSBkZXNj cmliZSAoZm9yIGxvb3BiYWNrIGFuZCBwaHlzaWNhbCBpbnRlcmZhY2VzKSwgZm9yIEFDTHMgaGF2 ZSBtdWNoIGhhcmRlciB0aW1lIHRvIGZpbmQgYW4gZXhhbXBsZSB1c2UgY2FzZSB3aGVyZSBhIHN5 c3RlbSB3b3VsZCBnZW5lcmF0ZSBhbiBBQ0wuIE1heWJlIGZvciBhIGhpZ2hseSBzZWN1cmUgc3lz dGVtIHdvdWxkIGdlbmVyYXRlIGFuIEFDTCB0byBkZW55IGFsbCB0cmFmZmljIHRvIGFuZCBmcm9t LCBleGNlcHQgdG8gYWNjZXNzIGl0IHZpYSBjb25zb2xlIHdoZW4gaXQgY29tZXMgdXAuIENhbiB5 b3UgY29tZSB3aXRoIHNvbWUgb3RoZXIgdXNlIGNhc2VzPyBJZiB3ZSBjYW4gZmluZCB2aWFibGUg dXNlIGNhc2VzLCB0aGVuIHllcywgd291bGQgc2F5IHRoYXQgcmVwb3J0aW5nIG9wc3RhdGUgZm9y IHN5c3RlbSBnZW5lcmF0ZWQgQUNMcyBpcyB1c2VmdWwuDQoNCkRlYW4NCg0KDQoNCg0KVGhhbmtz LA0KS2VudA0KDQpGcm9tOiBEZWFuIEJvZ2Rhbm92aWMgPGl2YW5kZWFuQGdtYWlsLmNvbTxtYWls dG86aXZhbmRlYW5AZ21haWwuY29tPj4NCkRhdGU6IEZyaWRheSwgTm92ZW1iZXIgMTEsIDIwMTYg YXQgMzo0NSBQTQ0KVG86IEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0PG1haWx0bzpr d2F0c2VuQGp1bmlwZXIubmV0Pj4NCkNjOiAibmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RA aWV0Zi5vcmc+IiA8bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogUmU6IFtuZXRtb2RdIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1uZXRtb2QtYWNs LW1vZGVsLTA5ICh1bnRpbCBPY3QgMjcsIDIwMTYpDQoNCg0KT24gT2N0IDI5LCAyMDE2LCBhdCA0 OjAxIEFNLCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldDxtYWlsdG86a3dhdHNlbkBq dW5pcGVyLm5ldD4+IHdyb3RlOg0KDQpUaGUgbGFzdCBjYWxsIHBlcmlvZCBmb3IgdGhpcyBkcmFm dCBoYXMgZW5kZWQuICAgVGhhbmsgeW91IHRvIGFsbCB0aGF0IHJlc3BvbmRlZC4gIEdpdmVuIHRo ZSByZXNwb25zZXMgcmVjZWl2ZWQsIG15IGNvLWNoYWlyIGFuZCBJIGJlbGlldmUgdGhhdCB0aGUg ZHJhZnQgaXMgcmVhZHkgdG8gbW92ZSBmb3J3YXJkLiAgSSB3aWxsIGJlZ2luIHRoZSBzaGVwaGVy ZCB3cml0ZS11cCBzaG9ydGx5Lg0KSW4gcGFyYWxsZWwsIHByb21wdGVkIGJ5IGEgY29udmVyc2F0 aW9uIEkgaGFkIHRoaXMgbW9ybmluZywgSeKAmW0gd29uZGVyaW5nIGFib3V0IHRoZSBZQU5HIG1v ZHVsZeKAmXMgdXNlIG9mIHRoZSBjb25maWcgZmFsc2Ugbm9kZXMg4oCYYWNsLW9wZXItZGF0YeKA mSBhbmQg4oCYYWNlLW9wZXItZGF0YeKAmS4gIEluIHBhcnRpY3VsYXIsIGFyZSB0aGUgbGlmZXRp bWVzIG9mIHRoZXNlIG5vZGVzIGFsd2F5cyB0aGUgc2FtZSBhcyB0aGUgY29uZmlndXJlZCBub2Rl cz8NCg0KWWVzLCB0aGV5IGFyZS4gV2hlbiB0aGUgbm9kZXMgYXJlIGNyZWF0ZWQsIHRoZXkgYXJl IGRvbuKAmXQgaGF2ZSB0byBiZSBhdHRhY2hlZCB0byBhbiBhbm90aGVyIG9iamVjdCwgbGlrZSBp bnRlcmZhY2Ugb3IgUklCLCBldGMsIGJ1dCB0aGV5IGdldCBvcGVyYXRpb25hbCBzdGF0ZS4gT25j ZSBhdHRhY2hlZCwgKHRvIGNvbnRpbnVlIHdpdGggdGhlIGV4YW1wbGUpIG9wZXJhdGlvbmFsIHN0 YXR1cyBvZiBjb3VudGVycyBpcyBjaGFuZ2luZy4gV2hlbiBkZXRhY2hlZCBmcm9tIHRoZSBpbnRl cmZhY2UsIHRoZSBsYXN0IGtub3cgY291bnRlciBpcyBrZXB0LCB1bnRpbCB0aGUgYWNlIGlzIGRl bGV0ZWQuIFNhbWUgaXMgZm9yIGFjbC1vcGVyLWRhdGEuDQoNCi0gaXMgdGhlcmUgYW55IG5lZWQg dG8gc3VwcG9ydCByZXBvcnRpbmcgb3BzdGF0ZSBmb3Igc3lzdGVtLWdlbmVyYXRlZCBhY3RzPw0K DQpEb27igJl0IHVuZGVyc3RhbmQgeW91ciBxdWVzdGlvbi4gV2hhdCBpcyB0aGUgZGlmZmVyZW5j ZSBiZXR3ZWVuIHN5c3RlbSBhbmQgdXNlciBnZW5lcmF0ZWQgYWNscz8NCg0KRGVhbg0KDQoNClRo YW5rcywNCktlbnQgKGFzIHNoZXBoZXJkKQ0KDQoNCkZyb206IG5ldG1vZCA8bmV0bW9kLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9m IEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0PG1haWx0bzprd2F0c2VuQGp1bmlwZXIu bmV0Pj4NCkRhdGU6IFRodXJzZGF5LCBPY3RvYmVyIDEzLCAyMDE2IGF0IDU6MDUgUE0NClRvOiAi bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+IiA8bmV0bW9kQGlldGYub3Jn PG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW25ldG1vZF0gV0cgTGFzdCBDYWxs IGZvciBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMDkgKHVudGlsIE9jdCAyNywgMjAxNikN Cg0KDQpUaGlzIGlzIGEgbm90aWNlIHRvIHN0YXJ0IGEgdHdvLXdlZWsgTkVUTU9EIFdHIGxhc3Qg Y2FsbCBmb3IgdGhlIGRvY3VtZW50Og0KDQogICAgICAgICAgICAgICBOZXR3b3JrIEFjY2VzcyBD b250cm9sIExpc3QgKEFDTCkgWUFORyBEYXRhIE1vZGVsDQogICAgICAgICAgICAgICBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTA5DQoNClBs ZWFzZSBpbmRpY2F0ZSB5b3VyIHN1cHBvcnQgb3IgY29uY2VybnMgYnkgVGh1cnNkYXksIE9jdG9i ZXIgMjcsIDIwMTYuDQoNCldlIGFyZSBwYXJ0aWN1bGFybHkgaW50ZXJlc3RlZCBpbiBzdGF0ZW1l bnRzIG9mIHRoZSBmb3JtOg0KICAqIEkgaGF2ZSByZXZpZXdlZCBkcmFmdC1pZXRmLW5ldG1vZC1h Y2wtbW9kZWwtMDkgYW5kIGZvdW5kIG5vIGlzc3Vlcy4NCiAgKiBJIGhhdmUgcmV2aWV3ZWQgZHJh ZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTA5IGFuZCBmb3VuZCB0aGUgZm9sbG93aW5nIGlzc3Vl czogLi4uDQoNCkFzIHdlbGwgYXM6DQogKiBJIGhhdmUgaW1wbGVtZW50ZWQgdGhlIGRhdGEgbW9k ZWwgaW4gZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTA5Lg0KICAqIEkgYW0gaW1wbGVtZW50 aW5nIHRoZSBkYXRhIG1vZGVsIGluIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0wOS4NCiAg KiBJIGFtIGNvbnNpZGVyaW5nIHRvIGltcGxlbWVudCB0aGUgZGF0YSBtb2RlbCBpbiBkcmFmdC1p ZXRmLW5ldG1vZC1hY2wtbW9kZWwtMDkuDQogICogSSBhbSBub3QgY29uc2lkZXJpbmcgdG8gaW1w bGVtZW50IHRoZSBkYXRhIG1vZGVsIGluIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0wOS4N Cg0KVGhhbmsgeW91LA0KTkVUTU9EIFdHIENoYWlycw0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RA aWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCm5ldG1vZCBtYWlsaW5nIGxpc3QNCg0KbmV0 bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5v cmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kDQoNCg0KDQo= --_000_7635AD99C24541FA86224ABA220DEF47junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <10792D7D1E2A054DA9F1EBD0AF9DEB2F@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb3Vy aWVyO30NCnAuZ21haWxtc2csIGxpLmdtYWlsbXNnLCBkaXYuZ21haWxtc2cNCgl7bXNvLXN0eWxl LW5hbWU6Z21haWxfbXNnOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iO30NCnNwYW4uZ21haWxtc2cxDQoJe21zby1zdHlsZS1uYW1lOmdt YWlsX21zZzE7fQ0Kc3Bhbi5tODc5NjEwNzAzMTE2OTAzMDgzOWFwcGxlLWNvbnZlcnRlZC1zcGFj ZQ0KCXttc28tc3R5bGUtbmFtZTptXzg3OTYxMDcwMzExNjkwMzA4MzlhcHBsZS1jb252ZXJ0ZWQt c3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglmb250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRhbnQ7DQoJ Y29sb3I6d2luZG93dGV4dDsNCgl0ZXh0LXRyYW5zZm9ybTpub25lOw0KCXRleHQtZGVjb3JhdGlv bjpub25lIG5vbmU7DQoJdmVydGljYWwtYWxpZ246YmFzZWxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJy aTsNCglmb250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRhbnQ7DQoJY29sb3I6d2luZG93dGV4dDsN Cgl0ZXh0LXRyYW5zZm9ybTpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7DQoJdmVy dGljYWwtYWxpZ246YmFzZWxpbmU7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8 Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5IaSBBbGwsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5UaGUgZXh0ZW5kZWQgTGFzdCBDYWxsIHBl cmlvZCBpcyBub3cgY2xvc2VkOyBubyBuZXcgaXNzdWVzIGNhbiBiZSByYWlzZWQgbm93LiZuYnNw OyBJIGJlbGlldmUgaXNzdWVzIHdlcmUgcmFpc2VkIGJ5IERhdmlkLCBNYWhlc2gsIGFuZCBvbmUg ZnJvbSBEZWFuIGhpbXNlbGYgKGhvcGVmdWxseSBJIGRpZG7igJl0IG1pc3MgYW55b25lKS4mbmJz cDsgVGhlIGF1dGhvcnMgc2hvdWxkDQogbm93IHdvcmsgdG93YXJkcyByZXNvbHZpbmcgKG9uIGxp c3QsIG9mIGNvdXJzZSkgYWxsIHRoZSBpc3N1ZXMgcmFpc2VkIGR1cmluZyB0aGUgTGFzdCBDYWxs IHBlcmlvZCwgYW5kIHVsdGltYXRlbHkgcG9zdCBhbiB1cGRhdGVkIGRyYWZ0IGNhcHR1cmluZyB0 aGUgV0cgY29uc2Vuc3VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaSI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5LZW50IC8vIGFzIHNoZXBoZXJk IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5uZXRtb2QgJmx0O25l dG1vZC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgS2VudCBXYXRzZW4gJmx0O2t3 YXRzZW5AanVuaXBlci5uZXQmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgTm92ZW1i ZXIgMjMsIDIwMTYgYXQgMTA6NTQgQU08YnI+DQo8Yj5UbzogPC9iPkVsaW90IExlYXIgJmx0O2xl YXJAY2lzY28uY29tJmd0OywgRGF2aWQgQmFubmlzdGVyICZsdDtkcGJAbmV0ZmxpeC5jb20mZ3Q7 LCAmcXVvdDtBY2VlIExpbmRlbSAoYWNlZSkmcXVvdDsgJmx0O2FjZWVAY2lzY28uY29tJmd0Oywg RGVhbiBCb2dkYW5vdmljICZsdDtpdmFuZGVhbkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwv Yj4mcXVvdDtuZXRtb2RAaWV0Zi5vcmcmcXVvdDsgJmx0O25ldG1vZEBpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtuZXRtb2RdIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0 Zi1uZXRtb2QtYWNsLW1vZGVsLTA5ICh1bnRpbCBPY3QgMjcsIDIwMTYpPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+WWVzLCB0aGlzIGRy YWZ0IGlzIGN1cnJlbnRseSBwYXN0IGxhc3QtY2FsbCwgYW5kIG5vdCBmb3IgdGhlIGZpcnN0IHRp bWUsIGFuZCB0aGVyZSBiZWluZyB0d28gaW1wbGVtZW50YXRpb25zIHdhcyBoaWdobHkgZW5jb3Vy YWdpbmcuJm5ic3A7Jm5ic3A7IFN0aWxsLCBhcyBzaGVwaGVyZCBhbmQgY2hhaXIsIEkgbmVlZCB0 byBrbm93IHdlIGhhdmUgV0cgY29uc2Vuc3VzIG9uDQogbmV4dCBzdGVwcyBhbmQgdGhlcmVmb3Jl IHdhbnQgdG8gZWNobyBFbGlvdOKAmXMgcmVxdWVzdCBmb3IgYWxsIGFuZCBhbnkgcmVtYWluaW5n IGlzc3VlcyB0byBiZSBicm91Z2h0IGZvcndhcmQgbm93LCBvciBsZXTigJlzIHNheSB3aXRoaW4g dGhlIG5leHQgY291cGxlIHdlZWtzLCBzbyB3ZSBjYW4gZGlzY3VzcyB3aGljaCBjaGFuZ2VzIHRv IGFjY2VwdCBvciBub3QuJm5ic3A7IFRvIGJlIGNsZWFyLCBJ4oCZbSBpbiBlZmZlY3QgZXh0ZW5k aW5nIHRoZSBsYXN0LWNhbGwNCiBwZXJpb2QgZm9yIHRoaXMgZHJhZnQgdW50aWwgRGVjZW1iZXIg Ny48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkZXSVcs IHRoZSBpc3N1ZSBJIHJhaXNlZCByZWdhcmRpbmcgaWYgdGhlcmUgd2FzIGEgbmVlZCB0byBzdXBw b3J0IHN5c3RlbS1nZW5lcmF0ZWQgQUNMcyByZXNvbHZlZCBhcyBhIG5vLW9wIHRvIHRoZSBkcmFm dC4mbmJzcDsgRGVhbuKAmXMgaXNzdWUgcmVnYXJkaW5nIGNoYW5naW5nIGEgbGVhZiB0byBhIGxl YWYtbGlzdCBzZWVtZWQgaW5ub2N1b3VzIGVub3VnaCwNCiBidXQgQWNlZeKAmXMgcXVlc3Rpb24g cmVtYWlucyB1bmFuc3dlcmVkLiZuYnNwOyBBZGRpdGlvbmFsbHksIGZyb20gYSBwcmUtIEJpdHMt Ti1CaXRlcyBtZWV0aW5nIEkgaGFkLCBJ4oCZbSBhd2FyZSB0aGF0IG90aGVyIGNvbmNlcm5zIGxp bmdlciwgd2hpY2ggSSBob3BlIHRvIHNlZSBkaXNjdXNzZWQgbm93IGluIHRoaXMgZXh0ZW5kZWQg bGFzdC1jYWxsIHBlcmlvZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmkiPktlbnQmbmJzcDsgLy8gYXMgc2hlcGhlcmQgYW5kIGNvLWNoYWlyPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJv bTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJs YWNrIj5FbGlvdCBMZWFyICZsdDtsZWFyQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+ RnJpZGF5LCBOb3ZlbWJlciAxOCwgMjAxNiBhdCA5OjI0IEFNPGJyPg0KPGI+VG86IDwvYj5EYXZp ZCBCYW5uaXN0ZXIgJmx0O2RwYkBuZXRmbGl4LmNvbSZndDssICZxdW90O0FjZWUgTGluZGVtIChh Y2VlKSZxdW90OyAmbHQ7YWNlZUBjaXNjby5jb20mZ3Q7LCBEZWFuIEJvZ2Rhbm92aWMgJmx0O2l2 YW5kZWFuQGdtYWlsLmNvbSZndDssIEtlbnQgV2F0c2VuICZsdDtrd2F0c2VuQGp1bmlwZXIubmV0 Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7bmV0bW9kQGlldGYub3JnJnF1b3Q7ICZsdDtuZXRt b2RAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbbmV0bW9kXSBXRyBMYXN0 IENhbGwgZm9yIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0wOSAodW50aWwgT2N0IDI3LCAy MDE2KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cD5JdCdzIGFscmVhZHkgdXNl ZnVsIHRvIG1lLiZuYnNwOyBBbmQgd2UndmUgc2VlbiBvdGhlciBwZW9wbGUgc2F5IGl0IGlzIHVz ZWZ1bCB0byB0aGVtLiZuYnNwOyBJZiB5b3UgbmVlZCBzb21ldGhpbmcgc3BlY2lmaWMsIHNheSBz byBub3cgcGxlYXNlLCBidXQgb3RoZXJ3aXNlIGxldCdzIHBsZWFzZSBtb3ZlIGFsb25nLjxvOnA+ PC9vOnA+PC9wPg0KPHA+RWxpb3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDEx LzE4LzE2IDM6MDcgUE0sIERhdmlkIEJhbm5pc3RlciB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBkcmFmdCBzaG91bGQgbm90 IG1vdmUgZm9yd2FyZCwgaXQgbmVlZHMgbW9yZSB3b3JrIHRvIGJlIHVzZWZ1bC4gV2lsbCBiZSB3 b3JraW5nIHdpdGggRGVhbiBuZXh0IHdlZWsgdG8gZml4IHRoaW5ncyB1cC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgTm92IDE4LCAyMDE2IGF0 IDExOjAyIFBNIEVsaW90IExlYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsZWFyQGNpc2NvLmNvbSI+ bGVhckBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9ImdtYWlsbXNnIj5EZWFuIGFuZCBmcmllbmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9ImdtYWlsbXNnIj5JJ2QganVzdCBsaWtlIHRvIGFkZCBvbmUgYWRkaXRpb25hbCBwb2ludC4m bmJzcDsgVGhpcyBkcmFmdCBoYXMgYmVlbiBpbiBudW1lcm91cyBmb3JtcyBvZiBXR0xDIGZvciBh IHdoaWxlIG5vdy4mbmJzcDsmbmJzcDsgQ2FuIHdlIHBsZWFzZSBhZ3JlZSB0aGF0IGFzIGEgcHJv cG9zZWQgc3RhbmRhcmQgd2UgaGF2ZSBwYXNzZWQgdGhlIHBvaW50IHdoZXJlIHBlcmZlY3QgaXMg dGhlIGVuZW15IG9mIGdvb2Q/Jm5ic3A7IFNvbWUgb2YgdXMgbmVlZCB0aGlzDQogd29yayBmaW5p c2hlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbG1zZyI+VGhhbmtzLDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsbXNnIj5FbGlvdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9ImdtYWlsbXNnIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJnbWFpbG1zZyI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWxtc2ci PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTEvMTgvMTYgMTo1NSBQ TSwgQWNlZSBMaW5kZW0gKGFjZWUpIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBEZWFuLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgeW91IG1ha2UgdGhpcyBhIGxp c3Qgb2YgaGV0ZXJvZ2VuZW91cyBJUHY0IGhlYWRlciBmaWVsZHMsIGhvdyB3aWxsIHlvdSBjb25z dHJhaW4gc3BlY2lmaWNhdGlvbiB0byBvbmx5IG9uZSBmaWVsZCBvZiBlYWNoIHR5cGU/IEZvciBl eGFtcGxlLCBvbmUgc291cmNlIGFkZHJlc3M/IEV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBkbyBu b3Qgc3VwcG9ydCBtdWx0aXBsZXMgYW5kIGdlbmVyYXRlIGFsbCBwZXJtdXRhdGlvbnMNCiAoZ2l2 ZW4gbXVsdGlwbGUgc3BlY2lmaWNhdGlvbnMgb2YgZWFjaCBmaWVsZCkgY291bGQgYmUgY29tcGxl eC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFjZWUmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJnbWFpbG1z ZzEiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7 Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5uZXRtb2QgJmx0Ozxh IGhyZWY9Im1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5l dG1vZC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIERlYW4gQm9nZGFub3Zp YyAmbHQ7PGEgaHJlZj0ibWFpbHRvOml2YW5kZWFuQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pml2YW5kZWFuQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsbXNnMSI+ PGI+RGF0ZTogPC9iPjwvc3Bhbj5UdWVzZGF5LCBOb3ZlbWJlciAxNSwgMjAxNiBhdCAxMDowNiBB TTxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPjxiPlRvOiA8L2I+PC9zcGFuPktlbnQgV2F0 c2VuICZsdDs8YSBocmVmPSJtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldCIgdGFyZ2V0PSJfYmxh bmsiPmt3YXRzZW5AanVuaXBlci5uZXQ8L2E+Jmd0Ozxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbG1z ZzEiPjxiPkNjOiA8L2I+PC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2RAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kQGlldGYub3Jn PC9hPiZndDs8YnI+DQo8c3BhbiBjbGFzcz0iZ21haWxtc2cxIj48Yj5TdWJqZWN0OiA8L2I+PC9z cGFuPlJlOiBbbmV0bW9kXSBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1t b2RlbC0wOSAodW50aWwgT2N0IDI3LCAyMDE2KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1 QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCIgaWQ9 Im1fODc5NjEwNzAzMTE2OTAzMDgzOU1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUi Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgc29tZXRoaW5nIHRo YXQgbWlnaHQgZGVsYXkgV0dMQywgYnV0IGZvdW5kIG91dCBhbiBvcHRpbWl6YXRpb24gd2hpY2gg d291bGQgaGVscCBpbiB0aGUgZnV0dXJlDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkluIGlldGYtcGFja2V0LWZpZWxkcy55YW5nLCBleGFtcGxlIGJlbG93 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmdy b3VwaW5nIGFjbC1pcHY0LWhlYWRlci1maWVsZHMgezxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO2Rl c2NyaXB0aW9uPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7RmllbGRz IGluIElQdjQgaGVhZGVyLiZxdW90Ozs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtsZWFmIGRlc3Rp bmF0aW9uLWlwdjQtbmV0d29yayB7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 dHlwZSBpbmV0OmlwdjQtcHJlZml4Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O2Rlc2NyaXB0aW9uPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7JnF1b3Q7RGVzdGluYXRpb24gSVB2NCBhZGRyZXNzIHByZWZpeC4mcXVvdDs7PGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7fTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO2xlYWYgc291cmNlLWlwdjQt bmV0d29yayB7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dHlwZSBpbmV0Omlw djQtcHJlZml4Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2Rlc2NyaXB0aW9u PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7U291 cmNlIElQdjQgYWRkcmVzcyBwcmVmaXguJnF1b3Q7Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO308 YnI+DQombmJzcDt9PGJyPg0KPGJyPg0KSW5zdGVhZCBvZiB1c2luZyAmcXVvdDtsZWFmJnF1b3Q7 IGZvciAmcXVvdDtkZXN0aW5hdGlvbi1pcHY0LW5ldHdvcmsmcXVvdDsgYW5kICZxdW90O3NvdXJj ZS1pcHY0LW5ldHdvcmsmcXVvdDssICZxdW90O2xlYWYtbGlzdCZxdW90OyByZWR1Y2VzIHRoZSBu dW1iZXIgb2YgdGVybXMvYWNlIG5lZWRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgd2Ugd291bGQgYWdyZWUgd2l0aCB0aGlzIGNoYW5n ZSwgdGhlbiB3b3VsZCBwcm9wb3NlIG9uZSBtb3JlJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZvciBtYWMtYWRkcmVzc2VzLCBoYXZp bmcgdGhlIG1hc2sgdW5kZXIgdGhlIGFkZHJlc3MgaXRzZWxmIGxvb2smbmJzcDtiZXR0ZXIgaW4g dGhlIGRhdGEgaXRzZWxmOjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZsdDtkZXN0aW5hdGlvbi1t YWMtYWRkcmVzcyZndDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7YWRkcmVzcyZn dDswMTowMTowMTowMDowMDowMCZsdDsvYWRkcmVzcyZndDs8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbHQ7bWFzayZndDtmZjpmZjpmZjowMDowMDowMCZsdDsvbWFzayZndDs8YnI+DQom bmJzcDsmbmJzcDsmbHQ7L2Rlc3RpbmF0aW9uLW1hYy1hZGRyZXNzJmd0Ozxicj4NCjxicj4NCiZu YnNwOyZuYnNwO09yIGNyZWF0ZSBhIG5ldyB0eXBlICdtYWMtYWRkcmVzcy1wcmVmaXgnLjxicj4N Cjxicj4NCiZuYnNwOyZuYnNwO1RoaXMgYWxsb3dzIGhhdmluZyBtYXRjaGluZyBtdWx0aXBsZSBk ZXN0aW5hdGlvbnMgdG8gMSBzb3VyY2UsIG9yJm5ic3A7bXVsdGlwbGUgc291cmNlcyB0byAxIGRl c3RpbmF0aW9uLCBpZiB0aGV5IGNhbm5vdCBiZSBlYXNpbHkgY29tYmluZWQmbmJzcDtpbnRvIDEg ZW50cnkuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jmx0O2Rlc3RpbmF0aW9uLW1hYy1hZGRyZXNz Jmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDthZGRyZXNzJmd0OzAxOjAxOjAx OjAwOjAwOjAwJmx0Oy9hZGRyZXNzJmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZs dDttYXNrJmd0O2ZmOmZmOmZmOjAwOjAwOjAwJmx0Oy9tYXNrJmd0Ozxicj4NCiZuYnNwOyZuYnNw OyZsdDsvZGVzdGluYXRpb24tbWFjLWFkZHJlc3MmZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jmx0O2Rl c3RpbmF0aW9uLW1hYy1hZGRyZXNzJmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZs dDthZGRyZXNzJmd0OzAxOjA0OjAxOjAwOjAwOjAwJmx0Oy9hZGRyZXNzJmd0Ozxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZsdDttYXNrJmd0O2ZmOmZmOmZmOjAwOjAwOjAwJmx0Oy9tYXNr Jmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZsdDsvZGVzdGluYXRpb24tbWFjLWFkZHJlc3MmZ3Q7PGJy Pg0KJm5ic3A7Jm5ic3A7Jmx0O3NvdXJjZS1tYWMtYWRkcmVzcyZndDs8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsuLi4uPGJyPg0KJm5ic3A7Jm5ic3A7Jmx0Oy9zb3VyY2UtbWFjLWFkZHJl c3MmZ3Q7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gTm92IDE0LCAyMDE2LCBhdCA3OjM1IEFNLCBEZWFuIEJvZ2Rhbm92aWMgJmx0OzxhIGhy ZWY9Im1haWx0bzppdmFuZGVhbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5pdmFuZGVhbkBn bWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPktlbnQsIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhhbmsgeW91IGZvciB0aGUgYW5zd2VyPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTm92IDEzLCAyMDE2LCBhdCAxOjIwIFBN LCBLZW50IFdhdHNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQiIHRh cmdldD0iX2JsYW5rIj5rd2F0c2VuQGp1bmlwZXIubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkhpIERlYW4sPC9zcGFuPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBjbGFzcz0iZ21haWxtc2cxIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZndDsgRG9u4oCZdCB1bmRlcnN0 YW5kIHlvdXIgcXVlc3Rpb24uIFdoYXQgaXMgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBzeXN0ZW0g YW5kIHVzZXIgZ2VuZXJhdGVkIGFjbHM/PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBjbGFzcz0iZ21haWxtc2cxIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlVzZXItZ2VuZXJhdGVkIHdvdWxkIGJlLCBmb3IgaW5zdGFu Y2UsIGNvbmZpZ3VyZWQgdmlhIE5FVENPTkYgb3IgUkVTVENPTkYsIHdoZXJlYXMgc3lzdGVtLWdl bmVyYXRlZCB3b3VsZCBiZSBBQ0xzIHRoYXQgZ2V0IGNyZWF0ZWQgYnkgZGVmYXVsdC4mbmJzcDsN CiBGb3IgZXhhbXBsZSwgUkZDIDcyMjMgaGFzIHRoZSB0b3AtbGV2ZWwgL2ludGVyZmFjZXMtc3Rh dGUgdG8gc3VwcG9ydCBzeXN0ZW0tZ2VuZXJhdGVkIGludGVyZmFjZXMgKGUuZy4sIGxvKSBzbywg d2hlbiBydW5uaW5nIGBzaG93cyBpbnRlcmZhY2VzYCwgdGhlIHJlc3VsdCBpbmNsdWRlcyBib3Ro IGNvbmZpZ3VyZWQgYW5kIHN5c3RlbS1nZW5lcmF0ZWQgaW50ZXJmYWNlcy4mbmJzcDsmbmJzcDsg TWFrZXMgc2Vuc2U/PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB1bmRlcnN0 YW5kIG5vdyB3aGF0IHlvdSBtZWFudC4gV2hlcmUgSSBjYW4gc2VlIGZvciB0aGUgaW50ZXJmYWNl cyB0aGUgdXNlIGNhc2UgeW91IGRlc2NyaWJlIChmb3IgbG9vcGJhY2sgYW5kIHBoeXNpY2FsIGlu dGVyZmFjZXMpLCBmb3IgQUNMcyBoYXZlIG11Y2ggaGFyZGVyIHRpbWUgdG8gZmluZCBhbiBleGFt cGxlIHVzZSBjYXNlIHdoZXJlIGEgc3lzdGVtIHdvdWxkIGdlbmVyYXRlIGFuIEFDTC4gTWF5YmUN CiBmb3IgYSBoaWdobHkgc2VjdXJlIHN5c3RlbSB3b3VsZCBnZW5lcmF0ZSBhbiBBQ0wgdG8gZGVu eSBhbGwgdHJhZmZpYyB0byBhbmQgZnJvbSwgZXhjZXB0IHRvIGFjY2VzcyBpdCB2aWEgY29uc29s ZSB3aGVuIGl0IGNvbWVzIHVwLiBDYW4geW91IGNvbWUgd2l0aCBzb21lIG90aGVyIHVzZSBjYXNl cz8gSWYgd2UgY2FuIGZpbmQgdmlhYmxlIHVzZSBjYXNlcywgdGhlbiB5ZXMsIHdvdWxkIHNheSB0 aGF0IHJlcG9ydGluZyBvcHN0YXRlIGZvciBzeXN0ZW0NCiBnZW5lcmF0ZWQgQUNMcyBpcyB1c2Vm dWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkRlYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gY2xh c3M9ImdtYWlsbXNnMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBj bGFzcz0iZ21haWxtc2cxIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj5UaGFua3MsPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBjbGFzcz0iZ21haWxtc2cxIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj5LZW50PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBjbGFzcz0iZ21haWxtc2cxIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPjxiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5Gcm9tOjwvc3Bhbj48L2I+PC9zcGFuPjxzcGFu IGNsYXNzPSJtODc5NjEwNzAzMTE2OTAzMDgzOWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48L2I+PC9zcGFuPjxz cGFuIGNsYXNzPSJnbWFpbG1zZzEiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5E ZWFuDQogQm9nZGFub3ZpYyAmbHQ7PGEgaHJlZj0ibWFpbHRvOml2YW5kZWFuQGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPml2YW5kZWFuQGdtYWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWls bXNnMSI+PGI+RGF0ZTo8L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJtODc5NjEwNzAzMTE2OTAzMDgz OWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PGI+Jm5ic3A7PC9iPjwvc3Bhbj48c3BhbiBjbGFzcz0i Z21haWxtc2cxIj5GcmlkYXksIE5vdmVtYmVyIDExLCAyMDE2IGF0IDM6NDUgUE08L3NwYW4+PGJy Pg0KPHNwYW4gY2xhc3M9ImdtYWlsbXNnMSI+PGI+VG86PC9iPjwvc3Bhbj48c3BhbiBjbGFzcz0i bTg3OTYxMDcwMzExNjkwMzA4MzlhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxiPiZuYnNwOzwvYj48 L3NwYW4+PHNwYW4gY2xhc3M9ImdtYWlsbXNnMSI+S2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9Im1h aWx0bzprd2F0c2VuQGp1bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+a3dhdHNlbkBqdW5pcGVy Lm5ldDwvYT4mZ3Q7PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPjxiPkNjOjwv Yj48L3NwYW4+PHNwYW4gY2xhc3M9Im04Nzk2MTA3MDMxMTY5MDMwODM5YXBwbGUtY29udmVydGVk LXNwYWNlIj48Yj4mbmJzcDs8L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPiZxdW90 OzxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2RA aWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+bmV0bW9kQGlldGYub3JnPC9hPiZndDs8L3NwYW4+PGJyPg0KPHNwYW4g Y2xhc3M9ImdtYWlsbXNnMSI+PGI+U3ViamVjdDo8L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJtODc5 NjEwNzAzMTE2OTAzMDgzOWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PGI+Jm5ic3A7PC9iPjwvc3Bh bj48c3BhbiBjbGFzcz0iZ21haWxtc2cxIj5SZTogW25ldG1vZF0gV0cgTGFzdCBDYWxsIGZvciBk cmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMDkgKHVudGlsIE9jdCAyNywgMjAxNik8L3NwYW4+ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTpIZWx2ZXRpY2EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRp Y2EiPk9uIE9jdCAyOSwgMjAxNiwgYXQgNDowMSBBTSwgS2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9 Im1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+a3dhdHNlbkBqdW5pcGVyLm5ldDwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRoZSBsYXN0IGNhbGwgcGVyaW9k IGZvciB0aGlzIGRyYWZ0IGhhcyBlbmRlZC4mbmJzcDsgJm5ic3A7VGhhbmsgeW91IHRvIGFsbCB0 aGF0IHJlc3BvbmRlZC4mbmJzcDsgR2l2ZW4gdGhlIHJlc3BvbnNlcyByZWNlaXZlZCwgbXkgY28t Y2hhaXIgYW5kIEkgYmVsaWV2ZQ0KIHRoYXQgdGhlIGRyYWZ0IGlzIHJlYWR5IHRvIG1vdmUgZm9y d2FyZC4mbmJzcDsgSSB3aWxsIGJlZ2luIHRoZSBzaGVwaGVyZCB3cml0ZS11cCBzaG9ydGx5Ljwv c3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gY2xh c3M9ImdtYWlsbXNnMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+SW4gcGFyYWxsZWwsIHByb21wdGVkIGJ5IGEgY29udmVyc2F0aW9uIEkgaGFkIHRo aXMgbW9ybmluZywgSeKAmW0gd29uZGVyaW5nIGFib3V0IHRoZSBZQU5HIG1vZHVsZeKAmXMgdXNl IG9mIHRoZSBjb25maWcgZmFsc2Ugbm9kZXMg4oCYYWNsLW9wZXItZGF0YeKAmQ0KIGFuZCDigJhh Y2Utb3Blci1kYXRh4oCZLiZuYnNwOyBJbiBwYXJ0aWN1bGFyLCBhcmUgdGhlIGxpZmV0aW1lcyBv ZiB0aGVzZSBub2RlcyBhbHdheXMgdGhlIHNhbWUgYXMgdGhlIGNvbmZpZ3VyZWQgbm9kZXM/Jm5i c3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPlllcywgdGhleSBhcmUuIFdoZW4gdGhlIG5vZGVzIGFyZSBjcmVhdGVkLCB0aGV5IGFyZSBk b27igJl0IGhhdmUgdG8gYmUgYXR0YWNoZWQgdG8gYW4gYW5vdGhlciBvYmplY3QsIGxpa2UgaW50 ZXJmYWNlIG9yIFJJQiwgZXRjLCBidXQgdGhleSBnZXQgb3BlcmF0aW9uYWwgc3RhdGUuIE9uY2Ug YXR0YWNoZWQsICh0byBjb250aW51ZSB3aXRoIHRoZSBleGFtcGxlKSBvcGVyYXRpb25hbA0KIHN0 YXR1cyBvZiBjb3VudGVycyBpcyBjaGFuZ2luZy4gV2hlbiBkZXRhY2hlZCBmcm9tIHRoZSBpbnRl cmZhY2UsIHRoZSBsYXN0IGtub3cgY291bnRlciBpcyBrZXB0LCB1bnRpbCB0aGUgYWNlIGlzIGRl bGV0ZWQuIFNhbWUgaXMgZm9yIGFjbC1vcGVyLWRhdGEuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBjbGFzcz0iZ21haWxtc2cxIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj4tIGlzIHRoZXJlIGFueSBuZWVkIHRvIHN1cHBvcnQgcmVwb3J0aW5n IG9wc3RhdGUgZm9yIHN5c3RlbS1nZW5lcmF0ZWQgYWN0cz88L3NwYW4+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkRvbuKAmXQgdW5kZXJzdGFuZCB5b3VyIHF1ZXN0 aW9uLiBXaGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gc3lzdGVtIGFuZCB1c2VyIGdlbmVy YXRlZCBhY2xzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkRlYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBjbGFzcz0iZ21haWxtc2cxIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UaGFua3MsPC9zcGFuPjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBjbGFzcz0iZ21haWxtc2cx Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5LZW50 IChhcyBzaGVwaGVyZCk8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gY2xhc3M9ImdtYWlsbXNnMSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBjbGFzcz0iZ21haWxtc2cxIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkZyb206PC9zcGFuPjwvYj48L3NwYW4+PHNw YW4gY2xhc3M9Im04Nzk2MTA3MDMxMTY5MDMwODM5YXBwbGUtY29udmVydGVkLXNwYWNlIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwv c3Bhbj48L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+bmV0bW9kDQogJmx0OzxhIGhyZWY9Im1h aWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjojOTU0RjcyIj5uZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0OyBv biBiZWhhbGYgb2YgS2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9Im1haWx0bzprd2F0c2VuQGp1bmlw ZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPmt3YXRz ZW5AanVuaXBlci5uZXQ8L3NwYW4+PC9hPiZndDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PGJyPg0KPHNwYW4gY2xhc3M9Imdt YWlsbXNnMSI+PGI+RGF0ZTo8L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJtODc5NjEwNzAzMTE2OTAz MDgzOWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PGI+Jm5ic3A7PC9iPjwvc3Bhbj48c3BhbiBjbGFz cz0iZ21haWxtc2cxIj5UaHVyc2RheSwgT2N0b2JlciAxMywgMjAxNiBhdCA1OjA1IFBNPC9zcGFu Pjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPjxiPlRvOjwvYj48L3NwYW4+PHNwYW4gY2xh c3M9Im04Nzk2MTA3MDMxMTY5MDMwODM5YXBwbGUtY29udmVydGVkLXNwYWNlIj48Yj4mbmJzcDs8 L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPiZxdW90OzxhIGhyZWY9Im1haWx0bzpu ZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3 MiI+bmV0bW9kQGlldGYub3JnPC9zcGFuPjwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpu ZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3 MiI+bmV0bW9kQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNz PSJnbWFpbG1zZzEiPjxiPlN1YmplY3Q6PC9iPjwvc3Bhbj48c3BhbiBjbGFzcz0ibTg3OTYxMDcw MzExNjkwMzA4MzlhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxiPiZuYnNwOzwvYj48L3NwYW4+PHNw YW4gY2xhc3M9ImdtYWlsbXNnMSI+W25ldG1vZF0gV0cgTGFzdCBDYWxsIGZvciBkcmFmdC1pZXRm LW5ldG1vZC1hY2wtbW9kZWwtMDkgKHVudGlsIE9jdCAyNywgMjAxNik8L3NwYW4+PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBjbGFzcz0i Z21haWxtc2cxIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRoaXMgaXMgYSBub3RpY2UgdG8gc3RhcnQgYSB0d28td2Vl ayBORVRNT0QgV0cgbGFzdCBjYWxsIGZvciB0aGUgZG9jdW1lbnQ6PC9zcGFuPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBjbGFzcz0iZ21haWxtc2cxIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGNs YXNzPSJnbWFpbG1zZzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO05ldHdvcmsgQWNjZXNz IENvbnRyb2wgTGlzdCAoQUNMKSBZQU5HIERhdGEgTW9kZWw8L3NwYW4+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzx1PjxzcGFuIHN0eWxlPSJjb2xvcjojMEI0Q0I0Ij48YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1v ZGVsLTA5IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMDk8L3Nw YW4+PC9hPjwvc3Bhbj48L3U+PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBjbGFzcz0iZ21haWxtc2cxIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlBsZWFzZSBpbmRp Y2F0ZSB5b3VyIHN1cHBvcnQgb3IgY29uY2VybnMgYnkgVGh1cnNkYXksIE9jdG9iZXIgMjcsIDIw MTYuPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBjbGFzcz0iZ21haWxtc2cxIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPldlIGFyZSBwYXJ0aWN1bGFybHkgaW50ZXJl c3RlZCBpbiBzdGF0ZW1lbnRzIG9mIHRoZSBmb3JtOjwvc3Bhbj48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gY2xhc3M9ImdtYWlsbXNnMSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7ICogSSBoYXZl IHJldmlld2VkIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0wOSBhbmQgZm91bmQgbm8gaXNz dWVzLjwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gY2xhc3M9ImdtYWlsbXNnMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7KiBJIGhhdmUgcmV2aWV3ZWQgZHJhZnQtaWV0Zi1u ZXRtb2QtYWNsLW1vZGVsLTA5IGFuZCBmb3VuZCB0aGUgZm9sbG93aW5nIGlzc3VlczogLi4uPC9z cGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBjbGFz cz0iZ21haWxtc2cxIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkFzIHdlbGwgYXM6PC9zcGFuPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBjbGFzcz0iZ21haWxtc2cxIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsqIEkg aGF2ZSBpbXBsZW1lbnRlZCB0aGUgZGF0YSBtb2RlbCBpbiBkcmFmdC1pZXRmLW5ldG1vZC1hY2wt bW9kZWwtMDkuPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBjbGFzcz0iZ21haWxtc2cxIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsgKiBJIGFtIGltcGxlbWVudGluZyB0aGUgZGF0YSBt b2RlbCBpbiBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMDkuPC9zcGFuPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBjbGFzcz0iZ21haWxtc2cxIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsg KiBJIGFtIGNvbnNpZGVyaW5nIHRvIGltcGxlbWVudCB0aGUgZGF0YSBtb2RlbCBpbiBkcmFmdC1p ZXRmLW5ldG1vZC1hY2wtbW9kZWwtMDkuPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBjbGFzcz0iZ21haWxtc2cxIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsgKiBJIGFtIG5vdCBjb25z aWRlcmluZyB0byBpbXBsZW1lbnQgdGhlIGRhdGEgbW9kZWwgaW4gZHJhZnQtaWV0Zi1uZXRtb2Qt YWNsLW1vZGVsLTA5Ljwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gY2xhc3M9ImdtYWlsbXNnMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRoYW5rIHlvdSw8L3NwYW4+ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGNsYXNzPSJn bWFpbG1zZzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPk5FVE1PRCBXRyBDaGFpcnM8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBjbGFzcz0iZ21haWxtc2cxIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bh bj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBjbGFzcz0iZ21haWxt c2cxIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTti YWNrZ3JvdW5kOndoaXRlIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTpIZWx2ZXRpY2EiPjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPjxzcGFuIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj5uZXRtb2QgbWFpbGluZyBsaXN0PC9zcGFuPjwvc3Bhbj48YnI+ DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiM5NTRGNzI7YmFja2dyb3VuZDp3aGl0ZSI+bmV0bW9k QGlldGYub3JnPC9zcGFuPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTpIZWx2ZXRpY2EiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGNs YXNzPSJnbWFpbG1zZzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhO2NvbG9yOiM5NTRGNzI7YmFja2dyb3VuZDp3aGl0ZSI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L3NwYW4+PC9zcGFuPjwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm5ldG1vZCBtYWlsaW5nIGxpc3Q8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+bmV0bW9kQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8 L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm5ldG1vZCBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_7635AD99C24541FA86224ABA220DEF47junipernet_-- From nobody Thu Dec 15 05:08:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F357129D82; Thu, 15 Dec 2016 05:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QbHcAs_zQRL; Thu, 15 Dec 2016 05:08:54 -0800 (PST) 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 77C5D129618; Thu, 15 Dec 2016 05:08:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2868; q=dns/txt; s=iport; t=1481807333; x=1483016933; h=to:from:subject:cc:message-id:date:mime-version; bh=rET4nJvoAcwgiFot2B3SUJa6L7QzEpxkAVHhKqqXZsM=; b=LmUIc8y8IUZwp7KR2bURFxaC3EiytZoLuk4ElcRvDzI6mAbTLr7xCuBR tDoyKjfg0XNdrw81C5Im4HimMQSknmpMGnAMy6OOps0vBRO8qr8R45wR0 L30jC3VTyULztR6xrTGsXS8X/eGN0DYOXKndtB0xC8jGnNwhHfB/Fq4Oi s=; X-IronPort-AV: E=Sophos;i="5.33,351,1477958400"; d="scan'208,217";a="647909854" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Dec 2016 13:08:51 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uBFD8pDC015780; Thu, 15 Dec 2016 13:08:51 GMT To: draft-ietf-netmod-entity@ietf.org From: Benoit Claise Message-ID: Date: Thu, 15 Dec 2016 14:08:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------13313C56A5AD9CF605010A0D" Archived-At: Cc: timothy.carey@nokia.com, NETMOD Working Group , JOEY BOYD , david.sinicrope@ericsson.com Subject: [netmod] BBF work depending on draft-ietf-netmod-entity-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 13:08:55 -0000 This is a multi-part message in MIME format. --------------13313C56A5AD9CF605010A0D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear draft-ietf-netmod-entity authors, As mentioned by Tim Carey during the last IETF meeting, BBF work depends on the draft-ietf-netmod-entity-01. Message from BBF: We are now in the final stages of reviewing “TR-383” “Common YANG” modules that have the following dependencies: * iana-entity * iana-if-type * ietf-hardware * ietf-inet-types * ietf-interfaces * ietf-system * ietf-yang-types If all goes to plan, the TR-383 modules will be published in March 2017, but you can see that there is a dependency on iana-entity and ietf-hardware, which are currently taken from draft-ietf-netmod-entity-01. We will potentially need to reference draft versions? I hope we all agree that referencing a draft version is not ideal. Would it be possible to progress draft-ietf-netmod-entity, and therefore help our BBF friends? Is the March deadline a reachable goal? Regards, Benoit --------------13313C56A5AD9CF605010A0D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear draft-ietf-netmod-entity authors,

As mentioned by Tim Carey during the last IETF meeting, BBF work depends on the draft-ietf-netmod-entity-01.

Message from BBF:
We are now in the final stages of reviewing “TR-383” “Common YANG” modules that have the following dependencies:
  • iana-entity
  • iana-if-type
  • ietf-hardware
  • ietf-inet-types
  • ietf-interfaces
  • ietf-system
  • ietf-yang-types
If all goes to plan, the TR-383 modules will be published in March 2017, but you can see that there is a dependency on iana-entity and ietf-hardware, which are currently taken from draft-ietf-netmod-entity-01. We will potentially need to reference draft versions?
I hope we all agree that referencing a draft version is not ideal.
Would it be possible to progress draft-ietf-netmod-entity, and therefore help our BBF friends?
Is the March deadline a reachable goal?

Regards, Benoit

--------------13313C56A5AD9CF605010A0D-- From nobody Thu Dec 15 05:57:36 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6751B1294C7; Thu, 15 Dec 2016 05:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 uDfv0HH-5A44; Thu, 15 Dec 2016 05:57:34 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AFA5E1295AC; Thu, 15 Dec 2016 05:57:32 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 494321AE03B5; Thu, 15 Dec 2016 14:57:31 +0100 (CET) Date: Thu, 15 Dec 2016 14:57:29 +0100 (CET) Message-Id: <20161215.145729.704925239472686261.mbj@tail-f.com> To: bclaise@cisco.com 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=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: timothy.carey@nokia.com, draft-ietf-netmod-entity@ietf.org, joey.boyd@adtran.com, netmod@ietf.org, david.sinicrope@ericsson.com Subject: Re: [netmod] BBF work depending on draft-ietf-netmod-entity-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 13:57:35 -0000 QmVub2l0IENsYWlzZSA8YmNsYWlzZUBjaXNjby5jb20+IHdyb3RlOg0KPiBEZWFyIGRyYWZ0LWll dGYtbmV0bW9kLWVudGl0eSBhdXRob3JzLA0KPiANCj4gQXMgbWVudGlvbmVkIGJ5IFRpbSBDYXJl eSBkdXJpbmcgdGhlIGxhc3QgSUVURiBtZWV0aW5nLCBCQkYgd29yaw0KPiBkZXBlbmRzIG9uIHRo ZSBkcmFmdC1pZXRmLW5ldG1vZC1lbnRpdHktMDEuDQo+IA0KPiBNZXNzYWdlIGZyb20gQkJGOg0K PiANCj4gICAgV2UgYXJlIG5vdyBpbiB0aGUgZmluYWwgc3RhZ2VzIG9mIHJldmlld2luZyDigJxU Ui0zODPigJ0g4oCcQ29tbW9uIFlBTkfigJ0NCj4gICAgbW9kdWxlcyB0aGF0IGhhdmUgdGhlIGZv bGxvd2luZyBkZXBlbmRlbmNpZXM6DQo+IA0KPiAgICAgICogaWFuYS1lbnRpdHkNCj4gICAgICAq IGlhbmEtaWYtdHlwZQ0KPiAgICAgICogaWV0Zi1oYXJkd2FyZQ0KPiAgICAgICogaWV0Zi1pbmV0 LXR5cGVzDQo+ICAgICAgKiBpZXRmLWludGVyZmFjZXMNCj4gICAgICAqIGlldGYtc3lzdGVtDQo+ ICAgICAgKiBpZXRmLXlhbmctdHlwZXMNCj4gDQo+ICAgIElmIGFsbCBnb2VzIHRvIHBsYW4sIHRo ZSBUUi0zODMgbW9kdWxlcyB3aWxsIGJlIHB1Ymxpc2hlZCBpbiBNYXJjaA0KPiAgICAyMDE3LCBi dXQgeW91IGNhbiBzZWUgdGhhdCB0aGVyZSBpcyBhIGRlcGVuZGVuY3kgb24gaWFuYS1lbnRpdHkg YW5kDQo+ICAgIGlldGYtaGFyZHdhcmUsIHdoaWNoIGFyZSBjdXJyZW50bHkgdGFrZW4gZnJvbQ0K PiAgICBkcmFmdC1pZXRmLW5ldG1vZC1lbnRpdHktMDEuIFdlIHdpbGwgcG90ZW50aWFsbHkgbmVl ZCB0byByZWZlcmVuY2UNCj4gICAgZHJhZnQgdmVyc2lvbnM/DQo+IA0KPiBJIGhvcGUgd2UgYWxs IGFncmVlIHRoYXQgcmVmZXJlbmNpbmcgYSBkcmFmdCB2ZXJzaW9uIGlzIG5vdCBpZGVhbC4NCj4g V291bGQgaXQgYmUgcG9zc2libGUgdG8gcHJvZ3Jlc3MgZHJhZnQtaWV0Zi1uZXRtb2QtZW50aXR5 LCBhbmQNCj4gdGhlcmVmb3JlIGhlbHAgb3VyIEJCRiBmcmllbmRzPw0KDQpXaGF0IHdlIG5lZWQg aXMgYSBXRyBkaXNjdXNzaW9uIG9uIHRoZSBvcGVuIGlzc3Vlcy4gIEkgd2lsbCBzZW5kIG91dA0K b25lIG1haWwgcGVyIG9wZW4gaXNzdWUuDQoNCj4gSXMgdGhlIE1hcmNoIGRlYWRsaW5lIGEgcmVh Y2hhYmxlIGdvYWw/DQoNCkV2ZW4gaWYgd2Ugc3RhcnRlZCBXR0xDIHRvZGF5IHdlIHdvdWxkIG5v dCBoYXZlIGFuIFJGQyBwdWJsaXNoZWQgaW4NCk1hcmNoLi4uDQoNCg0KL21hcnRpbg0K From nobody Thu Dec 15 06:18:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53760129FCF; Thu, 15 Dec 2016 06:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WywW12VoXJz3; Thu, 15 Dec 2016 06:18:36 -0800 (PST) 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 22842129FD0; Thu, 15 Dec 2016 06:16:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1564; q=dns/txt; s=iport; t=1481811406; x=1483021006; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=6VcrIWYEsKnOdFqDHNxJhZmH1BstYVgcus5NTqt+ns8=; b=lXS1o3X3UY+f6P1pdwUXTdmts5a5oGQL6xdhdiQrqptiGq4NQKNGLpa/ Le3nhz9YRRC+HyH/PF5qXFycmhRBjeNpH2zdBD4zDC7vMq0qE2dY39MqE /wS59MT0BqB3t7qRFJ0uNMcvfkRVR+6LE3MS/PK71BUEWAQGxcZbdcjPG s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AAAGpVJY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAXkuWI1Oc5VklQmCCSqFeAKCQxQBAgEBAQEBAQFiKIR?= =?us-ascii?q?pAQEEEhEPAQU8BRAJAg4KAgImAgJXBg0GAgEBHohJDot4j1UBjXaCKIsPAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARoFgQuFK4F9CIJUhCMBAYMfgl0BBJpshlGKYYochi+?= =?us-ascii?q?KL4NlhA8fN4EBEw6Fdz00hgqCLgEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,352,1477958400"; d="scan'208";a="647911511" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Dec 2016 14:16:41 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uBFEGf5f018075; Thu, 15 Dec 2016 14:16:41 GMT To: Martin Bjorklund References: <20161215.145729.704925239472686261.mbj@tail-f.com> From: Benoit Claise Message-ID: Date: Thu, 15 Dec 2016 15:16:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161215.145729.704925239472686261.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: timothy.carey@nokia.com, draft-ietf-netmod-entity@ietf.org, joey.boyd@adtran.com, netmod@ietf.org, david.sinicrope@ericsson.com Subject: Re: [netmod] BBF work depending on draft-ietf-netmod-entity-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 14:18:39 -0000 On 12/15/2016 2:57 PM, Martin Bjorklund wrote: > Benoit Claise wrote: >> Dear draft-ietf-netmod-entity authors, >> >> As mentioned by Tim Carey during the last IETF meeting, BBF work >> depends on the draft-ietf-netmod-entity-01. >> >> Message from BBF: >> >> We are now in the final stages of reviewing “TR-383” “Common YANG” >> modules that have the following dependencies: >> >> * iana-entity >> * iana-if-type >> * ietf-hardware >> * ietf-inet-types >> * ietf-interfaces >> * ietf-system >> * ietf-yang-types >> >> If all goes to plan, the TR-383 modules will be published in March >> 2017, but you can see that there is a dependency on iana-entity and >> ietf-hardware, which are currently taken from >> draft-ietf-netmod-entity-01. We will potentially need to reference >> draft versions? >> >> I hope we all agree that referencing a draft version is not ideal. >> Would it be possible to progress draft-ietf-netmod-entity, and >> therefore help our BBF friends? > What we need is a WG discussion on the open issues. I will send out > one mail per open issue. > >> Is the March deadline a reachable goal? > Even if we started WGLC today we would not have an RFC published in > March... That's a very pessimistic view. https://datatracker.ietf.org/doc/rfc8022/history/ 2016-10-20, IETF WG state changed to "Submitted to IESG for Publication" 2016-11-10, RFC 8022 published Regards, Benoit > > > /martin From nobody Thu Dec 15 06:56:42 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC611296B7 for ; Thu, 15 Dec 2016 06:56:41 -0800 (PST) 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 XwRWETx1yZht for ; Thu, 15 Dec 2016 06:56:40 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 CD03F12969E for ; Thu, 15 Dec 2016 06:56:39 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id n204so58845364qke.2 for ; Thu, 15 Dec 2016 06:56:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:message-id:date:to:mime-version; bh=ReF3uYVOqczDSha+09vui4aySeHbSPyRCfvhHIf1+hI=; b=YNpMSXfOgvAT1ROS1S86NLzmyg8zMWVacRakattlgq+d71E/e1Wi7TftJWlyhChHrS H+re1ODjGH7OgmF+/mSJABKaeNU7j2HeXZ9x+vC+3MvkKhOFAukH49XgztR54jBfp+UR 82t5cUxvE1mMxu43bg2mGBiZ/ArTYcos9klpK9j9B3HwW/UomuAUYSv2qd1x6ObISmi6 4/l/E+9B1oSJ04A5qWaZq9QnAAzzuV8BwdpcR0tDc6g/KoEOBambcCjI/BYWRdRLtUk7 Uw6tjFHpWB015YKr6a1qVKt9iI1ozKjO63SVcikkzOlPO8q7MEXrKofyxmnqlJCcIluj JWkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=ReF3uYVOqczDSha+09vui4aySeHbSPyRCfvhHIf1+hI=; b=FhJAGs6Zo1dp4bgvlAHbnxOQWe+/I1Ah7UeKqai+d7a3SdZiGtzXCIJMGSjCV1y0kI C0bTZ9nfPO71S42+3wAB0LXppFgcwykyxk4MUiXyRdCneOMGStCc04MQsZ2JICfe2CAh bkh5j/KlGnGxTex7TS95FjlOPtAXKI7LKKYz/j//LftTTmeIWYJrhfOopWCyJ7RtPhSF DfIqK2HgvgOeJTijlWpfVBgpHYIFcePFXteJIhk3g3il4DZsbfegqp1FRQZ0XO8/60KO E4I1tfFzEhgstC+LRRem8hDs0GsfaRVLOE25YkEfNFyOoHVmq9ORKlfsCiyDQbDu2Pdt Wj2Q== X-Gm-Message-State: AIkVDXJfeY9lQ228hL2kVqCxK5AcdYGnTlsZFQg+f1hsr2FRIVU+JO14ocCrzGVwxe1ftA== X-Received: by 10.55.184.3 with SMTP id i3mr1483082qkf.7.1481813798824; Thu, 15 Dec 2016 06:56:38 -0800 (PST) Received: from [10.0.1.12] (c-75-68-179-118.hsd1.ma.comcast.net. [75.68.179.118]) by smtp.gmail.com with ESMTPSA id h43sm1181441qth.29.2016.12.15.06.56.38 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 15 Dec 2016 06:56:38 -0800 (PST) From: Dean Bogdanovic Content-Type: multipart/alternative; boundary="Apple-Mail=_D01BFF77-1AFA-4120-99CF-88C44CE5B741" Message-Id: Date: Thu, 15 Dec 2016 09:56:37 -0500 To: NetMod WG Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [netmod] Applied data store clarification in draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 14:56:41 -0000 --Apple-Mail=_D01BFF77-1AFA-4120-99CF-88C44CE5B741 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Authors, Need some clarification about applied data store In the draft, applied data store can contain data from=20 This data can come from several sources; from , from dynamic = configuration protocols (e.g., DHCP), or from control-plane datastore. The control-plane stores are not well clarified in my opinion The model foresees control-plane datastores that are by definition not part of the persistent configuration of a device. In some contexts, these have been termed ephemeral datastores since the information is ephemeral, i.e., lost upon reboot. The control-plane datastores interact with the rest of the system through the or datastores, depending on the type of data they contain. Note that the ephemeral datastore discussed in I2RS documents maps to a control-plane datastore in the revised datastore model described here. The other issue I have is with that control-plane data stores are shown = connected to applied and operational-state. Which control plane data = stores are directly influencing operational-state?=20 Also, in the diagram control-plane protocols are connected only to = operational-state data store. But isn=E2=80=99t the previous state = exchanged via control plane protocols taken into account when validating = data that is copied into applied data store? Thx Dean= --Apple-Mail=_D01BFF77-1AFA-4120-99CF-88C44CE5B741 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Authors,

Need some clarification about applied data store

In the draft, applied = data store can contain data from 

This data can come from = several sources; from  <intended>, from dynamic configuration = protocols (e.g., DHCP), or from control-plane datastore.

The control-plane stores = are not well clarified in my opinion

 The model foresees control-plane datastores =
that are by definition
   not part of the persistent configuration of a device.  In some
   contexts, these have been termed ephemeral datastores since the
   information is ephemeral, i.e., lost upon reboot.  The control-plane
   datastores interact with the rest of the system through the =
<applied>
   or <operational-state> datastores, depending on the type of =
data they
   contain.  Note that the ephemeral datastore discussed in I2RS
   documents maps to a control-plane datastore in the revised datastore
   model described here.

The other issue I have is with = that control-plane data stores are shown connected to applied and = operational-state. Which control plane data stores are directly = influencing operational-state? 

Also, in the diagram control-plane = protocols are connected only to operational-state data store. But = isn=E2=80=99t the previous state exchanged via control plane protocols = taken into account when validating data that is copied into applied data = store?

Thx

Dean
= --Apple-Mail=_D01BFF77-1AFA-4120-99CF-88C44CE5B741-- From nobody Thu Dec 15 07:01:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A315D129FF2 for ; Thu, 15 Dec 2016 07:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 R4SE2jmpl1gr for ; Thu, 15 Dec 2016 07:01:50 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 455C0129FB6 for ; Thu, 15 Dec 2016 07:01:12 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 506151AE0477 for ; Thu, 15 Dec 2016 16:01:11 +0100 (CET) Date: Thu, 15 Dec 2016 16:01:10 +0100 (CET) Message-Id: <20161215.160110.1071208720534123811.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund 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: [netmod] draft-ietf-netmod-entity issue #11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 15:01:56 -0000 Hi, Issue https://github.com/netmod-wg/entity/issues/11 RFC 6933 introduced a new compliance level for constrained resources - entity4CRCompliance. Do we need a corresponding feature? In YANG, we cannot to the equivalent of compliance levels, so we would need to mark all nodes with some optional feature, except the few nodes that a constrained device would implement. OTOH, most nodes are already optional and config false. So a constrained server that doesn't know the serial number for example could just no return it. There is one catch though; the current text, copied from the MIB, says e.g.: If the manufacturer name string associated with the physical component is unknown to the server, then this node will contain a zero-length string. Maybe we should change this so that the object isn't returned at all instead of returning a zero-length string. /martin From nobody Thu Dec 15 07:04:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B767129FD7 for ; Thu, 15 Dec 2016 07:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 z7rHQOI2RHUj for ; Thu, 15 Dec 2016 07:03:53 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 27C941296F2 for ; Thu, 15 Dec 2016 07:03:43 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 56CC31AE018B for ; Thu, 15 Dec 2016 16:03:42 +0100 (CET) Date: Thu, 15 Dec 2016 16:03:40 +0100 (CET) Message-Id: <20161215.160340.1681037049004689530.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund 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: [netmod] draft-ietf-netmod-entity issue #12 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 15:03:55 -0000 Hi, Issue https://github.com/netmod-wg/entity/issues/12 entConfigChange is useful but maybe covered by netconf-config-change notification, or pub/sub. it is also a bad name, since it fires when the opstate changes... Need to think about which notifs to define. Currently we have three notifications: harwdare-state-change hardware-state-oper-enabled hardware-state-oper-disabled Jason Sterne also made the observation on the ML that maybe pub/sub is a better mechanism for these simple notifs. /martin From nobody Thu Dec 15 07:15:07 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD261296C0 for ; Thu, 15 Dec 2016 07:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 1Ka1QVI-FjEh for ; Thu, 15 Dec 2016 07:15:02 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3B983126D74 for ; Thu, 15 Dec 2016 07:15:02 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 5AED91AE018B for ; Thu, 15 Dec 2016 16:15:01 +0100 (CET) Date: Thu, 15 Dec 2016 16:15:00 +0100 (CET) Message-Id: <20161215.161500.22404400342814101.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund 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: [netmod] draft-ietf-netmod-entity issue #13 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 15:15:05 -0000 Hi, Issue https://github.com/netmod-wg/entity/issues/13 Should the model support pre-configuration of hardware components? The current model supports pre-configuration of components provided the operator knows the name of the component to be installed. A more useful model would use the parent component, class, and parent-rel-pos as identification. If the system detects a component and there is configuration available for the parent component, class, and parent-rel-pos then the system would instatiate the component with the provided name, and optionally additional parameters. See also various mails from Timothy Carey and Bart Bogaert on this issue. Personally, I think that we should add these nodes, since the ML comments indicated that pre configuration is pretty useful. /martin From nobody Thu Dec 15 07:21:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D149C1296CA for ; Thu, 15 Dec 2016 07:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 5I_HIAtj4Xfd for ; Thu, 15 Dec 2016 07:21:40 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D218129645 for ; Thu, 15 Dec 2016 07:21:35 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 915D86DC; Thu, 15 Dec 2016 16:21:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id EwWPaBQ_1bGC; Thu, 15 Dec 2016 16:21:33 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 15 Dec 2016 16:21:33 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D0602007A; Thu, 15 Dec 2016 16:21:33 +0100 (CET) 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 cVkEcjVGJ2By; Thu, 15 Dec 2016 16:21:32 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 72FF920077; Thu, 15 Dec 2016 16:21:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A96DA3DBC696; Thu, 15 Dec 2016 16:21:31 +0100 (CET) Date: Thu, 15 Dec 2016 16:21:31 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20161215152130.GA7351@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20161215.160110.1071208720534123811.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161215.160110.1071208720534123811.mbj@tail-f.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-entity issue #11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 15:21:43 -0000 I do not think the goal should be to emulate SMIv2 compliance levels using features. So I propose to do nothing about entity4CRCompliance. The other question (which should perhaps have been a separate issue) is whether non-existing values are indicated by zero-length strings or non-existing objects. I think in general we prefer to simply not report those objects in the YANG world. If so, I am not sure whether the goal to not depart too much from the ENTITY-MIB overrules this. Note that there are a couple of objects where non-existing values lead to zero-length string or other special values. (The 'alias' description is kind of interesting - the server may set the value of this node to a locally unique value; entPhysicalAlias says something different, namely On the first instantiation ... is set to the zero-length string.) Looking at the YANG fragment, I am also not sure how useful it is to carry the 32 'something' restriction forward. Note that 32 means unicode characters in YANG but space of the UTF-8 encoding of characters for SMIv2 (since it all ends up being a restriction for the OCTET STRING). Perhaps this deserves a feature, namely, whether an implementation supports flexible names or restricts names according to the SMIv2 ENTITY-MIB rules. /js On Thu, Dec 15, 2016 at 04:01:10PM +0100, Martin Bjorklund wrote: > Hi, > > Issue https://github.com/netmod-wg/entity/issues/11 > > RFC 6933 introduced a new compliance level for constrained resources > - entity4CRCompliance. Do we need a corresponding feature? > > In YANG, we cannot to the equivalent of compliance levels, so we would > need to mark all nodes with some optional feature, except the few > nodes that a constrained device would implement. > > OTOH, most nodes are already optional and config false. So a > constrained server that doesn't know the serial number for example > could just no return it. There is one catch though; the current text, > copied from the MIB, says e.g.: > > If the manufacturer name string associated with the > physical component is unknown to the server, then this > node will contain a zero-length string. > > Maybe we should change this so that the object isn't returned at all > instead of returning a zero-length string. > > > > /martin > > _______________________________________________ > 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 Dec 15 07:25:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4EEA1295C8 for ; Thu, 15 Dec 2016 07:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 EfdO6I1_5HlJ for ; Thu, 15 Dec 2016 07:25:01 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C080F1296CF for ; Thu, 15 Dec 2016 07:24:42 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id CE3CE1AE018B; Thu, 15 Dec 2016 16:24:41 +0100 (CET) Date: Thu, 15 Dec 2016 16:24:40 +0100 (CET) Message-Id: <20161215.162440.325342744038767189.mbj@tail-f.com> To: ivandean@gmail.com 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=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Applied data store clarification in draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 15:25:08 -0000 SGksDQoNCkRlYW4gQm9nZGFub3ZpYyA8aXZhbmRlYW5AZ21haWwuY29tPiB3cm90ZToNCj4gQXV0 aG9ycywNCj4gDQo+IE5lZWQgc29tZSBjbGFyaWZpY2F0aW9uIGFib3V0IGFwcGxpZWQgZGF0YSBz dG9yZQ0KPiANCj4gSW4gdGhlIGRyYWZ0LCBhcHBsaWVkIGRhdGEgc3RvcmUgY2FuIGNvbnRhaW4g ZGF0YSBmcm9tIA0KPiANCj4gVGhpcyBkYXRhIGNhbiBjb21lIGZyb20gc2V2ZXJhbCBzb3VyY2Vz OyBmcm9tIDxpbnRlbmRlZD4sIGZyb20gZHluYW1pYw0KPiBjb25maWd1cmF0aW9uIHByb3RvY29s cyAoZS5nLiwgREhDUCksIG9yIGZyb20gY29udHJvbC1wbGFuZSBkYXRhc3RvcmUuDQo+IA0KPiBU aGUgY29udHJvbC1wbGFuZSBzdG9yZXMgYXJlIG5vdCB3ZWxsIGNsYXJpZmllZCBpbiBteSBvcGlu aW9uDQo+IA0KPiAgVGhlIG1vZGVsIGZvcmVzZWVzIGNvbnRyb2wtcGxhbmUgZGF0YXN0b3JlcyB0 aGF0IGFyZSBieSBkZWZpbml0aW9uDQo+ICAgIG5vdCBwYXJ0IG9mIHRoZSBwZXJzaXN0ZW50IGNv bmZpZ3VyYXRpb24gb2YgYSBkZXZpY2UuICBJbiBzb21lDQo+ICAgIGNvbnRleHRzLCB0aGVzZSBo YXZlIGJlZW4gdGVybWVkIGVwaGVtZXJhbCBkYXRhc3RvcmVzIHNpbmNlIHRoZQ0KPiAgICBpbmZv cm1hdGlvbiBpcyBlcGhlbWVyYWwsIGkuZS4sIGxvc3QgdXBvbiByZWJvb3QuICBUaGUgY29udHJv bC1wbGFuZQ0KPiAgICBkYXRhc3RvcmVzIGludGVyYWN0IHdpdGggdGhlIHJlc3Qgb2YgdGhlIHN5 c3RlbSB0aHJvdWdoIHRoZSA8YXBwbGllZD4NCj4gICAgb3IgPG9wZXJhdGlvbmFsLXN0YXRlPiBk YXRhc3RvcmVzLCBkZXBlbmRpbmcgb24gdGhlIHR5cGUgb2YgZGF0YSB0aGV5DQo+ICAgIGNvbnRh aW4uICBOb3RlIHRoYXQgdGhlIGVwaGVtZXJhbCBkYXRhc3RvcmUgZGlzY3Vzc2VkIGluIEkyUlMN Cj4gICAgZG9jdW1lbnRzIG1hcHMgdG8gYSBjb250cm9sLXBsYW5lIGRhdGFzdG9yZSBpbiB0aGUg cmV2aXNlZCBkYXRhc3RvcmUNCj4gICAgbW9kZWwgZGVzY3JpYmVkIGhlcmUuDQo+IA0KPiBUaGUg b3RoZXIgaXNzdWUgSSBoYXZlIGlzIHdpdGggdGhhdCBjb250cm9sLXBsYW5lIGRhdGEgc3RvcmVz IGFyZQ0KPiBzaG93biBjb25uZWN0ZWQgdG8gYXBwbGllZCBhbmQgb3BlcmF0aW9uYWwtc3RhdGUu IFdoaWNoIGNvbnRyb2wgcGxhbmUNCj4gZGF0YSBzdG9yZXMgYXJlIGRpcmVjdGx5IGluZmx1ZW5j aW5nIG9wZXJhdGlvbmFsLXN0YXRlPw0KDQpXZSB3YW50ZWQgdG8gYWxsb3cgZm9yIG90aGVyIHRv LWJlLWRlZmluZWQgZGF0YSBzdG9yZXMgYnkgc2hvd2luZw0Kd2hlcmUgdGhleSBjYW4gZml0IGlu dG8gdGhlIGFyY2hpdGVjdHVyZS4gIFdoZW4vaWYgc3VjaCBhIGRhdGEgc3RvcmUNCmlzIGRlZmlu ZWQsIGl0IGNhbiByZWxhdGUgdG8gdGhpcyBhcmNoaXRlY3R1cmUgYW5kIGV4cGxhaW4gZXhhY3Rs eSBob3cNCml0IGZpdHMgaW4gYW5kIGhvdyBpdCBhZmZlY3RzIGFwcGxpZWQgY29uZmlnIGFuZC9v ciBvcGVyYXRpb25hbCBzdGF0ZS4NCg0KPiBBbHNvLCBpbiB0aGUgZGlhZ3JhbSBjb250cm9sLXBs YW5lIHByb3RvY29scyBhcmUgY29ubmVjdGVkIG9ubHkgdG8NCj4gb3BlcmF0aW9uYWwtc3RhdGUg ZGF0YSBzdG9yZS4gQnV0IGlzbuKAmXQgdGhlIHByZXZpb3VzIHN0YXRlIGV4Y2hhbmdlZA0KPiB2 aWEgY29udHJvbCBwbGFuZSBwcm90b2NvbHMgdGFrZW4gaW50byBhY2NvdW50IHdoZW4gdmFsaWRh dGluZyBkYXRhDQo+IHRoYXQgaXMgY29waWVkIGludG8gYXBwbGllZCBkYXRhIHN0b3JlPw0KDQpX aGVuIHlvdSBzYXkgImRhdGEgdGhhdCBpcyBjb3BpZWQgaW50byBhcHBsaWVkIiwgYXJlIHlvdSBy ZWZlcnJpbmcgdG8NCnRoZSBhcnJvdyBiZXR3ZWVuIGludGVuZGVkIGFuZCBhcHBsaWVkPw0KDQpU aGUgYW5zd2VyIGlzIHRoYXQgdGhlIGFycm93cyBzaG93IGRhdGEgZmxvdy4gIFRoZSBtZWNoYW5p c20gdGhhdA0KY29waWVzIGRhdGEgZnJvbSBpbnRlbmRlZCB0byBhcHBsaWVkIHdpbGwgc3VyZWx5 IGhhdmUgdG8gY2hlY2sNCm9wZXJhdGlvbmFsIHN0YXRlIGFuZCBtYXliZSBwaHlzaWNhbCByZXNv dXJjZXMgaW4gcm9kZXIgdG8gZG8gaXRzIGpvYi4NCg0KDQovbWFydGluDQo= From nobody Thu Dec 15 07:31:22 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AAE12968A for ; Thu, 15 Dec 2016 07:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 n5NY67FZYow2 for ; Thu, 15 Dec 2016 07:31:14 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED791296D4 for ; Thu, 15 Dec 2016 07:31:12 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 5E76B1AE018B; Thu, 15 Dec 2016 16:31:11 +0100 (CET) Date: Thu, 15 Dec 2016 16:31:10 +0100 (CET) Message-Id: <20161215.163110.1419490157367794869.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20161215152130.GA7351@elstar.local> References: <20161215.160110.1071208720534123811.mbj@tail-f.com> <20161215152130.GA7351@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-entity issue #11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 15:31:21 -0000 Juergen Schoenwaelder wrote: > I do not think the goal should be to emulate SMIv2 compliance levels > using features. So I propose to do nothing about entity4CRCompliance. Ok. > The other question (which should perhaps have been a separate issue) > is whether non-existing values are indicated by zero-length strings or > non-existing objects. I think in general we prefer to simply not > report those objects in the YANG world. I agree. > If so, I am not sure whether > the goal to not depart too much from the ENTITY-MIB overrules > this. Note that there are a couple of objects where non-existing > values lead to zero-length string or other special values. I think this "depature" is fine. > (The > 'alias' description is kind of interesting - the server may set the > value of this node to a locally unique value; entPhysicalAlias says > something different, namely On the first instantiation ... is set to > the zero-length string.) The MIB says that the object is set to a zero-length string OR a locally unique value. After this a manager can change this value. So I believe this semantics is reflected in the YANG model (esp. if we make it clear that a zero-length string in the MIB maps to a non-existing node in YANG). > Looking at the YANG fragment, I am also not sure how useful it is to > carry the 32 'something' restriction forward. Note that 32 means > unicode characters in YANG but space of the UTF-8 encoding of > characters for SMIv2 (since it all ends up being a restriction for the > OCTET STRING). Perhaps this deserves a feature, namely, whether an > implementation supports flexible names or restricts names according to > the SMIv2 ENTITY-MIB rules. Hmm, this cannot easily be done with a YANG feature, but maybe we can simply change these strings to unrestricted strings, and then state that a server MAY impose additional restrictions on valid values? /martin > /js > > On Thu, Dec 15, 2016 at 04:01:10PM +0100, Martin Bjorklund wrote: > > Hi, > > > > Issue https://github.com/netmod-wg/entity/issues/11 > > > > RFC 6933 introduced a new compliance level for constrained resources > > - entity4CRCompliance. Do we need a corresponding feature? > > > > In YANG, we cannot to the equivalent of compliance levels, so we would > > need to mark all nodes with some optional feature, except the few > > nodes that a constrained device would implement. > > > > OTOH, most nodes are already optional and config false. So a > > constrained server that doesn't know the serial number for example > > could just no return it. There is one catch though; the current text, > > copied from the MIB, says e.g.: > > > > If the manufacturer name string associated with the > > physical component is unknown to the server, then this > > node will contain a zero-length string. > > > > Maybe we should change this so that the object isn't returned at all > > instead of returning a zero-length string. > > > > > > > > /martin > > > > _______________________________________________ > > 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 Dec 15 07:47:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA171296F9 for ; Thu, 15 Dec 2016 07:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 luYA38KpblQy for ; Thu, 15 Dec 2016 07:47:38 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CDE61296CD for ; Thu, 15 Dec 2016 07:47:38 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E2CC46E4; Thu, 15 Dec 2016 16:47:36 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id fhEVOS4U7Tgs; Thu, 15 Dec 2016 16:47:36 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 15 Dec 2016 16:47:36 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9DE4020077; Thu, 15 Dec 2016 16:47:36 +0100 (CET) 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 d0cIuuu29SpL; Thu, 15 Dec 2016 16:47:35 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CF6C520075; Thu, 15 Dec 2016 16:47:35 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BD4453DBC77D; Thu, 15 Dec 2016 16:47:35 +0100 (CET) Date: Thu, 15 Dec 2016 16:47:35 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20161215154735.GA7432@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20161215.160110.1071208720534123811.mbj@tail-f.com> <20161215152130.GA7351@elstar.local> <20161215.163110.1419490157367794869.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161215.163110.1419490157367794869.mbj@tail-f.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-entity issue #11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 15:47:40 -0000 On Thu, Dec 15, 2016 at 04:31:10PM +0100, Martin Bjorklund wrote: > > Looking at the YANG fragment, I am also not sure how useful it is to > > carry the 32 'something' restriction forward. Note that 32 means > > unicode characters in YANG but space of the UTF-8 encoding of > > characters for SMIv2 (since it all ends up being a restriction for the > > OCTET STRING). Perhaps this deserves a feature, namely, whether an > > implementation supports flexible names or restricts names according to > > the SMIv2 ENTITY-MIB rules. > > Hmm, this cannot easily be done with a YANG feature, but maybe we can > simply change these strings to unrestricted strings, and then state > that a server MAY impose additional restrictions on valid values? Yes, I would go towards less restrictions in general with a caveat that systems implementing a direct mapping to the ENTITY-MIB MAY impose additional length restrictions on valid values. /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 Dec 15 07:58:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25068129D7A for ; Thu, 15 Dec 2016 07:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 vCvdxrXnmzdj for ; Thu, 15 Dec 2016 07:58:31 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6083C1298D5 for ; Thu, 15 Dec 2016 07:58:31 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 310C16CF; Thu, 15 Dec 2016 16:58:30 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id UTCjad_Ct5Hr; Thu, 15 Dec 2016 16:58:29 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 15 Dec 2016 16:58:29 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D5C6F20077; Thu, 15 Dec 2016 16:58:29 +0100 (CET) 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 pD92P47Le5yX; Thu, 15 Dec 2016 16:58:29 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5CCCC20075; Thu, 15 Dec 2016 16:58:29 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 46D363DBC838; Thu, 15 Dec 2016 16:58:29 +0100 (CET) Date: Thu, 15 Dec 2016 16:58:29 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20161215155829.GB7432@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20161215.160340.1681037049004689530.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161215.160340.1681037049004689530.mbj@tail-f.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-entity issue #12 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 15:58:33 -0000 On Thu, Dec 15, 2016 at 04:03:40PM +0100, Martin Bjorklund wrote: > Hi, > > Issue https://github.com/netmod-wg/entity/issues/12 > > entConfigChange is useful but maybe covered by netconf-config-change > notification, or pub/sub. it is also a bad name, since it fires when > the opstate changes... Need to think about which notifs to define. > > Currently we have three notifications: > > harwdare-state-change > hardware-state-oper-enabled > hardware-state-oper-disabled It seems harwdare-state-change is not netconf-config-change. The harwdare-state-change indicates that the '/hardware-state/component' list has changed, i.e., operational state has changed not config. (It is always important to read the descriptions and not to draw wrong conclusions from the fact the SNMP notification was called entConfigChange.) > Jason Sterne also made the observation on the ML that maybe pub/sub is > a better mechanism for these simple notifs. Not sure what 'better' means. I assume that generating these specific notifications can likely be done way more efficiently than doing the same via a pub/sub interface unless the pub/sub backend code is really really smart. That said, I would not be surprised if application writers will use pub/sub for everything because the hammer makes everything look like a nail. /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 Dec 15 08:09:13 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6A31296CD for ; Thu, 15 Dec 2016 08:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 QRgm-M-pm8Zj for ; Thu, 15 Dec 2016 08:09:09 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 333A91279EB for ; Thu, 15 Dec 2016 08:09:09 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 12D1E1AE018B; Thu, 15 Dec 2016 17:09:08 +0100 (CET) Date: Thu, 15 Dec 2016 17:09:06 +0100 (CET) Message-Id: <20161215.170906.2138860999284264918.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20161215155829.GB7432@elstar.local> References: <20161215.160340.1681037049004689530.mbj@tail-f.com> <20161215155829.GB7432@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-entity issue #12 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 16:09:11 -0000 Juergen Schoenwaelder wrote: > On Thu, Dec 15, 2016 at 04:03:40PM +0100, Martin Bjorklund wrote: > > Hi, > > > > Issue https://github.com/netmod-wg/entity/issues/12 > > > > entConfigChange is useful but maybe covered by netconf-config-change > > notification, or pub/sub. it is also a bad name, since it fires when > > the opstate changes... Need to think about which notifs to define. > > > > Currently we have three notifications: > > > > harwdare-state-change > > hardware-state-oper-enabled > > hardware-state-oper-disabled > > It seems harwdare-state-change is not netconf-config-change. The > harwdare-state-change indicates that the '/hardware-state/component' > list has changed, i.e., operational state has changed not config. (It > is always important to read the descriptions and not to draw wrong > conclusions from the fact the SNMP notification was called > entConfigChange.) Yes. > > Jason Sterne also made the observation on the ML that maybe pub/sub is > > a better mechanism for these simple notifs. > > Not sure what 'better' means. I assume that generating these specific > notifications can likely be done way more efficiently than doing the > same via a pub/sub interface unless the pub/sub backend code is really > really smart. Yes, I share this concern. I don't think it would be a good idea to remove all notifications and just provide state nodes, and then assume that clients write clever filters in order to get the notificaitons they want. However, in this particular case, the notifications hardware-state-oper-enabled and hardware-state-oper-disabled are simple in the sense that they defined to be generated when a certain node changes its value. > That said, I would not be surprised if application > writers will use pub/sub for everything because the hammer makes > everything look like a nail. We'll see. Specific notifications are often designed to deliver related information, and this might not be to easy to do with a generic solution like pub/sub. /martin From nobody Thu Dec 15 08:14:45 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1994B129D7A for ; Thu, 15 Dec 2016 08:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 kzwt2I5ORJgi for ; Thu, 15 Dec 2016 08:14:40 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 249291299AB for ; Thu, 15 Dec 2016 08:14:40 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E95DF6BC; Thu, 15 Dec 2016 17:14:38 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id h4E_VgQR0Bds; Thu, 15 Dec 2016 17:14:38 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 15 Dec 2016 17:14:38 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B2BA20077; Thu, 15 Dec 2016 17:14:38 +0100 (CET) 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 HI3uXNDJhfmn; Thu, 15 Dec 2016 17:14:38 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A11E20075; Thu, 15 Dec 2016 17:14:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5BBB63DBC9FF; Thu, 15 Dec 2016 17:14:37 +0100 (CET) Date: Thu, 15 Dec 2016 17:14:36 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20161215161434.GD7432@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20161215.161500.22404400342814101.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161215.161500.22404400342814101.mbj@tail-f.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-entity issue #13 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 16:14:42 -0000 On Thu, Dec 15, 2016 at 04:15:00PM +0100, Martin Bjorklund wrote: > Hi, > > Issue https://github.com/netmod-wg/entity/issues/13 > > Should the model support pre-configuration of hardware components? > The current model supports pre-configuration of components provided > the operator knows the name of the component to be installed. A more > useful model would use the parent component, class, and > parent-rel-pos as identification. If the system detects a component > and there is configuration available for the parent component, > class, and parent-rel-pos then the system would instatiate the > component with the provided name, and optionally additional > parameters. > > See also various mails from Timothy Carey and Bart Bogaert on this > issue. > > Personally, I think that we should add these nodes, since the ML > comments indicated that pre configuration is pretty useful. > I am still not sure what exactly this will do. I have been looking at . I am provisioning mfg-name (Preferred value is the manufacturer name string actually printed on the component itself (if present).) but all I have is that something of a certain expected class has been plugged into a certain position of the parent container. Also note that mfg-name scopes comparisons of other properties. I would have similar questions concerning the model-name; how can a provisioning system predict the 'vendor-specific model name identifier'? Or is the whole idea that if I plug something that does not match, the component is left in a special state (which one)? If this is the intention, then this needs to be spelled out clearly somewhere. /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 Dec 15 08:26:15 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD782129874 for ; Thu, 15 Dec 2016 08:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 zVE_cAVkNOIX for ; Thu, 15 Dec 2016 08:26:12 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 12AEB1296C0 for ; Thu, 15 Dec 2016 08:26:12 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 017541AE018B; Thu, 15 Dec 2016 17:26:10 +0100 (CET) Date: Thu, 15 Dec 2016 17:26:09 +0100 (CET) Message-Id: <20161215.172609.1950541994949692852.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20161215161434.GD7432@elstar.local> References: <20161215.161500.22404400342814101.mbj@tail-f.com> <20161215161434.GD7432@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-entity issue #13 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 16:26:14 -0000 Juergen Schoenwaelder wrote: > On Thu, Dec 15, 2016 at 04:15:00PM +0100, Martin Bjorklund wrote: > > Hi, > > > > Issue https://github.com/netmod-wg/entity/issues/13 > > > > Should the model support pre-configuration of hardware components? > > The current model supports pre-configuration of components provided > > the operator knows the name of the component to be installed. A more > > useful model would use the parent component, class, and > > parent-rel-pos as identification. If the system detects a component > > and there is configuration available for the parent component, > > class, and parent-rel-pos then the system would instatiate the > > component with the provided name, and optionally additional > > parameters. > > > > See also various mails from Timothy Carey and Bart Bogaert on this > > issue. > > > > Personally, I think that we should add these nodes, since the ML > > comments indicated that pre configuration is pretty useful. > > > > I am still not sure what exactly this will do. I have been looking at > . > I am provisioning mfg-name (Preferred value is the manufacturer name > string actually printed on the component itself (if present).) but all > I have is that something of a certain expected class has been plugged > into a certain position of the parent container. Also note that > mfg-name scopes comparisons of other properties. I would have similar > questions concerning the model-name; how can a provisioning system > predict the 'vendor-specific model name identifier'? Or is the whole > idea that if I plug something that does not match, the component is > left in a special state (which one)? If this is the intention, then > this needs to be spelled out clearly somewhere. The current model works fine if the user looks into the state list and finds a component that he wants to configure. To do this, he uses the name of the component as found in the state list, and writes the config for this component. The current model also supports pre-configuration if the user somehow can predict the name of a component to-be-inserted. In this case he can write the config, and when the component is plugged in, the system will derive the component name, and check the config list for this name. This is a fragile model. In the proposed model, the user can provide configuration for a tuple (parent, class, parent-rel-pos). If the server finds a component in the state list (or such a component is later plugged in), then the corresponding config leafs are used for the state of this component (including the name). If you plug in something that doesn't match the config list, well that just means that nothing has been configured for this component, and the system will populate the state list accordingly. /martin From nobody Thu Dec 15 08:30:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C346129A5D for ; Thu, 15 Dec 2016 08:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 Nn05rW1prDMi for ; Thu, 15 Dec 2016 08:30:30 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92EEA129702 for ; Thu, 15 Dec 2016 08:30:30 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 697886DC; Thu, 15 Dec 2016 17:30:29 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id a2CK1mRCXd1K; Thu, 15 Dec 2016 17:30:28 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 15 Dec 2016 17:30:28 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D319820077; Thu, 15 Dec 2016 17:30:28 +0100 (CET) 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 U3_7lmmSHRzC; Thu, 15 Dec 2016 17:30:28 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 285BB20075; Thu, 15 Dec 2016 17:30:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0AB073DBCC10; Thu, 15 Dec 2016 17:30:28 +0100 (CET) Date: Thu, 15 Dec 2016 17:30:27 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20161215163027.GA7632@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20161215.161500.22404400342814101.mbj@tail-f.com> <20161215161434.GD7432@elstar.local> <20161215.172609.1950541994949692852.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161215.172609.1950541994949692852.mbj@tail-f.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-entity issue #13 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 16:30:32 -0000 On Thu, Dec 15, 2016 at 05:26:09PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Thu, Dec 15, 2016 at 04:15:00PM +0100, Martin Bjorklund wrote: > > > Hi, > > > > > > Issue https://github.com/netmod-wg/entity/issues/13 > > > > > > Should the model support pre-configuration of hardware components? > > > The current model supports pre-configuration of components provided > > > the operator knows the name of the component to be installed. A more > > > useful model would use the parent component, class, and > > > parent-rel-pos as identification. If the system detects a component > > > and there is configuration available for the parent component, > > > class, and parent-rel-pos then the system would instatiate the > > > component with the provided name, and optionally additional > > > parameters. > > > > > > See also various mails from Timothy Carey and Bart Bogaert on this > > > issue. > > > > > > Personally, I think that we should add these nodes, since the ML > > > comments indicated that pre configuration is pretty useful. > > > > > > > I am still not sure what exactly this will do. I have been looking at > > . > > I am provisioning mfg-name (Preferred value is the manufacturer name > > string actually printed on the component itself (if present).) but all > > I have is that something of a certain expected class has been plugged > > into a certain position of the parent container. Also note that > > mfg-name scopes comparisons of other properties. I would have similar > > questions concerning the model-name; how can a provisioning system > > predict the 'vendor-specific model name identifier'? Or is the whole > > idea that if I plug something that does not match, the component is > > left in a special state (which one)? If this is the intention, then > > this needs to be spelled out clearly somewhere. > > The current model works fine if the user looks into the state list and > finds a component that he wants to configure. To do this, he uses the > name of the component as found in the state list, and writes the > config for this component. > > The current model also supports pre-configuration if the user somehow > can predict the name of a component to-be-inserted. In this case he > can write the config, and when the component is plugged in, the system > will derive the component name, and check the config list for this > name. This is a fragile model. > > In the proposed model, the user can provide configuration for a tuple > (parent, class, parent-rel-pos). If the server finds a component in > the state list (or such a component is later plugged in), then the > corresponding config leafs are used for the state of this component > (including the name). > > If you plug in something that doesn't match the config list, well that > just means that nothing has been configured for this component, and > the system will populate the state list accordingly. > Well, this is not what I read out of https://www.ietf.org/mail-archive/web/netmod/current/msg17039.html since there are leafs like mfg-name and model-name that seem to be hardware component properties. And the config list is still indexed by a name; so for list elements that have a (class, parent, position) triple, the name would be arbitrary and not necessarily matching the component name. Well, if you understand the edits,... /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 Dec 15 09:02:08 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9960B129BA9 for ; Thu, 15 Dec 2016 09:02:06 -0800 (PST) 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 vfCA6QX5UweR for ; Thu, 15 Dec 2016 09:02:01 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B90129B30 for ; Thu, 15 Dec 2016 09:02:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id AD6DB1E5669; Thu, 15 Dec 2016 09:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3GM9yuNWU_zs; Thu, 15 Dec 2016 09:00:54 -0800 (PST) Received: from [192.168.1.129] (host5-81-223-185.range5-81.btcentralplus.com [5.81.223.185]) by c8a.amsl.com (Postfix) with ESMTPSA id 09E831E5667; Thu, 15 Dec 2016 09:00:53 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: William Lupton In-Reply-To: Date: Thu, 15 Dec 2016 17:01:58 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <88C30E13-A7DF-4919-9BCC-3969E2E6AF11@broadband-forum.org> References: <20161215.145729.704925239472686261.mbj@tail-f.com> To: netmod@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [netmod] BBF work depending on draft-ietf-netmod-entity-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 17:02:06 -0000 The current draft-ietf-netmod-entity-01 defines ietf-hardware and = iana-entity modules. Is it intended that iana-entity will become = iana-hardware? Thanks, W.= From nobody Thu Dec 15 10:29:26 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CAB129B87 for ; Thu, 15 Dec 2016 10:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnyXqb24zm3l for ; Thu, 15 Dec 2016 10:29:21 -0800 (PST) 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 8798B12944C for ; Thu, 15 Dec 2016 10:29:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10708; q=dns/txt; s=iport; t=1481826561; x=1483036161; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=fGiHNVSE4ELj0aSDonQLbe4CdfWd61m3YWCTEAuz//c=; b=GLNBFzzJ3XLnt3qf0tKzhDhek9DAmxr65XJ/OKZEN4ocOanT+fWXBjoA wLp8IMIMAywm1I6xzRdnqhSMdQbv4kmiNd59sPF09arNBu/IJ5k66Aaot sZIn1xUNJ5YHMkMS2MPuZWp6ngg/a8NbOvKe/zvOC2Llj42i8Intf1hfZ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DTAQAV4FJY/4gNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAR9agQYHAY1GlliVCoIJHwuFLkoCGoFuPxQBAgEBAQE?= =?us-ascii?q?BAQFiKIRoAQEBBAEBEAsGEToLEgEIEQQBAQMCJgIEJQsVCAoEDgUiiEkOmyQBj?= =?us-ascii?q?XaCKIsIAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4UrgX0IglSECDiDBC2CMAW?= =?us-ascii?q?PAYVqhgEBhlCDEoMVhDsKgWoYhGmEWYR9jhSEDgEfN4EiKQ8BAYM+gX5yhj6BI?= =?us-ascii?q?QGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,353,1477958400"; d="scan'208";a="360553929" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Dec 2016 18:29:20 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uBFITKKj020360 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Dec 2016 18:29:20 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 15 Dec 2016 12:29:19 -0600 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1210.000; Thu, 15 Dec 2016 12:29:19 -0600 From: "Clyde Wildes (cwildes)" To: Alex Campbell Thread-Topic: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 Thread-Index: AQHSVwEmf0zqhzKmtE+Zpe9My2EhJg== Date: Thu, 15 Dec 2016 18:29:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.151.30] Content-Type: text/plain; charset="utf-8" Content-ID: <9F853963494D974C960CD879A7FF9E6B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 18:29:24 -0000 SGkgQWxleCwNCg0KVGhhbmtzIGZvciB5b3VyIHJldmlldy4gTXkgY29tbWVudHMgYXJlIGlubGlu ZSBhcyBbY2x5ZGVd4oCmDQoNCk9uIDEyLzEzLzE2LCA4OjE2IFBNLCAibmV0bW9kIG9uIGJlaGFs ZiBvZiBBbGV4IENhbXBiZWxsIiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9m IEFsZXguQ2FtcGJlbGxAQXZpYXRuZXQuY29tPiB3cm90ZToNCg0KICAgIEkgYW0gY29uc2lkZXJp bmcgdG8gaW1wbGVtZW50IHRoZSBkYXRhIG1vZGVsIGluIHRoaXMgZHJhZnQuDQogICAgDQogICAg SSBoYXZlIHJldmlld2VkIHRoaXMgZHJhZnQgYW5kIGZvdW5kIHRoZSBmb2xsb3dpbmcgaXNzdWVz LiBJbiBhcHByb3hpbWF0ZWx5IGRlY3JlYXNpbmcgb3JkZXIgb2Ygc2V2ZXJpdHk6DQogICAgDQog ICAgKiBJbiB0aGUgInNlbGVjdG9yLWZhY2lsaXR5IiBjaG9pY2Ugc3RhdGVtZW50IHRoZSBjYXNl cyBoYXZlIG1pc2xlYWRpbmcgbmFtZXMgLSB0aGUgY2FzZSB3aGVyZSBubyBmYWNpbGl0eSBpcyBt YXRjaGVkIGlzIG5hbWVkICJmYWNpbGl0eSIsIGFuZCB0aGUgY2FzZSB3aGVyZSBzcGVjaWZpYyBm YWNpbGl0aWVzIGFyZSBtYXRjaGVkIGlzIG5hbWVkICJuYW1lIi4gSSBzdWdnZXN0ICJuby1mYWNp bGl0aWVzIiBhbmQgInNwZWNpZmllZC1mYWNpbGl0aWVzIiwgb3Igc2ltaWxhci4NCiAgICANCltj bHlkZV0gSSB1bmRlcnN0YW5kIHlvdXIgY29uY2VybiBhbmQgYWdyZWUuIFBsZWFzZSBzZWUgdGhl IG5leHQgYW5zd2VyIHdoZXJlIEkgaGF2ZSByZW1vdmVkIHRoZSBuby1mYWNpbGl0aWVzIGNhc2Ug ZnJvbSB0aGUgbW9kZWwuDQoNCg0KICAgICogSSBkaXNhZ3JlZSB3aXRoIHRoZSBwcmVtaXNlIG9m IHRoZSAibm8tZmFjaWxpdGllcyIgY2FzZSwgd2hpY2ggaXMgdGhhdCBpdCBjYW4gYmUgdXNlZCB0 byBkaXNhYmxlIGEgbG9nIGFjdGlvbiwgYWNjb3JkaW5nIHRvIHRoZSBkZXNjcmlwdGlvbjoNCiAg ICANCiAgICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAgICAgIlRoaXMgY2FzZSBzcGVj aWZpZXMgbm8gZmFjaWxpdGllcyB3aWxsIG1hdGNoIHdoZW4NCiAgICAgICAgICAgICAgICAgY29t cGFyaW5nIHRoZSBzeXNsb2cgbWVzc2FnZSBmYWNpbGl0eS4gVGhpcyBpcyBhDQogICAgICAgICAg ICAgICAgIG1ldGhvZCB0aGF0IGNhbiBiZSB1c2VkIHRvIGVmZmVjdGl2ZWx5IGRpc2FibGUgYQ0K ICAgICAgICAgICAgICAgICBwYXJ0aWN1bGFyIGxvZy1hY3Rpb24gKGJ1ZmZlciwgZmlsZSwgZXRj KS4iOw0KICAgIA0KICAgICAgSWYgYW4gYWRtaW5pc3RyYXRvciB3YW50cyB0byBkaXNhYmxlIGEg bG9nIGFjdGlvbiB0aGV5IHNob3VsZCBkbyBpdCBieSBlaXRoZXIgcmVtb3ZpbmcgaXQgZnJvbSB0 aGUgY29uZmlndXJhdGlvbiwgb3IgYnkgc2V0dGluZyBhbiAiZW5hYmxlZCIgbGVhZiB0byBmYWxz ZS4NCiAgICAgIFdpdGggdGhhdCBpbiBtaW5kLCB0aGVyZSBpcyBubyByZWFzb24gZm9yIHRoZSAi bm8tZmFjaWxpdGllcyIgY2FzZSB0byBleGlzdC4NCg0KW2NseWRlXSBJIGFncmVlIHdpdGggeW91 ciBzdWdnZXN0aW9uIHRvIHNpbXBsaWZ5IGJ5IHJlbW92aW5nIHRoZSBuby1mYWNpbGl0aWVzIGNh c2UuIFBsZWFzZSBzZWUgdGhlIHJldmlzZWQgc2VsZWN0b3IgZ3JvdXBpbmcgd2hpY2ggd2lsbCBh cHBlYXIgaW4gdGhlIG5leHQgZHJhZnQ6DQoNCiAgZ3JvdXBpbmcgc2VsZWN0b3Igew0KICAgIGRl c2NyaXB0aW9uDQogICAgICAiVGhpcyBncm91cGluZyBkZWZpbmVzIGEgc3lzbG9nIHNlbGVjdG9y IHdoaWNoIGlzIHVzZWQgdG8gDQogICAgICAgc2VsZWN0IGxvZyBtZXNzYWdlcyBmb3IgdGhlIGxv Zy1hY3Rpb24gKGNvbnNvbGUsIGZpbGUsIA0KICAgICAgIHJlbW90ZSwgZXRjLikuIENob29zZSBv bmUgb3IgYm90aCBvZiB0aGUgZm9sbG93aW5nOg0KICAgICAgICAgZmFjaWxpdHkgWzxmYWNpbGl0 eT4gPHNldmVyaXR5Pi4uLl0NCiAgICAgICAgIHBhdHRlcm4tbWF0Y2ggcmVndWxhci1leHByZXNz aW9uLW1hdGNoLXN0cmluZw0KICAgICAgIElmIGJvdGggZmFjaWxpdHkgYW5kIHBhdHRlcm4tbWF0 Y2ggYXJlIHNwZWNpZmllZCwgYm90aCBtdXN0IA0KICAgICAgIG1hdGNoIGluIG9yZGVyIGZvciBh IGxvZyBtZXNzYWdlIHRvIGJlIHNlbGVjdGVkLiI7DQogICAgY29udGFpbmVyIHNlbGVjdG9yIHsN CiAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICJUaGlzIGNvbnRhaW5lciBkZXNjcmliZXMgdGhl IGxvZyBzZWxlY3RvciBwYXJhbWV0ZXJzIA0KICAgICAgICAgZm9yIHN5c2xvZy4iOw0KICAgICAg bGlzdCBmYWNpbGl0eS1saXN0IHsNCiAgICAgICAga2V5IGZhY2lsaXR5Ow0KICAgICAgICBkZXNj cmlwdGlvbg0KICAgICAgICAgICJUaGlzIGxpc3QgZGVzY3JpYmVzIGEgY29sbGVjdGlvbiBvZiBz eXNsb2cgDQogICAgICAgICAgIGZhY2lsaXRpZXMgYW5kIHNldmVyaXRpZXMuIjsNCiAgICAgICAg bGVhZiBmYWNpbGl0eSB7DQogICAgICAgICAgdHlwZSB1bmlvbiB7DQogICAgICAgICAgICB0eXBl IGlkZW50aXR5cmVmIHsNCiAgICAgICAgICAgICAgYmFzZSBzeXNsb2d0eXBlczpzeXNsb2ctZmFj aWxpdHk7DQogICAgICAgICAgICB9DQogICAgICAgICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCiAg ICAgICAgICAgICAgZW51bSBhbGwgew0KICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQogICAg ICAgICAgICAgICAgICAiVGhpcyBlbnVtIGRlc2NyaWJlcyB0aGUgY2FzZSB3aGVyZSBhbGwgDQog ICAgICAgICAgICAgICAgICAgZmFjaWxpdGllcyBhcmUgcmVxdWVzdGVkLiI7DQogICAgICAgICAg ICAgIH0NCiAgICAgICAgICAgIH0NCiAgICAgICAgICB9DQogICAgICAgICAgZGVzY3JpcHRpb24N CiAgICAgICAgICAgICJUaGUgbGVhZiB1bmlxdWVseSBpZGVudGlmaWVzIGEgc3lzbG9nIGZhY2ls aXR5LiI7DQogICAgICAgIH0NCiAgICAgICAgdXNlcyBsb2ctc2V2ZXJpdHk7DQogICAgICB9DQog ICAgICBsZWFmIHBhdHRlcm4tbWF0Y2ggew0KICAgICAgICBpZi1mZWF0dXJlIHNlbGVjdC1tYXRj aDsNCiAgICAgICAgdHlwZSBzdHJpbmc7DQogICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAg IlRoaXMgbGVhZiBkZXNyaWJlcyBhIFBvc2l4IDEwMDMuMiByZWd1bGFyIGV4cHJlc3Npb24gDQog ICAgICAgICAgIHN0cmluZyB0aGF0IGNhbiBiZSB1c2VkIHRvIHNlbGVjdCBhIHN5c2xvZyBtZXNz YWdlIGZvciANCiAgICAgICAgICAgbG9nZ2luZy4gVGhlIG1hdGNoIGlzIHBlcmZvcm1lZCBvbiB0 aGUgUkZDIDU0MjQgDQogICAgICAgICAgIFNZU0xPRy1NU0cgZmllbGQuIjsNCiAgICAgIH0NCiAg ICB9DQogIH0NCiAgICANCg0KICAgICogV2hhdCBpcyB0aGUgYmVoYXZpb3VyIG9mIGEgc2VsZWN0 b3IgaWYgbmVpdGhlciAibm8tZmFjaWxpdGllcyIgbm9yICJmYWNpbGl0eS1saXN0IiBpcyBwcmVz ZW50Pw0KDQpbY2x5ZGVdIEF0IGxlYXN0IG9uZSBvciBib3RoIG9mIHRoZSBmb2xsb3dpbmcgbXVz dCBiZSBzcGVjaWZpZWQ6IGZhY2lsaXR5OyBwYXR0ZXJuLW1hdGNoIChpZiBzdXBwb3J0ZWQpLg0K DQpJIGhhdmUgdXBkYXRlZCB0aGUgZGVzY3JpcHRpb24gYXQgdGhlIGJlZ2lubmluZyBvZiB0aGUg c2VsZWN0b3Ig4oCTIHBsZWFzZSBzZWUgYWJvdmUuDQoNCg0KICAgICogSW4gdGhlICJzZWxlY3Rv ciIgZ3JvdXBpbmcgaXQgaXMgbm90IGNsZWFyIGhvdyB0aGUgZmFjaWxpdHkgYW5kIHBhdHRlcm4g Y29uZGl0aW9ucyBhcmUgY29tYmluZWQgdG8gZGVjaWRlIHdoZXRoZXIgYSBtZXNzYWdlIGlzIHNl bGVjdGVkLg0KDQogICAgICBNdXN0IHRoZXkgYm90aCBtYXRjaCB0aGUgbWVzc2FnZSwgb3IgaXMg aXQgc3VmZmljaWVudCBmb3IgZWl0aGVyIG9uZSB0byBtYXRjaCB0aGUgbWVzc2FnZT8NCg0KW2Ns eWRlXSBJZiBib3RoIGFyZSBzcGVjaWZpZWQgdGhleSBtdXN0IGJvdGggbWF0Y2ggdGhlIG1lc3Nh Z2UuIFRoaXMgaXMgY29uc2lzdGVudCB3aXRoIHRoZSBzeXNsb2cgaW1wbGVtZW50YXRpb25zIGJ5 IENpc2NvIGFuZCBKdW5pcGVyLg0KDQoNCiAgICAqIE5vdCBhbGwgc2VydmVycyBoYXZlIGEgY29u c29sZTsgdGhlcmUgc2hvdWxkIGJlIGEgZmVhdHVyZSB0byBpbmRpY2F0ZSB3aGV0aGVyIGxvZ2dp bmcgdG8gdGhlIGNvbnNvbGUgaXMgc3VwcG9ydGVkLg0KDQpbY2x5ZGVdIEkgaGF2ZSByZWNlaXZl ZCBjb21tZW50cyBpbiBlYXJsaWVyIHJldmlld3MgdGhhdCB3ZSBzaG91bGQgaW1wbGVtZW50IHRo ZSBtaW5pbXVtIHNldCBvZiBmdW5jdGlvbmFsaXR5IHRoYXQgaXMgY29udGFpbmVkIGluIGF0IGxl YXN0IHRocmVlIHZlbmRvciBpbXBsZW1lbnRhdGlvbnMuDQoNCkNvbnNvbGUgaXMgc3VwcG9ydGVk IGJ5IEFsY2F0ZWwvTHVjZW50LCBCcm9jYWRlLCBDaXNjbyAoWEUsIFhSLCBhbmQgTlhPUyksIEp1 bmlwZXIsIGFuZCBMaW51eC1yc3lzbG9nLiBSZW1vdmFsIG9mIHRoZSBjb25zb2xlIGFjdGlvbiBm b3IgeW91ciBjYXNlIGNvdWxkIGJlIGRvbmUgdGhyb3VnaCBhIHZlbmRvciBzcGVjaWZpYyBkZXZp YXRpb24gc3RhdGVtZW50Lg0KDQoNCiAgICAqIExpa2V3aXNlLCBub3QgYWxsIHNlcnZlcnMgbWF5 IHN1cHBvcnQgbG9nZ2luZyB0byB1c2VyIHNlc3Npb25zLg0KDQpbY2x5ZGVdIFVzZXIgc2Vzc2lv bnMgYXJlIHN1cHBvcnRlZCBieSBBbGNhdGVsL0x1Y2VudCwgYW5kIEp1bmlwZXIuIEkgd2lsbCBt YWtlIHRoaXMgYSBmZWF0dXJlIGluIHRoZSBuZXh0IHJldmlzaW9uIG9mIHRoZSBkcmFmdCBzaW5j ZSBvbmx5IHR3byB2ZW5kb3JzIGltcGxlbWVudCBpdC4NCg0KDQogICAgKiBMaWtld2lzZSwgbm90 IGFsbCBzZXJ2ZXJzIG1heSBzdXBwb3J0IGEgdXNlci1hY2Nlc3NpYmxlIGZpbGVzeXN0ZW0uDQoN CltjbHlkZV0gRmlsZXMgYXJlIHN1cHBvcnRlZCBieSBBbGNhdGVsL0x1Y2VudCwgQ2lzY28gKFhF LCBYUiwgYW5kIE5YT1MpLCBKdW5pcGVyLCBhbmQgTGludXgtcnN5c2xvZy4gUmVtb3ZhbCBvZiB0 aGUgZmlsZSBhY3Rpb24gZm9yIHlvdXIgY2FzZSBjb3VsZCBiZSBkb25lIHRocm91Z2ggYSB2ZW5k b3Igc3BlY2lmaWMgZGV2aWF0aW9uIHN0YXRlbWVudC4NCg0KDQogICAgKiBSRkMgNTQyNCBzdGF0 ZXMgdGhhdCB0aGUgc2V2ZXJpdHkgYW5kIHByb3RvY29sIHZhbHVlcyBhcmUgbm90IG5vcm1hdGl2 ZS4gDQoNCltjbHlkZV0gSXMgaXQgdGhhdCB5b3UgYXJlIGFza2luZyBmb3IgUkZDIDU0MjQgdG8g YmUgcmVtb3ZlZCBmcm9tIHRoZSBOb3JtYXRpdmUgUmVmZXJlbmNlIHNlY3Rpb24gb2YgdGhlIGRy YWZ0IGFuZCBhZGRlZCB0byB0aGUgSW5mb3JtYXRpdmUgc2VjdGlvbj8NCg0KDQogICAgKiBJdCdz IG5vdCBjbGVhciB0byBtZSB3aHkgdGhpcyBuZWVkcyB0byBiZSBzcGxpdCBpbnRvIHR3byBtb2R1 bGVzLiBJcyBpdCBzbyB0aGF0IG90aGVyIG1vZHVsZXMgY2FuIGRlZmluZSBsb2dnaW5nIHBhcmFt ZXRlcnMgYnV0IHN0aWxsIGJlIHVzYWJsZSBvbiBhIGRldmljZSB3aXRob3V0IHN5c2xvZz8NCg0K W2NseWRlXSBXZSB3ZXJlIGd1aWRlZCBieSBhbiBlYXJseSBZYW5nIERyLuKAmXMgYWR2aWNlIGlu IHRoZSBjaG9pY2Ugb2YgdHdvIG1vZHVsZXMg4oCTIG9uZSBmb3IgdHlwZXMgYW5kIG9uZSBmb3Ig dGhlIG1vZGVsLiBJIHdpbGwgZGVmZXIgdG8gb3VyIG1lbnRvciBKw7xyZ2VuIGZvciBoaXMgYWR2 aWNlLiANCg0KDQogICAgKiAibG9nLXNldmVyaXR5IiBkZWZpbmVzIGEgc2V2ZXJpdHkgZmlsdGVy LCBub3QgYSBzZXZlcml0eSwgc28gaXRzIG5hbWUgaXMgbWlzbGVhZGluZy4NCg0KW2NseWRlXSBQ bGVhc2Ugc3VnZ2VzdCBhIGJldHRlciBuYW1lLg0KDQoNCiAgICAqIFBlcmhhcHMgdGhlICJzZXZl cml0eSIgdHlwZSBhbmQgdGhlIGZhY2lsaXR5IGlkZW50aXRpZXMgc2hvdWxkIGhhdmUgInJlZmVy ZW5jZSIgc3RhdGVtZW50cyByZWZlcnJpbmcgdG8gUkZDIDU0MjQsIHJhdGhlciB0aGFuIHJlZmVy cmluZyB0byBpdCBpbiB0aGUgZGVzY3JpcHRpb24uDQoNCltjbHlkZV0gSSB3aWxsIGRlZmVyIHRv IG91ciBtZW50b3IgSsO8cmdlbiBmb3IgaGlzIGFkdmljZS4gV2UgcHJldmlvdXNseSBmb2xsb3dl ZCBoaXMgYWR2aWNlIGhlcmUuDQoNCg0KICAgICogSW4gc2VjdGlvbiAiOC4yIiwgImFkbWlzaW50 cmF0b3IiIGlzIGEgdHlwby4NCg0KW2NseWRlXSBUaGlzIHdpbGwgYmUgZml4ZWQgaW4gdGhlIG5l eHQgZHJhZnQuDQoNCiAgICANCiAgICBJIGFzc3VtZSB0aGF0IHRoZSBtZWFucyBvZiBhY2Nlc3Np bmcgdGhlIG1lbW9yeSBidWZmZXIgYW5kIGxvZyBmaWxlcyBhcmUgb3V0IG9mIHNjb3BlIG9mIHRo aXMgZGF0YSBtb2RlbC4NCg0KW2NseWRlXSBUaGlzIGRyYWZ0IGNvdmVycyBzeXNsb2cgY29uZmln dXJhdGlvbiBvbmx5Lg0KDQoNClRoYW5rcywNCg0KQ2x5ZGUNCg0KICAgIA0KICAgIEFsZXgNCiAg ICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgRnJv bTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEtlbnQgV2F0 c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0Pg0KICAgIFNlbnQ6IFdlZG5lc2RheSwgMTQgRGVjZW1i ZXIgMjAxNiAyOjAxIHAubS4NCiAgICBUbzogbmV0bW9kQGlldGYub3JnDQogICAgU3ViamVjdDog W25ldG1vZF0gV0cgTGFzdCBDYWxsIGZvciBkcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWwt MTENCiAgICANCiAgICBUaGlzIGlzIGEgbm90aWNlIHRvIHN0YXJ0IGEgdHdvLXdlZWsgTkVUTU9E IFdHIGxhc3QgY2FsbCBmb3IgdGhlIGRvY3VtZW50Og0KICAgIA0KICAgICAgICBBIFlBTkcgRGF0 YSBNb2RlbCBmb3IgU3lzbG9nIENvbmZpZ3VyYXRpb24NCiAgICAgICAgaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbC0xMQ0KICAgIA0KICAg IFBsZWFzZSBpbmRpY2F0ZSB5b3VyIHN1cHBvcnQgb3IgY29uY2VybnMgYnkgVHVlc2RheSwgRGVj ZW1iZXIgMjcsIDIwMTYuDQogICAgDQogICAgV2UgYXJlIHBhcnRpY3VsYXJseSBpbnRlcmVzdGVk IGluIHN0YXRlbWVudHMgb2YgdGhlIGZvcm06DQogICAgICAqIEkgaGF2ZSByZXZpZXdlZCB0aGlz IGRyYWZ0IGFuZCBmb3VuZCBubyBpc3N1ZXMuDQogICAgICAqIEkgaGF2ZSByZXZpZXdlZCB0aGlz IGRyYWZ0IGFuZCBmb3VuZCB0aGUgZm9sbG93aW5nIGlzc3VlczogLi4uDQogICAgDQogICAgQXMg d2VsbCBhczoNCiAgICAgICogSSBoYXZlIGltcGxlbWVudGVkIHRoZSBkYXRhIG1vZGVsIGluIHRo aXMgZHJhZnQuDQogICAgICAqIEkgYW0gaW1wbGVtZW50aW5nIHRoZSBkYXRhIG1vZGVsIGluIHRo aXMgZHJhZnQuDQogICAgICAqIEkgYW0gY29uc2lkZXJpbmcgdG8gaW1wbGVtZW50IHRoZSBkYXRh IG1vZGVsIGluIHRoaXMgZHJhZnQuDQogICAgICAqIEkgYW0gbm90IGNvbnNpZGVyaW5nIHRvIGlt cGxlbWVudCB0aGUgZGF0YSBtb2RlbCBpbiB0aGlzIGRyYWZ0Lg0KICAgIA0KICAgIFRoYW5rIHlv dSwNCiAgICBORVRNT0QgV0cgQ2hhaXJzDQogICAgDQogICAgDQogICAgDQogICAgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBuZXRtb2QgbWFpbGlu ZyBsaXN0DQogICAgbmV0bW9kQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRtb2QNCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KICAgIG5ldG1vZCBtYWlsaW5nIGxpc3QNCiAgICBuZXRt b2RAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dG1vZA0KICAgIA0KDQo= From nobody Thu Dec 15 10:55:46 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F9312967C; Thu, 15 Dec 2016 10:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=infinera.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 I2wOof-sNC53; Thu, 15 Dec 2016 10:55:43 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0061.outbound.protection.outlook.com [104.47.40.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80CF9129443; Thu, 15 Dec 2016 10:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infinera.onmicrosoft.com; s=selector1-infinera-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bxNGuVAsoY16QUl2ISz8I46IoLt0Q9fdziUYY4y1HMQ=; b=j0w4KK/VUv0DOA+limAWuqfCeYePzAO2paf+PQXBguabHVYqiMXdyMlGSmtzoYl5sXZmAV3Y8KlD1RUzq5cw5nbj67lAZCxr98xE5Z7sDrUs3Qd14j9b7x5VsQnojv8yH79VoO6k3QKf3RmFyBlI/IMxzuJpa3meW4kLwFIr/mg= Received: from BN6PR1001CA0018.namprd10.prod.outlook.com (10.174.84.31) by BLUPR10MB0482.namprd10.prod.outlook.com (10.162.90.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Thu, 15 Dec 2016 18:55:39 +0000 Received: from DM3NAM03FT053.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::201) by BN6PR1001CA0018.outlook.office365.com (2603:10b6:405:28::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8 via Frontend Transport; Thu, 15 Dec 2016 18:55:39 +0000 Authentication-Results: spf=pass (sender IP is 204.128.141.23) smtp.mailfrom=infinera.com; labn.net; dkim=none (message not signed) header.d=none;labn.net; dmarc=bestguesspass action=none header.from=infinera.com; Received-SPF: Pass (protection.outlook.com: domain of infinera.com designates 204.128.141.23 as permitted sender) receiver=protection.outlook.com; client-ip=204.128.141.23; helo=owa.infinera.com; Received: from owa.infinera.com (204.128.141.23) by DM3NAM03FT053.mail.protection.outlook.com (10.152.83.181) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.10 via Frontend Transport; Thu, 15 Dec 2016 18:55:38 +0000 Received: from SV-EX13-PRD1.infinera.com (10.100.103.228) by sv-ex13-prd1.infinera.com (10.100.103.228) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 15 Dec 2016 10:55:38 -0800 Received: from SV-EX13-PRD1.infinera.com ([10.100.97.11]) by sv-ex13-prd1.infinera.com ([10.100.97.11]) with mapi id 15.00.1178.000; Thu, 15 Dec 2016 10:55:38 -0800 From: Iftekhar Hussain To: Lou Berger , NetMod WG Thread-Topic: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04 Thread-Index: AQHSVrezBGS7hRMxYEOqdNcnM2TMpaEJTb2g Date: Thu, 15 Dec 2016 18:55:37 +0000 Message-ID: <4010c7f4de4941e1b41c2665926eb574@sv-ex13-prd1.infinera.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.100.99.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:204.128.141.23; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(39410400002)(39830400002)(2980300002)(438002)(199003)(377454003)(189002)(13464003)(23726003)(356003)(229853002)(86362001)(305945005)(2900100001)(8676002)(106466001)(92566002)(8746002)(106116001)(6116002)(3846002)(246002)(38730400001)(47776003)(5890100001)(97756001)(5001770100001)(7736002)(102836003)(24736003)(77096006)(80792005)(7636002)(53416004)(108616004)(54356999)(2950100002)(626004)(7696004)(46406003)(4326007)(189998001)(5660300001)(76176999)(8936002)(50466002)(230783001)(50986999)(2906002)(33646002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR10MB0482; H:owa.infinera.com; FPR:; SPF:Pass; PTR:outgoingmail1.infinera.com; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT053; 1:moKcYARGYk1rTuqs6Ehw/akFGzATNqbC8kKDhItNq7FLH76OGpltXRjjGGqwHcHm7BclblXIVH0maF3Wl69wJ0tsKAmoCKxmjcddXlrFDk/jIEtGGh+1hX2CtWtMkYdWvAvbA9lgTytDt9x6AJRl8BLChhnqLJpYFw1hSmPoMEJIE5G76maCNF2MD8ZFkdxmK0gs0Qa+L2H3ypv6hkRJQOtNgCROUR1nXFC6Ey//psPSNumBEqXUo4yFDbNsm0Nz3SelhjHKV8sPzUcCFCklUptZpx2zKUIcFVnbf2QPWBhORyTvfvLuHp6JprsXXsonbZpj+e1x48NYYoXLv+rY5vtf6uqmbH65xuYvtoK8DS0m6c/fQlsxoN2rrb5Z/qMoMJQCMcUy1z0utnj4Csm6QpcUdcurFmGZXC30P9Za2Q799YdnuspL6Nnrw40rF2s9EnWBIAkdE+5yc1O5+I5wPVN+PSDc5iiNtOCv7TzSqk8xnDtWOgZVnO59QtRF3PkptXj8pUJ214XyZE+TlHAk4A0H9QM3D3gL1i6o9sFbeVc= X-MS-Office365-Filtering-Correlation-Id: 9f32bd15-ba31-422b-ca63-08d4251bf647 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002); SRVR:BLUPR10MB0482; X-Microsoft-Exchange-Diagnostics: 1; BLUPR10MB0482; 3:y9aRhvBxW0ZSDvi+MjkplncCfOSOlZFK6WDSzjOB7RNdrgCf8m+S4MUMjMlJFbZRVTFs29hKehcyciL0H5OKvmLm+eUsRvTT6hNMFgL/IyJxbee32g2nh9RYFCk9ybsSzmWf9dvGxDcyvlxzc1oCDMRAY9GjfeMJ+uLM7X8RPKefzUs3EKSanZnMKZ/8xmhkSfsbIeoDw5X7igjjMORrZ8vEkhvPhCiH6/QNFfHMQYmbDgVqYWClKpBkBS6aMDSrugCGnHOKJx7Ez89HSBuhVVsgWORSurJ0Zz7QFC26tARqPLu+yU7osLWXu/dzft2ZvydVPrjJXI1bvsiN9In45WwPKjenpLEIqTYo6uusg5RTgSULf35MGmugCRJDhfi2w9ZoCP4NuDiNlk+b0vWzAQ== X-Microsoft-Exchange-Diagnostics: 1; BLUPR10MB0482; 25:1u2wPcHh65u3svuwtrwqP25pd/4KYOhkA47Rh/xaxAQHTlYEnIZEjyziUL44dHu7vWwQeRbrEFefdeyOIKAyAkPwXBgNHY4RX5p9/D2cep0R6w1XJeIo8br3i2psdheSdf/LIrBY5eXLPwbFc0Uj+e5ekf7v9qh38fIcsVbjbOKk8elmU7S4MNmNz1rjZnm3GDlMecHJIbU3om5+osFV3E4iiFI80+4mpb4jcUctDm9Q8z2/zaVfwbuPUaE/pHDhNsXw9MkTfHF4Y5KspprFxE/bf4iR2N/aojrw/x5V1k4AQsIPKLJn2a7TRjYgeVe00MLPtIU7Bl7W/N+9mKP6MLXMWcravUvBvr7PbznQ/EobuQVi7aVs6ywFsakV/G8R4VeEzuXZlAsi7pR6w5vcVSMhGMlyiSU3zKzZ53QsXKc4kTORX7FGDTqx0MIDt5tANZW94CY53z/FcLHBjpwX6b8Vw5SkG+qjByASjvW+5/eO/ifur7kqEVFXoA4UEyY+xmH+EeQnza030BhUqfBawChu2ZKWK94/DYaazACohJtnZToYWZQlWVcXreLR3ETyui7kfcApuJmanBpruu5PcyPrXJoRS8qB6ybNpG83emB91Squ8REb5WDoD9JOR6rh+TZXCi6EGLyxL2j9S2FCZaNHTdHlURy48jiTd9R25HBY7QZtTGObpC4lx/FLX7bfsQz15Kujv1Nuw59kg8Rxxb4GbhsjrOHIj7mYMU6afiWKwlFTbwXYcmrIEf73smuAbC/3TptStm15hcU1uFz5q0hKVAuK6kHlAyaKD4hAxPGY0/o5LZO1NGUWoAhTEoCQrt1qgY3zykvIUcKTSu3GhwUn2R42zOPdqDQPImMCqoCJO5+HKV0i25waWvUQdxFZcs5EUn+oUc1og8ZA91JVEirI1ch+HoNbpXAQnpC1j08= X-Microsoft-Exchange-Diagnostics: 1; BLUPR10MB0482; 31:rTvOEkconQhXdzEB1VIO+c/R9L+/ga5lKKGFKmRS1ySGp5UVdEsC/3dA3q7GxahdWB7KRq8oFXkn0wFY2qKg019hIuH4hngrVeZEK36MwH8IOrHscF0h7cHVXmC0bPJTA9Qm8/X2DpYbQZ39CJT572K05YelZ7eqws1YXSoxbbqfJnIjoegD4HQ/hJF9wsKXihk3yXv/wkffzSpcLPk4/z4PwV6a2wgpdtWsGyMrbyvpolj2mxK0O+IhMhjJUwcAYDRYJxAv41Djhi6KQEX02g== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(788757137089); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13023025)(13024025)(13015025)(13018025)(13017025)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:BLUPR10MB0482; BCL:0; PCL:0; RULEID:; SRVR:BLUPR10MB0482; X-Microsoft-Exchange-Diagnostics: 1; BLUPR10MB0482; 4:rWoA/35307vlnoRiEI4QQrD4OulWisDIKKocFXASdp6KBIYDG51YyESdST/75cG/uJfcSWmfHi986ZvurArPGxreGTng6k5wjPdRpWY1EhpOp3hx5y7hp4ALr+OBFpNrNPrqiWEkMtT9B0ZHIagpGf5jkvQ/Y2v9Bx93h0nUSp9BwOtUVeY/qRq5GwaJ4+tG22Y8YV1xOED8pfo/K/Vsrz/nL+p4ZR1giYt8Z3wN+TWva6VtfhVR+HE9rQjIrLYbI7DcXWj/U8X1mlznRT4nH5FVjDcJ/QwnIxYamzIXr5hezcWehLW4hTwO/XAynNakG7H5Geu2FhyQ5idKoLHqwxKWcZr9s5QnzCp9D4kNaTBAUwx/aDESC8A+UnvLmYOKI2MIdyHReRktw9+vBI2XD80N3UyMC2zBLplZdtzrDrCW+k0d0do8misnMQXze25efdszIQ3sAYYwiJU+IHhYTM0Pkxx/qgxQ2j/nAYyhcbxsgO4z/B7pzTkg2ut1V3qqqNVxomiqoNBuT9iWVDM28Ba2satDyApg8DQOgf0p1v/i42rEFaXK/Ee22iLXu0zVT8wqg/NUWntFxRpTFnPvji0NMfp5SkWlEIG/fLG2MJ0qFi4IYk9rV7qulVGy2Wa/oSyHGfmeCnO4ROv56ze5oHba7z7HncnkiNb6aZGUxTFyEA7iF82iCl6q9j41W/qOPL4voU0c5LIM1NpXtpP/sw== X-Forefront-PRVS: 0157DEB61B X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR10MB0482; 23:mRnL3E4Ysshjp3SgiKabmKSdASmcbmUZ/MvMm/PId?= =?us-ascii?Q?WcWzToOIs7GLagmi4e227ll527rzEGC1eByGerqwkRMIyTpmlz+cTbtvpD7m?= =?us-ascii?Q?+Tz3FfbkMSH/lv5QFUcUpQRNh4NqW41xhOs2WxP8U4HfaLeNN9wK//q5Cq5X?= =?us-ascii?Q?2Y1oTkI50XiTXn0mdsmh5O6832H71u7EWoxjgNsFyBs+zSUTY97ZFiutQmLF?= =?us-ascii?Q?wCOuCTiBD1lxua1KdzZg6DptpgDTIixo+YhRvOJs5250ag7vgofpPoV8fJpY?= =?us-ascii?Q?ck6O86A6ivB9IdQ1llW0YSdqV5I248a+FDWU86SJPdkB0O0y+1Rx7Awxymuy?= =?us-ascii?Q?T41k3gEHw35UjKg3+jVl0PK5E3dA96AE1pnbZ8iVMM0IE0V2ipbJCgkoEk+2?= =?us-ascii?Q?H9mRndsmYMOy27X2+hnqY9jXFEImFSbpQsjvg7CPA/ck+bTHUP7b7A+BT55Z?= =?us-ascii?Q?p/rjW/pBaOEnwduLsfC63a/kbO6u1rl0J4ft21EiUVEh1bkcFya0VsGOxWAD?= =?us-ascii?Q?jBtKm3BhU1fuJrSxhiv+XfhojP/7GdrizjjbgOQ092t935gZWWtf3bHa2s5k?= =?us-ascii?Q?35keiCb5mzf4gEyL4SpWH2skVxpxO4AUkEFdhFcyT2s+e4xI9e2fTeFKj7UJ?= =?us-ascii?Q?nqOVwliDn1JGw/syN8ODbPr1PnvADZaHMMsMhwasIUXhkF5QcfC09m5kI2jQ?= =?us-ascii?Q?ni6yWhn2oLyqOvHsb5fUfRn2PxdTahyFj93RJXTkbbcKtrLeLL5O6pvUV98j?= =?us-ascii?Q?1zHrry8gOWyWUUClN8Isfw06rxinOgaJWHocJSif3bQwt8lU8hxD21UqxLjD?= =?us-ascii?Q?pEe2kqD/ColtLFuSoM6N2IFKobLjb7LHwVqRo2bkdfxPm7tx3ZCjcZRQc/TS?= =?us-ascii?Q?AHfb93VCWckBCvmlG7hw/rsG2SCCno2z32nG4O2jNfucHWhOyucVAn8AZ5af?= =?us-ascii?Q?zvqAqn9wta1SqM+0GF8wtrysUjhP1XluVtCYzprdTlXhQMbbdlsz/c5r1rKC?= =?us-ascii?Q?YHCipC7ZpLurxpN/IlflxO2H6NShxfDWg3shM1IwRQ+nG0KZZU6ihdx16dQR?= =?us-ascii?Q?n4h6Dppqg1BzcheY+Yx1oV+7H/dfennXftqLZMblL8T91XkYIM9J06Ms/MJU?= =?us-ascii?Q?tdFmNHN5Cv9mB+/hiQhZNnEW8hOfGuYKhxtq5DqTqdApv1D40iTUMUY0MBRn?= =?us-ascii?Q?C9NGnvAMZIusGw7rMfpVcz1dAog5vpjCV14JUATFxRuu7JUOSNhD90SYdWNT?= =?us-ascii?Q?wyTcUlFixPodChFOXpafPn7MHnCCG54x2N6phBq?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR10MB0482; 6:cspM+iXJKytYZdHrywSkl2DjsxklnT8eHHeClLyjeiiwRuSpIRaDIHAQeXlbXVW8m69u0cW6ZVX+zMOebseWucgR4W0lVYTrU4ucfD4ZtcoKM+fI3UtGeYGhnA0nqxwvyqA3pQC1E13Lrn/lmKbI2KC6G/+RSL5gYZAvkLMKzT2uImNhOXqhKNf47YSQHLGStT8VqUJwj0KK7KgiZ+/aT3/2Ph07WSEINV2xcap3su1KAwicJpImt42I1Q0YeX3KakYBbQ2MtJdk1N8RbOuEL7aQ8Ps2DqfvDL3RfY5xbiMiPm+KfqSjHpBDLrEOLaOlVxxkMpmisJUzqpWrjqQiudIUniHbixMPF9OT8uWHyQLiQoJUm76XioBGFHx7pzgHvpm0v4JDsi3bcm4pysmgJorTv4ekfW0JftUED1ztYHk=; 5:LHyshxO0JQFN1wXe2q01Td8vt/hemT0dAWDnjJj6tRAFoEzWW0vfNeHQ5Sdauqf06s/RKocIMNDkj+Es/3qKeCqWkzU6JDtaRFKrCsXBlvyzvZ8/fxFx4mIjKvnBcEUTNF4E69T7W10ItmTZpa2dnQ==; 24:O+r+e/IAUUoBdRXM347nn6RjaBk0zOTQVFdbZIdPTLmR5Hc9H7Q5pbrT2ho97L5mgfMSjgnkH8J0C+iN2PhMVmM4H5jL75WJjLpR+l0D77E= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR10MB0482; 7:CPwmSuWNFE1QyNSGtKIqGxWNUQ4yiNN/bfsv1UQZIe1hC0IoDnQV17X3KlpFM7/jahPm5Mx/PibWLroZsBtdSPliuqHC0IofpyVX5TlgSdiBL/fwtXSKqnzUSsAegNUW1FRmkH0ONBa6BHX54gZl5ct94q86es7hyvhTfDV4E/p4Udug/H+ZM0TU98xIk1J5sL1QcfMUYsrmniz08BL1cfrKN+XcV5C4/cUd2XoZH/8z1pJUTa4Xuv0sXyO6CYaCqOrReAdIysiRNiUxv/OZcMOlua7U/iNbiddF8oNna8ExZJsKy6u3mZORaKNIX9QDEabhyfIB1GrPNi2tt4PT0P272pMjjeiRUWVuKlzeV6ZSAGMbZeh/wXhgBxnwsmjMFODXFCKFcnsHOWoHQKQJC93ZoNqswCMYc6XLQ7vD51WmC8YHvQnG+lPwJPlj4ngCXTW2PylJCKyb0BdlDofnhg== X-OriginatorOrg: infinera.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Dec 2016 18:55:38.9827 (UTC) X-MS-Exchange-CrossTenant-Id: 285643de-5f5b-4b03-a153-0ae2dc8aaf77 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=285643de-5f5b-4b03-a153-0ae2dc8aaf77; Ip=[204.128.141.23]; Helo=[owa.infinera.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR10MB0482 Archived-At: Cc: NetMod WG Chairs , "draft-wilton-netmod-intf-vlan-yang@ietf.org" Subject: Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 18:55:45 -0000 Yes/support. I have read this draft and believe it would be very useful for enabling man= y Layer 2 and Layer 3 services. However, I do have few comments and that I would like the authors to addres= s once the document is a WG document. a) Suggest to replace this text: "These modules allow IETF forwarding protocols (such as IPv6 and VPLS) = ..."=20 with the following text: " These modules allow configuration Layer 2 and Layer 3 subinterfaces (= e.g., attachment circuits) for providing for IETF L2VPN (e.g., VPWS, VPLS, = EVPN) and L3VPN services".=20 b) The document should clearly identify the scope. For example, suggest rep= lace this text: "... to interoperate with VLAN tagged traffic orginated from an IEE= E 802.1Q compliant bridge".=20 with the following text: "... to interoperate with traffic originated from an IEEE 802.1D, 80= 2.1Q, or 802.1AD compliant bridge." Note: In the data model, the draft is talking about untagged as well as = 802.1AD (see "tag type (802.1Q or 802.1ad)") =20 c) Are there any sub-interface level common statistics counters that the = model should address? Currently, I don't see any. Thanks, Iftekhar -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger Sent: Monday, December 12, 2016 3:32 PM To: NetMod WG Cc: NetMod WG Chairs Subject: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04 All, This is start of a two week* poll on making draft-wilton-netmod-intf-vlan-yang-04 a NetMod working group document. Please send email to the list indicating "yes/support" or "no/do not suppor= t". If indicating no, please state your reservations with the document. I= f yes, please also feel free to provide comments you'd like to see addresse= d once the document is a WG document. * Given the holiday, the poll ends December 28. Thank you, NetMod WG Chairs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod . From nobody Thu Dec 15 11:23:22 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BD7129E42 for ; Thu, 15 Dec 2016 11:23:21 -0800 (PST) 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 52I_91KC3ZWU for ; Thu, 15 Dec 2016 11:23:18 -0800 (PST) Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F60D129E45 for ; Thu, 15 Dec 2016 11:23:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 6B4D7268139D; Thu, 15 Dec 2016 20:23:13 +0100 (CET) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id zCu6gmi2TeCb; Thu, 15 Dec 2016 20:23:13 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 3B367268139C; Thu, 15 Dec 2016 20:23:13 +0100 (CET) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MhftfUm3qG6O; Thu, 15 Dec 2016 20:23:13 +0100 (CET) Received: from [192.168.209.111] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 180A92681399; Thu, 15 Dec 2016 20:23:13 +0100 (CET) To: Kent Watsen , Robert Wilton References: <20161209120651.GA93531@elstar.local> <03ca5365-8640-5019-a9da-802ed248fb0f@cisco.com> <20161209.161712.2008691146816809010.mbj@tail-f.com> <541638F1-53CC-4656-B0A1-3BE650F3DB3B@juniper.net> <870394e0-28c9-cf62-5268-fa1ddfec06a8@cisco.com> <4E091DC6-99B2-4B34-A35E-B16A97AD0E6E@juniper.net> From: Vladimir Vassilev Message-ID: Date: Thu, 15 Dec 2016 20:23:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: <4E091DC6-99B2-4B34-A35E-B16A97AD0E6E@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 19:23:21 -0000 Hi, Here is a summary of the proposed solutions so far: * The solution with introduction of YANG statement "diagnostics true;",=20 additional datastore and NETCONF protocol change. IMO that sounds heavy=20 but valid solution. * The solution with RPC returning the data as output. IMO has the=20 limitation of not presenting the diagnostics data in the data tree (no=20 valid instance-identifiers to be used in notifications). But is the=20 simplest to have in place. * The solution with RPC enabling the containers only for a certain sessio= n. I thought also of this alternative solution: The solution is to avoid=20 clobbering the replies to s without filter or s with filter=20 matching only parent nodes of the "diagnostics state" container data =20 and not return those nodes in the reply except in the cases the filter=20 matches data nodes part of the diagnostics data explicitly. Example for /interfaces-state/interfaces/diagnostics (using xpath filter=20 for brevity but valid for the "subtree" case): These skip "diagnostics": These return "diagnostics": This looks like a violation of RFC 6241 6.2.5 bullet 12 but IMO the=20 container is non-mandatory diagnostics data so returning it only when=20 someone really wants it and not otherwise is the definition of the=20 solution to the problem. /Vladimir On 12/12/2016 05:47 PM, Kent Watsen wrote: > > Hi Robert, > > You=92re right, it should=92ve been the (not ). = =20 > However, I think that it=92s better to use a flag on the=20 > datastore, rather than to define a new datastore. =20 > Not only would it mimic how with-defaults works, but it also seems=20 > more intuitive from a retrieval perspective, as the diagnostics nodes=20 > could be sprinkled throughout a data model, and a single =20 > could return all nodes (not just the diagnostics) for a given=20 > subtree. Thoughts? > > Separately, from a modelling perspective, presumably there would have=20 > to be an additional flag to go with the config false flag, something=20 > like the below. Is this what you were envisioning? > > container thermostat { > > leaf configured-temperature { > > type int8; > > } > > leaf current-temperature { > > config false; > > type int8; > > } > > container diagnostics { > > config false; > > diagnostics true; <-- new flag here > > ... > > } > > Is all this leading up to a draft? ;) > > Kent // contributor > > *From: *Robert Wilton > *Date: *Monday, December 12, 2016 at 6:10 AM > *To: *Kent Watsen , Andy Bierman > *Cc: *"netmod@ietf.org" > *Subject: *Re: [netmod] Modelling different "levels" of data in YANG > > Hi Kent, > > On 10/12/2016 00:59, Kent Watsen wrote: > > > I prefer not to use specialized operations. > > Agreed, I was thinking something more along the lines of: > > > > > > > > > > <--- note this flag here > > > > > > > > > > > > > > > > > > > Thus explicitly requesting all the extra stuff get returned... > > Yes, that is roughly along the lines that I was thinking. > > Or building on draft-nmdsdt-netmod-revised-datastores: > - presuming the existing of a operation to generically=20 > return the contents of any datastore, > - defining a new datastore that contains the contents of=20 > the along with all config false schema nodes=20 > labelled as "diagnostics true". > > > > > > > > > > > > .... > > > > > Thanks, > Rob > > > > > In the usage model that Rob described, the service tech will be > > > setting diag-mode to 'system' then retrieving the extra > 'diag-stats', > > >then setting diag-mode back to 'user'. > > Right, but this does not seem ideal as the diag-mode toggle is a > global setting that would affect all clients for some window of > time, or do we envision diag-mode dropping the system down to > single-user mode? > > Kent // contributor > From nobody Thu Dec 15 12:11:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EA4129E7D for ; Thu, 15 Dec 2016 12:11:32 -0800 (PST) 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 cgjF93ETjwWd for ; Thu, 15 Dec 2016 12:11:30 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C0D0129D6D for ; Thu, 15 Dec 2016 12:11:24 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id q130so69268436qke.1 for ; Thu, 15 Dec 2016 12:11:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=r/Z1zKl4HjQXJPftuQ2KRjllf9C/BFrRRlhzH2tT0yw=; b=IAl+kEBr7grP+0xltI97CHRN4v19L5gkRIc7XBj16yD9m9jCiZcBGIC8Q7Ar1m+T59 0J+4mZ49jLsTF4wFHlAYWEjhmWOOArv9hCJkPFCm+tMDr4YMJbsFya4skd1O+9rchoaL xXX3M5pAxHL/pXv6JP2ljpxsPNFneAkac08lfQMJXbWwdiVV7/QMJUCBCrMW1jNHtwm8 mYFEw/ieV9QfSuX9R0YYscFBFM+RUwX4USf8zb1zlG6pDJuzNlVJy7nFUHr6SBtPe9Iy sitwBAJXENUTvHep78tktTSFZ58w3cX9RRd69C+Yog5rWMEe+XwITVCe3T+Nh3yj2IIh gv9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=r/Z1zKl4HjQXJPftuQ2KRjllf9C/BFrRRlhzH2tT0yw=; b=Nm+xzPhnRCthiRyfPSURLOYHmQRvXRvgAwWQW4mxm3zkZTSXFY3qZHrYgZ1r+jtXFE fmGkfDzG6nU0l239/Iw5fJsa3gwhIGl0tXz9fLwwy+vN8btQCVOkSleKmQbkMuFUuH/v GJLjiOnjjtLPWfgA9H/DS31qbB0ZQphJpolULOCl//Loe2Jdsza5iSHX/oMPLdttXBhd l3wBDvOouwP8v5ne3Fyt/gIx5JyyQE05beQMi+ZeIKk7qDSwSImrzpGr0rSmfMGg7WWr RK+fswdsQWJTqGPA99N6TTZTBlZSCd5Sh+PQYS0+ff+oqOWCIlIKVFf8rXW4QDHkOf7m NTRA== X-Gm-Message-State: AIkVDXL0C4j7v0UkspWvsotzXRiguxdoy+/TDu18bKNOCnKfnzSBIcFd9L9KYqESvsR9Ew== X-Received: by 10.55.31.2 with SMTP id f2mr2301146qkf.5.1481832683625; Thu, 15 Dec 2016 12:11:23 -0800 (PST) Received: from [10.245.39.167] ([192.64.64.178]) by smtp.gmail.com with ESMTPSA id w8sm1911821qta.25.2016.12.15.12.11.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 15 Dec 2016 12:11:23 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_11873E36-01BD-4628-838B-29BA2DD5CC99" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dean Bogdanovic In-Reply-To: <20161215.162440.325342744038767189.mbj@tail-f.com> Date: Thu, 15 Dec 2016 15:11:22 -0500 Message-Id: References: <20161215.162440.325342744038767189.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.3124) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Applied data store clarification in draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 20:11:33 -0000 --Apple-Mail=_11873E36-01BD-4628-838B-29BA2DD5CC99 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 15, 2016, at 10:24 AM, Martin Bjorklund wrote: >=20 > Hi, >=20 > Dean Bogdanovic > = wrote: >> Authors, >>=20 >> Need some clarification about applied data store >>=20 >> In the draft, applied data store can contain data from=20 >>=20 >> This data can come from several sources; from , from = dynamic >> configuration protocols (e.g., DHCP), or from control-plane = datastore. >>=20 >> The control-plane stores are not well clarified in my opinion >>=20 >> The model foresees control-plane datastores that are by definition >> not part of the persistent configuration of a device. In some >> contexts, these have been termed ephemeral datastores since the >> information is ephemeral, i.e., lost upon reboot. The = control-plane >> datastores interact with the rest of the system through the = >> or datastores, depending on the type of data = they >> contain. Note that the ephemeral datastore discussed in I2RS >> documents maps to a control-plane datastore in the revised = datastore >> model described here. >>=20 >> The other issue I have is with that control-plane data stores are >> shown connected to applied and operational-state. Which control plane >> data stores are directly influencing operational-state? >=20 > We wanted to allow for other to-be-defined data stores by showing > where they can fit into the architecture. When/if such a data store > is defined, it can relate to this architecture and explain exactly how > it fits in and how it affects applied config and/or operational state. >=20 >> Also, in the diagram control-plane protocols are connected only to >> operational-state data store. But isn=E2=80=99t the previous state = exchanged >> via control plane protocols taken into account when validating data >> that is copied into applied data store? >=20 > When you say "data that is copied into applied", are you referring to > the arrow between intended and applied? Yes, correct >=20 > The answer is that the arrows show data flow. The mechanism that > copies data from intended to applied will surely have to check > operational state and maybe physical resources in roder to do its job. But from the same diagram, it states that control protocols are not = impacting applied data store, except the operational state. This is = something I have to wrap my mind around it, as when the applied state is = computed, it is taking into account data exchanged via control = protocols. Dean >=20 >=20 > /martin --Apple-Mail=_11873E36-01BD-4628-838B-29BA2DD5CC99 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Dec 15, 2016, at 10:24 AM, Martin Bjorklund <mbj@tail-f.com> = wrote:

Hi,

Dean Bogdanovic <ivandean@gmail.com> wrote:
Authors,

Need some clarification about applied data store

In the draft, applied data store can contain = data from 

This data can come from several sources; from = <intended>, from dynamic
configuration protocols = (e.g., DHCP), or from control-plane datastore.

The control-plane stores are not well clarified in my = opinion

The model foresees control-plane = datastores that are by definition
  not part of = the persistent configuration of a device.  In some
  contexts, these have been termed ephemeral = datastores since the
  information is ephemeral, = i.e., lost upon reboot.  The control-plane
  datastores interact with the rest of the system = through the <applied>
  or = <operational-state> datastores, depending on the type of data = they
  contain.  Note that the ephemeral = datastore discussed in I2RS
  documents maps to = a control-plane datastore in the revised datastore
  model described here.

The other issue I have is with that control-plane data stores = are
shown connected to applied and operational-state. = Which control plane
data stores are directly influencing = operational-state?

We wanted to allow for other = to-be-defined data stores by showing
where they can fit into the architecture. =  When/if such a data store
is defined, it can relate to this = architecture and explain exactly how
it fits in and how it affects applied = config and/or operational state.

Also, in = the diagram control-plane protocols are connected only to
operational-state data store. But isn=E2=80=99t the previous = state exchanged
via control plane protocols taken into = account when validating data
that is copied into applied = data store?

When you say "data that is copied into = applied", are you referring to
the arrow between intended and = applied?

Yes, correct

The answer is that = the arrows show data flow.  The mechanism that
copies data from = intended to applied will surely have to check
operational state = and maybe physical resources in roder to do its job.

But from the same diagram, it states that control = protocols are not impacting applied data store, except the operational = state. This is something I have to wrap my mind around it, as when the = applied state is computed, it is taking into account data exchanged via = control protocols.

Dean




/martin

= --Apple-Mail=_11873E36-01BD-4628-838B-29BA2DD5CC99-- From nobody Thu Dec 15 13:58:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCBE129487 for ; Thu, 15 Dec 2016 13:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 515PKHZrsfVB for ; Thu, 15 Dec 2016 13:58:47 -0800 (PST) Received: from mail-pg0-f42.google.com (mail-pg0-f42.google.com [74.125.83.42]) (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 69D2112944D for ; Thu, 15 Dec 2016 13:58:47 -0800 (PST) Received: by mail-pg0-f42.google.com with SMTP id f188so24092776pgc.3 for ; Thu, 15 Dec 2016 13:58:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=EPeHtwLxmqLb8qHTLakKWrVEMDAZLx7TWlNgZ+E4jGg=; b=c2QB76AMSr0mMm/t52FRH2UhGuzGm07upo7O/EV389VDZP3tpuK0Ta6x6DVmYeJJHM pC2RyMikTPk3h5+h8+UKwys5Ali13vdwqHfE0VjeZO1ea0P0zUrraIMKL96AS8/UmSaA F+/JOyuYH0qKqc79Ba2B581qJOTR38kSw8mNbOuJ7ZZQ4u/8mWgia2vqDyuoS6QqH9iq wd/bkWngfJ6u18CRnNiCdWsmtIByih21KLVSQrOmslc7+YSMBQ2dXdoCw1j4rv6pGJhF p1hT90WOHS9HgVceWY8I7Y6sEZJTqh10SUWFL0uNmDr6OPhkshNOAtyhsT76PlsTEy70 UBeg== X-Gm-Message-State: AKaTC03E1fBegPrwODpxbaErTAwWlGAenIuSU8E2Chv/aDaOdcJJSAJxf5rhi/bj7QSwZjDk X-Received: by 10.84.210.167 with SMTP id a36mr6671064pli.125.1481839126474; Thu, 15 Dec 2016 13:58:46 -0800 (PST) Received: from [192.168.1.114] (c-50-168-48-150.hsd1.ca.comcast.net. [50.168.48.150]) by smtp.gmail.com with ESMTPSA id y2sm6652891pff.82.2016.12.15.13.58.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Dec 2016 13:58:45 -0800 (PST) To: netmod@ietf.org References: <20161215.160110.1071208720534123811.mbj@tail-f.com> <20161215152130.GA7351@elstar.local> From: Randy Presuhn Message-ID: <5227d6df-1de8-2e3e-2caf-066af7047d9a@alumni.stanford.edu> Date: Thu, 15 Dec 2016 13:58:44 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161215152130.GA7351@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] draft-ietf-netmod-entity issue #11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 21:58:49 -0000 Hi - My recollection is that part of the motivation for the use of zero-length strings as sentinel values in situations like this in MIB modules (rather than skipping the object instance) was to permit a clear distinction between "information not available" and "access denied". Randy On 12/15/2016 7:21 AM, Juergen Schoenwaelder wrote: > I do not think the goal should be to emulate SMIv2 compliance levels > using features. So I propose to do nothing about entity4CRCompliance. > > The other question (which should perhaps have been a separate issue) > is whether non-existing values are indicated by zero-length strings or > non-existing objects. I think in general we prefer to simply not > report those objects in the YANG world. If so, I am not sure whether > the goal to not depart too much from the ENTITY-MIB overrules > this. Note that there are a couple of objects where non-existing > values lead to zero-length string or other special values. (The > 'alias' description is kind of interesting - the server may set the > value of this node to a locally unique value; entPhysicalAlias says > something different, namely On the first instantiation ... is set to > the zero-length string.) > > Looking at the YANG fragment, I am also not sure how useful it is to > carry the 32 'something' restriction forward. Note that 32 means > unicode characters in YANG but space of the UTF-8 encoding of > characters for SMIv2 (since it all ends up being a restriction for the > OCTET STRING). Perhaps this deserves a feature, namely, whether an > implementation supports flexible names or restricts names according to > the SMIv2 ENTITY-MIB rules. > > /js > > On Thu, Dec 15, 2016 at 04:01:10PM +0100, Martin Bjorklund wrote: >> Hi, >> >> Issue https://github.com/netmod-wg/entity/issues/11 >> >> RFC 6933 introduced a new compliance level for constrained resources >> - entity4CRCompliance. Do we need a corresponding feature? >> >> In YANG, we cannot to the equivalent of compliance levels, so we would >> need to mark all nodes with some optional feature, except the few >> nodes that a constrained device would implement. >> >> OTOH, most nodes are already optional and config false. So a >> constrained server that doesn't know the serial number for example >> could just no return it. There is one catch though; the current text, >> copied from the MIB, says e.g.: >> >> If the manufacturer name string associated with the >> physical component is unknown to the server, then this >> node will contain a zero-length string. >> >> Maybe we should change this so that the object isn't returned at all >> instead of returning a zero-length string. >> >> >> >> /martin >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Dec 16 00:40:21 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6DA129861 for ; Fri, 16 Dec 2016 00:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 sjgq5LuZsvai for ; Fri, 16 Dec 2016 00:40:17 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D8F2126579 for ; Fri, 16 Dec 2016 00:40:17 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:344e:1067:fdc6:a0dd] (unknown [IPv6:2001:718:1a02:1:344e:1067:fdc6:a0dd]) by mail.nic.cz (Postfix) with ESMTPSA id 18CF360ABD; Fri, 16 Dec 2016 09:40:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1481877616; bh=DJRzBWdPuBm0Vhj3cJ2dQm3uwj2aBfN3JExewG26rpM=; h=From:Date:To; b=UXP/HbO8MKqX9ZdGUN7eX/cba5C1px9724OqFFtwDirFPHOwauqqSNt9L7zkQnaPs T5py3WFDXaxlRm0SKq6SfYI1KsehVzZZA08VqMYtH46eQnkP48wLOdc2+phdOV4tET r1yh9nKsrWksd0Kv+q0ZPdLkYxaolOPzutgQP11U= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6B004002@DGGEMA502-MBX.china.huawei.com> Date: Fri, 16 Dec 2016 09:40:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <86927E83-6B6B-4528-BEBF-DD98DB0E48DC@nic.cz> References: <991B70D8B4112A4699D5C00DDBBF878A6B004002@DGGEMA502-MBX.china.huawei.com> To: Rohit R Ranade X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NETMOD WG Subject: Re: [netmod] [Netconf] Leaf-list usage X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 08:40:19 -0000 Hi, > On 16 Dec 2016, at 06:44, Rohit R Ranade = wrote: >=20 > I was going through the ietf discussion for leaf-list subtree and = found a link = (https://www.ietf.org/mail-archive/web/netmod/current/msg01982.html) Your question belongs to to the NETMOD mailing list, so I am moving it = there. > =20 > A question that I have : > 1) Consider leaf-list f1=3D [1, 2, 3] in DB.. If I provide = condition on leaflist f1=3D[1], will it select [1,2,3] ? Will it always = be sub-set match ? How to get an exact match for the whole leaf-list. I assume you mean condition expressed in XPath. In this case you cannot = test whole lists on equality, but if you have must "f1 =3D 1"; then "f1": [1, 2, 3] would satisfy that condition. You could also write, for example, must "f1 =3D 1 and count(f1) =3D 1"; and then only "f1": [1] will match. Lada > =20 > =20 > =20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Dec 16 00:45:53 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6720126579 for ; Fri, 16 Dec 2016 00:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7nWWNJeyMVH for ; Fri, 16 Dec 2016 00:45:51 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3F812945D for ; Fri, 16 Dec 2016 00:38:36 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 56B451AE028C; Fri, 16 Dec 2016 09:38:35 +0100 (CET) Date: Fri, 16 Dec 2016 09:38:35 +0100 (CET) Message-Id: <20161216.093835.352524882984989660.mbj@tail-f.com> To: wlupton@broadband-forum.org From: Martin Bjorklund In-Reply-To: <88C30E13-A7DF-4919-9BCC-3969E2E6AF11@broadband-forum.org> References: <20161215.145729.704925239472686261.mbj@tail-f.com> <88C30E13-A7DF-4919-9BCC-3969E2E6AF11@broadband-forum.org> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] BBF work depending on draft-ietf-netmod-entity-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 08:45:52 -0000 Hi, William Lupton wrote: > The current draft-ietf-netmod-entity-01 defines ietf-hardware and > iana-entity modules. Is it intended that iana-entity will become > iana-hardware? Thanks, W. I don't have a strong opinion, but it probably makes sense. In the MIB, the word "entity" is just present in the MIB name: IANA-ENTITY-MIB defines the TC IANAPhysicalClass So in YANG we can do: iana-hardware defines the base identity physical-class (+ derived identities) /martin From nobody Fri Dec 16 00:52:37 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4ADF129AFD for ; Fri, 16 Dec 2016 00:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 7Cwr2dPN9BzG for ; Fri, 16 Dec 2016 00:52:33 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CA68129AF4 for ; Fri, 16 Dec 2016 00:52:33 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B8BC76CF; Fri, 16 Dec 2016 09:52:31 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id aM6xzQAptRaO; Fri, 16 Dec 2016 09:52:30 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 16 Dec 2016 09:52:31 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6FC9020078; Fri, 16 Dec 2016 09:52:31 +0100 (CET) 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 hb0XP9UOFWE4; Fri, 16 Dec 2016 09:52:31 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 05FF920077; Fri, 16 Dec 2016 09:52:30 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CBB213DBE667; Fri, 16 Dec 2016 09:52:30 +0100 (CET) Date: Fri, 16 Dec 2016 09:52:30 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20161216085230.GB9119@elstar.local> Mail-Followup-To: Martin Bjorklund , wlupton@broadband-forum.org, netmod@ietf.org References: <20161215.145729.704925239472686261.mbj@tail-f.com> <88C30E13-A7DF-4919-9BCC-3969E2E6AF11@broadband-forum.org> <20161216.093835.352524882984989660.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161216.093835.352524882984989660.mbj@tail-f.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] BBF work depending on draft-ietf-netmod-entity-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 08:52:36 -0000 On Fri, Dec 16, 2016 at 09:38:35AM +0100, Martin Bjorklund wrote: > Hi, > > William Lupton wrote: > > The current draft-ietf-netmod-entity-01 defines ietf-hardware and > > iana-entity modules. Is it intended that iana-entity will become > > iana-hardware? Thanks, W. > > I don't have a strong opinion, but it probably makes sense. In the > MIB, the word "entity" is just present in the MIB name: > > IANA-ENTITY-MIB defines the TC IANAPhysicalClass > > So in YANG we can do: > > iana-hardware defines the base identity physical-class (+ derived > identities) > Should the base identity be called 'entity-physical-class'? Or would 'hardware-class' be more appropriate? OK, all the descriptions talk about 'physical entity class'. I guess the question is how far we go with renaming. We also have features called entity-state and entity-sensor. (Also the short page title should probably be changed from 'YANG Entity Management' to 'YANG Hardware Management'.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Dec 16 00:53:06 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0951129B1B for ; Fri, 16 Dec 2016 00:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 vpJu8U9ZwMVh for ; Fri, 16 Dec 2016 00:53:04 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id EDDAE129712 for ; Fri, 16 Dec 2016 00:53:03 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id EDEDF1AE028C; Fri, 16 Dec 2016 09:53:02 +0100 (CET) Date: Fri, 16 Dec 2016 09:53:02 +0100 (CET) Message-Id: <20161216.095302.2017223317806480125.mbj@tail-f.com> To: randy_presuhn@alumni.stanford.edu From: Martin Bjorklund In-Reply-To: <5227d6df-1de8-2e3e-2caf-066af7047d9a@alumni.stanford.edu> References: <20161215.160110.1071208720534123811.mbj@tail-f.com> <20161215152130.GA7351@elstar.local> <5227d6df-1de8-2e3e-2caf-066af7047d9a@alumni.stanford.edu> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-entity issue #11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 08:53:06 -0000 Randy Presuhn wrote: > Hi - > > My recollection is that part of the motivation for the use of > zero-length strings as sentinel values in situations like this > in MIB modules (rather than skipping the object instance) was > to permit a clear distinction between "information not available" > and "access denied". Ok. But if this is an important use case, maybe we should try to have generic support for it, instead of using special values. Not all types have a natural value for "not available". I think that people often used these kinds of constructs in MIBs to avoid "holes" in the tables; I don't know if that applied to this MIB though. /martin > > Randy > > On 12/15/2016 7:21 AM, Juergen Schoenwaelder wrote: > > I do not think the goal should be to emulate SMIv2 compliance levels > > using features. So I propose to do nothing about entity4CRCompliance. > > > > The other question (which should perhaps have been a separate issue) > > is whether non-existing values are indicated by zero-length strings or > > non-existing objects. I think in general we prefer to simply not > > report those objects in the YANG world. If so, I am not sure whether > > the goal to not depart too much from the ENTITY-MIB overrules > > this. Note that there are a couple of objects where non-existing > > values lead to zero-length string or other special values. (The > > 'alias' description is kind of interesting - the server may set the > > value of this node to a locally unique value; entPhysicalAlias says > > something different, namely On the first instantiation ... is set to > > the zero-length string.) > > > > Looking at the YANG fragment, I am also not sure how useful it is to > > carry the 32 'something' restriction forward. Note that 32 means > > unicode characters in YANG but space of the UTF-8 encoding of > > characters for SMIv2 (since it all ends up being a restriction for the > > OCTET STRING). Perhaps this deserves a feature, namely, whether an > > implementation supports flexible names or restricts names according to > > the SMIv2 ENTITY-MIB rules. > > > > /js > > > > On Thu, Dec 15, 2016 at 04:01:10PM +0100, Martin Bjorklund wrote: > >> Hi, > >> > >> Issue https://github.com/netmod-wg/entity/issues/11 > >> > >> RFC 6933 introduced a new compliance level for constrained resources > >> - entity4CRCompliance. Do we need a corresponding feature? > >> > >> In YANG, we cannot to the equivalent of compliance levels, so we would > >> need to mark all nodes with some optional feature, except the few > >> nodes that a constrained device would implement. > >> > >> OTOH, most nodes are already optional and config false. So a > >> constrained server that doesn't know the serial number for example > >> could just no return it. There is one catch though; the current text, > >> copied from the MIB, says e.g.: > >> > >> If the manufacturer name string associated with the > >> physical component is unknown to the server, then this > >> node will contain a zero-length string. > >> > >> Maybe we should change this so that the object isn't returned at all > >> instead of returning a zero-length string. > >> > >> > >> > >> /martin > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Dec 16 01:08:55 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88612129462 for ; Fri, 16 Dec 2016 01:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.117 X-Spam-Level: X-Spam-Status: No, score=-7.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, 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 E8mJ_0AbilA9 for ; Fri, 16 Dec 2016 01:08:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC4D8129461 for ; Fri, 16 Dec 2016 01:08:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CXE88035; Fri, 16 Dec 2016 09:08:48 +0000 (GMT) Received: from DGGEMA406-HUB.china.huawei.com (10.3.20.47) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 16 Dec 2016 09:08:46 +0000 Received: from DGGEMA502-MBX.china.huawei.com ([169.254.2.221]) by DGGEMA406-HUB.china.huawei.com ([10.3.20.47]) with mapi id 14.03.0301.000; Fri, 16 Dec 2016 17:08:43 +0800 From: Rohit R Ranade To: Ladislav Lhotka Thread-Topic: [Netconf] Leaf-list usage Thread-Index: AdJXX2aakgSC5E/YQlukLb5liyQxs///qyGA//921FA= Date: Fri, 16 Dec 2016 09:08:43 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6B004060@DGGEMA502-MBX.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A6B004002@DGGEMA502-MBX.china.huawei.com> <86927E83-6B6B-4528-BEBF-DD98DB0E48DC@nic.cz> In-Reply-To: <86927E83-6B6B-4528-BEBF-DD98DB0E48DC@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.242.206] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5853AF21.0370, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.221, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6e8d07af43467808231f24a5ce75471e Archived-At: Cc: NETMOD WG Subject: Re: [netmod] [Netconf] Leaf-list usage X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 09:08:54 -0000 Hi, Consider we have 2 records as given below =20 (Rec1) 10 fred (Rec2) 20 fred barney wilma someother Q1 : Using subtree filtering which condition on the leaf-list node can the = user give such that he selects the record which contains foo=3Dfred only... [we can assume user does not know the value of "name"] Q2 : Also about the leaf-list, I have tried searching but have not found ho= w this leaf-list originated ? Whether XSD list is the representation for le= af-list in xsd ? The XSD list is represented slightly differently as per http://www.w3s= chools.com/xml/el_list.asp : I love XML Schema -----Original Message----- From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 Sent: 16 December, 2016 17:40 To: Rohit R Ranade Cc: NETMOD WG Subject: Re: [Netconf] Leaf-list usage Hi, > On 16 Dec 2016, at 06:44, Rohit R Ranade wrote: >=20 > I was going through the ietf discussion for leaf-list subtree and found a= link (https://www.ietf.org/mail-archive/web/netmod/current/msg01982.html) Your question belongs to to the NETMOD mailing list, so I am moving it ther= e. > =20 > A question that I have : > 1) Consider leaf-list f1=3D [1, 2, 3] in DB.. If I provide condition= on leaflist f1=3D[1], will it select [1,2,3] ? Will it always be sub-set = match ? How to get an exact match for the whole leaf-list. I assume you mean condition expressed in XPath. In this case you cannot tes= t whole lists on equality, but if you have must "f1 =3D 1"; then "f1": [1, 2, 3] would satisfy that condition. You could also write, for example, must "f1 =3D 1 and count(f1) =3D 1"; and then only "f1": [1] will match. Lada > =20 > =20 > =20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Dec 16 01:13:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA76E12997A for ; Fri, 16 Dec 2016 01:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 Rm-cxzbs2mlj for ; Fri, 16 Dec 2016 01:13:48 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 29B30129461 for ; Fri, 16 Dec 2016 01:13:48 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 5F5A81AE028C; Fri, 16 Dec 2016 10:13:47 +0100 (CET) Date: Fri, 16 Dec 2016 10:13:47 +0100 (CET) Message-Id: <20161216.101347.808412846580770182.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20161216085230.GB9119@elstar.local> References: <88C30E13-A7DF-4919-9BCC-3969E2E6AF11@broadband-forum.org> <20161216.093835.352524882984989660.mbj@tail-f.com> <20161216085230.GB9119@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] BBF work depending on draft-ietf-netmod-entity-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 09:13:50 -0000 Juergen Schoenwaelder wrote: > On Fri, Dec 16, 2016 at 09:38:35AM +0100, Martin Bjorklund wrote: > > Hi, > > > > William Lupton wrote: > > > The current draft-ietf-netmod-entity-01 defines ietf-hardware and > > > iana-entity modules. Is it intended that iana-entity will become > > > iana-hardware? Thanks, W. > > > > I don't have a strong opinion, but it probably makes sense. In the > > MIB, the word "entity" is just present in the MIB name: > > > > IANA-ENTITY-MIB defines the TC IANAPhysicalClass > > > > So in YANG we can do: > > > > iana-hardware defines the base identity physical-class (+ derived > > identities) > > > > Should the base identity be called 'entity-physical-class'? Or would > 'hardware-class' be more appropriate? OK, all the descriptions talk > about 'physical entity class'. I think it's ok to change both the name and descriptions to 'hardware'. > I guess the question is how far we go > with renaming. We also have features called entity-state and > entity-sensor. I think it makes sense to rename them as well. Then the word "entity" would be used wwhen referring to the MIBs. > (Also the short page title should probably be changed > from 'YANG Entity Management' to 'YANG Hardware Management'.) Yes, I found and fixed this bug yesterday. /martin From nobody Fri Dec 16 01:31:36 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2324A129462 for ; Fri, 16 Dec 2016 01:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 wVkh-RkYJKZR for ; Fri, 16 Dec 2016 01:31:33 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E7012129461 for ; Fri, 16 Dec 2016 01:31:32 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id CFFBE1AE028C; Fri, 16 Dec 2016 10:31:31 +0100 (CET) Date: Fri, 16 Dec 2016 10:31:31 +0100 (CET) Message-Id: <20161216.103131.190811205717956437.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20161215163027.GA7632@elstar.local> References: <20161215161434.GD7432@elstar.local> <20161215.172609.1950541994949692852.mbj@tail-f.com> <20161215163027.GA7632@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-entity issue #13 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 09:31:35 -0000 Juergen Schoenwaelder wrote: > On Thu, Dec 15, 2016 at 05:26:09PM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Thu, Dec 15, 2016 at 04:15:00PM +0100, Martin Bjorklund wrote: > > > > Hi, > > > > > > > > Issue https://github.com/netmod-wg/entity/issues/13 > > > > > > > > Should the model support pre-configuration of hardware components? > > > > The current model supports pre-configuration of components provided > > > > the operator knows the name of the component to be installed. A more > > > > useful model would use the parent component, class, and > > > > parent-rel-pos as identification. If the system detects a component > > > > and there is configuration available for the parent component, > > > > class, and parent-rel-pos then the system would instatiate the > > > > component with the provided name, and optionally additional > > > > parameters. > > > > > > > > See also various mails from Timothy Carey and Bart Bogaert on this > > > > issue. > > > > > > > > Personally, I think that we should add these nodes, since the ML > > > > comments indicated that pre configuration is pretty useful. > > > > > > > > > > I am still not sure what exactly this will do. I have been looking at > > > . > > > I am provisioning mfg-name (Preferred value is the manufacturer name > > > string actually printed on the component itself (if present).) but all > > > I have is that something of a certain expected class has been plugged > > > into a certain position of the parent container. Also note that > > > mfg-name scopes comparisons of other properties. I would have similar > > > questions concerning the model-name; how can a provisioning system > > > predict the 'vendor-specific model name identifier'? Or is the whole > > > idea that if I plug something that does not match, the component is > > > left in a special state (which one)? If this is the intention, then > > > this needs to be spelled out clearly somewhere. > > > > The current model works fine if the user looks into the state list and > > finds a component that he wants to configure. To do this, he uses the > > name of the component as found in the state list, and writes the > > config for this component. > > > > The current model also supports pre-configuration if the user somehow > > can predict the name of a component to-be-inserted. In this case he > > can write the config, and when the component is plugged in, the system > > will derive the component name, and check the config list for this > > name. This is a fragile model. > > > > In the proposed model, the user can provide configuration for a tuple > > (parent, class, parent-rel-pos). If the server finds a component in > > the state list (or such a component is later plugged in), then the > > corresponding config leafs are used for the state of this component > > (including the name). > > > > If you plug in something that doesn't match the config list, well that > > just means that nothing has been configured for this component, and > > the system will populate the state list accordingly. > > > > Well, this is not what I read out of > > https://www.ietf.org/mail-archive/web/netmod/current/msg17039.html > > since there are leafs like mfg-name and model-name that seem to be > hardware component properties. The description statements in this email are just copied from the corresponding config false nodes. I think they need to be rewritten; compare with serial-num. This text can probably be further improved. The idea is that the user probably would configure say mfg-name only if the system cannot detect it automatically. > And the config list is still indexed by > a name; so for list elements that have a (class, parent, position) > triple, the name would be arbitrary and not necessarily matching the > component name. I think that the idea is that if there is a matching triple, then the system MUST use the configured 'name' as the 'name' also in the state list. One reason for pre-confiugring these components is to be able to refer to them in other config. > Well, if you understand the edits,... I think the idea would be explained along these lines: The sytem conceptually behaves like this: 1. When a physical component is detected, the system will initialize an entry in the /hardware-state/component list. If there is an entry in /hardare/component list with a matching (class,parent,parent-rel-pos) triple, then the state entry is initialized with the configured values for all configured leafs (name, mfg-name, ...). If there is no such matching entry, the system assigns a 'name' in an implementation-specific manner. If there is an entry in /hardare/component list with a matching 'name' and where the triple (class,parent,parent-rel-pos) is not set, then the state entry is initialized with the configured values for all configured leafs (name, mfg-name, ...). Otherwise, the state entry is initialized with the detected values for all leafs. 2. If the /hardware/component list is modified (i.e., someone changed the config), then the system MUST behave as if it was restarted and followed the procedure in (1). /martin From nobody Fri Dec 16 01:47:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4165C1299D4 for ; Fri, 16 Dec 2016 01:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 Bi0Jb5CgX75t for ; Fri, 16 Dec 2016 01:47:30 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2BD129BBC for ; Fri, 16 Dec 2016 01:47:30 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 750C81AE028C; Fri, 16 Dec 2016 10:47:28 +0100 (CET) Date: Fri, 16 Dec 2016 10:47:28 +0100 (CET) Message-Id: <20161216.104728.1386223505634208297.mbj@tail-f.com> To: rohitrranade@huawei.com From: Martin Bjorklund In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6B004060@DGGEMA502-MBX.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A6B004002@DGGEMA502-MBX.china.huawei.com> <86927E83-6B6B-4528-BEBF-DD98DB0E48DC@nic.cz> <991B70D8B4112A4699D5C00DDBBF878A6B004060@DGGEMA502-MBX.china.huawei.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] [Netconf] Leaf-list usage X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 09:47:33 -0000 Rohit R Ranade wrote: > Hi, > Consider we have 2 records as given below > (Rec1) > 10 > fred > > (Rec2) > 20 > fred > barney > wilma > someother > > > Q1 : Using subtree filtering which condition on the leaf-list node can > the user give such that he selects the record which contains foo=fred > only... > [we can assume user does not know the value of "name"] fred > Q2 : Also about the leaf-list, I have tried searching but have not > found how this leaf-list originated ? 1 instance of a scalar type => leaf N instances of a scalar type => leaf-list 1 instance of a structure => container N instances of a structure => list > Whether XSD list is the > representation for leaf-list in xsd ? No. > The XSD list is represented slightly differently as per > http://www.w3schools.com/xml/el_list.asp : I love XML > Schema Correct. /martin From nobody Fri Dec 16 02:25:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06CE1294B8 for ; Fri, 16 Dec 2016 02:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.117 X-Spam-Level: X-Spam-Status: No, score=-7.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, 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 bmrGmYjs3Aey for ; Fri, 16 Dec 2016 02:25:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E8E2129BEF for ; Fri, 16 Dec 2016 02:24:37 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DCR56972; Fri, 16 Dec 2016 10:24:33 +0000 (GMT) Received: from DGGEMA402-HUB.china.huawei.com (10.3.20.43) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 16 Dec 2016 10:24:03 +0000 Received: from DGGEMA502-MBX.china.huawei.com ([169.254.2.221]) by DGGEMA402-HUB.china.huawei.com ([10.3.20.43]) with mapi id 14.03.0301.000; Fri, 16 Dec 2016 18:23:56 +0800 From: Rohit R Ranade To: Martin Bjorklund Thread-Topic: [netmod] [Netconf] Leaf-list usage Thread-Index: AdJXX2aakgSC5E/YQlukLb5liyQxs///qyGA//921FCAAJv0AP//cVRQ Date: Fri, 16 Dec 2016 10:23:55 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6B0040D7@DGGEMA502-MBX.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A6B004002@DGGEMA502-MBX.china.huawei.com> <86927E83-6B6B-4528-BEBF-DD98DB0E48DC@nic.cz> <991B70D8B4112A4699D5C00DDBBF878A6B004060@DGGEMA502-MBX.china.huawei.com> <20161216.104728.1386223505634208297.mbj@tail-f.com> In-Reply-To: <20161216.104728.1386223505634208297.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.242.206] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.5853C0E2.002D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.221, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0c87e00c32e5ec720ebbc7a012eec052 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] [Netconf] Leaf-list usage X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 10:25:09 -0000 Whether condition as below: fred barney Can select below record ? barney fred Basically , whether leaf-list with [barney, fred] are treated as same as le= af-list with [fred, barney] ? In ordered-by system the order does not matte= r to user, so it can be treated as same ? I think in the ordered-by user case, this treatment cannot be extended. Ple= ase clarify. -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: 16 December, 2016 18:47 To: Rohit R Ranade Cc: lhotka@nic.cz; netmod@ietf.org Subject: Re: [netmod] [Netconf] Leaf-list usage Rohit R Ranade wrote: > Hi, > Consider we have 2 records as given below =20 > (Rec1) > 10 > fred > > (Rec2) > 20 > fred > barney > wilma > someother > >=20 > Q1 : Using subtree filtering which condition on the leaf-list node can > the user give such that he selects the record which contains foo=3Dfred > only... > [we can assume user does not know the value of "name"] fred > Q2 : Also about the leaf-list, I have tried searching but have not > found how this leaf-list originated ? 1 instance of a scalar type =3D> leaf N instances of a scalar type =3D> leaf-list 1 instance of a structure =3D> container N instances of a structure =3D> list > Whether XSD list is the > representation for leaf-list in xsd ? No. > The XSD list is represented slightly differently as per > http://www.w3schools.com/xml/el_list.asp : I love XML > Schema Correct. /martin From nobody Fri Dec 16 03:03:13 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D66D129EDF for ; Fri, 16 Dec 2016 03:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 nWjQz_RTg8AY for ; Fri, 16 Dec 2016 03:03:10 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 33D89129EDD for ; Fri, 16 Dec 2016 03:03:10 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 79E221AE028C; Fri, 16 Dec 2016 12:03:07 +0100 (CET) Date: Fri, 16 Dec 2016 12:03:07 +0100 (CET) Message-Id: <20161216.120307.1407556532244977392.mbj@tail-f.com> To: rohitrranade@huawei.com From: Martin Bjorklund In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6B0040D7@DGGEMA502-MBX.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A6B004060@DGGEMA502-MBX.china.huawei.com> <20161216.104728.1386223505634208297.mbj@tail-f.com> <991B70D8B4112A4699D5C00DDBBF878A6B0040D7@DGGEMA502-MBX.china.huawei.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] [Netconf] Leaf-list usage X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 11:03:12 -0000 Rohit R Ranade wrote: > Whether condition as below: > > > fred > barney > > > Can select below record ? > > barney > fred > > > Basically , whether leaf-list with [barney, fred] are treated as same > as leaf-list with [fred, barney] ? In ordered-by system the order does > not matter to user, so it can be treated as same ? > I think in the ordered-by user case, this treatment cannot be > extended. Please clarify. For subtree filtering, the order of elements does not matter, so in the example above, the record will be selected. Whether the leaf-list is defined as ordered-by user or ordered-by system does not matter for the filter result. /martin > > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: 16 December, 2016 18:47 > To: Rohit R Ranade > Cc: lhotka@nic.cz; netmod@ietf.org > Subject: Re: [netmod] [Netconf] Leaf-list usage > > Rohit R Ranade wrote: > > Hi, > > Consider we have 2 records as given below > > (Rec1) > > 10 > > fred > > > > (Rec2) > > 20 > > fred > > barney > > wilma > > someother > > > > > > Q1 : Using subtree filtering which condition on the leaf-list node can > > the user give such that he selects the record which contains foo=fred > > only... > > [we can assume user does not know the value of "name"] > > > fred > > > > > Q2 : Also about the leaf-list, I have tried searching but have not > > found how this leaf-list originated ? > > 1 instance of a scalar type => leaf > N instances of a scalar type => leaf-list > 1 instance of a structure => container > N instances of a structure => list > > > Whether XSD list is the > > representation for leaf-list in xsd ? > > No. > > > The XSD list is represented slightly differently as per > > http://www.w3schools.com/xml/el_list.asp : I love XML > > Schema > > Correct. > > > /martin > From nobody Fri Dec 16 03:20:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37C4129FD2 for ; Fri, 16 Dec 2016 03:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSu9FspRLTw9 for ; Fri, 16 Dec 2016 03:20:17 -0800 (PST) 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 A1048129F1E for ; Fri, 16 Dec 2016 03:19:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5813; q=dns/txt; s=iport; t=1481887162; x=1483096762; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=YmvJtQO3l+ff3nX6PRS2MxNB6V1iVRGnHzXwqmQ5MT0=; b=mZVuiTcNkEW9Hcz1EJOj8+rnjWdcIKBVkqaGvy/itJ/pG0hH9SpKJqYq o14TvXrq5UOK1XOb3Qpn4nd7xbgKUFQXqLijx0NUxlymBWQDIU2YgT8JI tVmvzJz2ozt0X2rDU6Zx/O8qO5UTtaYKTCO6smxDRHnh350Y82vhI0gAU M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAQADzVNY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAXkuWI1Oc5Vlkn6CD4IJJoV8AoJTFAECAQEBAQEBAWI?= =?us-ascii?q?ohGgBAQEEEiABBUEQCxEDAQIBLk8IBgEMBgIBARcHiEkOmwsBkB6LGQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2GNoF9CIJUiiEBBJpwhlKKY4JFh1mGL4o0g2WEDx8?= =?us-ascii?q?3MVATDoV2PjSIfQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,357,1477958400"; d="scan'208";a="650778583" 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; 16 Dec 2016 11:19:20 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uBGBJJql021492; Fri, 16 Dec 2016 11:19:20 GMT To: Vladimir Vassilev , Kent Watsen References: <20161209120651.GA93531@elstar.local> <03ca5365-8640-5019-a9da-802ed248fb0f@cisco.com> <20161209.161712.2008691146816809010.mbj@tail-f.com> <541638F1-53CC-4656-B0A1-3BE650F3DB3B@juniper.net> <870394e0-28c9-cf62-5268-fa1ddfec06a8@cisco.com> <4E091DC6-99B2-4B34-A35E-B16A97AD0E6E@juniper.net> From: Robert Wilton Message-ID: <2407cc1a-c05b-4926-4c56-f26987d05b8a@cisco.com> Date: Fri, 16 Dec 2016 11:19:20 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Modelling different "levels" of data in YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 11:20:19 -0000 Hi, A variant on your suggestion: Rather than "diagnostics true;" a potentially more general way of handling this could be a generalized schema flag to indicate that a particular node (and its children) is never returned unless explicitly requested. E.g. "hidden: true" instead of "diagnostics: true". The data would only be returned if either (i) the filter explicitly indicated that hidden data should be returned (as per Kent's suggestion), or possibly also (ii) if the request path (or filter) explicitly specified the hidden node(s). Thanks, Rob On 15/12/2016 19:23, Vladimir Vassilev wrote: > Hi, > > Here is a summary of the proposed solutions so far: > > * The solution with introduction of YANG statement "diagnostics > true;", additional datastore and NETCONF protocol change. IMO that > sounds heavy but valid solution. > * The solution with RPC returning the data as output. IMO has the > limitation of not presenting the diagnostics data in the data tree (no > valid instance-identifiers to be used in notifications). But is the > simplest to have in place. > * The solution with RPC enabling the containers only for a certain > session. > > I thought also of this alternative solution: The solution is to avoid > clobbering the replies to s without filter or s with filter > matching only parent nodes of the "diagnostics state" container data > and not return those nodes in the reply except in the cases the filter > matches data nodes part of the diagnostics data explicitly. > > Example for /interfaces-state/interfaces/diagnostics (using xpath > filter for brevity but valid for the "subtree" case): > > These skip "diagnostics": > > > > These return "diagnostics": > > select="/interfaces-state/interface/diagnostics"\> > > > This looks like a violation of RFC 6241 6.2.5 bullet 12 but IMO the > container is non-mandatory diagnostics data so returning it only when > someone really wants it and not otherwise is the definition of the > solution to the problem. > > /Vladimir > > On 12/12/2016 05:47 PM, Kent Watsen wrote: >> >> Hi Robert, >> >> Youre right, it shouldve been the (not ). >> However, I think that its better to use a flag on the >> datastore, rather than to define a new >> datastore. Not only would it mimic how with-defaults works, but it >> also seems more intuitive from a retrieval perspective, as the >> diagnostics nodes could be sprinkled throughout a data model, and a >> single could return all nodes (not just the diagnostics) >> for a given subtree. Thoughts? >> >> Separately, from a modelling perspective, presumably there would have >> to be an additional flag to go with the config false flag, something >> like the below. Is this what you were envisioning? >> >> container thermostat { >> >> leaf configured-temperature { >> >> type int8; >> >> } >> >> leaf current-temperature { >> >> config false; >> >> type int8; >> >> } >> >> container diagnostics { >> >> config false; >> >> diagnostics true; <-- new flag here >> >> ... >> >> } >> >> Is all this leading up to a draft? ;) >> >> Kent // contributor >> >> *From: *Robert Wilton >> *Date: *Monday, December 12, 2016 at 6:10 AM >> *To: *Kent Watsen , Andy Bierman >> >> *Cc: *"netmod@ietf.org" >> *Subject: *Re: [netmod] Modelling different "levels" of data in YANG >> >> Hi Kent, >> >> On 10/12/2016 00:59, Kent Watsen wrote: >> >> > I prefer not to use specialized operations. >> >> Agreed, I was thinking something more along the lines of: >> >> >> >> >> >> >> >> >> >> <--- note this flag here >> >> >> >> > > >> >> >> >> >> >> >> >> >> >> >> >> >> >> Thus explicitly requesting all the extra stuff get returned... >> >> Yes, that is roughly along the lines that I was thinking. >> >> Or building on draft-nmdsdt-netmod-revised-datastores: >> - presuming the existing of a operation to generically >> return the contents of any datastore, >> - defining a new datastore that contains the contents >> of the along with all config false schema nodes >> labelled as "diagnostics true". >> >> >> >> >> >> >> >> >> >> >> >> .... >> >> >> >> >> Thanks, >> Rob >> >> >> >> > In the usage model that Rob described, the service tech will be >> >> > setting diag-mode to 'system' then retrieving the extra >> 'diag-stats', >> >> >then setting diag-mode back to 'user'. >> >> Right, but this does not seem ideal as the diag-mode toggle is a >> global setting that would affect all clients for some window of >> time, or do we envision diag-mode dropping the system down to >> single-user mode? >> >> Kent // contributor >> > . > From nobody Fri Dec 16 03:31:00 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371B3129D61 for ; Fri, 16 Dec 2016 03:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 FVbnG1xwL9u7 for ; Fri, 16 Dec 2016 03:30:56 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B7A12A137 for ; Fri, 16 Dec 2016 03:27:32 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 70F636E3; Fri, 16 Dec 2016 12:27:31 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ap57uCITmp1k; Fri, 16 Dec 2016 12:27:29 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 16 Dec 2016 12:27:30 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9AD7220078; Fri, 16 Dec 2016 12:27:30 +0100 (CET) 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 udqZcTBgBmBo; Fri, 16 Dec 2016 12:27:29 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AAA0520077; Fri, 16 Dec 2016 12:27:29 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 766C53DBED4E; Fri, 16 Dec 2016 12:27:28 +0100 (CET) Date: Fri, 16 Dec 2016 12:27:28 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20161216112728.GA9710@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20161215161434.GD7432@elstar.local> <20161215.172609.1950541994949692852.mbj@tail-f.com> <20161215163027.GA7632@elstar.local> <20161216.103131.190811205717956437.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161216.103131.190811205717956437.mbj@tail-f.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-entity issue #13 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 11:30:59 -0000 On Fri, Dec 16, 2016 at 10:31:31AM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Thu, Dec 15, 2016 at 05:26:09PM +0100, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > > On Thu, Dec 15, 2016 at 04:15:00PM +0100, Martin Bjorklund wrote: > > > > > Hi, > > > > > > > > > > Issue https://github.com/netmod-wg/entity/issues/13 > > > > > > > > > > Should the model support pre-configuration of hardware components? > > > > > The current model supports pre-configuration of components provided > > > > > the operator knows the name of the component to be installed. A more > > > > > useful model would use the parent component, class, and > > > > > parent-rel-pos as identification. If the system detects a component > > > > > and there is configuration available for the parent component, > > > > > class, and parent-rel-pos then the system would instatiate the > > > > > component with the provided name, and optionally additional > > > > > parameters. > > > > > > > > > > See also various mails from Timothy Carey and Bart Bogaert on this > > > > > issue. > > > > > > > > > > Personally, I think that we should add these nodes, since the ML > > > > > comments indicated that pre configuration is pretty useful. > > > > > > > > > > > > > I am still not sure what exactly this will do. I have been looking at > > > > . > > > > I am provisioning mfg-name (Preferred value is the manufacturer name > > > > string actually printed on the component itself (if present).) but all > > > > I have is that something of a certain expected class has been plugged > > > > into a certain position of the parent container. Also note that > > > > mfg-name scopes comparisons of other properties. I would have similar > > > > questions concerning the model-name; how can a provisioning system > > > > predict the 'vendor-specific model name identifier'? Or is the whole > > > > idea that if I plug something that does not match, the component is > > > > left in a special state (which one)? If this is the intention, then > > > > this needs to be spelled out clearly somewhere. > > > > > > The current model works fine if the user looks into the state list and > > > finds a component that he wants to configure. To do this, he uses the > > > name of the component as found in the state list, and writes the > > > config for this component. > > > > > > The current model also supports pre-configuration if the user somehow > > > can predict the name of a component to-be-inserted. In this case he > > > can write the config, and when the component is plugged in, the system > > > will derive the component name, and check the config list for this > > > name. This is a fragile model. > > > > > > In the proposed model, the user can provide configuration for a tuple > > > (parent, class, parent-rel-pos). If the server finds a component in > > > the state list (or such a component is later plugged in), then the > > > corresponding config leafs are used for the state of this component > > > (including the name). > > > > > > If you plug in something that doesn't match the config list, well that > > > just means that nothing has been configured for this component, and > > > the system will populate the state list accordingly. > > > > > > > Well, this is not what I read out of > > > > https://www.ietf.org/mail-archive/web/netmod/current/msg17039.html > > > > since there are leafs like mfg-name and model-name that seem to be > > hardware component properties. > > The description statements in this email are just copied from the > corresponding config false nodes. I think they need to be rewritten; > compare with serial-num. This text can probably be further improved. > The idea is that the user probably would configure say mfg-name only > if the system cannot detect it automatically. I still wonder why it could be useful to provision things like the mfg-name or the serial-num. I would rather like to know what is really there instead of overwriting these properties. > > And the config list is still indexed by > > a name; so for list elements that have a (class, parent, position) > > triple, the name would be arbitrary and not necessarily matching the > > component name. > > I think that the idea is that if there is a matching triple, then the > system MUST use the configured 'name' as the 'name' also in the state > list. One reason for pre-confiugring these components is to be able > to refer to them in other config. This may make sense. > > Well, if you understand the edits,... > > I think the idea would be explained along these lines: > > The sytem conceptually behaves like this: > > 1. When a physical component is detected, the system will initialize > an entry in the /hardware-state/component list. > > If there is an entry in /hardare/component list with a matching > (class,parent,parent-rel-pos) triple, then the state entry is > initialized with the configured values for all configured leafs > (name, mfg-name, ...). > > If there is no such matching entry, the system assigns a 'name' > in an implementation-specific manner. > > If there is an entry in /hardare/component list with a matching > 'name' and where the triple (class,parent,parent-rel-pos) is not > set, then the state entry is initialized with the configured > values for all configured leafs (name, mfg-name, ...). > > Otherwise, the state entry is initialized with the detected values > for all leafs. > > 2. If the /hardware/component list is modified (i.e., someone changed > the config), then the system MUST behave as if it was restarted > and followed the procedure in (1). This way of pre-configuring that name may indeed make sense. Lets see if this is what BBF really wanted. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Dec 16 03:40:19 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FFE12A078 for ; Fri, 16 Dec 2016 03:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 jyy7QlnaqUBr for ; Fri, 16 Dec 2016 03:40:15 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C459C12A077 for ; Fri, 16 Dec 2016 03:38:18 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id C9B711AE028C; Fri, 16 Dec 2016 12:38:17 +0100 (CET) Date: Fri, 16 Dec 2016 12:38:17 +0100 (CET) Message-Id: <20161216.123817.888297015862938973.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20161216112728.GA9710@elstar.local> References: <20161215163027.GA7632@elstar.local> <20161216.103131.190811205717956437.mbj@tail-f.com> <20161216112728.GA9710@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-entity issue #13 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 11:40:17 -0000 Juergen Schoenwaelder wrote: > On Fri, Dec 16, 2016 at 10:31:31AM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Thu, Dec 15, 2016 at 05:26:09PM +0100, Martin Bjorklund wrote: > > > > Juergen Schoenwaelder wrote: > > > > > On Thu, Dec 15, 2016 at 04:15:00PM +0100, Martin Bjorklund wrote: > > > > > > Hi, > > > > > > > > > > > > Issue https://github.com/netmod-wg/entity/issues/13 > > > > > > > > > > > > Should the model support pre-configuration of hardware components? > > > > > > The current model supports pre-configuration of components provided > > > > > > the operator knows the name of the component to be installed. A more > > > > > > useful model would use the parent component, class, and > > > > > > parent-rel-pos as identification. If the system detects a component > > > > > > and there is configuration available for the parent component, > > > > > > class, and parent-rel-pos then the system would instatiate the > > > > > > component with the provided name, and optionally additional > > > > > > parameters. > > > > > > > > > > > > See also various mails from Timothy Carey and Bart Bogaert on this > > > > > > issue. > > > > > > > > > > > > Personally, I think that we should add these nodes, since the ML > > > > > > comments indicated that pre configuration is pretty useful. > > > > > > > > > > > > > > > > I am still not sure what exactly this will do. I have been looking at > > > > > . > > > > > I am provisioning mfg-name (Preferred value is the manufacturer name > > > > > string actually printed on the component itself (if present).) but all > > > > > I have is that something of a certain expected class has been plugged > > > > > into a certain position of the parent container. Also note that > > > > > mfg-name scopes comparisons of other properties. I would have similar > > > > > questions concerning the model-name; how can a provisioning system > > > > > predict the 'vendor-specific model name identifier'? Or is the whole > > > > > idea that if I plug something that does not match, the component is > > > > > left in a special state (which one)? If this is the intention, then > > > > > this needs to be spelled out clearly somewhere. > > > > > > > > The current model works fine if the user looks into the state list and > > > > finds a component that he wants to configure. To do this, he uses the > > > > name of the component as found in the state list, and writes the > > > > config for this component. > > > > > > > > The current model also supports pre-configuration if the user somehow > > > > can predict the name of a component to-be-inserted. In this case he > > > > can write the config, and when the component is plugged in, the system > > > > will derive the component name, and check the config list for this > > > > name. This is a fragile model. > > > > > > > > In the proposed model, the user can provide configuration for a tuple > > > > (parent, class, parent-rel-pos). If the server finds a component in > > > > the state list (or such a component is later plugged in), then the > > > > corresponding config leafs are used for the state of this component > > > > (including the name). > > > > > > > > If you plug in something that doesn't match the config list, well that > > > > just means that nothing has been configured for this component, and > > > > the system will populate the state list accordingly. > > > > > > > > > > Well, this is not what I read out of > > > > > > https://www.ietf.org/mail-archive/web/netmod/current/msg17039.html > > > > > > since there are leafs like mfg-name and model-name that seem to be > > > hardware component properties. > > > > The description statements in this email are just copied from the > > corresponding config false nodes. I think they need to be rewritten; > > compare with serial-num. This text can probably be further improved. > > The idea is that the user probably would configure say mfg-name only > > if the system cannot detect it automatically. > > I still wonder why it could be useful to provision things like the > mfg-name or the serial-num. I would rather like to know what is really > there instead of overwriting these properties. Note that entPhysicalSerialNum is read-write in the MIB. I assume that the reason for this is that operators can use this as an inventory list, and manually enter the values that the system cannot detect automatically. > > > And the config list is still indexed by > > > a name; so for list elements that have a (class, parent, position) > > > triple, the name would be arbitrary and not necessarily matching the > > > component name. > > > > I think that the idea is that if there is a matching triple, then the > > system MUST use the configured 'name' as the 'name' also in the state > > list. One reason for pre-confiugring these components is to be able > > to refer to them in other config. > > This may make sense. > > > > Well, if you understand the edits,... > > > > I think the idea would be explained along these lines: > > > > The sytem conceptually behaves like this: > > > > 1. When a physical component is detected, the system will initialize > > an entry in the /hardware-state/component list. > > > > If there is an entry in /hardare/component list with a matching > > (class,parent,parent-rel-pos) triple, then the state entry is > > initialized with the configured values for all configured leafs > > (name, mfg-name, ...). > > > > If there is no such matching entry, the system assigns a 'name' > > in an implementation-specific manner. > > > > If there is an entry in /hardare/component list with a matching > > 'name' and where the triple (class,parent,parent-rel-pos) is not > > set, then the state entry is initialized with the configured > > values for all configured leafs (name, mfg-name, ...). > > > > Otherwise, the state entry is initialized with the detected values > > for all leafs. > > > > 2. If the /hardware/component list is modified (i.e., someone changed > > the config), then the system MUST behave as if it was restarted > > and followed the procedure in (1). > > This way of pre-configuring that name may indeed make sense. Lets see > if this is what BBF really wanted. /martin From nobody Fri Dec 16 03:49:01 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3371297C1 for ; Fri, 16 Dec 2016 03:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 UcXZZ2gnJVxo for ; Fri, 16 Dec 2016 03:48:58 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BCF5129854 for ; Fri, 16 Dec 2016 03:48:58 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:344e:1067:fdc6:a0dd] (unknown [IPv6:2001:718:1a02:1:344e:1067:fdc6:a0dd]) by mail.nic.cz (Postfix) with ESMTPSA id 209D360A4B for ; Fri, 16 Dec 2016 12:48:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1481888937; bh=99PVEI4EteEFqm28EqkZxYYXnzH5bTVeBNqjAhRrGzc=; h=From:Date:To; b=qHWPRgVUD8PHCypTc3TsGV1y152BgiP8xFiD/3XH2T+O7fWWm0khYgLexWYlORzMs JGvXtLba2ifn/19CchYIg311CSw92xesEFC4S2dYiOCHA8MeOqtghoFcZ4lC3UGlE/ F2698ptggCwMjp9elHX9PXdbunpKDo/3V8rEE7pk= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Fri, 16 Dec 2016 12:48:56 +0100 To: NETMOD WG X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: [netmod] top-level mandatory nodes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 11:49:00 -0000 Hi, 6087bis says in sec. 5.10: Top-level database data definitions MUST NOT be mandatory. It think this makes sense only for config=3Dtrue nodes. It is absolutely = OK to have mandatory top-level state data, and some published modules = already have them, e.g. ietf-yang-library. Also, I wonder - should the text use "datastore" rather than "database"? Lada =20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Dec 16 04:13:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EFA129C91; Fri, 16 Dec 2016 04:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBchb6p-bNyp; Fri, 16 Dec 2016 04:13:37 -0800 (PST) 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 6B39C129CD1; Fri, 16 Dec 2016 04:13:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2867; q=dns/txt; s=iport; t=1481890414; x=1483100014; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=5SjAsb3YwC5Zj2/Qf+OAWitkmPiP1nR+EdOkoeSBjbQ=; b=R4pRdfL9nLpmh8t2bJPO1FNhdv1hKf6UCaVxgR409D3Sw8H0qGtZIZdX SVnRbNcWPTvpMHoHSXCfRKUoHDlmDKI0yag2AYjcSNgZpao9goJlCnYii b9ReXB9EcXsRQvLve23C7EhzBobjheZPn0Kb0qU70l73vQ1G/syRTMcHg o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAQDE2VNY/xbLJq1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM3AQEBAQF5LliNTnOVZZUNggkCHQuFLkoCglMUAQIBAQEBAQE?= =?us-ascii?q?BYiiEaAEBAQMBAQEQJjYLDAQLDgMEAQEBJwcnHwkIBgEMBgIBAR6IQQgOmmABj?= =?us-ascii?q?EkBg1SLGwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFMoYEgX0IglSEEgYLAYV9AQS?= =?us-ascii?q?acJE1gXSFA4MnI4YMijSDZYQPHzdjHhMOKYVNPjSGT4IuAQEB?= X-IronPort-AV: E=Sophos;i="5.33,357,1477958400"; d="scan'208";a="690499544" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Dec 2016 12:13:32 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uBGCDVsm025328; Fri, 16 Dec 2016 12:13:32 GMT To: Iftekhar Hussain , Lou Berger , NetMod WG References: <4010c7f4de4941e1b41c2665926eb574@sv-ex13-prd1.infinera.com> From: Robert Wilton Message-ID: <3fca5e5e-8374-7ec2-d340-7b2240833b8e@cisco.com> Date: Fri, 16 Dec 2016 12:13:31 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <4010c7f4de4941e1b41c2665926eb574@sv-ex13-prd1.infinera.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: NetMod WG Chairs , "draft-wilton-netmod-intf-vlan-yang@ietf.org" Subject: Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 12:13:39 -0000 Hi Iftekhar, Thanks for the comments and support, please see inline ... On 15/12/2016 18:55, Iftekhar Hussain wrote: > Yes/support. > > I have read this draft and believe it would be very useful for enabling many Layer 2 and Layer 3 services. > > However, I do have few comments and that I would like the authors to address once the document is a WG document. > > a) Suggest to replace this text: > "These modules allow IETF forwarding protocols (such as IPv6 and VPLS) ..." > with the following text: > " These modules allow configuration Layer 2 and Layer 3 subinterfaces (e.g., attachment circuits) for providing for IETF L2VPN (e.g., VPWS, VPLS, EVPN) and L3VPN services". Yes, OK. I think that this text can be tweaked. > > b) The document should clearly identify the scope. For example, suggest replace this text: > "... to interoperate with VLAN tagged traffic orginated from an IEEE 802.1Q compliant bridge". > with the following text: > "... to interoperate with traffic originated from an IEEE 802.1D, 802.1Q, or 802.1AD compliant bridge." > > Note: In the data model, the draft is talking about untagged as well as 802.1AD (see "tag type (802.1Q or 802.1ad)") Yes, it should mention 802.1D. 802.1ad is part of 802.1Q. The draft would be best referring to S-VLANs vs C-VLANs rather than 802.1Q vs 802.1ad. > > c) Are there any sub-interface level common statistics counters that the model should address? Currently, I don't see any. A sub-interface is still just an interface, so by default it would pick up all of RFC7223 interface statistics. Were you looking for any additional specific statistics? However, it would probably be useful to have a counter on the parent trunk to indicate the number of packets that haven't been matched to any sub-interface, so I think that I should add that. Thanks, Rob > > Thanks, > Iftekhar > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Monday, December 12, 2016 3:32 PM > To: NetMod WG > Cc: NetMod WG Chairs > Subject: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04 > > All, > > This is start of a two week* poll on making > draft-wilton-netmod-intf-vlan-yang-04 a NetMod working group document. > > Please send email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your reservations with the document. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. > > * Given the holiday, the poll ends December 28. > > Thank you, > NetMod WG Chairs > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Fri Dec 16 05:24:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404B81295CC for ; Fri, 16 Dec 2016 05:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 ITnYEgoy_O5a for ; Fri, 16 Dec 2016 05:24:27 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBBEB129ADD for ; Fri, 16 Dec 2016 05:24:26 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B34FB6F8; Fri, 16 Dec 2016 14:24:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id lqpyzeZVyBdh; Fri, 16 Dec 2016 14:24:24 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 16 Dec 2016 14:24:25 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7696C20079; Fri, 16 Dec 2016 14:24:25 +0100 (CET) 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 YtGoPIvGxhyU; Fri, 16 Dec 2016 14:24:25 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 387A220077; Fri, 16 Dec 2016 14:24:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1D5B73DBF14D; Fri, 16 Dec 2016 14:24:25 +0100 (CET) Date: Fri, 16 Dec 2016 14:24:25 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20161216132425.GB443@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD WG References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NETMOD WG Subject: Re: [netmod] top-level mandatory nodes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 13:24:29 -0000 On Fri, Dec 16, 2016 at 12:48:56PM +0100, Ladislav Lhotka wrote: > Hi, > > 6087bis says in sec. 5.10: > > Top-level database data definitions MUST NOT be mandatory. > > It think this makes sense only for config=true nodes. It is absolutely OK to have mandatory top-level state data, and some published modules already have them, e.g. ietf-yang-library. > > Also, I wonder - should the text use "datastore" rather than "database"? > We should not use the term 'database'. I do no think 'datastore' is the appropriate replacement. Since this document talks about YANG, I think the proper terms are data tree and schema tree (or any other terms that the YANG specification defines). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Dec 16 05:33:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57732129A3A for ; Fri, 16 Dec 2016 05:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 Y4CyjpYmFG9L for ; Fri, 16 Dec 2016 05:33:06 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF314129A4D for ; Fri, 16 Dec 2016 05:33:06 -0800 (PST) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 23B9461042 for ; Fri, 16 Dec 2016 14:33:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1481895185; bh=DgJ/rTAGcY7wBHmJN9qkPqe/CBl0AERInl6y4ilJ4i0=; h=From:Date:To; b=IYha9arXofKhfc2xpULIH+aa/rQkHtAr4MNYkkHw6kjRriNzIhxqjCJZ26jlfcC1p YFjOIFQehTmTH+bObDEMB1ndLZkEHNkuGB8I6FqQdfI5fthDyPgj0KjoVedFwcQBFN JJiTfNxtlbAUfK0Jy+fGXWUmWkD6ZRKnbQy5g8cA= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <92694F93-CCD0-4BAD-95D2-F57CF5A8F1CE@nic.cz> Date: Fri, 16 Dec 2016 14:33:04 +0100 To: NETMOD WG X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: [netmod] RFC 7277: ip-address-origin X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 13:33:08 -0000 Hi, I think that one important enum is missing in the "ip-address-origin" = typedef: enum link-local { description "Indicates a link-local address."; reference "RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses RFC 4291: IP Version 6 Addressing Architecture"; Would an erratum be possible/useful? Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Dec 16 05:36:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E29E1295B0 for ; Fri, 16 Dec 2016 05:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 e_jclCq-7Tup for ; Fri, 16 Dec 2016 05:36:52 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A76581294FE for ; Fri, 16 Dec 2016 05:36:52 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:344e:1067:fdc6:a0dd] (unknown [IPv6:2001:718:1a02:1:344e:1067:fdc6:a0dd]) by mail.nic.cz (Postfix) with ESMTPSA id 29BD5600B7; Fri, 16 Dec 2016 14:36:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1481895411; bh=4kAcbkGjHpHm8UXB/qr98VUNrm2hp4bioLEgJ8R/fxY=; h=From:Date:To; b=cQP8e5WxYO0aXkLxwofDI7VFs5co7mqNg+lIQWoOsm/V8g2OSeU09MMGNWHrtvx18 ILGxpAwtJMQ32bG211Z7so4AlusV/uYFMSUcbc9Q46sTbjWZxbisOUu06ORuvkgjcS 0jIwJtuls6ugU5BQZU09VhjhkYFz1ShIyvHrqDiI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20161216132425.GB443@elstar.local> Date: Fri, 16 Dec 2016 14:36:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <381D9948-23B1-4FFC-A476-4F96890C16BD@nic.cz> References: <20161216132425.GB443@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NETMOD WG Subject: Re: [netmod] top-level mandatory nodes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 13:36:54 -0000 > On 16 Dec 2016, at 14:24, Juergen Schoenwaelder = wrote: >=20 > On Fri, Dec 16, 2016 at 12:48:56PM +0100, Ladislav Lhotka wrote: >> Hi, >>=20 >> 6087bis says in sec. 5.10: >>=20 >> Top-level database data definitions MUST NOT be mandatory. >>=20 >> It think this makes sense only for config=3Dtrue nodes. It is = absolutely OK to have mandatory top-level state data, and some published = modules already have them, e.g. ietf-yang-library. >>=20 >> Also, I wonder - should the text use "datastore" rather than = "database"? >>=20 >=20 > We should not use the term 'database'. I do no think 'datastore' is > the appropriate replacement. Since this document talks about YANG, I > think the proper terms are data tree and schema tree (or any other > terms that the YANG specification defines). Right - I think the following should do: OLD Top-level database data definitions MUST NOT be mandatory. NEW Top-level data nodes that represent configuration MUST NOT be = mandatory. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Dec 16 05:39:47 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6AB129CC1 for ; Fri, 16 Dec 2016 05:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 oMFu6ENqOA0k for ; Fri, 16 Dec 2016 05:39:45 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22404129CE4 for ; Fri, 16 Dec 2016 05:39:45 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E479E9A; Fri, 16 Dec 2016 14:39:43 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Sf7gehQreJ_6; Fri, 16 Dec 2016 14:39:42 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 16 Dec 2016 14:39:43 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9CBB12007A; Fri, 16 Dec 2016 14:39:43 +0100 (CET) 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 N3lP4vCr_78h; Fri, 16 Dec 2016 14:39:43 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C7C320077; Fri, 16 Dec 2016 14:39:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 524E83DBF2BE; Fri, 16 Dec 2016 14:39:42 +0100 (CET) Date: Fri, 16 Dec 2016 14:39:42 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20161216133941.GD443@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD WG References: <92694F93-CCD0-4BAD-95D2-F57CF5A8F1CE@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92694F93-CCD0-4BAD-95D2-F57CF5A8F1CE@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NETMOD WG Subject: Re: [netmod] RFC 7277: ip-address-origin X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 13:39:47 -0000 Lada, when would I use link-layer and when link-local? Perhaps all needed is a clarification of the description of link-layer? (Perhaps link-local would have been a better name but too late now...) An RFC 3927 address could also be a 'random' address. In fact, the 169.254/16 prefix kind of hings at RFC 3927 addresses falling under 'random'. /js On Fri, Dec 16, 2016 at 02:33:04PM +0100, Ladislav Lhotka wrote: > Hi, > > I think that one important enum is missing in the "ip-address-origin" typedef: > > enum link-local { > description > "Indicates a link-local address."; > reference > "RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses > RFC 4291: IP Version 6 Addressing Architecture"; > > Would an erratum be possible/useful? > > Lada > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > 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 Fri Dec 16 05:40:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A20129CE4 for ; Fri, 16 Dec 2016 05:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 lZKWcklvRP6f for ; Fri, 16 Dec 2016 05:40:34 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C21129CDC for ; Fri, 16 Dec 2016 05:40:34 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 54101704; Fri, 16 Dec 2016 14:40:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id aJXkOL1m0uFW; Fri, 16 Dec 2016 14:40:32 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 16 Dec 2016 14:40:33 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0862420079; Fri, 16 Dec 2016 14:40:33 +0100 (CET) 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 k0zdxdTmThLI; Fri, 16 Dec 2016 14:40:32 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A903920077; Fri, 16 Dec 2016 14:40:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 956693DBF2F3; Fri, 16 Dec 2016 14:40:32 +0100 (CET) Date: Fri, 16 Dec 2016 14:40:32 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20161216134032.GE443@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD WG References: <20161216132425.GB443@elstar.local> <381D9948-23B1-4FFC-A476-4F96890C16BD@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <381D9948-23B1-4FFC-A476-4F96890C16BD@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NETMOD WG Subject: Re: [netmod] top-level mandatory nodes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 13:40:36 -0000 On Fri, Dec 16, 2016 at 02:36:50PM +0100, Ladislav Lhotka wrote: > > > On 16 Dec 2016, at 14:24, Juergen Schoenwaelder wrote: > > > > On Fri, Dec 16, 2016 at 12:48:56PM +0100, Ladislav Lhotka wrote: > >> Hi, > >> > >> 6087bis says in sec. 5.10: > >> > >> Top-level database data definitions MUST NOT be mandatory. > >> > >> It think this makes sense only for config=true nodes. It is absolutely OK to have mandatory top-level state data, and some published modules already have them, e.g. ietf-yang-library. > >> > >> Also, I wonder - should the text use "datastore" rather than "database"? > >> > > > > We should not use the term 'database'. I do no think 'datastore' is > > the appropriate replacement. Since this document talks about YANG, I > > think the proper terms are data tree and schema tree (or any other > > terms that the YANG specification defines). > > Right - I think the following should do: > > OLD > > Top-level database data definitions MUST NOT be mandatory. > > NEW > > Top-level data nodes that represent configuration MUST NOT be mandatory. > There are a few more occurances of the word 'database' that should all be rewritten to use YANG terminology. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Dec 16 05:40:48 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4261B129D05 for ; Fri, 16 Dec 2016 05:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDroNeFjWlr3 for ; Fri, 16 Dec 2016 05:40:40 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3DBA129CED for ; Fri, 16 Dec 2016 05:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=878; q=dns/txt; s=iport; t=1481895640; x=1483105240; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=SoWDUkiXpVjidNWQ+5bhVOUG09Whud7CHc2Jpv4gQYQ=; b=ZW6+BP60fVwItGDX2j/I1jUV4BV+y6sClCO+Yz+iTfuw66jsfXkN99Or 2y2xsn12uPNvlEcytokofpdVlJYcyUheJdZvS/Q3OxwXWjaNYdkIb7dVR wR/ku3jHzrdQ+t58BMcqlYCEiXFGShrwvGhtjsay9TqypsfK/6XCfYd9a 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQBR7VNY/5xdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAR9agQYHjUerZYIJHwuFLkoCghU/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGkCBAEBEFwbAgEIEjQnCxcOAgQBEiKISQ6aAwGQHosYAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEZBYsPgT2IZAWPP4sxAZE0kE2SJwEfN4EiKYNhgWxyh3CBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,357,1477958400"; d="scan'208";a="359897270" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Dec 2016 13:40:39 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id uBGDedEQ005033 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 16 Dec 2016 13:40:39 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 16 Dec 2016 08:40:38 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 16 Dec 2016 08:40:38 -0500 From: "Acee Lindem (acee)" To: Ladislav Lhotka , NETMOD WG Thread-Topic: [netmod] RFC 7277: ip-address-origin Thread-Index: AQHSV6D2DRJSber8YkWxrK161WtIgKEKlLKA Date: Fri, 16 Dec 2016 13:40:38 +0000 Message-ID: References: <92694F93-CCD0-4BAD-95D2-F57CF5A8F1CE@nic.cz> In-Reply-To: <92694F93-CCD0-4BAD-95D2-F57CF5A8F1CE@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.204] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0C0742D8B79AE04B97EF994F0012551C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] RFC 7277: ip-address-origin X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 13:40:47 -0000 Semantically, link-local seems more like a type of address than the origin of the address. Also, the enum already has the type =B3link-layer=B2. Thanks, Acee=20 On 12/16/16, 8:33 AM, "netmod on behalf of Ladislav Lhotka" wrote: >Hi, > >I think that one important enum is missing in the "ip-address-origin" >typedef: > > enum link-local { > description > "Indicates a link-local address."; > reference > "RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses > RFC 4291: IP Version 6 Addressing Architecture"; > >Would an erratum be possible/useful? > >Lada > >-- >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: E74E8C0C > > > > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Dec 16 05:42:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E6A129605 for ; Fri, 16 Dec 2016 05:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNfrvDDWCqNm for ; Fri, 16 Dec 2016 05:42:29 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44F9A129A46 for ; Fri, 16 Dec 2016 05:42:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1769; q=dns/txt; s=iport; t=1481895749; x=1483105349; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BI5B5RDxNQ3aKV6Wj45VJnWBdVG2rgij+mmsScTOxjk=; b=LotbInJU6Z9PWbbqjk88BFYUC8g1Eyl+u98fgQ2tfLDlrbgNhpBH9y0O EZu2y/h6yyYW6+26obflML46aiaWD3VQlQ7Wn2YcLvMuuPlS6H0XNbLNT HbmJQr7xVofm3WdKkNN4nnTTGvimusekaPCVFiRhi3P+ZLXpsxUtEKpay E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQDN7lNY/5NdJa1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM3AQEBAQEfWoEGB41HlliVDYIJHwuFLkoCghU/FAECAQEBAQE?= =?us-ascii?q?BAWIohGkBAQQBARBcCw4CAgEIDgICBi4bDAsXDgIEAQ0FIohJDpoGAZAeixgBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEdBYsKgT2DAyEmhRoFjwGLbwGRNJBNjhmEDgE?= =?us-ascii?q?fN4EiKYNhgWxyh3CBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,357,1477958400"; d="scan'208";a="361708297" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Dec 2016 13:42:28 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id uBGDgS8O007586 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 16 Dec 2016 13:42:28 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 16 Dec 2016 08:42:27 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 16 Dec 2016 08:42:27 -0500 From: "Acee Lindem (acee)" To: Juergen Schoenwaelder , "Ladislav Lhotka" Thread-Topic: [netmod] RFC 7277: ip-address-origin Thread-Index: AQHSV6D2DRJSber8YkWxrK161WtIgKEK6EUA//+s54A= Date: Fri, 16 Dec 2016 13:42:27 +0000 Message-ID: References: <92694F93-CCD0-4BAD-95D2-F57CF5A8F1CE@nic.cz> <20161216133941.GD443@elstar.local> In-Reply-To: <20161216133941.GD443@elstar.local> 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.204] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: NETMOD WG Subject: Re: [netmod] RFC 7277: ip-address-origin X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 13:42:31 -0000 On 12/16/16, 8:39 AM, "netmod on behalf of Juergen Schoenwaelder" wrote: >Lada, > >when would I use link-layer and when link-local? Perhaps all needed is >a clarification of the description of link-layer? (Perhaps link-local >would have been a better name but too late now...) > >An RFC 3927 address could also be a 'random' address. In fact, the >169.254/16 prefix kind of hings at RFC 3927 addresses falling under >'random'. Actually, I think =8Crandom=B9 is a more semantically correct classificatio= n for RFC 3927 addresses than the proposed =8Clink-local=B9. Acee > >/js > >On Fri, Dec 16, 2016 at 02:33:04PM +0100, Ladislav Lhotka wrote: >> Hi, >>=20 >> I think that one important enum is missing in the "ip-address-origin" >>typedef: >>=20 >> enum link-local { >> description >> "Indicates a link-local address."; >> reference >> "RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses >> RFC 4291: IP Version 6 Addressing Architecture"; >>=20 >> Would an erratum be possible/useful? >>=20 >> Lada >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >Fax: +49 421 200 3103 > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Dec 16 06:00:53 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F751295C3 for ; Fri, 16 Dec 2016 06:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 pnbeQfwFw6Rj for ; Fri, 16 Dec 2016 06:00:50 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9D53129D8B for ; Fri, 16 Dec 2016 06:00:01 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:344e:1067:fdc6:a0dd] (unknown [IPv6:2001:718:1a02:1:344e:1067:fdc6:a0dd]) by mail.nic.cz (Postfix) with ESMTPSA id 4A4B461042; Fri, 16 Dec 2016 15:00:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1481896800; bh=+XV7nXH1muaihzZtFhvaRnNdY7fzyyhDH0VgV6LmYHE=; h=From:Date:To; b=A6i4jhtBjGXrHpcTe7NhUh4krhshBMpg8gLJLZLEPfzC1js1zydR+O6pvDSN23YdJ ondOVUrdF3Zfts75G7JT8Tjc+Q8mlZWaQjtgu/VavgFUTER3u02Y4zWjlWUXTcNRWe XEzg/13hBpbkFDxr0qSKlNL0W2Nf5rOrbejxkDSo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20161216133941.GD443@elstar.local> Date: Fri, 16 Dec 2016 14:59:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <92694F93-CCD0-4BAD-95D2-F57CF5A8F1CE@nic.cz> <20161216133941.GD443@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NETMOD WG Subject: Re: [netmod] RFC 7277: ip-address-origin X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 14:00:52 -0000 > On 16 Dec 2016, at 14:39, Juergen Schoenwaelder = wrote: >=20 > Lada, >=20 > when would I use link-layer and when link-local? Perhaps all needed is > a clarification of the description of link-layer? (Perhaps link-local The distinction between SLAAC and link-local address is IMO also = important. > would have been a better name but too late now...) That's why I believe the draconian update rules in sec. 11 of RFC 7950 = are seriously counterproductive (at this stage at least). We should = simply fix such mistakes and omissions in a new revision of ietf-ip, = because otherwise the modules will soon be full of rubbish. >=20 > An RFC 3927 address could also be a 'random' address. In fact, the > 169.254/16 prefix kind of hings at RFC 3927 addresses falling under > 'random'. OK, so adding 3927 to "reference" should suffice in this case. Lada >=20 > /js >=20 > On Fri, Dec 16, 2016 at 02:33:04PM +0100, Ladislav Lhotka wrote: >> Hi, >>=20 >> I think that one important enum is missing in the "ip-address-origin" = typedef: >>=20 >> enum link-local { >> description >> "Indicates a link-local address."; >> reference >> "RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses >> RFC 4291: IP Version 6 Addressing Architecture"; >>=20 >> Would an erratum be possible/useful? >>=20 >> Lada >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Dec 16 06:05:47 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0AB4129D8E for ; Fri, 16 Dec 2016 06:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 pTyB0nnaqBka for ; Fri, 16 Dec 2016 06:05:43 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0E4129DA7 for ; Fri, 16 Dec 2016 06:05:36 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 2F88C1AE028C; Fri, 16 Dec 2016 15:05:35 +0100 (CET) Date: Fri, 16 Dec 2016 15:05:34 +0100 (CET) Message-Id: <20161216.150534.1735458951959104027.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <92694F93-CCD0-4BAD-95D2-F57CF5A8F1CE@nic.cz> <20161216133941.GD443@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] RFC 7277: ip-address-origin X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 14:05:45 -0000 Ladislav Lhotka wrote: > > > On 16 Dec 2016, at 14:39, Juergen Schoenwaelder wrote: > > > > Lada, > > > > when would I use link-layer and when link-local? Perhaps all needed is > > a clarification of the description of link-layer? (Perhaps link-local > > The distinction between SLAAC and link-local address is IMO also important. > > > would have been a better name but too late now...) > > That's why I believe the draconian update rules in sec. 11 of RFC > 7950 are seriously counterproductive (at this stage at least). We > should simply fix such mistakes and omissions in a new revision of > ietf-ip, because otherwise the modules will soon be full of > rubbish. I agree w/ Acee that the name 'link-layer' is more appropriate for the *origin* of the address. If you manually configure a link-local address the origin would be 'static'. /martin > > An RFC 3927 address could also be a 'random' address. In fact, the > > 169.254/16 prefix kind of hings at RFC 3927 addresses falling under > > 'random'. > > OK, so adding 3927 to "reference" should suffice in this case. > > Lada > > > > > /js > > > > On Fri, Dec 16, 2016 at 02:33:04PM +0100, Ladislav Lhotka wrote: > >> Hi, > >> > >> I think that one important enum is missing in the "ip-address-origin" typedef: > >> > >> enum link-local { > >> description > >> "Indicates a link-local address."; > >> reference > >> "RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses > >> RFC 4291: IP Version 6 Addressing Architecture"; > >> > >> Would an erratum be possible/useful? > >> > >> Lada > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> > >> > >> > >> > >> _______________________________________________ > >> 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 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Dec 16 06:14:02 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743C7129DD4 for ; Fri, 16 Dec 2016 06:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 9Z86X6fixztc for ; Fri, 16 Dec 2016 06:13:59 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1990E129DCF for ; Fri, 16 Dec 2016 06:13:58 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:344e:1067:fdc6:a0dd] (unknown [IPv6:2001:718:1a02:1:344e:1067:fdc6:a0dd]) by mail.nic.cz (Postfix) with ESMTPSA id 6176461151; Fri, 16 Dec 2016 15:13:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1481897637; bh=jI3bD/5WTaCNTGKDyB3o6a11+n4iGJhxMWSrL51jGnQ=; h=From:Date:To; b=i/egTNHTu9TgmsH1FMT6YfFOW1JIC++F3y0HOiY/uBvjwKtPleDqh4Qu1SG8yWF/3 v7Z5zMR3PKTu/FDShwEKLCbqUwL4wh0T10DNJUIgdwV5db0rjvfQ0Cy4UxPaEj7B+6 GoLemeR+j+Gs7Vz3uAT8Lpn8cwB6sCNYmcdqaDiU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20161216.150534.1735458951959104027.mbj@tail-f.com> Date: Fri, 16 Dec 2016 15:13:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4B7A123C-F640-4422-A33F-713A2F4C6B39@nic.cz> References: <92694F93-CCD0-4BAD-95D2-F57CF5A8F1CE@nic.cz> <20161216133941.GD443@elstar.local> <20161216.150534.1735458951959104027.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] RFC 7277: ip-address-origin X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 14:14:01 -0000 > On 16 Dec 2016, at 15:05, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 16 Dec 2016, at 14:39, Juergen Schoenwaelder = wrote: >>>=20 >>> Lada, >>>=20 >>> when would I use link-layer and when link-local? Perhaps all needed = is >>> a clarification of the description of link-layer? (Perhaps = link-local >>=20 >> The distinction between SLAAC and link-local address is IMO also = important. >>=20 >>> would have been a better name but too late now...) >>=20 >> That's why I believe the draconian update rules in sec. 11 of RFC >> 7950 are seriously counterproductive (at this stage at least). We >> should simply fix such mistakes and omissions in a new revision of >> ietf-ip, because otherwise the modules will soon be full of >> rubbish. >=20 > I agree w/ Acee that the name 'link-layer' is more appropriate for the > *origin* of the address. That's possible for link-local but not for SLAAC, which is an L3 = mechanism. So a fix might be: 1. Change description of "link-layer" to include link-local addresses. 2. Add a new enum, e.g. "slaac". Lada >=20 > If you manually configure a link-local address the origin would be > 'static'. >=20 >=20 > /martin >=20 >=20 >>> An RFC 3927 address could also be a 'random' address. In fact, the >>> 169.254/16 prefix kind of hings at RFC 3927 addresses falling under >>> 'random'. >>=20 >> OK, so adding 3927 to "reference" should suffice in this case. >>=20 >> Lada >>=20 >>>=20 >>> /js >>>=20 >>> On Fri, Dec 16, 2016 at 02:33:04PM +0100, Ladislav Lhotka wrote: >>>> Hi, >>>>=20 >>>> I think that one important enum is missing in the = "ip-address-origin" typedef: >>>>=20 >>>> enum link-local { >>>> description >>>> "Indicates a link-local address."; >>>> reference >>>> "RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses >>>> RFC 4291: IP Version 6 Addressing Architecture"; >>>>=20 >>>> Would an erratum be possible/useful? >>>>=20 >>>> Lada >>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Dec 16 06:48:14 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B2A129679 for ; Fri, 16 Dec 2016 06:48:12 -0800 (PST) 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 wCYCXalLK-aq for ; Fri, 16 Dec 2016 06:48:09 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D54B3129A83 for ; Fri, 16 Dec 2016 06:48:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id BE29A1E5673; Fri, 16 Dec 2016 06:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7bIWxiRZXTEL; Fri, 16 Dec 2016 06:46:59 -0800 (PST) Received: from [192.168.1.129] (host5-81-223-185.range5-81.btcentralplus.com [5.81.223.185]) by c8a.amsl.com (Postfix) with ESMTPSA id 93C161E566F; Fri, 16 Dec 2016 06:46:58 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_07F1428E-FA2A-4EA4-8A96-4C44E560FBBB" From: William Lupton In-Reply-To: <4B7A123C-F640-4422-A33F-713A2F4C6B39@nic.cz> Date: Fri, 16 Dec 2016 14:48:06 +0000 Message-Id: References: <92694F93-CCD0-4BAD-95D2-F57CF5A8F1CE@nic.cz> <20161216133941.GD443@elstar.local> <20161216.150534.1735458951959104027.mbj@tail-f.com> <4B7A123C-F640-4422-A33F-713A2F4C6B39@nic.cz> To: Ladislav Lhotka X-Mailer: Apple Mail (2.3124) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] RFC 7277: ip-address-origin X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 14:48:12 -0000 --Apple-Mail=_07F1428E-FA2A-4EA4-8A96-4C44E560FBBB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FYI the TR-181 =E2=80=9CDevice:2=E2=80=9D data model (a TR-069 data = model) defines a conceptually similar IPv6 address origin parameter (*): =E2=80=94=E2=80=94=20 Mechanism via which the IP address was assigned. Enumeration of: AutoConfigured (Automatically generated. For example, a link-local = address as specified by SLAAC [Section 5.3/RFC4862], a global address as = specified by SLAAC [Section 5.5/RFC4862], or generated via CPE logic = (e.g. from delegated prefix as specified by [RFC3633]), or from ULA /48 = prefix as specified by [RFC4193]) DHCPv6 (Assigned by DHCPv6 [RFC3315]) IKEv2 (Assigned by IKEv2 [RFC5996]) MAP (Assigned by MAP [RFC7597], i.e. is this interface's MAP IPv6 = address) WellKnown (Specified by a standards organization, e.g. the ::1 loopback = address, which is defined in [RFC4291]) Static (For example, present in the factory default configuration (but = not WellKnown), created by the ACS, or created by some other management = entity (e.g. via a GUI)) This parameter is based on ipOrigin from [RFC4293]. =E2=80=94=E2=80=94 Rather than defining a =E2=80=9Cslaac=E2=80=9D value we defined = AutoConfigured to include SLAAC and other auto-configuration mechanisms. = We also listed some other protocols via which the address might be = assigned. We perhaps should have defined an =E2=80=9COther=E2=80=9D = value but the thinking might have been that it was better to extend the = enumeration with other specific protocols rather than use =E2=80=9COther=E2= =80=9D. This is intended for IPv6 only. We also defined an IPv4 addressing type = parameter (**) with enumerations {DHCP, IKEv2, AutoIP, IPCP, Static}. William (*) = https://www.broadband-forum.org/cwmp/tr-181-2-11-0.html#D.Device:2.Device.= IP.Interface.%7Bi%7D.IPv6Address.%7Bi%7D.Origin (**) = https://www.broadband-forum.org/cwmp/tr-181-2-11-0.html#D.Device:2.Device.= IP.Interface.%7Bi%7D.IPv4Address.%7Bi%7D.AddressingType > On 16 Dec 2016, at 14:13, Ladislav Lhotka wrote: >=20 >=20 >> On 16 Dec 2016, at 15:05, Martin Bjorklund wrote: >>=20 >> Ladislav Lhotka wrote: >>>=20 >>>> On 16 Dec 2016, at 14:39, Juergen Schoenwaelder = wrote: >>>>=20 >>>> Lada, >>>>=20 >>>> when would I use link-layer and when link-local? Perhaps all needed = is >>>> a clarification of the description of link-layer? (Perhaps = link-local >>>=20 >>> The distinction between SLAAC and link-local address is IMO also = important. >>>=20 >>>> would have been a better name but too late now...) >>>=20 >>> That's why I believe the draconian update rules in sec. 11 of RFC >>> 7950 are seriously counterproductive (at this stage at least). We >>> should simply fix such mistakes and omissions in a new revision of >>> ietf-ip, because otherwise the modules will soon be full of >>> rubbish. >>=20 >> I agree w/ Acee that the name 'link-layer' is more appropriate for = the >> *origin* of the address. >=20 > That's possible for link-local but not for SLAAC, which is an L3 = mechanism. >=20 > So a fix might be: >=20 > 1. Change description of "link-layer" to include link-local addresses. >=20 > 2. Add a new enum, e.g. "slaac". >=20 > Lada >=20 >>=20 >> If you manually configure a link-local address the origin would be >> 'static'. >>=20 >>=20 >> /martin >>=20 >>=20 >>>> An RFC 3927 address could also be a 'random' address. In fact, the >>>> 169.254/16 prefix kind of hings at RFC 3927 addresses falling under >>>> 'random'. >>>=20 >>> OK, so adding 3927 to "reference" should suffice in this case. >>>=20 >>> Lada >>>=20 >>>>=20 >>>> /js >>>>=20 >>>> On Fri, Dec 16, 2016 at 02:33:04PM +0100, Ladislav Lhotka wrote: >>>>> Hi, >>>>>=20 >>>>> I think that one important enum is missing in the = "ip-address-origin" typedef: >>>>>=20 >>>>> enum link-local { >>>>> description >>>>> "Indicates a link-local address."; >>>>> reference >>>>> "RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses >>>>> RFC 4291: IP Version 6 Addressing Architecture"; >>>>>=20 >>>>> Would an erratum be possible/useful? >>>>>=20 >>>>> Lada >>>>>=20 >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>=20 >>>> --=20 >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>> Fax: +49 421 200 3103 >>>=20 >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 --Apple-Mail=_07F1428E-FA2A-4EA4-8A96-4C44E560FBBB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
FYI = the TR-181 =E2=80=9CDevice:2=E2=80=9D data model (a TR-069 data model) = defines a conceptually similar IPv6 address origin parameter = (*):

=E2=80=94=E2=80=94 
Mechanism via = which the IP address was assigned. Enumeration of:
  • AutoConfigured (Automatically generated. = For example, a link-local address as specified by SLAAC [Section = 5.3/RFC4862], a global address as specified by SLAAC [Section = 5.5/RFC4862], or generated via CPE logic (e.g. from delegated = prefix as specified by [RFC3633]), or from ULA /48 prefix as specified = by [RFC4193])
  • DHCPv6 (Assigned by DHCPv6 = [RFC3315])
  • IKEv2 (Assigned by IKEv2 = [RFC5996])
  • MAP (Assigned by MAP [RFC7597], i.e. = is this interface's MAP IPv6 address)
  • WellKnown (Specified by a standards organization, e.g. = the ::1 loopback address, which is defined in = [RFC4291])
  • Static (For example, present in the = factory default configuration (but not WellKnown), created by the = ACS, or created by some other management entity (e.g. via a = GUI))
This parameter is based = on ipOrigin from [RFC4293].
=E2=80=94=E2=80=94

Rather than defining a =E2=80=9Cslaac=E2=80= =9D value we defined AutoConfigured to include SLAAC and other = auto-configuration mechanisms. We also listed some other protocols via = which the address might be assigned. We perhaps should have defined an = =E2=80=9COther=E2=80=9D value but the thinking might have been that it = was better to extend the enumeration with other specific protocols = rather than use =E2=80=9COther=E2=80=9D.

This is intended for IPv6 only. We also = defined an IPv4 addressing type parameter (**) with enumerations {DHCP, = IKEv2, AutoIP, IPCP, Static}.

William

(*) https://www.broadband-forum.org/cwmp/tr-181-2-11-0.html#D.Devic= e:2.Device.IP.Interface.%7Bi%7D.IPv6Address.%7Bi%7D.Origin
(**) https://www.broadband-forum.org/cwmp/tr-181-2-11-0.html#D.Devic= e:2.Device.IP.Interface.%7Bi%7D.IPv4Address.%7Bi%7D.AddressingType
On 16 Dec 2016, at = 14:13, Ladislav Lhotka <lhotka@nic.cz> wrote:


On 16 Dec 2016, at = 15:05, Martin Bjorklund <mbj@tail-f.com> wrote:

Ladislav Lhotka <lhotka@nic.cz> wrote:

On 16 Dec 2016, at 14:39, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

Lada,

when would = I use link-layer and when link-local? Perhaps all needed is
a clarification of the description of link-layer? (Perhaps = link-local

The distinction = between SLAAC and link-local address is IMO also important.

would = have been a better name but too late now...)

That's why I believe the = draconian update rules in sec. 11 of RFC
7950 are = seriously counterproductive (at this stage at least). We
should simply fix such mistakes and omissions in a new = revision of
ietf-ip, because otherwise the modules will = soon be full of
rubbish.

I agree w/ Acee that the name 'link-layer' is more = appropriate for the
*origin* of the address.

That's possible for link-local = but not for SLAAC, which is an L3 mechanism.

So a fix might be:

1. Change = description of "link-layer" to include link-local addresses.

2. Add a new enum, e.g. "slaac".

Lada


If you manually configure a = link-local address the origin would be
'static'.


/martin


An RFC 3927 address could also be a 'random' = address. In fact, the
169.254/16 prefix kind of hings at = RFC 3927 addresses falling under
'random'.

OK, so adding 3927 to "reference" = should suffice in this case.

Lada


/js

On Fri, Dec 16, 2016 at = 02:33:04PM +0100, Ladislav Lhotka wrote:
Hi,

I think that = one important enum is missing in the "ip-address-origin" typedef:

enum link-local {
 description
   "Indicates a = link-local address.";
 reference
  =  "RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses
    RFC 4291: IP Version 6 Addressing = Architecture";

Would an erratum be = possible/useful?

Lada

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




_______________________________________________
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         <http://www.jacobs-university.de/>

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




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

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




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


= --Apple-Mail=_07F1428E-FA2A-4EA4-8A96-4C44E560FBBB-- From nobody Fri Dec 16 10:31:46 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70101296D5 for ; Fri, 16 Dec 2016 10:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwJb_Hl_l2Yk for ; Fri, 16 Dec 2016 10:31:44 -0800 (PST) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 15C35129B20 for ; Fri, 16 Dec 2016 10:31:44 -0800 (PST) Received: (qmail 3752 invoked by uid 0); 16 Dec 2016 18:31:36 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy6.mail.unifiedlayer.com with SMTP; 16 Dec 2016 18:31:36 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id LiXW1u00k2SSUrH01iXZp4; Fri, 16 Dec 2016 11:31:34 -0700 X-Authority-Analysis: v=2.1 cv=Zvl+dbLG c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=n5n_aSjo0skA:10 a=48vgC7mUAAAA:8 a=ngwYvln4HPmK8yx8zYoA:9 a=pILNOxqGKmIA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:Cc:References:To:Subject:From; bh=+OtymkWKF5EqlZyCGd/ZhgWCa7518EwqWd4gWkJaJ1I=; b=U8WmxRlYc9lmAWT8XhVshznB8J 80xIJvYrb2nZt6GLxSOCtetvdR6OBJjhfze8iWsB4uuseeQNYj6gExivTf59qwhYQbnx3xUFxCHeF 6rk6TU8F/Dp+gsdq+Aocl+sts; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:59981 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1cHxI4-0002QM-3b; Fri, 16 Dec 2016 11:31:32 -0700 From: Lou Berger To: Netmod WG , draft-ietf-netmod-yang-model-classification@ietf.org References: <5d05d686-5962-9ffc-16d4-c4459baf9c7a@labn.net> Message-ID: Date: Fri, 16 Dec 2016 13:31:18 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <5d05d686-5962-9ffc-16d4-c4459baf9c7a@labn.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cHxI4-0002QM-3b X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:59981 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: Netmod WG Chairs Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-yang-model-classification-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 18:31:46 -0000 [resend] All, This WG LC is closed. Authors, Please update your document per any (on & off list) comments received as well as ensure it passes ID nits, preferably without any warnings. If there are issues to be discussed based on comment, please do so on the list. Once the document is updated to address all comments, please let us (all) know by sending a message to the list summarizing resolution of issues raised and changes. Publication will be requested at that point. Thank you! Lou On 11/30/2016 12:35 PM, Lou Berger wrote: > All, > This starts a two-week working group last call on > draft-ietf-netmod-yang-model-classification-04. > > The working group last call ends on December 14. Please send your > comments to the netmod mailing list. > > Positive comments, e.g., "I've reviewed this document and > believe it is ready for publication", are welcome! > This is useful and important, even from authors. > > Thank you, > Netmod Chairs > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Dec 16 11:54:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3302C129D0A for ; Fri, 16 Dec 2016 11:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEKoFUN_9NHB for ; Fri, 16 Dec 2016 11:54:30 -0800 (PST) Received: from mail-pg0-f51.google.com (mail-pg0-f51.google.com [74.125.83.51]) (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 C1816129C67 for ; Fri, 16 Dec 2016 11:54:30 -0800 (PST) Received: by mail-pg0-f51.google.com with SMTP id 3so35462849pgd.0 for ; Fri, 16 Dec 2016 11:54:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ssk2Pn6T598BpJOSFcXU+hlvOQvqLCpMbUMOVW54rWs=; b=W/ETbhZWYyY0vZRJujXHC/AXeTWWzKiOD8wwZz+lFKmo2gpP2A+xGxXFBfz4KZPyzp 02UQi5yai9Kh6XV1y2QFq7nEGVcgVYqmSxIYop1CMVAQ/Wf2Kdp8Gl1qzPtPzTykCgl5 2GkBHyBjcHSXSAsmLa7jLWPCOTXK4oGmoOqrB+YP9bkmyEpVnJ7cBTTpRQB0e2llVRUI daZlgPkZSR9GHeCpmmnGG0Aqywai2co5EPH01FtOxyQGXTfkykltLk5tCEN0qQVKfiIw MH6Fs7y3X7T6Le0cH8l51gLF6GIKZXNnahtz2vVUxCWqsV+dPStf/aMYf5Qketkt6x6R JWgg== X-Gm-Message-State: AKaTC01dpYd1fXV8fH0HEQ95IL58DnwRjG2IAS8tdXSMBuxQxGQREw6DI8YDXH5U0f7zuR2b X-Received: by 10.84.204.8 with SMTP id a8mr10499851ple.172.1481918069857; Fri, 16 Dec 2016 11:54:29 -0800 (PST) Received: from [192.168.1.114] (c-50-168-48-150.hsd1.ca.comcast.net. [50.168.48.150]) by smtp.gmail.com with ESMTPSA id p79sm13731746pfj.51.2016.12.16.11.54.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Dec 2016 11:54:29 -0800 (PST) To: Netmod Mailing list References: <20161215.160110.1071208720534123811.mbj@tail-f.com> <20161215152130.GA7351@elstar.local> <5227d6df-1de8-2e3e-2caf-066af7047d9a@alumni.stanford.edu> <20161216.095302.2017223317806480125.mbj@tail-f.com> From: Randy Presuhn Message-ID: Date: Fri, 16 Dec 2016 11:54:28 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161216.095302.2017223317806480125.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] draft-ietf-netmod-entity issue #11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 19:54:32 -0000 Hi - On 12/16/2016 12:53 AM, Martin Bjorklund wrote: > Randy Presuhn wrote: >> Hi - >> >> My recollection is that part of the motivation for the use of >> zero-length strings as sentinel values in situations like this >> in MIB modules (rather than skipping the object instance) was >> to permit a clear distinction between "information not available" >> and "access denied". > > Ok. But if this is an important use case, maybe we should try to have > generic support for it, instead of using special values. Not all > types have a natural value for "not available". Just providing background. I don't know whether the distinction is needed in netconf-managed environments. > I think that people often used these kinds of constructs in MIBs > to avoid "holes" in the tables; I don't know if that applied to this > MIB though. I think the fear of holes belongs in the "folklore" category. Due to the way access control works in SNMP, holes in tables are always a possibility when retrieving information. Employing sentinel values can't change that reality. However, for some objects (by no means all) the distinction between "I don't know" and "I won't tell you" was important to SNMP-based management. Whether this is also true in netconf-land is a another question. Randy From nobody Fri Dec 16 15:20:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE65129473; Fri, 16 Dec 2016 15:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=infinera.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 TF-2GKP2UbRh; Fri, 16 Dec 2016 15:20:28 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0073.outbound.protection.outlook.com [104.47.32.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 780E312946E; Fri, 16 Dec 2016 15:20:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infinera.onmicrosoft.com; s=selector1-infinera-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=i3PZOM4G9BUazEG/kj6r7YVkRQ7xTvlaY3wT9fjc6nk=; b=pXKfrUAGzBvHqRtuysQVhskOiuysUCCA6ZzVxXDXzJuAu54+ZjFQIp5N2bcBuegXo3Vjqa/MhF7ReDoGXZPBqzFhmWNUTxxMhhrixvVZVAn1L5KTBGstu7woMV1zlwBdICLGBK+31ohSCKQ9+9Y2niV2C0DqlyB/01Xp6i6li5c= Received: from DM2PR10CA0027.namprd10.prod.outlook.com (10.160.213.37) by SN1PR10MB0496.namprd10.prod.outlook.com (10.162.103.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Fri, 16 Dec 2016 23:20:25 +0000 Received: from CO1NAM03FT010.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::205) by DM2PR10CA0027.outlook.office365.com (2a01:111:e400:5014::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8 via Frontend Transport; Fri, 16 Dec 2016 23:20:25 +0000 Authentication-Results: spf=pass (sender IP is 204.128.141.23) smtp.mailfrom=infinera.com; cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=bestguesspass action=none header.from=infinera.com; Received-SPF: Pass (protection.outlook.com: domain of infinera.com designates 204.128.141.23 as permitted sender) receiver=protection.outlook.com; client-ip=204.128.141.23; helo=owa.infinera.com; Received: from owa.infinera.com (204.128.141.23) by CO1NAM03FT010.mail.protection.outlook.com (10.152.80.104) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.10 via Frontend Transport; Fri, 16 Dec 2016 23:20:25 +0000 Received: from SV-EX13-PRD1.infinera.com (10.100.103.228) by sv-ex13-prd1.infinera.com (10.100.103.228) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 16 Dec 2016 15:20:24 -0800 Received: from SV-EX13-PRD1.infinera.com ([10.100.97.11]) by sv-ex13-prd1.infinera.com ([10.100.97.11]) with mapi id 15.00.1178.000; Fri, 16 Dec 2016 15:20:24 -0800 From: Iftekhar Hussain To: Robert Wilton , Lou Berger , "NetMod WG" Thread-Topic: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04 Thread-Index: AQHSVrezBGS7hRMxYEOqdNcnM2TMpaEJTb2ggAG2kYCAADJpcA== Date: Fri, 16 Dec 2016 23:20:23 +0000 Message-ID: <2902121af8d54615936a752920e66af9@sv-ex13-prd1.infinera.com> References: <4010c7f4de4941e1b41c2665926eb574@sv-ex13-prd1.infinera.com> <3fca5e5e-8374-7ec2-d340-7b2240833b8e@cisco.com> In-Reply-To: <3fca5e5e-8374-7ec2-d340-7b2240833b8e@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.100.99.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:204.128.141.23; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39410400002)(39450400003)(39830400002)(2980300002)(438002)(13464003)(51914003)(24454002)(189002)(377454003)(51444003)(199003)(33646002)(80792005)(8676002)(50466002)(246002)(92566002)(38730400001)(77096006)(7736002)(8936002)(24736003)(8746002)(7636002)(5890100001)(230783001)(229853002)(108616004)(5001770100001)(106116001)(356003)(2950100002)(189998001)(46406003)(106466001)(86362001)(3846002)(7696004)(97756001)(2906002)(53416004)(305945005)(4326007)(5660300001)(2900100001)(47776003)(626004)(76176999)(54356999)(50986999)(102836003)(6116002)(23726003); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR10MB0496; H:owa.infinera.com; FPR:; SPF:Pass; PTR:outgoingmail1.infinera.com; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT010; 1:0wyt2QHjIrKlMPah7scUrA1xeQ1EaS1danVwQcvKgzcKkooRvvzjil0noUbL2BryXJrNK6pwS1vdRzgCJ5ZmeQUqJmxb8W92XmquB/TpjPO5KSmeAf6HG+nh+lNevxGGZB3Umc4o8ztYC2r4Kq6gy08O9zKSc/UJDYf26hBa8j2hTPwIFWrzhxlQThTX/RNXxM4/ZMLjJVOiL51a/esJvxuoo7LqfpnMQtazChrKkPI2UDR+mdhBZ6Vj+RVb2r3l3naJQbXx/KDGBttfs9pV+tIqki2GK2XrktT41Q6Xp5E7e1dAzVs+mStojyosDmK6aEJxk3/IZmL7idKu43cimKcy6cIXcGNXST1eZz4vEV0543URJdLCMmXSR72oFrRmUfYT1+mUGU/PU+VEtCTqdcSoOoHyum0WzxUNlQREMT6CtIrmv8dsLvNOrb4ZBZpDdggwF83rbbXjd2nMQLq1CP7GxDkLl6Oo9bGK9cQcdWDdtZYlXLAfesMGtOXXFq7MBFaYcCcw+cWRp9rI6/yu68exxF4nA+WHxtoL6Md8sPdmnJjGJ6kSNzVzAVKLq7Ha X-MS-Office365-Filtering-Correlation-Id: bffb82b0-bbc2-4741-bf7e-08d4260a1d95 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002); SRVR:SN1PR10MB0496; X-Microsoft-Exchange-Diagnostics: 1; SN1PR10MB0496; 3:S0/fDzcPPpkLP4vIzkrjzVvExQnIVcor90ZKXLnLl3NfHKTM5LN9lTDXXxgNDS8JnhchxccWsKthBUM/15+2Ng0c+buAg+Sfz5AQGAwUuCXMywcT4OZBkKQTocM5mAeRclfprLmYqPKDS3tsLH7yVNBIpS451W1HaIwLPk+ztC3/OnrbNvZhXAG+hDY5SUuu1yQzesxGTq3k7UQiwFnEnZZxKOzhb5+K7yUPWq/FgBPzfXEtG/CXLhE79QrIrSsCS8JNdHtJG/YAZTp1DVy9+hxy4s7Wvq7lYB7t5IR+66jV4tDc5PU2btxZw9YnpxX0tLOzvIEeX3eb1bUklAgJGFFa+rvxZOvC2RfUg618AVYGBBAaSqP3Jy+6BqTCW7owWe1je4g4Q/2MJECijk1WJg== X-Microsoft-Exchange-Diagnostics: 1; SN1PR10MB0496; 25:89WlQFkcLBoCjhPG/6GhZeQUPP4zswGcd5/l0ePrZ5GQrSh4OQzylLTdp3dScQankKVl0X5loDTjNcRYniERtqoe4RgPxZeAnZqX2R2Fp0P+W10uvljOcCKfaQjDVvvGRwJfYABoOEhg4yA8nZOI8HAJeubJmjhjQYvlrEJBgxo2ZerN0Ym9LZFQuIY5SA3X9GXXvhP116l2ADTJiGu4iix7ATBR0KEnFKJCMzFs8acZ0fECERHGN6I6Bpt9xtu+iRo7klC0aTtbMtkpENS4yXEH3SJMSwq6IA+tAhl9xHDw8kqcnPmtMY230dM+ONoYZWoaPKK4evms/5VRGZA2e1phTK+j6G3mT0L5X8ugNvkjHwz5oJ9sPZN/3wt1JPf91qB9tQ/m++bsBkNYbjtrNv3QaB8bxErHaErwMQInUo3GVhJ60YC4uRqFmuBar6fXHxWzQ66eRcPiUoygox4v25/vldXtlPxxG9DDue5c6cpXlCHrI0vEEwFWk9CyhgYBXscXgrWbdXbGubl9mCIqlZp6PaaSO4iEHB8O+1v2bS6zTf1IGv3M4xyVwrDGZngoatSFAqRBe6jS8t7S/uHh3i8pr0R1d+vbxiJ3NstYjBEpOEKwID67ejkwfqXlxK5SdmDrKJ84gBIJY43q5UmYmZGZMNl8/6D3LhHtiYSxZVM3uv7OwW1Y1Fn9ubEahLIQT4vbX2Agat6DvOlnfq/vMvIhoICs8f3CbXvdJld12Yp7+zCD5/D1c34jTB1sNNZdiv/WGVwpGy1MbP5hBWOC2EzKkAEewMkaeHF1FbqJD73nb0eZt3L28EIUaNwFIpWh+DmQiyzbYHvRk4fgD6j/ZUMXuwvuGWTEWea/BJs995l8+e9CfuToK5AM5Hom+4kJ3GukLXE+3gAZ2pfFrPSG8IBzSTLhjMxDcGQcqeCAJ9w= X-Microsoft-Exchange-Diagnostics: 1; SN1PR10MB0496; 31:hqxmkFSfC0N1bGMK4qFMoPEVABO/fRc8UMEeSUo8CsKeS+Us0xJ5JHHutMejHWxqmOoRRsnzBdf7zxEbykXi6yAgU5/iKHaxGttbfNMNfo+Nv6b6plLFduNjlaYO5EcRb0aJEV9Ff6M1qbN8MuNW7ePvzUwPCNizUSU62P4HV7Now7AYwgzf9zQEv/yfq1/D058WucNP01DvqzCGiyySzIBf2EBrJRScLQdZg1lSyYOC1NnBnCy2TnSzbo8Kpy8MwwWWJtTCqNVphFP4ZceC4Q== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(788757137089)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13024025)(13017025)(13018025)(13015025)(8121501046)(13023025)(5005006)(3002001)(10201501046)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:SN1PR10MB0496; BCL:0; PCL:0; RULEID:; SRVR:SN1PR10MB0496; X-Microsoft-Exchange-Diagnostics: 1; SN1PR10MB0496; 4:T4AqkQiDdJslYFY/r0djS1oIf6BuACLukSvd3BVOqXCdWmP68cKEVDrpQGQpJgBI69aUxt9rFi6g+rZ2EGZywL8RlS02zQS4Wrdf5vINrIamXPxP/Ak1k+/PI4+xxWUxM9386LrY3GhWTZAJKnH3RsQv6Gl2GlkxdTAdunJkys8hRpv1Z7EzjCIU5Tv3FfamKj+VfTGWfMH8tM+uMfRb2dtYBARzxcfzIzkVH98Y9nVs8C3Trm0NVSiREuEvwSCFs0zQ5kt6WshHsrA4+afKYmeScWiFxq9gWo5ikbQbt489NMQxlSaI/kzEH7iTh64UNaoWYoGKAiqr0aXfOcxAiHWxVS/GhKp/vw1GOw886XQbDSTYvPSr/G+CqHo1RQBgVZecI3psZ1oucxbwJQyHeUyGLDSnH2pEwbKLS02Jumc6z1RZrz2RcVcwfkzKyfH0lWxehJS3yllyW4N/OJsq8htwwfZRQPP+V/FvgSwgtlcEONExCYtkU4LQWK9521MXGBXhmXn7spLVOE3Oyj00/4mcHvjAcrd2CS39uZuqi+zMGcsMzIUdC6s43+OrUe/2t8RfER1MP8FZhMTk0uS6x2c8VwoMRFRBOmq6ci91ArKu9Cle2QLT+VLvWotNyKv3SPyrWCiAfMba/veSXDub/tb2k22lGFJ4vYAo9KE/r1M35wxD5iz+gqWWmfwnN1uQ/Wi/2EjAhGN0Iykzm1t7Aa9g6u251eoAp9S5ms5Vui0= X-Forefront-PRVS: 01583E185C X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR10MB0496; 23:HQjtZvgm4kSpBrfy+tRJRjzAD1yDEkpjqm3FLMxTK?= =?us-ascii?Q?0Wa2c0kqjFRMkfzBULSdy2vVHbXocdELFhK5k0JF6HiLJXMfsxbsMy2mqvf/?= =?us-ascii?Q?dudW3EO0n7MfkAG+tTZRMf9eMYpGkOpWaMqQY0ckXULlF1D1jfllnfHYtQRC?= =?us-ascii?Q?4v0iHpirFz5f+C/JvJEqZi6FEMrxa0CYvxPaml15OHaam/Je09cmf0kpxIjz?= =?us-ascii?Q?CKdsbGqmyqR7cd97rRZ2o5tsS5LxpHzzkzy5+CAWIBCVAQEqaIl9PyPMCOqq?= =?us-ascii?Q?TgA6i+b5QYemrEKjvEWlNRZ9WB24Q9edYM06T0aA+QLbb0LkuvBrWTPEkQ3i?= =?us-ascii?Q?91Wk/by9jEOWcWu3fPiMRKhinvImCvGhCie0HdMkK+eGF0vCW0ifOYATxz7Q?= =?us-ascii?Q?ISHiVlK/PXTBC/nPRYMRlXuFJWtDBtiwzRfF6xzLcL9pfszVuM3GNBlSDEon?= =?us-ascii?Q?bfsgZPYuePzNtw5yWdEK0ernSSd3rwP1v5dCoC9uEJUyR3xmaDbDSV/fzbxo?= =?us-ascii?Q?irxEZEG8dOUBoGPDiETxnXp5JoJjHgu5s9CxfXzfaXCiYZqmmZ+zuRQlkdgb?= =?us-ascii?Q?BXUlgqbLbtwIBcl8qobcW8sdYkvxt/wEuo7+2Fqw4n2B1xWst4UeXVAFcpIE?= =?us-ascii?Q?qM8qe57wgHFMPypDjIOn4HDZSVMg2Hd9lSLM1p+UDlR6WZb0ZfECVr2ikvI1?= =?us-ascii?Q?DIC2SSwSt1zC87e4GWBcsUbS4DggmHPvArEq4e5IdMVaBSVlZdrY+99UgrKd?= =?us-ascii?Q?qA+8DVM2XPiDI05tCUCT8n5KG9dYpTMCfyrYsUwPjhr77oysExWdmXDMFULC?= =?us-ascii?Q?0lA073XA+3zTo+fEOYBquuoryfJhULiZp02Sq3b3B+e+3Fl2eaVVdgVPSKZc?= =?us-ascii?Q?Az9L8X4gdg2f4G0I7jdJ7xzLhlPtNgmFgDyeEZfknSc75szuFFW9QhBZN3pO?= =?us-ascii?Q?2HJVa9BLhnlbaROEI2PWPHSGV9OU1ccUEc7BaWMDaqKuB/Az5JUjSRVgHhJp?= =?us-ascii?Q?eTnAo4Ljg6jFex2TwD5rD15WzMYE/IjBVXCTFkkkm1AMb8OIGDpb34jPWseg?= =?us-ascii?Q?5CHN2AuPCiMHJYao9Z4P/ZdDZOGyw2rqu0RKGVJvxPVQuHJBxiSGW2DNO27l?= =?us-ascii?Q?uQ+5YpBrGaAD5Qpx6oSt0pmEdqPY8yD6uHA000tL5jD57+l3USQUf3i+DgeV?= =?us-ascii?Q?uQH3/bzGRT4s+LSR5NjIA6LimASfeKRZ5lwhmi2esD2FH9IDun98oyeaXsGM?= =?us-ascii?Q?VwP8RKgEywG9J0/MDvY/EKfCtu4FtZlJ5p0cv1wSE/Y4imtGIsH8w2i4wtEn?= =?us-ascii?Q?pNtH4rK+kKuLu8sr1NHNBDWUddb/3CV9iAp6UAWRKfw?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR10MB0496; 6:FzRYs5OEa+IBgmwPndPiXcbTwVAMZ43/FiUBeMZXFUmc3ppavXVjIqB7JE2qYjkKc2aiN7QsFxX8oKMmJWtUqejJnCycROOLa6yDKyhycpAGKJMei9Qxu+Olt29M/ZaujZVC4xkMV9bbfdfA1qv2qy0O0LhuSfmE8aDAUJR0CwG1X4HzYELY1d0SHrZAaMHQsy3Dggt++hlW9ktec1GMugCcd8/I/rtpoUG/w1dzA2RjrRQXtdAyi211X/l93yc4X2TrROlzy1zKjvf0eLgQK4JjOadRn91MJSlGQCHTy42mIWfkUZyBwD5NjGVJ4x/jhY7Co8Criw/0TYGieIKIoUl1N4EVtmCCbZxHyYNJZWgZxtah8LVlkmWG/0r86jQcINqX2gXMZtbqXuDrZ8vzoC3iB5pHT2LHs658r/Y/eU0=; 5:qD6pvDVUIJpUdH9mNOWyvepPRIWK0uCpSM7SjNB7ORi3jrL1qIaXR8VllLnlu4ukCPSey7pFw0k6dGwTkH1ceoJH9dwNZqXHX6GSn2xx6bugZAvzPpGAmn3dF/ntuysVofH0v1tyEckqD6R83COT2Q==; 24:n9HcwvThAyQC2JTCqdLiwEno+Fds0MvPg31NYgRlxqv8dXN/zYEllDn/2BMcp7BynAZEiY2Bizs580xbR3Cu304BkI1wyJpv5cJGuv5YWNI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR10MB0496; 7:E97dV61Tum3VXZPyZUZQvc7GU+LTyex62SeBZokvL29/CXYLa49U3qS9XKVn+0UmWQTcCrRiy7tqLa8DrsJNjt/lQl1XDKa8Bp8TnwLploYI6VD+bewJRqe56JeAwmgiLtoBCLRTZ540QAegxoHHrbcgXAlfIO4mTfltVTMT24y90m+qgOzPph9/spAME8ATa2RaT13EDHUskWLHCm0JmVKuLX+8KqsLG1xw0DCrofMc3s5jyCWokOMm2RHCGnSDJpq69Hpwr9rRLyvtM5X46R4ZeXca5f5crZDQ/J6fnFHc7ZKuhkXxqbt0Spvy3NK8nR9itGSssIAhjT5PR5nmAVSr1YrCGGekYrLlxJmCvVAmlBIfSwhNllGegDXyDZF8hpLOidKmswXHOxOPEQGMUr6/tgMT1bC2zkuEmQ/A4BxJmHFs/dk3/pMcuOX+Ylr2oG2H6juyP0jM/VxOdfausg== X-OriginatorOrg: infinera.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Dec 2016 23:20:25.2245 (UTC) X-MS-Exchange-CrossTenant-Id: 285643de-5f5b-4b03-a153-0ae2dc8aaf77 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=285643de-5f5b-4b03-a153-0ae2dc8aaf77; Ip=[204.128.141.23]; Helo=[owa.infinera.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR10MB0496 Archived-At: Cc: NetMod WG Chairs , "draft-wilton-netmod-intf-vlan-yang@ietf.org" Subject: Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 23:20:31 -0000 Hi Rob, Regarding ".... Were you looking for any additional specific statistics?".= =20 As long as RFC7223 interface statistics - relevant to a given subinterface= are picked and are available on per subinterface level that should be fin= e. "However, it would probably be useful to have a counter on the parent trunk= to indicate the number of packets that haven't been matched to any sub-int= erface, so I think that I should add that." Yes - I think, this would be useful. Thanks, Iftekhar -----Original Message----- From: Robert Wilton [mailto:rwilton@cisco.com]=20 Sent: Friday, December 16, 2016 4:14 AM To: Iftekhar Hussain; Lou Berger; NetMod WG Cc: NetMod WG Chairs; draft-wilton-netmod-intf-vlan-yang@ietf.org Subject: Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-0= 4 Hi Iftekhar, Thanks for the comments and support, please see inline ... On 15/12/2016 18:55, Iftekhar Hussain wrote: > Yes/support. > > I have read this draft and believe it would be very useful for enabling m= any Layer 2 and Layer 3 services. > > However, I do have few comments and that I would like the authors to addr= ess once the document is a WG document. > > a) Suggest to replace this text: > "These modules allow IETF forwarding protocols (such as IPv6 and VPL= S) ..." > with the following text: > " These modules allow configuration Layer 2 and Layer 3 subinterface= s (e.g., attachment circuits) for providing for IETF L2VPN (e.g., VPWS, VPL= S, EVPN) and L3VPN services". Yes, OK. I think that this text can be tweaked. > > b) The document should clearly identify the scope. For example, suggest r= eplace this text: > "... to interoperate with VLAN tagged traffic orginated from an = IEEE 802.1Q compliant bridge". > with the following text: > "... to interoperate with traffic originated from an IEEE 802.1D,= 802.1Q, or 802.1AD compliant bridge." > > Note: In the data model, the draft is talking about untagged as=20 > well as 802.1AD (see "tag type (802.1Q or 802.1ad)") Yes, it should mention 802.1D. 802.1ad is part of 802.1Q. The draft would= be best referring to S-VLANs vs C-VLANs rather than 802.1Q vs 802.1ad. > =20 > c) Are there any sub-interface level common statistics counters that t= he model should address? Currently, I don't see any. A sub-interface is still just an interface, so by default it would pick up = all of RFC7223 interface statistics. Were you looking for any additional s= pecific statistics? However, it would probably be useful to have a counter on the parent trunk = to indicate the number of packets that haven't been matched to any sub-inte= rface, so I think that I should add that. Thanks, Rob > > Thanks, > Iftekhar > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Monday, December 12, 2016 3:32 PM > To: NetMod WG > Cc: NetMod WG Chairs > Subject: [netmod] WG adoption poll=20 > draft-wilton-netmod-intf-vlan-yang-04 > > All, > > This is start of a two week* poll on making > draft-wilton-netmod-intf-vlan-yang-04 a NetMod working group document. > > Please send email to the list indicating "yes/support" or "no/do not supp= ort". If indicating no, please state your reservations with the document. = If yes, please also feel free to provide comments you'd like to see addres= sed once the document is a WG document. > > * Given the holiday, the poll ends December 28. > > Thank you, > NetMod WG Chairs > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Sun Dec 18 21:30:35 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70441297C4 for ; Sun, 18 Dec 2016 21:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.321 X-Spam-Level: X-Spam-Status: No, score=-7.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, 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 QQYosEI2bEAf for ; Sun, 18 Dec 2016 21:30:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E7831296C9 for ; Sun, 18 Dec 2016 21:30:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CXI18007; Mon, 19 Dec 2016 05:30:28 +0000 (GMT) Received: from DGGEMA406-HUB.china.huawei.com (10.3.20.47) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 19 Dec 2016 05:30:27 +0000 Received: from DGGEMA502-MBX.china.huawei.com ([169.254.2.221]) by DGGEMA406-HUB.china.huawei.com ([10.3.20.47]) with mapi id 14.03.0301.000; Mon, 19 Dec 2016 13:30:14 +0800 From: Rohit R Ranade To: Martin Bjorklund Thread-Topic: [netmod] [Netconf] Leaf-list usage Thread-Index: AdJXX2aakgSC5E/YQlukLb5liyQxs///qyGA//921FCAAJv0AP/7DcrA Date: Mon, 19 Dec 2016 05:30:14 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6B01157D@DGGEMA502-MBX.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A6B004002@DGGEMA502-MBX.china.huawei.com> <86927E83-6B6B-4528-BEBF-DD98DB0E48DC@nic.cz> <991B70D8B4112A4699D5C00DDBBF878A6B004060@DGGEMA502-MBX.china.huawei.com> <20161216.104728.1386223505634208297.mbj@tail-f.com> In-Reply-To: <20161216.104728.1386223505634208297.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.242.206] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58577074.02B2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.221, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1dd95c121905aa8ad9d687b05220ddf4 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] [Netconf] Leaf-list usage X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 05:30:34 -0000 Hi Martin, As per the discussion in https://www.ietf.org/mail-archive/web/netmod/curre= nt/msg01984.html, the understanding is that=20 fred Will select both the records: (Rec1) 10 fred (Rec2) 20 fred barney =A0wilma someother "Since there is a node in the data store that matches the content match node fred, all sibling nodes at this level are selected." This was the explanation given that time.=20 Q1: Can you please clarify as to why the Record 2 is not selected as per RF= C 6241. Q2: Whether to select Record 2 only, user need to provide all its leaf-list= elements values in the query request? With Regards, Rohit -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: 16 December, 2016 17:47 To: Rohit R Ranade Cc: lhotka@nic.cz; netmod@ietf.org Subject: Re: [netmod] [Netconf] Leaf-list usage Rohit R Ranade wrote: > Hi, > Consider we have 2 records as given below =20 > (Rec1) > 10 > fred > > (Rec2) > 20 > fred > barney > wilma > someother > >=20 > Q1 : Using subtree filtering which condition on the leaf-list node can > the user give such that he selects the record which contains foo=3Dfred > only... > [we can assume user does not know the value of "name"] fred > Q2 : Also about the leaf-list, I have tried searching but have not > found how this leaf-list originated ? 1 instance of a scalar type =3D> leaf N instances of a scalar type =3D> leaf-list 1 instance of a structure =3D> container N instances of a structure =3D> list > Whether XSD list is the > representation for leaf-list in xsd ? No. > The XSD list is represented slightly differently as per > http://www.w3schools.com/xml/el_list.asp : I love XML > Schema Correct. /martin From nobody Mon Dec 19 00:09:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC87129522; Mon, 19 Dec 2016 00:09:39 -0800 (PST) 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 (2048-bit key) header.d=hansfords.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 s88LG0D4he87; Mon, 19 Dec 2016 00:09:37 -0800 (PST) Received: from server.myfast.site (server.myfast.site [212.113.130.90]) (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 A0B3C126B6D; Mon, 19 Dec 2016 00:09:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dFC+NGluHVhOMVBPb5Ulco2YCZW+MwgiQMvgJtiRh8I=; b=mJLyJNc0vlANT9AN5meIYfVTvE fRk1ivANjfXQfADQZFDUKtebMcg+77LCTe/M+TMzUDj9N3PoFrgO6Z5bYyGTns69OAGvRR3doZA1D jjmrlcMMcsTY1RI29flf7BFcP6WUIO/hcPcvApBwmXpF2qEhPhXuVCyeQLWzS6RKZjHWHXK06Ge66 HRd8RpERa9WsIRmksUTBXNvw8SwT//lbTji+v3QKk/akL6kit4PNgbuzBRV2Lgp3INT+jtjFuh4jP fKz64HOuW3sBKGGMN70Kg2tpZuGLGugAeHFsWe6BfzfceMufg1eW4jlzmToNHlcBOeqlPPMzKAuHH Cv7h2zOw==; Received: from hansfords.plus.com ([84.92.116.209]:37265 helo=Vanguard) by server.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1cIt0p-002Nb7-63; Mon, 19 Dec 2016 08:09:35 +0000 From: "Jonathan Hansford" To: "'Ladislav Lhotka'" , "'Andy Bierman'" , "'Mehmet Ersue'" References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> In-Reply-To: Date: Mon, 19 Dec 2016 08:09:36 -0000 Message-ID: <001001d259cf$3d5a0de0$b80e29a0$@hansfords.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJvIdnLcbPhtZVe/ZwhlJOAl849fwFrVtQ3AezV2tIA+5xlnwL4zh2sAk77YEwCCFzmZgJIVCHNAgcLeowB7aW4ZgFJbBpLAgSx2bABY2d4S58gwHvQ Content-Language: en-gb X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.myfast.site X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hansfords.net X-Get-Message-Sender-Via: server.myfast.site: authenticated_id: jonathan@hansfords.net X-Authenticated-Sender: server.myfast.site: jonathan@hansfords.net Archived-At: Cc: 'NetMod WG Chairs' , 'NetConf WG Chairs' , 'NetMod WG' , 'Netconf' Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 08:09:39 -0000 > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav > Lhotka > Sent: 14 December 2016 14:25 > To: Andy Bierman ; Mehmet Ersue > > Cc: NetMod WG Chairs ; NetConf WG Chairs > ; NetMod WG ; Netconf > > Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod- > revised-datastores-00 > : > As for candidate, it is optional and we all know that it is quite problematic if > concurrent access of multiple clients is possible. Therefore, it would IMO be a > good riddance. For someone who is yet to see NETCONF and YANG used in anger, can you explain why judicious use of candidate and lock is problematic with concurrent access and why, as a consequence, it should be got rid of? One of the features of NETCONF that attracted us to it is its support for transactioning, a feature which it would appear came from previous experience with JUNOS. Is it current guidance that transactioning should not be used? Jonathan > > Lada From nobody Mon Dec 19 01:57:39 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE76A12940B for ; Mon, 19 Dec 2016 01:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 vJNcdk911i3W for ; Mon, 19 Dec 2016 01:57:37 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E312B129409 for ; Mon, 19 Dec 2016 01:57:36 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 9802D1AE028C; Mon, 19 Dec 2016 10:57:35 +0100 (CET) Date: Mon, 19 Dec 2016 10:57:34 +0100 (CET) Message-Id: <20161219.105734.2288928219739570577.mbj@tail-f.com> To: rohitrranade@huawei.com From: Martin Bjorklund In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6B01157D@DGGEMA502-MBX.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A6B004060@DGGEMA502-MBX.china.huawei.com> <20161216.104728.1386223505634208297.mbj@tail-f.com> <991B70D8B4112A4699D5C00DDBBF878A6B01157D@DGGEMA502-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=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] [Netconf] Leaf-list usage X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 09:57:39 -0000 Rohit R Ranade wrote: > Hi Martin, > = > As per the discussion in https://www.ietf.org/mail-archive/web/netmod= /current/msg01984.html, the understanding is that = > = > > fred > > = > Will select both the records: > = > (Rec1) > 10 > fred > > (Rec2) > 20 > fred > barney > =A0wilma > someother > > = > "Since there is a node in the data store that matches > the content match node fred, all sibling nodes at this > level are selected." > This was the explanation given that time. = > = > Q1: Can you please clarify as to why the Record 2 is not selected as > per RFC 6241. Sorry I misread your original question. You are correct that this request will get both records. The client will get both records, and will have to do further filtering in the client code. > Q2: Whether to select Record 2 only, user need to provide all its lea= f-list elements values in the query request? It depends on what's in the db. /martin > = > With Regards, > Rohit > = > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] = > Sent: 16 December, 2016 17:47 > To: Rohit R Ranade > Cc: lhotka@nic.cz; netmod@ietf.org > Subject: Re: [netmod] [Netconf] Leaf-list usage > = > Rohit R Ranade wrote: > > Hi, > > Consider we have 2 records as given below = > > (Rec1) > > 10 > > fred > > > > (Rec2) > > 20 > > fred > > barney > > wilma > > someother > > > > = > > Q1 : Using subtree filtering which condition on the leaf-list node = can > > the user give such that he selects the record which contains foo=3D= fred > > only... > > [we can assume user does not know the value of "name"] > = > > fred > > = > = > > Q2 : Also about the leaf-list, I have tried searching but have not > > found how this leaf-list originated ? > = > 1 instance of a scalar type =3D> leaf > N instances of a scalar type =3D> leaf-list > 1 instance of a structure =3D> container > N instances of a structure =3D> list > = > > Whether XSD list is the > > representation for leaf-list in xsd ? > = > No. > = > > The XSD list is represented slightly differently as per > > http://www.w3schools.com/xml/el_list.asp : I lov= e XML > > Schema > = > Correct. > = > = > /martin > = From nobody Mon Dec 19 02:38:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33261129604; Mon, 19 Dec 2016 02:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 f5GrbuPt3m7P; Mon, 19 Dec 2016 02:38:16 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F994129669; Mon, 19 Dec 2016 02:37:59 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:691f:24b5:66f8:76be] (unknown [IPv6:2001:718:1a02:1:691f:24b5:66f8:76be]) by mail.nic.cz (Postfix) with ESMTPSA id 0120A60ABD; Mon, 19 Dec 2016 11:37:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1482143878; bh=urzxPjNQEFqpMbcIwqR441qts8iytfuTnei3g17JSMQ=; h=From:Date:To; b=IGZMfYePYBHZQ1Boy77dyhnvs4+nsGYhVaPpqWxzA5drZg6OIBApYeeWHIPMku0fM pf4SxlFvaBNif9mWAA3YMKXYOBZEy1Wa1Pdlq7iigMeCxIDdtUd8+Pkl3jYEnb2PKw 35orx6ZvLSjA1n0GmuMl+084FN7j7UuSy3nw0vDQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <001001d259cf$3d5a0de0$b80e29a0$@hansfords.net> Date: Mon, 19 Dec 2016 11:37:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <462EE5E8-2FBD-4946-93B5-81E048AB3BE2@nic.cz> References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> <001001d259cf$3d5a0de0$b80e29a0$@hansfords.net> To: Jonathan Hansford X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 10:38:18 -0000 > On 19 Dec 2016, at 09:09, Jonathan Hansford = wrote: >=20 >> -----Original Message----- >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav >> Lhotka >> Sent: 14 December 2016 14:25 >> To: Andy Bierman ; Mehmet Ersue >> >> Cc: NetMod WG Chairs ; NetConf WG Chairs >> ; NetMod WG ; Netconf >> >> Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod- >> revised-datastores-00 >>=20 > : >> As for candidate, it is optional and we all know that it is quite > problematic if >> concurrent access of multiple clients is possible. Therefore, it = would IMO > be a >> good riddance. >=20 > For someone who is yet to see NETCONF and YANG used in anger, can you > explain why judicious use of candidate and lock is problematic with > concurrent access and why, as a consequence, it should be got rid of? = One of I am not proposing to ban candidate or something but IMO it needn't be = part of the base NETCONF (or whatever protocol) spec. A typical problem of candidate combined with NACM is that user A edits = item X and B edits Y in candidate. If B doesn't have write access to X = and A to Y, then none of them is able to make a commit. Lada > the features of NETCONF that attracted us to it is its support for > transactioning, a feature which it would appear came from previous > experience with JUNOS. Is it current guidance that transactioning = should not > be used? >=20 > Jonathan >=20 >>=20 >> Lada >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Dec 19 02:50:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C29E1296FC; Mon, 19 Dec 2016 02:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-Hbqs4pvmqO; Mon, 19 Dec 2016 02:50:50 -0800 (PST) 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 2AF52129887; Mon, 19 Dec 2016 02:48:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2481; q=dns/txt; s=iport; t=1482144521; x=1483354121; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=+GcnLQAOV8Z12lB15Xbozb79KNz40GIVWbNRNBJmvfw=; b=RYxJ7LtXFtmjKq+LPCqt654lcqWEI+xRqYVgZS0iAeCvFkEnXW9kOHW7 FpaeaY+niudQ44UO8UQedNVXkpoLmTVTc8ZNjAV+Zxrxx12AJtSSCAJz/ 1XQNk2YMZ6dqTlbBv3jHW8FqJT6KdQpVzF5JDwF/4qG8D8GRsHiP7o8Wm M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CXAgDOuVdY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgywLAQEBAQF5gQaOQpVkh3aNGIIKHwuFLkoCglYSAQIBAQEBAQE?= =?us-ascii?q?BYiiEaAEBAQQBARAmNgsMBAsRAQMBAQEnByEGHwMGCAYBDAYCAQEXB4gvAxcOn?= =?us-ascii?q?kIBkB6HJw2DVwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhjaBfQiCVIJIh1kFiFu?= =?us-ascii?q?HaIl4NY1Cg3KBdIgqhi+HcIFyUoNlhA8mDSOBAhUOK4NdHBiBRT40iFwBAQE?= X-IronPort-AV: E=Sophos;i="5.33,373,1477958400"; d="scan'208";a="690562521" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Dec 2016 10:48:39 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uBJAmcZ2008163; Mon, 19 Dec 2016 10:48:39 GMT To: Jonathan Hansford , "'Ladislav Lhotka'" , "'Andy Bierman'" , "'Mehmet Ersue'" References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> <001001d259cf$3d5a0de0$b80e29a0$@hansfords.net> From: Robert Wilton Message-ID: <1665b254-b9eb-3260-9b66-1e82662b36ac@cisco.com> Date: Mon, 19 Dec 2016 10:48:34 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <001001d259cf$3d5a0de0$b80e29a0$@hansfords.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: 'NetMod WG Chairs' , 'NetConf WG Chairs' , 'NetMod WG' , 'Netconf' Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 10:50:51 -0000 Hi Jonathan, These are just my thoughts ... I'm not advocating getting rid of candidate/locking, but if I was designing a new network management solution, I would not plan on using candidate/locking. Candidate is great when you have got a human operator typing in some config on the CLI and want to stop anyone (or anything) else changing the config at the same time under their feet. But once you only have machines programming the config, then they should be able to easily construct a single message for each edit of the config (which can be applied/failed in its entirety). Candidate and locking don't seem to help here. Further, if you want to update multiple devices at the same time then you end up in the realm of distributed transactions which get very complicated and are hard to get right in a fully robust fashion. It is at this point, that I would try hard to build a network management architecture that doesn't rely on transactions or locking, and instead only relies on individual updates being consistently applied in a serialized fashion. Rob On 19/12/2016 08:09, Jonathan Hansford wrote: >> -----Original Message----- >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav >> Lhotka >> Sent: 14 December 2016 14:25 >> To: Andy Bierman ; Mehmet Ersue >> >> Cc: NetMod WG Chairs ; NetConf WG Chairs >> ; NetMod WG ; Netconf >> >> Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod- >> revised-datastores-00 >> > : >> As for candidate, it is optional and we all know that it is quite > problematic if >> concurrent access of multiple clients is possible. Therefore, it would IMO > be a >> good riddance. > For someone who is yet to see NETCONF and YANG used in anger, can you > explain why judicious use of candidate and lock is problematic with > concurrent access and why, as a consequence, it should be got rid of? One of > the features of NETCONF that attracted us to it is its support for > transactioning, a feature which it would appear came from previous > experience with JUNOS. Is it current guidance that transactioning should not > be used? > > Jonathan > >> Lada > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Mon Dec 19 03:31:14 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3760129712; Mon, 19 Dec 2016 03:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 X_ZsF0ONAfF4; Mon, 19 Dec 2016 03:31:11 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3F95E12954D; Mon, 19 Dec 2016 03:31:11 -0800 (PST) Received: from [10.147.40.119] (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 88C3D1AE028C; Mon, 19 Dec 2016 12:31:08 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3270799B-4DF7-49D6-8547-35878A9D6488"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jan Lindblad In-Reply-To: <1665b254-b9eb-3260-9b66-1e82662b36ac@cisco.com> Date: Mon, 19 Dec 2016 12:31:07 +0100 Message-Id: <81B98FB8-DF86-4151-B3E6-322F0A5FAAAE@tail-f.com> References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> <001001d259cf$3d5a0de0$b80e29a0$@hansfords.net> <1665b254-b9eb-3260-9b66-1e82662b36ac@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3124) Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 11:31:14 -0000 --Apple-Mail=_3270799B-4DF7-49D6-8547-35878A9D6488 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > But once you only have machines programming the config, then they = should be able to easily construct a single message for each edit of the = config (which can be applied/failed in its entirety). Candidate and = locking don't seem to help here. >=20 > Further, if you want to update multiple devices at the same time then = you end up in the realm of distributed transactions which get very = complicated and are hard to get right in a fully robust fashion. Harder still without the candidate. Any case where transaction phases or = timing is involved would be harder to get right without the candidate = and confirmed commit. Being far from perfect, it's the best standardized = configuration protocol out there. /jan --Apple-Mail=_3270799B-4DF7-49D6-8547-35878A9D6488 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYV8T7AAoJEBSCnbqufIis6Q4H/1oMPJdVqJBtZnLVm0EZ9s6V huYfmCep5sRUJqPeET2qiBpKsUuN9P6SThI6h1+hdQlMaMX03bFEcNAs+ozlMMOR +65L345lhijhf6plRj1JsslWcF77XV2kbybmcMfidIj1ZaltZ7kLOS4QYGISVgGi Fv63G/TiQrw/EjhGh94ttlOWJ4mcLegLMnO4ioZvs5rZEKJydvSrhcTMwCNKhscq g2uH6/svwCcDsPUAlZpUNxxV3W2GJfjFwORpYmjenIZYJc03copN+e94U4GGgxVc rWSbUR+Zme2lD8UuG/BdhGAm3qHfLnNXmtYMlWDCRnrgicfL6zzT6GhXGaVnNP0= =NmGu -----END PGP SIGNATURE----- --Apple-Mail=_3270799B-4DF7-49D6-8547-35878A9D6488-- From nobody Mon Dec 19 04:49:02 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA349129A04; Mon, 19 Dec 2016 04:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] 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 nSUkvY9f7T7G; Mon, 19 Dec 2016 04:48:55 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D94B1299F4; Mon, 19 Dec 2016 04:48:55 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6B6F77D5; Mon, 19 Dec 2016 13:48:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id EJ4p9j1z2vsy; Mon, 19 Dec 2016 13:48:53 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 19 Dec 2016 13:48:54 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B5F12007A; Mon, 19 Dec 2016 13:48:54 +0100 (CET) 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 bqyrs2dg56pt; Mon, 19 Dec 2016 13:48:53 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DBF3B20079; Mon, 19 Dec 2016 13:48:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7F8D33DD5C91; Mon, 19 Dec 2016 13:48:53 +0100 (CET) Date: Mon, 19 Dec 2016 13:48:53 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20161219124853.GB2012@elstar.local> Mail-Followup-To: Ladislav Lhotka , Jonathan Hansford , NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf References: <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> <001001d259cf$3d5a0de0$b80e29a0$@hansfords.net> <462EE5E8-2FBD-4946-93B5-81E048AB3BE2@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <462EE5E8-2FBD-4946-93B5-81E048AB3BE2@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 12:48:57 -0000 On Mon, Dec 19, 2016 at 11:37:57AM +0100, Ladislav Lhotka wrote: > > I am not proposing to ban candidate or something but IMO it needn't be part of the base NETCONF (or whatever protocol) spec. > Lets recall that candidate is a _capability_. Nobody is required to implement it. > A typical problem of candidate combined with NACM is that user A edits item X and B edits Y in candidate. If B doesn't have write access to X and A to Y, then none of them is able to make a commit. > The problem is caused by allowing users with inconsistent access rights to both use candidate. So you get what you asked for. But I assume you can still do and recover. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Dec 19 04:56:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C241299D6; Mon, 19 Dec 2016 04:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 N4qKF6Io6mlg; Mon, 19 Dec 2016 04:56:19 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 381F41299F2; Mon, 19 Dec 2016 04:56:19 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:691f:24b5:66f8:76be] (unknown [IPv6:2001:718:1a02:1:691f:24b5:66f8:76be]) by mail.nic.cz (Postfix) with ESMTPSA id 920DE6FF55; Mon, 19 Dec 2016 13:56:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1482152177; bh=zniibWwvHrKScqhkfICCfXWiFBTXM07XczeXdktOCjg=; h=From:Date:To; b=EU9MYYE1NZpdumi3kWkQRzSijzTqdJa5A6Wts92tKTIrdWQUzJ1EktgoP8qK8NUiS xuNurvVwmfeXS+jxH7dJ+bfX/ZxBoNM03b1q3jJXgZ1hWVUHrNHteJQSVqi3JL/+nI xn6XL1z8sBW/ZcQuerHaUlIzoefWtURyLNFzo5Eg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <81B98FB8-DF86-4151-B3E6-322F0A5FAAAE@tail-f.com> Date: Mon, 19 Dec 2016 13:56:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> <001001d259cf$3d5a0de0$b80e29a0$@hansfords.net> <1665b254-b9eb-3260-9b66-1e82662b36ac@cisco.com> <81B98FB8-DF86-4151-B3E6-322F0A5FAAAE@tail-f.com> To: Jan Lindblad X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 12:56:22 -0000 > On 19 Dec 2016, at 12:31, Jan Lindblad wrote: >=20 >> But once you only have machines programming the config, then they = should be able to easily construct a single message for each edit of the = config (which can be applied/failed in its entirety). Candidate and = locking don't seem to help here. >>=20 >> Further, if you want to update multiple devices at the same time then = you end up in the realm of distributed transactions which get very = complicated and are hard to get right in a fully robust fashion. >=20 > Harder still without the candidate. Any case where transaction phases = or timing is involved would be harder to get right without the candidate = and confirmed commit. Being far from perfect, it's the best standardized = configuration protocol out there. Per-user candidate datastores are much easier to deal with, and this is = what we do in our RESTCONF implementation: https://github.com/CZ-NIC/jetconf Lada >=20 > /jan >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Dec 19 05:14:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEBB129A1E; Mon, 19 Dec 2016 05:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 YO5PT2Zj2iYO; Mon, 19 Dec 2016 05:14:51 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E06D129A20; Mon, 19 Dec 2016 05:14:50 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:691f:24b5:66f8:76be] (unknown [IPv6:2001:718:1a02:1:691f:24b5:66f8:76be]) by mail.nic.cz (Postfix) with ESMTPSA id 967DB75DBC; Mon, 19 Dec 2016 14:14:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1482153289; bh=YJHx5RcAP2rGd/zqh2R6rtjUjcZE3HZysDl+EFwT+zw=; h=From:Date:To; b=RA/l3pDfIHRGhpRbZFDkHk0HeAgJ0snJooHQvuNpZ2DECN49xHz3N+0vaBcYg6Eex NPMtNwkDUWBEFnbYqx2dkmytPqL05wGkj4uRnRZL/HSC88MVw0DiUVA1A3Jg0c2QUP 2oWFeAUxBvrwzUzdDJw2EhV3NkWZ7kCM7bfUxj80= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20161219124853.GB2012@elstar.local> Date: Mon, 19 Dec 2016 14:14:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <357D486B-0EB0-45E6-9583-730AF0FBB260@nic.cz> References: <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> <001001d259cf$3d5a0de0$b80e29a0$@hansfords.net> <462EE5E8-2FBD-4946-93B5-81E048AB3BE2@nic.cz> <20161219124853.GB2012@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 13:14:52 -0000 > On 19 Dec 2016, at 13:48, Juergen Schoenwaelder = wrote: >=20 > On Mon, Dec 19, 2016 at 11:37:57AM +0100, Ladislav Lhotka wrote: >>=20 >> I am not proposing to ban candidate or something but IMO it needn't = be part of the base NETCONF (or whatever protocol) spec. >>=20 >=20 > Lets recall that candidate is a _capability_. Nobody is required to > implement it. Yes, this is what I wrote. My point is that this capability could/should = be moved out of the NETCONF spec to a separate document. The latter can = then be modified without affecting the former.=20 >=20 >> A typical problem of candidate combined with NACM is that user A = edits item X and B edits Y in candidate. If B doesn't have write access = to X and A to Y, then none of them is able to make a commit. >>=20 >=20 > The problem is caused by allowing users with inconsistent access > rights to both use candidate. So you get what you asked for. But I Well, as soon as you let clients manage their private data (user = accounts, routing instances etc.) you get these "inconsistent" access = rights automatically. > assume you can still do and recover. ..., or find somebody with superuser privileges to perform the commit, = but it is clumsy either way. Automated solutions are likely to break. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Dec 19 05:28:52 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894DA129A59; Mon, 19 Dec 2016 05:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] 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 V-ITQ8QOzM8g; Mon, 19 Dec 2016 05:28:47 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2136129A53; Mon, 19 Dec 2016 05:28:46 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AFE3B7F8; Mon, 19 Dec 2016 14:28:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 58WbtETeCw4A; Mon, 19 Dec 2016 14:28:44 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 19 Dec 2016 14:28:45 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5CAAC2007A; Mon, 19 Dec 2016 14:28:45 +0100 (CET) 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 rG3Jg9I1IUW3; Mon, 19 Dec 2016 14:28:45 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D7B120079; Mon, 19 Dec 2016 14:28:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AC0FC3DD5F01; Mon, 19 Dec 2016 14:28:44 +0100 (CET) Date: Mon, 19 Dec 2016 14:28:44 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20161219132844.GA2177@elstar.local> Mail-Followup-To: Ladislav Lhotka , Jonathan Hansford , NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf References: <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> <001001d259cf$3d5a0de0$b80e29a0$@hansfords.net> <462EE5E8-2FBD-4946-93B5-81E048AB3BE2@nic.cz> <20161219124853.GB2012@elstar.local> <357D486B-0EB0-45E6-9583-730AF0FBB260@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <357D486B-0EB0-45E6-9583-730AF0FBB260@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 13:28:49 -0000 On Mon, Dec 19, 2016 at 02:14:49PM +0100, Ladislav Lhotka wrote: > > > On 19 Dec 2016, at 13:48, Juergen Schoenwaelder wrote: > > > > On Mon, Dec 19, 2016 at 11:37:57AM +0100, Ladislav Lhotka wrote: > >> > >> I am not proposing to ban candidate or something but IMO it needn't be part of the base NETCONF (or whatever protocol) spec. > >> > > > > Lets recall that candidate is a _capability_. Nobody is required to > > implement it. > > Yes, this is what I wrote. My point is that this capability could/should be moved out of the NETCONF spec to a separate document. The latter can then be modified without affecting the former. > I believe it does not matter where a capability is defined. You can even declare the capability dead by writing a document declaring it dead; this does not require to revise the RFC the capability is defined in. Since the candidate datastore has been in NETCONF since day one and it is out there and apparently used, I do not see a strong reason to move the definition. Those who do not like it simply do not implement it. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Dec 19 05:40:39 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D76012943B for ; Mon, 19 Dec 2016 05:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALBBHbHCAA3l for ; Mon, 19 Dec 2016 05:40:36 -0800 (PST) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 3747B129A30 for ; Mon, 19 Dec 2016 05:40:36 -0800 (PST) Received: (qmail 16379 invoked by uid 0); 19 Dec 2016 13:33:53 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy6.mail.unifiedlayer.com with SMTP; 19 Dec 2016 13:33:53 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id MpZq1u00f2SSUrH01pZt9K; Mon, 19 Dec 2016 06:33:53 -0700 X-Authority-Analysis: v=2.1 cv=DKocvU9b c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=n5n_aSjo0skA:10 a=2pI7ILdtxjVHaGA5pc8A:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject; bh=NrheFPL+6qLWm+r+TGAmbAkHIK4ifFbUYuIvz0xSuCM=; b=D22E3Bo0dgCCdvja0vjoowVV5E AqSIr2oxyFRH8AepyHU/c/bkzYT9RlJarHahyjX+R68xY7HBw+6mLvGTGAabn/sr4CB3mKBk3/2uI x0lgWS5MJmpC9IdkvcqhttNiG; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:58903 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1cIy4c-0004dp-GA; Mon, 19 Dec 2016 06:33:50 -0700 To: NetMod WG , NetConf WG References: From: Lou Berger Message-ID: <23632d7c-51c2-732d-4928-1c23b3089077@labn.net> Date: Mon, 19 Dec 2016 08:33:47 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cIy4c-0004dp-GA X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:58903 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs Subject: Re: [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 13:40:37 -0000 All, This poll is closed and this document is adopted in the NETMOD WG. There have been many good topics raised during the call adoption call that we will work through. Kent and I are already working on a draft of the updated charter. Authors, Please resubmit your draft with the new name draft-nmdsdt-netmod-revised-datastores-00 and with that and the date being the only change. Please consider how you want to track and resolve the topics/issues raised during the adoption call. WG trac and github issue tracker are available to you. Please also set a topic-specific Subject line in any list followup. -- Draft specific discussion can now be limited to just the netmod list. Thank you! Lou On 12/2/2016 4:26 PM, Lou Berger wrote: > All, > > This is start of a two week poll on making > draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group > document. This document is unusual in that WG last call will be jointly > held in both the NetConf and NetMod WGs, while adoption and day-to-day processing > will take place in NetMod. > > Please send email to the list indicating "yes/support" or "no/do not > support". If indicating no, please state your reservations with the > document. If yes, please also feel free to provide comments you'd like > to see addressed once the document is a WG document. > > The poll ends December 16. > > Thank you, > NetConf and NetMod WG Chairs > > From nobody Mon Dec 19 06:25:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A86A129ADE; Mon, 19 Dec 2016 06:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 VVePhkMNmLDZ; Mon, 19 Dec 2016 06:25:26 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::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 A1AB4129AEB; Mon, 19 Dec 2016 06:25:25 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id g23so18970858wme.1; Mon, 19 Dec 2016 06:25:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language:disposition-notification-to; bh=yhhuobGye+0YSENxtbGJCq9MpZ7VNsewJcmQIvQTxFo=; b=QYGkTZPvZXCyykp3YuCAccicKmm72Zo4u+nhUENReN7FY+pYz6yeTRrvnEfohXrlkz dC9MW6FcbADi/pGpDeXbyZacO9Hn06H9BCMBYt1ZN7ZbaU0cOrfRoRaGlFMylc5B8/ka yTJdzWeFl6BpNmIR3LfBV8EyrC2GLu0xOmXKFPESqTn75DUFbti3EzgXnL8FlSjiHAK/ /wKNM82tal6M8SuM21g567c7BFuN9kk5AtQscJp8EXBEIQKfFmeL3NCk92qQMhsqPUXX AHFCBSGwz+NbUk0SSRni22bb+uxB3WOu/jX4LCYci/ILj19HQXjSeTyJet8Q8kYX14gC fNYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language:disposition-notification-to; bh=yhhuobGye+0YSENxtbGJCq9MpZ7VNsewJcmQIvQTxFo=; b=RHlLvVd5CCDxt6BC3hbvXkf9E1VZjPfiArkAFvL49zqvcATL3I3mws/iV03EMHdA5x LgYx3w+EA/l9vXiQg3GiMjXMKs0bf0TQdiw9odb1Azo1UUN3sj8GTto5Oorbie/jD+pm K3o5tOKBKjmmtycRsSsvEf/hYoOSu8TBi9VfTk1kaFsP/U8U4ZQLrx2JGW06RxJzYi2M dwgkMB3214757wnAVFeWlWQ5Xy4qpZ7YHVroTzQoasQSYHIeb1TCvrRLYpgr9tYMK05g aT/xMfr2LAuI7l1GPSKnU/wGqrVHFuaN9l2ty97nY3lwyjnWgiWVrfylGGfU/csLcbZR g8aQ== X-Gm-Message-State: AIkVDXL1cOQXiPGAswUw+Lnz+RJRPHqiYa79ty5HHDmW+tYr2wan33d1nDhDADAklewLwg== X-Received: by 10.28.164.196 with SMTP id n187mr13389447wme.44.1482157524099; Mon, 19 Dec 2016 06:25:24 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B3402E0.dip0.t-ipconnect.de. [91.52.2.224]) by smtp.gmail.com with ESMTPSA id d64sm17419475wmh.3.2016.12.19.06.25.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Dec 2016 06:25:23 -0800 (PST) From: "Mehmet Ersue" To: "'Lou Berger'" , "'NetMod WG'" , "'NetConf WG'" References: <23632d7c-51c2-732d-4928-1c23b3089077@labn.net> In-Reply-To: <23632d7c-51c2-732d-4928-1c23b3089077@labn.net> Date: Mon, 19 Dec 2016 15:25:22 +0100 Message-ID: <008e01d25a03$bc57d440$35077cc0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJvIdnLcbPhtZVe/ZwhlJOAl849fwJKHC9Dn8Nxd/A= Content-Language: de X-AVK-Virus-Check: AVA 25.9617;3C2B908 X-AVK-Spam-Check: 1; str=0001.0A0C0201.5857EDD3.005B,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Cc: 'NetMod WG Chairs' , 'NetConf WG Chairs' Subject: Re: [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 14:25:28 -0000 Dear Lou, as I stated earlier and some people agreed, I believe this document = should be published as Informational RFC. The reason I gave is below: > I see the DT document as a datastore solution proposal. There are = different gaps and issues which still need to be addressed and the = solution proposal needs yet to be=20 > discussed and finalized. The document is providing information on the = history, explaining the need for a generic solution as well as is = discussing different scenarios.=20 > As such I believe the datastore solution proposal from the DT should = be published with the intended status Informational RFC. I would like to recommend to change the intended status of the draft = accordingly. Thanks, Mehmet -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Monday, December 19, 2016 2:34 PM To: NetMod WG ; NetConf WG Cc: NetMod WG Chairs ; NetConf WG Chairs = Subject: Re: WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 All, This poll is closed and this document is adopted in the NETMOD WG. There have been many good topics raised during the call adoption call = that we will work through. Kent and I are already working on a draft of = the updated charter. Authors, Please resubmit your draft with the new name draft-nmdsdt-netmod-revised-datastores-00 and with that and the date = being the only change. Please consider how you want to track and resolve the topics/issues = raised during the adoption call. WG trac and github issue tracker are = available to you. Please also set a topic-specific Subject line in any = list followup.=20 -- Draft specific discussion can now be limited to just the netmod list. Thank you! Lou On 12/2/2016 4:26 PM, Lou Berger wrote: > All, > > This is start of a two week poll on making > draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group=20 > document. This document is unusual in that WG last call will be=20 > jointly held in both the NetConf and NetMod WGs, while adoption and=20 > day-to-day processing will take place in NetMod. > > Please send email to the list indicating "yes/support" or "no/do not=20 > support". If indicating no, please state your reservations with the=20 > document. If yes, please also feel free to provide comments you'd=20 > like to see addressed once the document is a WG document. > > The poll ends December 16. > > Thank you, > NetConf and NetMod WG Chairs > > From nobody Mon Dec 19 11:37:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E2F1295EB; Mon, 19 Dec 2016 11:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFUOsMqV3iYV; Mon, 19 Dec 2016 11:37:42 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08C01295C4; Mon, 19 Dec 2016 11:37:41 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id f82so110809600wmf.1; Mon, 19 Dec 2016 11:37:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Xh3DeryjwMBku5SRLI68IvHadfUCcah8MnRZqGhgB+k=; b=aUtK8XgvVmxJZJK4oiHS8XLii2IwU2luYbcIE8WCubuzit71dA13jrkbmBGHOtn7VB zvJqolV3zc5RGX7wu8++oHvh+b+kywj1ZROhUuLMkleHgGM8AL8xD6+INoabbsHHVqMW 4sbB1tj6UgZbaYZ5TqEDoOg+cz+db41x0e3rJGpfRRPMmSdHPBY1SLlkdzzLT3JpKExt IJW7Xgs3HYXRR7N+c9TwlsI4gKiEhDff29dp4W+V6xyRPhgejsIa3Top6vMC1cmDnsHM QmPgf5mHrBKJ4ho6GmkE+c8x0sublugrR5qcAuUSPITULDFCX0sqvuFIl0pAG2GUjIKe 1Tsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Xh3DeryjwMBku5SRLI68IvHadfUCcah8MnRZqGhgB+k=; b=pryMJWW/EVm6LqrZmK+QsOY5OQ29nGMHFbFJSG2zD0NTXosJRECPBPUDN2UbYnuXx1 72K/zLbMEA1BOgn93TD9fU1oJPF6j/agJzCTURLZI05q7jg+FGTxbkV3ZYlp6GLYwKrd hjtCPPUjHl8zoipfmCbRnsayurVo0nTck1j57+FPgz8mtjDXFcSKhRwwbNVo9B+KAVuj 3Uy+nY6WztUUvHYQ2K77oUbny93rB4whSO7aE3KYb9/ExdymlKLC2/Q+vTq4DSFNI/pB AG0sfqVvAkUpfFHKkdA2eAHU7mSdCA0vHcu1m1cYQ0V56vwp0WmrT+BiJdQU9ogS4NiF qHdQ== X-Gm-Message-State: AIkVDXIuVMy3HGQ+rGTFnBfFwNo0KwvrnjflM1dri+6hye7MFOgjSyfQXQcEnL2xmcLboA== X-Received: by 10.28.182.70 with SMTP id g67mr16369436wmf.90.1482176260241; Mon, 19 Dec 2016 11:37:40 -0800 (PST) Received: from ams-giheron-8913.cisco.com ([173.38.220.58]) by smtp.gmail.com with ESMTPSA id wg8sm22043313wjb.42.2016.12.19.11.37.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Dec 2016 11:37:39 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Giles Heron In-Reply-To: Date: Mon, 19 Dec 2016 19:37:37 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Lou Berger X-Mailer: Apple Mail (2.3259) Archived-At: Cc: NetMod WG Chairs , NetMod WG Subject: Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 19:37:44 -0000 support a couple of quick Qs for the authors: 1) is there a reason why you have the =E2=80=9Ctags=E2=80=9D container = in the L3 interface but don=E2=80=99t have equivalents in the flexible = encapsulation model? since the =E2=80=9Ctags=E2=80=9D container is the = only thing inside the enclosing =E2=80=9Cvlan=E2=80=9D container I=E2=80=99= m not sure it=E2=80=99s required. 2) would it be better to rename =E2=80=9Cpush-tags=E2=80=9D as = =E2=80=9Cpush-tag=E2=80=9D to stick with the convention of singular = names for YANG lists? Giles > On 12 Dec 2016, at 23:31, Lou Berger wrote: >=20 > All, >=20 > This is start of a two week* poll on making > draft-wilton-netmod-intf-vlan-yang-04 a NetMod working group > document. >=20 > Please send email to the list indicating "yes/support" or "no/do not > support". If indicating no, please state your reservations with the > document. If yes, please also feel free to provide comments you'd = like > to see addressed once the document is a WG document. >=20 > * Given the holiday, the poll ends December 28. >=20 > Thank you, > NetMod WG Chairs >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Dec 20 07:44:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E1B129AA6; Tue, 20 Dec 2016 07:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5j9do6Rzm6D; Tue, 20 Dec 2016 07:44:21 -0800 (PST) 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 8A865129AA1; Tue, 20 Dec 2016 07:44:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1769; q=dns/txt; s=iport; t=1482248660; x=1483458260; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=LJMjYuZKe2i2iT5WMB5XwWmhruCogYITZXTa5xxIIos=; b=HNQ86fimXuvEWylEE+FMpKEeMwzeo6CVLb9Nmg0IK+nDeaE2bdCq+xaf LefQ8X5JIQJb2FCsOchyowSuqW16JSpoy3fCBPtsW/msZyWzJ2wzOVQDZ Whr7t2N56lKxAzE21eSVy2yqzh2NkvkhIsqL1W7nsph2to47Gi+kHD3nq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAQDhUFlY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAXkuWI1Qc5VnlQ6CCgIdC4UuSgKCIhQBAgEBAQEBAQF?= =?us-ascii?q?iKIRoAQEBAwEBARARDwEFNgsQCxgCAiYCAicwBg0GAgEBHohBCA6bKwGMSQGBL?= =?us-ascii?q?IIoixsBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBTJZhSuBfYJchBIRAYMggl0FmnC?= =?us-ascii?q?RNIF0hQODJ4YvijSDZYQPHzdkHxUOLIVaPjSGRIIuAQEB?= X-IronPort-AV: E=Sophos;i="5.33,379,1477958400"; d="scan'208";a="690600178" 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; 20 Dec 2016 15:44:18 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uBKFiIov015488; Tue, 20 Dec 2016 15:44:18 GMT To: Giles Heron References: From: Robert Wilton Message-ID: <601d8ed8-c03b-60fe-a616-8a836ecb30a0@cisco.com> Date: Tue, 20 Dec 2016 15:44:18 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: NetMod WG Chairs , NetMod WG Subject: Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 15:44:27 -0000 Hi Giles, Thanks for the support, and comments. On 19/12/2016 19:37, Giles Heron wrote: > support > > a couple of quick Qs for the authors: > > 1) is there a reason why you have the “tags” container in the L3 interface but don’t have equivalents in the flexible encapsulation model? since the “tags” container is the only thing inside the enclosing “vlan” container I’m not sure it’s required. I agree that these should be consistent, although I'm not sure which one should be changed. Perhaps adding the tags container to the flexible encapsulation would be more consistent. I thought that it was always good practice to put a list into a container? > > 2) would it be better to rename “push-tags” as “push-tag” to stick with the convention of singular names for YANG lists? Yes. I can also fix that. Thanks, Rob > > Giles > >> On 12 Dec 2016, at 23:31, Lou Berger wrote: >> >> All, >> >> This is start of a two week* poll on making >> draft-wilton-netmod-intf-vlan-yang-04 a NetMod working group >> document. >> >> Please send email to the list indicating "yes/support" or "no/do not >> support". If indicating no, please state your reservations with the >> document. If yes, please also feel free to provide comments you'd like >> to see addressed once the document is a WG document. >> >> * Given the holiday, the poll ends December 28. >> >> Thank you, >> NetMod WG Chairs >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Dec 20 09:09:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E68129BB5 for ; Tue, 20 Dec 2016 09:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ll9mOoTmxfYy for ; Tue, 20 Dec 2016 09:09:20 -0800 (PST) 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 1DE95129BAC for ; Tue, 20 Dec 2016 09:09:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5570; q=dns/txt; s=iport; t=1482253760; x=1483463360; h=to:from:subject:message-id:date:mime-version; bh=ndAF4ZbFRVfBMgZtwmxZpZ48rN2uRuLtk2yl4hGOISk=; b=FBns7HCgetU+T4JwNXNnThGSg7BLpWYoutfE4OUIvvZrzD8TCQtxofzn 4s2ohoF+cMB1HImCZKY/MdF5jcABkcBGgBudtSXzjmEkqmNkT0HIXYw6d Wd/jv8Ld1xJUZ4x/JZMiJW8NDMJWPugQWqaPCnFQ8V0g8oSNwDiHbrsTG g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAgCXZFlY/xbLJq1dHAEBBAEBCgEBg?= =?us-ascii?q?nNEAQEBAQGBJ44oc6VQgxaCD4IKiEcUAQIBAQEBAQEBYiiFARFvRAJfAQwIAQE?= =?us-ascii?q?eiEmLQo9VAY12gigvilkBAQgCASWGNoF9iiCCXQWUboYCgUuIGYdQih6BMoR9i?= =?us-ascii?q?jWHdB83MVIVDoYGPokmAQEB?= X-IronPort-AV: E=Sophos;i="5.33,379,1477958400"; d="scan'208,217";a="648041346" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Dec 2016 17:09:16 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uBKH9Fvv020476; Tue, 20 Dec 2016 17:09:16 GMT To: "netmod@ietf.org" , Martin Bjorklund From: Robert Wilton Message-ID: <1db67b1d-36ef-5cc6-425f-7e22de7e80ae@cisco.com> Date: Tue, 20 Dec 2016 17:09:15 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------E15146EDA84011F650227822" Archived-At: Subject: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 17:09:22 -0000 This is a multi-part message in MIME format. --------------E15146EDA84011F650227822 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, The definition of "status" in RFC 7950 in section 7.21.2 (full text below), states: If no status is specified, the default is "current". From my interpretation of the text in the draft, this implies that the status of the "new" child leaf in the following example is "current", and that this example is allowed! My questions are: - Is my interpretation of the current text correct? - Is this actually the best behaviour, or should it inherit like the config statement? Should I raise an errata for this? container old { status deprecated; leaf new { description "what status do I have?"; } } Thanks, Rob Full 7.21.2 text from 7950: 7.21.2. The "status" Statement The "status" statement takes as an argument one of the strings "current", "deprecated", or "obsolete". o "current" means that the definition is current and valid. o "deprecated" indicates an obsolete definition, but it permits new/continued implementation in order to foster interoperability with older/existing implementations. o "obsolete" means that the definition is obsolete and SHOULD NOT be implemented and/or can be removed from implementations. If no status is specified, the default is "current". If a definition is "current", it MUST NOT reference a "deprecated" or "obsolete" definition within the same module. If a definition is "deprecated", it MUST NOT reference an "obsolete" definition within the same module. For example, the following is illegal: typedef my-type { status deprecated; type int32; } leaf my-leaf { status current; type my-type; // illegal, since my-type is deprecated } --------------E15146EDA84011F650227822 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

The definition of "status" in RFC 7950 in section 7.21.2 (full text below), states:

If no status is specified, the default is "current".

From my interpretation of the text in the draft, this implies that the status of the "new" child leaf in the following example is "current", and that this example is allowed!

My questions are:
 - Is my interpretation of the current text correct?
 - Is this actually the best behaviour, or should it inherit like the config statement?  Should I raise an errata for this?

container old {
  status deprecated;
  leaf new {
    description "what status do I have?"; 
  }
}

Thanks,
Rob


Full 7.21.2 text from 7950:

7.21.2.  The "status" Statement

   The "status" statement takes as an argument one of the strings
   "current", "deprecated", or "obsolete".

   o  "current" means that the definition is current and valid.

   o  "deprecated" indicates an obsolete definition, but it permits
      new/continued implementation in order to foster interoperability
      with older/existing implementations.

   o  "obsolete" means that the definition is obsolete and SHOULD NOT be
      implemented and/or can be removed from implementations.

   If no status is specified, the default is "current".

   If a definition is "current", it MUST NOT reference a "deprecated" or
   "obsolete" definition within the same module.

   If a definition is "deprecated", it MUST NOT reference an "obsolete"
   definition within the same module.

   For example, the following is illegal:

     typedef my-type {
       status deprecated;
       type int32;
     }

     leaf my-leaf {
       status current;
       type my-type; // illegal, since my-type is deprecated
     }

--------------E15146EDA84011F650227822-- From nobody Tue Dec 20 10:08:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56CA129C33; Tue, 20 Dec 2016 10:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0gaa0ZQgOxU; Tue, 20 Dec 2016 10:08:42 -0800 (PST) Received: from mail-wj0-x242.google.com (mail-wj0-x242.google.com [IPv6:2a00:1450:400c:c01::242]) (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 240C7129DBE; Tue, 20 Dec 2016 10:08:26 -0800 (PST) Received: by mail-wj0-x242.google.com with SMTP id xy5so28787407wjc.1; Tue, 20 Dec 2016 10:08:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HxIKCDtiRjFtuGuyIpYzpO2iOHFDwUaczwHqG3fNI2M=; b=dZQb9LvDqj5NTo0XaNXJHY93mz/UzDmJ7DAKgCGP3tFHngK/SCXamT8pUXoL9MyPa6 k9s4+b6WQB37FzgyBJhv4EZrr/zjqGXZM63pFurz7m9kvgjSrwpKgMWdW3MWUbcxNJ3p mTJGQsWgQQAm+8fQmhLtBRRX/+kYjlPAIQPHKEa0HoVn2lGfmbOu3GrJF1qE33GqF23w LnSvur7NTkXpj94wpJMB/GvG2G7oB4nxv3rRNUAd4Ax7pOFqfB1Ryawf3CGatiVKsKci 7PG5gani8VNt8iXTONf1UozkVoJ/cVjqVcUeGjXdFK995rlfPQoWD9TIDJ4esPJgUkP1 lX3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HxIKCDtiRjFtuGuyIpYzpO2iOHFDwUaczwHqG3fNI2M=; b=cnu0G+I659xKUX3ckVm6SW6KclIZ/cpqtGZQEN95ZEI6EEl68Aj1hO/je7ugCa7r8T 8Zsav87FAHqFVq61KNZVEGC7O4rfQi030XQN43Z4i5vwPJdkaFj7Utr7y0+SOLfGUMOp ilwFTN1dAFgxqweYZ0EMJCuYejemY4rHZChG7ionJiUBlmehUp1ZlEIpJh77TFN3PWZY 9HJ47puUuYYKKFdibv6Je0Kpq+qscPIzU1fOCvqtAV9BwcHomFwKkSeY+Ff6QgR6Aeyw 2tSVvgn7ylVkSuOhtyM8dpRDmP0Q4mbPTCL3FHaSRUb7W4WHYO2e3vfHqyFBKTQeIMFf Y3yA== X-Gm-Message-State: AIkVDXLFxVMTZ4kOq6AN/zpKWfQ8s+ZQhZvhh1kaKI0nJSpU2kt0uRI+xxrUt9nUQ8vfMw== X-Received: by 10.194.141.98 with SMTP id rn2mr517857wjb.1.1482257304626; Tue, 20 Dec 2016 10:08:24 -0800 (PST) Received: from ams-giheron-8914.cisco.com ([173.38.220.59]) by smtp.gmail.com with ESMTPSA id z6sm26659093wjt.24.2016.12.20.10.08.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Dec 2016 10:08:24 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Giles Heron In-Reply-To: <601d8ed8-c03b-60fe-a616-8a836ecb30a0@cisco.com> Date: Tue, 20 Dec 2016 18:08:22 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <18BBE32C-2CEA-4100-ADD1-D125723C7092@gmail.com> References: <601d8ed8-c03b-60fe-a616-8a836ecb30a0@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3259) Archived-At: Cc: NetMod WG Chairs , NetMod WG Subject: Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 18:08:43 -0000 Hi Robert, > On 20 Dec 2016, at 15:44, Robert Wilton wrote: >=20 > Hi Giles, >=20 > Thanks for the support, and comments. >=20 > On 19/12/2016 19:37, Giles Heron wrote: >> support >>=20 >> a couple of quick Qs for the authors: >>=20 >> 1) is there a reason why you have the =E2=80=9Ctags=E2=80=9D = container in the L3 interface but don=E2=80=99t have equivalents in the = flexible encapsulation model? since the =E2=80=9Ctags=E2=80=9D = container is the only thing inside the enclosing =E2=80=9Cvlan=E2=80=9D = container I=E2=80=99m not sure it=E2=80=99s required. > I agree that these should be consistent, although I'm not sure which = one should be changed. Perhaps adding the tags container to the = flexible encapsulation would be more consistent. I thought that it was = always good practice to put a list into a container? Yes - in general it=E2=80=99s a good practice to put a list into a = container. But in this case the tag list is the only entity in the = enclosing vlan container, so I=E2=80=99m not sure you need another level = of container. I suppose if you think you may add to the vlan container = in future then there may be value in the tags container (so you can get = all tags in one operation without getting the rest of the vlan = container) >>=20 >> 2) would it be better to rename =E2=80=9Cpush-tags=E2=80=9D as = =E2=80=9Cpush-tag=E2=80=9D to stick with the convention of singular = names for YANG lists? > Yes. I can also fix that. great. Giles > Thanks, > Rob >=20 >>=20 >> Giles >>=20 >>> On 12 Dec 2016, at 23:31, Lou Berger wrote: >>>=20 >>> All, >>>=20 >>> This is start of a two week* poll on making >>> draft-wilton-netmod-intf-vlan-yang-04 a NetMod working group >>> document. >>>=20 >>> Please send email to the list indicating "yes/support" or "no/do not >>> support". If indicating no, please state your reservations with the >>> document. If yes, please also feel free to provide comments you'd = like >>> to see addressed once the document is a WG document. >>>=20 >>> * Given the holiday, the poll ends December 28. >>>=20 >>> Thank you, >>> NetMod WG Chairs >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 From nobody Tue Dec 20 11:41:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA05129531 for ; Tue, 20 Dec 2016 11:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAuLnThr9vOo for ; Tue, 20 Dec 2016 11:41:08 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0128.outbound.protection.outlook.com [104.47.41.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1AE1129430 for ; Tue, 20 Dec 2016 11:33:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=anBDRHO89b+pyrecUSbVlfEOv2Sb4oYIAasXcyr48Xs=; b=IbzRKBjFA2gd4fPVI/eYjWgNM1BbDwd++8hiylxmUQPr2xQLCwC5iVSikbyoFZ83PPr+R6MseQiqhGD9CCtBXoDA+AA6/ieNo/z3wDRglfzAG5r/V+DuYJbGS1KEbXru+OLrddW5yHwjs7MQSPX9D6FMHSOa2QKJ15rA576wgEc= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.5; Tue, 20 Dec 2016 19:33:10 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0803.010; Tue, 20 Dec 2016 19:33:10 +0000 From: Kent Watsen To: Martin Bjorklund , "fenner@fenron.com" Thread-Topic: [netmod] A suggestion for yang namespaces Thread-Index: AQHSQIC8LPQhMigq5kqQghVyhkL3T6Dc6lgAgDQwnwA= Date: Tue, 20 Dec 2016 19:33:10 +0000 Message-ID: References: <20161117.103338.559979815043950622.mbj@tail-f.com> In-Reply-To: <20161117.103338.559979815043950622.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 552e369a-8d0e-4888-531c-08d4290f084b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1443; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:leLf5PVmzJNtgI5RZFWFxMVAkMTJYOnQAUPY67prP2PQdkZOtLzYWDjKv+bJxPWQKT7laCKCqb6Kyfa0VHgFBWu3GLJKU/7w1ajkEm/90PuJY5Kg99ajQHAHRtjdEk8rnkmO7C8YO19g9WjnMzeWw/+bOfvAF2MqAvXWW8C/SAujVhbhrVaFGLGCXwgu6dnpHFaGY9x+hAr3gmAQDfogRi0eZ+4qNstJV14lFKGAitHD41PsXJisiGFpt0ATEzxtsQTe71HDlTVipRHF0XHlQAhWLJTjx9j1FyIT1og2AArbRmuSaj0d0khkOs+R6rstG7+a7R03YS2PNWFBy+ALA/CbPL0Hc/TTps7O8L3UvH9uy1sq+TGIXKbaNOm6Ud5O6xGQ3jIEpiidFKpV412WyqssznIAolJiLDfZyKqUbT7VtToVG/CBHxqybLmuO/zefcyQ6Qvdpp9ptDE13xviag== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 0162ACCC24 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39850400002)(39410400002)(39450400003)(39840400002)(189002)(199003)(24454002)(4326007)(66066001)(76176999)(54356999)(50986999)(7736002)(3280700002)(2906002)(2900100001)(101416001)(305945005)(38730400001)(106356001)(2950100002)(25786008)(77096006)(36756003)(6512006)(6506006)(6486002)(6436002)(229853002)(99286002)(2501003)(92566002)(122556002)(105586002)(106116001)(102836003)(68736007)(6116002)(189998001)(5001770100001)(4001350100001)(81166006)(97736004)(83716003)(86362001)(33656002)(8936002)(82746002)(8676002)(5660300001)(3660700001)(3846002)(81156014)(83506001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <8191180DE0F22A4383786A80FD5C0937@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2016 19:33:10.4903 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] A suggestion for yang namespaces X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 19:41:09 -0000 DQoNCj5CaWxsIEZlbm5lciA8ZmVubmVyQGZlbnJvbi5jb20+IHdyb3RlOg0KPj4gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzQxNTEgZGVmaW5lcyB0aGUgInRhZzoiIFVSSSBzY2hlbWUs IHdoaWNoDQo+PiBhbGxvd3MgdGhlIGNyZWF0aW9uIG9mIFVSSXMgd2l0aCBuZWFybHkgYXJiaXRy YXJ5IHN5bnRheCBieSBhbnlvbmUgd2l0aCBhbg0KPj4gZW1haWwgYWRkcmVzcyBvciBkb21haW4g bmFtZS4gIEUuZy4sDQo+PiAidGFnOmV4YW1wbGUuY29tLDIwMTY6eWFuZzppbnRlcmZhY2UtZXh0 ZW5zaW9uIi4NCj4+IFRoZSBxdWlyayBoZXJlIGlzIHRoZSBkYXRlLCB3aGljaCBleGlzdHMgaW4g Y2FzZSBleGFtcGxlLmNvbSBnZXRzDQo+PiByZWFzc2lnbmVkIHRvIHNvbWVvbmUgZWxzZSBuZXh0 IHllYXIuDQo+PiANCj4+IElmIGF1dGhvcnMgY2FuIGFjY2VwdCB0aGUgZGF0ZSBxdWlyaywgdGhp cyBpcyBhbiBhbHJlYWR5LWV4aXN0aW5nIG1lY2hhbmlzbQ0KPj4gdGhhdCBpcyBuZWFybHkgaWRl bnRpY2FsIHRvIHRoZSBvbmUgdGhhdCB3YXMgcHJvcG9zZWQgaW4gWHVmZW5nJ3MNCj4+IHByZXNl bnRhdGlvbiB0b2RheS4NCj4NCj4gSSB3YXNuJ3QgYXdhcmUgb2YgdGhpcyBzY2hlbWUsIGJ1dCBJ IHRoaW5rIHRoaXMgaXMgZXhhY3RseSB3aGF0IGlzDQo+IG5lZWRlZC4gIEFzIGZvciB0aGUgZGF0 ZSBwYXJ0LCBpdCBpcyB0aGVyZSBmb3IgYSByZWFzb24sIHNvIGl0IHNob3VsZA0KPiBiZSBhY2Nl cHRhYmxlLg0KPg0KPiBTbywgc2luY2UgdGhpcyBzY2hlbWUgZXhpc3RzLCBJIGRvbid0IHRoaW5r IHdlIHNob3VsZCBkZWZpbmUgdGhlDQo+ICdyZG5zJyBzY2hlbWUuDQo+DQo+IC9tYXJ0aW4NCg0K DQpUaGFuayB5b3UsIEJpbGwsIGZvciBicmluZ2luZyBSRkMgNDE1MSB0byBvdXIgYXR0ZW50aW9u LiAgSGVsZW4sIHRoZSBhdXRob3Igb2YgdGhlIGRyYWZ0cyBpbiBxdWVzdGlvbiwgYWxzbyBhZ3Jl ZXMgdGhhdCB0aGUg4oCYdGFn4oCZIHNjaGVtZSBhZGRyZXNzZXMgdGhlIG5lZWQuICANCg0KR2l2 ZW4gdGhlc2UgY2lyY3Vtc3RhbmNlcywgd2UgY29uc2lkZXIgdGhlIG1hdHRlciBzZXR0bGVkIGFu ZCwgY29udHJhcnkgdG8gdGhlIE5FVE1PRCA5NyBtaW51dGVzLCB3ZSB3aWxsIG5vdCBpc3N1ZSBh IGNhbGwgZm9yIGFkb3B0aW9uIGZvciBkcmFmdC1jaGVuLXJkbnMtdXJuIGFuZCBkcmFmdC1jaGVu LW5ldG1vZC1lbnRlcnByaXNlLXlhbmctbmFtZXNwYWNlLg0KDQpPbmUgdGhpbmcsIHRoZXJlIGlz IGEgcmVxdWVzdCB0byBhZGQgYSByZWZlcmVuY2UgdG8gUkZDIDQxNTEgaW50byByZmM2MDg3Ymlz IGlmIHBvc3NpYmxlLiAgcmZjNjA4N2JpcyBpcyBjdXJyZW50bHkgaW4gQUQgRXZhbHVhdGlvbiBz dGF0ZSwgc28gdGhlcmUgbWF5IHN0aWxsIGJlIGFuIG9wcG9ydHVuaXR5IHRvIGRvIHRoaXMuDQoN ClRoYW5rcywNCktlbnQgLy8gYXMgY28tY2hhaXINCg0KDQo= From nobody Tue Dec 20 12:03:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3185D1295DE for ; Tue, 20 Dec 2016 12:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 uT5xayrg5biz for ; Tue, 20 Dec 2016 12:03:37 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 438C11295BE for ; Tue, 20 Dec 2016 12:03:37 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 507C81AE02BC; Tue, 20 Dec 2016 21:03:35 +0100 (CET) Date: Tue, 20 Dec 2016 21:03:35 +0100 (CET) Message-Id: <20161220.210335.1870203216124697421.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <1db67b1d-36ef-5cc6-425f-7e22de7e80ae@cisco.com> References: <1db67b1d-36ef-5cc6-425f-7e22de7e80ae@cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 20:03:39 -0000 Robert Wilton wrote: > Hi, > > The definition of "status" in RFC 7950 in section 7.21.2 (full text > below), states: > > If no status is specified, the default is "current". > > From my interpretation of the text in the draft, this implies that the > status of the "new" child leaf in the following example is "current", > and that this example is allowed! > > My questions are: > - Is my interpretation of the current text correct? Yes. > - Is this actually the best behaviour, or should it inherit like the > config statement? I think the idea was that if the status != current, it is better for the reader if it is explicitly stated. > Should I raise an errata for this? No. However, we could have said that a current node under a deprecated node (etc) in the same module is an error, in order to force people (through the useage of YANG validators) to detect and fix this. /martin > > container old { > status deprecated; > leaf new { > description "what status do I have?"; > } > } > > Thanks, > Rob > > > Full 7.21.2 text from 7950: > > 7.21.2. The "status" Statement > > The "status" statement takes as an argument one of the strings > "current", "deprecated", or "obsolete". > > o "current" means that the definition is current and valid. > > o "deprecated" indicates an obsolete definition, but it permits > new/continued implementation in order to foster interoperability > with older/existing implementations. > > o "obsolete" means that the definition is obsolete and SHOULD NOT be > implemented and/or can be removed from implementations. > > If no status is specified, the default is "current". > > If a definition is "current", it MUST NOT reference a "deprecated" or > "obsolete" definition within the same module. > > If a definition is "deprecated", it MUST NOT reference an "obsolete" > definition within the same module. > > For example, the following is illegal: > > typedef my-type { > status deprecated; > type int32; > } > > leaf my-leaf { > status current; > type my-type; // illegal, since my-type is deprecated > } > From nobody Tue Dec 20 12:15:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3919E129A28 for ; Tue, 20 Dec 2016 12:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] 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 Mb3xEDRs-cIJ for ; Tue, 20 Dec 2016 12:15:30 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA6D1295E1 for ; Tue, 20 Dec 2016 12:15:30 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3B9837EF; Tue, 20 Dec 2016 21:15:28 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 9y1a7YDBd4Bp; Tue, 20 Dec 2016 21:15:26 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 20 Dec 2016 21:15:27 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E55DC20079; Tue, 20 Dec 2016 21:15:27 +0100 (CET) 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 HPQ7bf2VJaKm; Tue, 20 Dec 2016 21:15:27 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7A02B20074; Tue, 20 Dec 2016 21:15:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1B2D53DD8028; Tue, 20 Dec 2016 21:15:27 +0100 (CET) Date: Tue, 20 Dec 2016 21:15:27 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20161220201527.GA3897@elstar.local> Mail-Followup-To: Martin Bjorklund , rwilton@cisco.com, netmod@ietf.org References: <1db67b1d-36ef-5cc6-425f-7e22de7e80ae@cisco.com> <20161220.210335.1870203216124697421.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161220.210335.1870203216124697421.mbj@tail-f.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 20:15:32 -0000 On Tue, Dec 20, 2016 at 09:03:35PM +0100, Martin Bjorklund wrote: > > However, we could have said that a current node under a deprecated > node (etc) in the same module is an error, in order to force people > (through the useage of YANG validators) to detect and fix this. > Is it an error or just something that deserves a warning and the author's attention? I am asking since we also have augmentations and if I mark a container as deprecated, this will not immediately cause an module augmenting the containter to get updated, hence I end up with definitions marked current in a deprecated container. And there are other situations where definitions may not be of the same status, i.e., a module (without import by revision) uses a type or grouping that in later revisions got marked deprecated. I think all of these status mismatches are things tools should warn about but I am not sure these are hard errors, in particular for 'deprecated'. Things may lead to stronger warnings for definitions marked 'obsolete'. /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 Dec 20 12:28:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906A5129601 for ; Tue, 20 Dec 2016 12:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqxCYaYEBaqk for ; Tue, 20 Dec 2016 12:28:46 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89C751295F0 for ; Tue, 20 Dec 2016 12:28:46 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id q68so61092393qki.1 for ; Tue, 20 Dec 2016 12:28:46 -0800 (PST) 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=m+P5Xb5OpcSOEdqhZfpRqX71bx3WV+H9gV3gBbeDKwI=; b=X3RETJozyYjpphrkQXZ/DngBpkSNwWE7sgHzTaiNMWZBRz2YQlVTYzfFSrhPeGmzI9 ptY2uFWvzkkTkE9eFRn1JbXMnPlkh6eTfDS1QrNaN440cPwt9gOrnBBicN91peVoxwKD T9Y0/yeiLE21e0CwLBKCz4o98MvCW1JZE7mM3UYwqe5KryBqrPJkkc4HjBKKINoH7mnh Gj3knJTMCgZqUim+uJgerc2OZiFNtAH8Zbc+ucw1SCl9IE8A6Fyhpq0dih4V7lwJxjrk EcT7WGPiZISLr9yZrEtMB8snuK0D/YjWErFiW/AnrNAhlqoMt21+z4Dd0oY5F1ytvrlV IiJQ== 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=m+P5Xb5OpcSOEdqhZfpRqX71bx3WV+H9gV3gBbeDKwI=; b=nggTcHn57NIgx/DvMHvcvmDtaesvLFIPtsC6OaLVVKhu4djbI7tijOI7SAwON8dx9L +j5u5dtHVvC7mN1Lqkv55Eu3kvQtYqw+iZU5MEmwqJK109gbJlBifDFLU7m382OsEs2L mZw0M6HFnOhMXqvNvR85ZAsTVoanNPUt4rw+7mzoQfSZf0X1+ZXQFnBAh+1f3N7ZrHXF Cf1SZQfxedhA4KE7DMDgqH+t45YvuV7w0V+cfpusJuEBLnjHle6OilsJsChaVj7OtSCL OySPhlNI6ONjPXdq0sqyuyIpFGBFGML8PHrgavV70HYpwyqMUUVU1uTCUmpdh/XlHHOT P29g== X-Gm-Message-State: AIkVDXKQ5SOYDVkil8CGNah95noYcTpEQcDHEqXIZ7NamiawGfEcCbgUHoxyOkHKNbbWF4lxA44YGO2+6c4msA== X-Received: by 10.55.69.68 with SMTP id s65mr1348217qka.314.1482265725535; Tue, 20 Dec 2016 12:28:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.113 with HTTP; Tue, 20 Dec 2016 12:28:45 -0800 (PST) In-Reply-To: <20161220201527.GA3897@elstar.local> References: <1db67b1d-36ef-5cc6-425f-7e22de7e80ae@cisco.com> <20161220.210335.1870203216124697421.mbj@tail-f.com> <20161220201527.GA3897@elstar.local> From: Andy Bierman Date: Tue, 20 Dec 2016 12:28:45 -0800 Message-ID: To: Juergen Schoenwaelder , Martin Bjorklund , Robert Wilton , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a1148aaf2089b0d05441ce2be Archived-At: Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 20:28:48 -0000 --001a1148aaf2089b0d05441ce2be Content-Type: text/plain; charset=UTF-8 Hi, I just checked the following YANG: container foo { status deprecated; leaf L1 { status current; type string; } } pyang does not complain about it at all. yangdump-pro issues a warning Warning: Invalid status: child node 'L1' = 'current' and parent node 'foo' = 'deprecated' t1003.yang:9.7: warning(1024): invalid status for child node IMO the status is inherited from its parent. The entire subtree is deprecated or obsolete. What does it even mean (from operations POV) to have an child nodes that are current but the ancestors are not? Andy On Tue, Dec 20, 2016 at 12:15 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Dec 20, 2016 at 09:03:35PM +0100, Martin Bjorklund wrote: > > > > However, we could have said that a current node under a deprecated > > node (etc) in the same module is an error, in order to force people > > (through the useage of YANG validators) to detect and fix this. > > > > Is it an error or just something that deserves a warning and the > author's attention? I am asking since we also have augmentations and > if I mark a container as deprecated, this will not immediately cause > an module augmenting the containter to get updated, hence I end up > with definitions marked current in a deprecated container. And there > are other situations where definitions may not be of the same status, > i.e., a module (without import by revision) uses a type or grouping > that in later revisions got marked deprecated. I think all of these > status mismatches are things tools should warn about but I am not sure > these are hard errors, in particular for 'deprecated'. Things may lead > to stronger warnings for definitions marked 'obsolete'. > > /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 > --001a1148aaf2089b0d05441ce2be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I just checked the following YANG:<= /div>

=C2=A0 =C2=A0 container foo {
=C2= =A0 =C2=A0 =C2=A0 status deprecated;
=C2=A0 =C2=A0 =C2=A0 leaf L1= {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0status current;
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
=C2=A0 =C2=A0 =C2= =A0 }
=C2=A0 =C2=A0 }


pyang does not complain about it at all.
yangdump-pro issues a= warning

Warning: Invalid status: child node = 'L1' =3D 'current' and parent node 'foo' =3D 'd= eprecated'
t1003.yang:9.7: warning(1024): invalid status for = child node


IMO the status is = inherited from its parent.
The entire subtree is deprecated or ob= solete.
What does it even mean (from operations POV) to have an c= hild nodes
that are current but the ancestors are not?
=

Andy



On Tue, Dec 20, = 2016 at 12:15 PM, Juergen Schoenwaelder <j.schoenwaelde= r@jacobs-university.de> wrote:
On Tue, Dec 20, 2016 at 09:03:35PM +0100, Martin Bjorklund wrote:
>
> However, we could have said that a current node under a deprecated
> node (etc) in the same module is an error, in order to force people > (through the useage of YANG validators) to detect and fix this.
>

Is it an error or just something that deserves a warning and the
author's attention? I am asking since we also have augmentations and if I mark a container as deprecated, this will not immediately cause
an module augmenting the containter to get updated, hence I end up
with definitions marked current in a deprecated container. And there
are other situations where definitions may not be of the same status,
i.e., a module (without import by revision) uses a type or grouping
that in later revisions got marked deprecated. I think all of these
status mismatches are things tools should warn about but I am not sure
these are hard errors, in particular for 'deprecated'. Things may l= ead
to stronger warnings for definitions marked 'obsolete'.

/js

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

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

--001a1148aaf2089b0d05441ce2be-- From nobody Tue Dec 20 16:08:59 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A06E12964D; Tue, 20 Dec 2016 16:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1, 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 SZgExIfwm2bP; Tue, 20 Dec 2016 16:08:57 -0800 (PST) Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46D61129579; Tue, 20 Dec 2016 16:08:57 -0800 (PST) From: Alex Campbell To: Lou Berger , NetMod WG Thread-Topic: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04 Thread-Index: AQHSVM/vVfbPnns5b0aNfTWoZgUv9aERj7Tl Date: Wed, 21 Dec 2016 00:08:55 +0000 Message-ID: <1482278935303.24094@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.9] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: NetMod WG Chairs Subject: Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 00:08:58 -0000 Yes/support=0A= =0A= The main issue I have with this draft, that I would like to be addressed at= some point, is the way it uses heavily restricted lists to model sequences= of VLAN tags.=0A= It seems to me that something like the following would be much simpler, wit= hout losing any expressive power, in most cases:=0A= =0A= container tags {=0A= leaf s-vlan {=0A= type dot1q:dot1q-vlan-id;=0A= }=0A= leaf c-vlan {=0A= type dot1q:dot1q-vlan-id;=0A= }=0A= must "s-vlan or c-vlan";=0A= }=0A= =0A= where either or both tags can be specified, and only specified tags are mat= ched (so if no c-vlan is specified then c-vlan is irrelevant for matching).= =0A= =0A= Alternatively, maybe the restrictions relating to tag type and order should= be removed, so that if I *want* to have an unusual device configuration (s= uch as pushing 3 consecutive c-vlan tags) then I am able to do so.=0A= =0A= Also, ietf-if-l3-vlan contains a feature (l3-vlan-sub-interfaces) that gate= s everything in the module. This is pointless IMO. If a server doesn't supp= ort L3 vlan subinterfaces then it should not implement the module (whose en= tire purpose is to model L3 vlan subinterfaces).=0A= =0A= =0A= Alex=0A= =0A= ________________________________________=0A= From: netmod on behalf of Lou Berger =0A= Sent: Tuesday, 13 December 2016 12:31 p.m.=0A= To: NetMod WG=0A= Cc: NetMod WG Chairs=0A= Subject: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04=0A= =0A= All,=0A= =0A= This is start of a two week* poll on making=0A= draft-wilton-netmod-intf-vlan-yang-04 a NetMod working group=0A= document.=0A= =0A= Please send email to the list indicating "yes/support" or "no/do not=0A= support". If indicating no, please state your reservations with the=0A= document. If yes, please also feel free to provide comments you'd like=0A= to see addressed once the document is a WG document.=0A= =0A= * Given the holiday, the poll ends December 28.=0A= =0A= Thank you,=0A= NetMod WG Chairs=0A= =0A= _______________________________________________=0A= netmod mailing list=0A= netmod@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netmod=0A= From nobody Wed Dec 21 00:33:01 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60AE81294FB for ; Wed, 21 Dec 2016 00:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNbQGJK5DMej for ; Wed, 21 Dec 2016 00:32:58 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E388D1294EC for ; Wed, 21 Dec 2016 00:32:57 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 5AE333EA72D46; Wed, 21 Dec 2016 08:32:53 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uBL8WrvE008151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Dec 2016 08:32:55 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id uBL8WE86020740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Dec 2016 08:32:49 GMT Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.164]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Wed, 21 Dec 2016 09:32:19 +0100 From: "Bogaert, Bart (Nokia - BE)" To: Juergen Schoenwaelder , "Martin Bjorklund" Thread-Topic: [netmod] draft-ietf-netmod-entity issue #13 Thread-Index: AQHSV4/zI+GWx4JDRkGCqJt+vJdcKqESGQyg Date: Wed, 21 Dec 2016 08:32:18 +0000 Message-ID: References: <20161215161434.GD7432@elstar.local> <20161215.172609.1950541994949692852.mbj@tail-f.com> <20161215163027.GA7632@elstar.local> <20161216.103131.190811205717956437.mbj@tail-f.com> <20161216112728.GA9710@elstar.local> In-Reply-To: <20161216112728.GA9710@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_024C_01D25B6D.1E8DD460" MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-ietf-netmod-entity issue #13 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 08:33:00 -0000 ------=_NextPart_000_024C_01D25B6D.1E8DD460 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, --- snip --- > > Well, this is not what I read out of > > > > https://www.ietf.org/mail-archive/web/netmod/current/msg17039.html > > > > since there are leafs like mfg-name and model-name that seem to be > > hardware component properties. > > The description statements in this email are just copied from the > corresponding config false nodes. I think they need to be rewritten; > compare with serial-num. This text can probably be further improved. > The idea is that the user probably would configure say mfg-name only > if the system cannot detect it automatically. I still wonder why it could be useful to provision things like the mfg-name or the serial-num. I would rather like to know what is really there instead of overwriting these properties. [Bart Bogaert] BBF did not propose to add serial-num, this is in the base ietf-entity YANG model. For pluggable items it makes sense to add the model name and mfg-name. In case of pre-provisioning (so preparing and sending a configuration to the device while the HW entity is actually not there yet) it makes sense to indicate what is the intended configuration. When the HW entity is inserted at a later point in time the device could raise a mismatch alarm in case another entity is detected then the one that was "predicted" to be inserted at that position. Best regards, Bart > > And the config list is still indexed by a name; so for list elements > > that have a (class, parent, position) triple, the name would be > > arbitrary and not necessarily matching the component name. > > I think that the idea is that if there is a matching triple, then the > system MUST use the configured 'name' as the 'name' also in the state > list. One reason for pre-confiugring these components is to be able > to refer to them in other config. This may make sense. > > Well, if you understand the edits,... > > I think the idea would be explained along these lines: > > The sytem conceptually behaves like this: > > 1. When a physical component is detected, the system will initialize > an entry in the /hardware-state/component list. > > If there is an entry in /hardare/component list with a matching > (class,parent,parent-rel-pos) triple, then the state entry is > initialized with the configured values for all configured leafs > (name, mfg-name, ...). > > If there is no such matching entry, the system assigns a 'name' > in an implementation-specific manner. > > If there is an entry in /hardare/component list with a matching > 'name' and where the triple (class,parent,parent-rel-pos) is not > set, then the state entry is initialized with the configured > values for all configured leafs (name, mfg-name, ...). > > Otherwise, the state entry is initialized with the detected values > for all leafs. > > 2. If the /hardware/component list is modified (i.e., someone changed > the config), then the system MUST behave as if it was restarted > and followed the procedure in (1). This way of pre-configuring that name may indeed make sense. Lets see if this is what BBF really wanted. /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 ------=_NextPart_000_024C_01D25B6D.1E8DD460 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/TCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr 4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0 ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3 dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93 d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy 7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6 /XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYzCCBkugAwIBAgIKXRYRuwAAAADQ8TANBgkq hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDE2MDU1MjI4WhcNMTcwNDE1 MDU1MjI4WjBDMREwDwYDVQQDEwhib2dhZXJ0YjEuMCwGCSqGSIb3DQEJARYfYmFydC5ib2dhZXJ0 QGFsY2F0ZWwtbHVjZW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJBS7alw mZfOimfXIdJjyp1G8U+E4Rs5y+eXtDfKWEuy6UOCstRCUiSz+eljCu737ZPkMHmPMdXDHZGnsV9y HsInD5cZHBTNnboc8lV7zLVpTrtrnflClsOiRD75CS1Vvehx+JnFuW4Mo/VeWjQtUD4tUU67W7b0 QPOkcB3KkZixozjERSxPUFHf6pMShshwQlKtvV6YLdhnNePiuFimfYqUDiOQs1LR8C+r3eSMHi8o lyWTHf49vFPL7z62HWSldeEkf6vhtuZuWLfH7xqO3CIQH63zUJF9p23ko2/Gtc1MpAcdWMwV3ymj V8ef+gZac/SFwFgA547zeawhhvtdiOUCAwEAAaOCBBQwggQQMD0GCSsGAQQBgjcVBwQwMC4GJisG AQQBgjcVCIW9xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisG AQQBgjcKAwQGCCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQB gjcKAwQwCgYIKwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZI hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBTzjeedsBUMWk5eyOwD8/c9 1B1G8jAfBgNVHSMEGDAWgBTZ7Gu9llgi99imd83+TYHvupe9EjCCAV0GA1UdHwSCAVQwggFQMIIB TKCCAUigggFEhoHZbGRhcDovLy9DTj1BbGNhdGVsJTIwTHVjZW50JTIwSW50ZXJuYWwlMjBTdWIl MjBDQSxDTj11c25hdnNwa2kwM3AsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NlcnRp ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu dIYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmyGOGh0dHA6Ly9z ZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0EuY3JsMIIBYQYIKwYB BQUHAQEEggFTMIIBTzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQl MjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWx1YWQsREM9bHVjZW50LERDPWNvbT9jQUNl cnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA4BggrBgEF BQcwAoYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwRAYIKwYB BQUHMAKGOGh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3Vi Q0EuY3J0MCoGA1UdEQQjMCGBH2JhcnQuYm9nYWVydEBhbGNhdGVsLWx1Y2VudC5jb20wDQYJKoZI hvcNAQEFBQADggEBAEARoPJfuwXhstAQ/fAz/XKDC//Je9A0RG9Q5XV7+URvR5GxhwuikL/MEtXs Dspufv0eHG/b92AVZxaSgdpzC6neLoW2Q/Rdeavuifm7H/Ob645vIufqDQEqRqsyt9xRP+31VphA do994d7kU6v5BI7DAA8s5rl6h4PFbtvY5qe8VLNiTnon1dCwPQ+mRSrLfgjlZUw+WsMh69JEOWZX EufZMg0oUvCboUe3LNNvh8+DtLafaT1gS/kpv3c+dXVApTjb1tPbeZHc5L85AVQBsbq/vYpWhiZR qDiyVyPh+dh7vTa/GBJx/UVLwv6IswAwtCWZ/r9aReHssqkgMH9evF8xggQpMIIEJQIBATCBlDCB hTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT 8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1 Y2VudCBJbnRlcm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwCQYFKw4DAhoFAKCCAmkwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMjIxMDgzMjE2WjAjBgkqhkiG9w0B CQQxFgQUYLR83WOHxRNLrMqq//0ehGPtoK8wgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQAA RklvjkqZv04sDsJGENb/quwRRMR6Kizy/0p/GJOei4tfxyyPNioD50itwF+aDIbv6qGYZohVKNKC zaPdpFSgqHBbbzNenq26V6Gf5Q/Pz6k+qJo7wy5M/DFZI2Tip3zvhVfgdBO1a5GbXq4LLpdA93zu hm+2sDgITmSLJt3qXB43gUEJaorwMC2lxulbmypx+1t7L/ZcBN4B2mnIWm6cSUzyIFZ6GFORGMhv KHgkMwannF+R/Z14ZJCRh/NKLYTXMopsNVVu0pO+Ea8+Qmn5aYr05r3uAqBeG8lT8D+/i1h5x4fW 3E02sPTvCDfql9azaSvT43qzu0o4dyvPpygYAAAAAAAA ------=_NextPart_000_024C_01D25B6D.1E8DD460-- From nobody Wed Dec 21 01:10:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E31112952C for ; Wed, 21 Dec 2016 01:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.32 X-Spam-Level: X-Spam-Status: No, score=-7.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, 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 lF4p0eKkZbUV for ; Wed, 21 Dec 2016 01:10:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 025EC12950B for ; Wed, 21 Dec 2016 01:10:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CXL80179; Wed, 21 Dec 2016 09:10:44 +0000 (GMT) Received: from DGGEMA405-HUB.china.huawei.com (10.3.20.46) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 21 Dec 2016 09:10:02 +0000 Received: from DGGEMA502-MBX.china.huawei.com ([169.254.2.221]) by DGGEMA405-HUB.china.huawei.com ([10.3.20.46]) with mapi id 14.03.0301.000; Wed, 21 Dec 2016 17:09:49 +0800 From: Rohit R Ranade To: "netmod@ietf.org" Thread-Topic: [netmod] RFC 6022 Query Thread-Index: AdJbafmzui97K1h8RsGEGmV5TDm5HA== Date: Wed, 21 Dec 2016 09:09:49 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6B01191A@DGGEMA502-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.242.206] Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6B01191ADGGEMA502MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.585A4714.03BA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.221, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6ede5ad682ff051e2ff38df9a1e8a5d3 Archived-At: Subject: [netmod] RFC 6022 Query X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 09:10:49 -0000 --_000_991B70D8B4112A4699D5C00DDBBF878A6B01191ADGGEMA502MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, /netconf-state/schemas =3D=3D> Will be used to retrieve the list of schemas= in the device. will be used to get the actual schema file-content based on th= e contents of the schema list. Q1: Section 2.1.3 has the below statement for "version": For YANG data models, version is the value of the most recent YANG 'revision' statement in the module or submodule, or the empty string if no 'revision' statement is present. This clearly means that all the revisions of a YANG module will not be list= ed. If a device has the YANG and YIN format for all the modules, then the Y= IN format is shown with all the revisions, but the YANG format will be show= n with the highest revision only. What is the logic behind this difference in behavior ? YANG is reader frien= dly while YIN is operation(xml parsing) friendly. I feel it is a valid scen= ario to have both these format in the device. Q2: Since all the revisions are never shown for YANG in the schema list, t= here is no mechanism to extract the lower revisions using . The= response from server also shows only the highest revision. One scenario for lower version usage : The import statement allows import b= y revision. Consider ModuleA imports SubModuleB with a lower revision. The = user will never be able to get the lower revision file of SubModule B ? If= some content has been deleted / modified in the latest revision of SubModu= le B it will cause confusion. With Regards, Rohit --_000_991B70D8B4112A4699D5C00DDBBF878A6B01191ADGGEMA502MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi All,

 

/netconf-state/schemas =E8 Will be used to retrieve the list of sche= mas in the device.

<get-schema> will be used to get th= e actual schema file-content based on the contents of the schema list.=

 

Q1: Section 2.1.3 has the below statement= for “version”:

 

For YANG data mo= dels, version is the value of the most recent YANG

  &nbs= p;   'revision' statement in the module or submodule, or the empt= y

  &nbs= p;   string if no 'revision' statement is present.

 

This clearly means that all the revisions of a YANG = module will not be listed. If a device has the YANG and YIN format for all = the modules, then the YIN format is shown with all the revisions, but the Y= ANG format will be shown with the highest revision only.

What is the logic behind this difference in behavior= ? YANG is reader friendly while YIN is operation(xml parsing) friendly. I = feel it is a valid scenario to have both these format in the device.

 

Q2:  Since all the revisions are never shown fo= r YANG in the schema list, there is no mechanism to extract the lower revis= ions using <get-schema>. The <hello> response from server also = shows only the highest revision.

One scenario for lower version usage : The import st= atement allows import by revision. Consider ModuleA imports SubModuleB with= a lower revision. The user will never be able to get the lower revision fi= le of SubModule B ?  If some content has been deleted / modified in the latest revision of SubModule B it will = cause confusion.

 

With Regards,

Rohit

--_000_991B70D8B4112A4699D5C00DDBBF878A6B01191ADGGEMA502MBXchi_-- From nobody Wed Dec 21 01:16:55 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C657C129489 for ; Wed, 21 Dec 2016 01:16:52 -0800 (PST) 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 xguLjg0cJJWD for ; Wed, 21 Dec 2016 01:16:50 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id F3101129458 for ; Wed, 21 Dec 2016 01:16:49 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 308901CC00A5; Wed, 21 Dec 2016 10:16:44 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund , rwilton@cisco.com In-Reply-To: <20161220.210335.1870203216124697421.mbj@tail-f.com> References: <1db67b1d-36ef-5cc6-425f-7e22de7e80ae@cisco.com> <20161220.210335.1870203216124697421.mbj@tail-f.com> Date: Wed, 21 Dec 2016 10:16:43 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 09:16:53 -0000 Martin Bjorklund writes: > Robert Wilton wrote: >> Hi, >> >> The definition of "status" in RFC 7950 in section 7.21.2 (full text >> below), states: >> >> If no status is specified, the default is "current". >> >> From my interpretation of the text in the draft, this implies that the >> status of the "new" child leaf in the following example is "current", >> and that this example is allowed! >> >> My questions are: >> - Is my interpretation of the current text correct? > > Yes. > >> - Is this actually the best behaviour, or should it inherit like the >> config statement? > > I think the idea was that if the status != current, it is better for > the reader if it is explicitly stated. > >> Should I raise an errata for this? > > No. > > However, we could have said that a current node under a deprecated > node (etc) in the same module is an error, in order to force people > (through the useage of YANG validators) to detect and fix this. Since "current" is the default, correctly deprecating a subtree would mean to explicitly add the "status" statement to every single node in the subtree. I think that "obsolete" should apply to the whole subtree, no matter what status descendants have, and "deprecated" should apply to the whole subtree except for parts that are obsolete. Lada > > > /martin > > > >> >> container old { >> status deprecated; >> leaf new { >> description "what status do I have?"; >> } >> } >> >> Thanks, >> Rob >> >> >> Full 7.21.2 text from 7950: >> >> 7.21.2. The "status" Statement >> >> The "status" statement takes as an argument one of the strings >> "current", "deprecated", or "obsolete". >> >> o "current" means that the definition is current and valid. >> >> o "deprecated" indicates an obsolete definition, but it permits >> new/continued implementation in order to foster interoperability >> with older/existing implementations. >> >> o "obsolete" means that the definition is obsolete and SHOULD NOT be >> implemented and/or can be removed from implementations. >> >> If no status is specified, the default is "current". >> >> If a definition is "current", it MUST NOT reference a "deprecated" or >> "obsolete" definition within the same module. >> >> If a definition is "deprecated", it MUST NOT reference an "obsolete" >> definition within the same module. >> >> For example, the following is illegal: >> >> typedef my-type { >> status deprecated; >> type int32; >> } >> >> leaf my-leaf { >> status current; >> type my-type; // illegal, since my-type is deprecated >> } >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Dec 21 01:29:02 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F684129489 for ; Wed, 21 Dec 2016 01:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 J1AfhMP-1jkW for ; Wed, 21 Dec 2016 01:28:59 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA87129458 for ; Wed, 21 Dec 2016 01:28:55 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 487051AE030A; Wed, 21 Dec 2016 10:28:54 +0100 (CET) Date: Wed, 21 Dec 2016 10:28:52 +0100 (CET) Message-Id: <20161221.102852.1273087448152459126.mbj@tail-f.com> To: rohitrranade@huawei.com From: Martin Bjorklund In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6B01191A@DGGEMA502-MBX.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A6B01191A@DGGEMA502-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: Cc: netmod@ietf.org Subject: Re: [netmod] RFC 6022 Query X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 09:29:00 -0000 Hi, Rohit R Ranade wrote: > Hi All, > > /netconf-state/schemas ==> Will be used to retrieve the list of > schemas in the device. > will be used to get the actual schema file-content based > on the contents of the schema list. > > Q1: Section 2.1.3 has the below statement for "version": > > For YANG data models, version is the value of the most recent YANG > 'revision' statement in the module or submodule, or the empty > string if no 'revision' statement is present. > > This clearly means that all the revisions of a YANG module will not be > listed. No. See the paragraph above the quoted one: Multiple versions MAY be supported simultaneously by a NETCONF server. Each version MUST be reported individually in the schema list, i.e., with same identifier, possibly different location, but different version. The text just means that for YANG module (in both formats 'yang' and 'yin') the version will contain the current revision for that version for the module. I hope this clarifies the rest of your questions below. > If a device has the YANG and YIN format for all the modules, > then the YIN format is shown with all the revisions, but the YANG > format will be shown with the highest revision only. > What is the logic behind this difference in behavior ? YANG is reader > friendly while YIN is operation(xml parsing) friendly. I feel it is a > valid scenario to have both these format in the device. > > Q2: Since all the revisions are never shown for YANG in the schema > list, there is no mechanism to extract the lower revisions using > . The response from server also shows only the > highest revision. > One scenario for lower version usage : The import statement allows > import by revision. Consider ModuleA imports SubModuleB with a lower > revision. The user will never be able to get the lower revision file > of SubModule B ? If some content has been deleted / modified in the > latest revision of SubModule B it will cause confusion. > > With Regards, > Rohit /martin From nobody Wed Dec 21 01:32:13 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356FA129458 for ; Wed, 21 Dec 2016 01:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 Q1Ws2nMQNa6N for ; Wed, 21 Dec 2016 01:32:10 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 924FC129455 for ; Wed, 21 Dec 2016 01:32:10 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id ACC3F1AE030A; Wed, 21 Dec 2016 10:32:09 +0100 (CET) Date: Wed, 21 Dec 2016 10:32:08 +0100 (CET) Message-Id: <20161221.103208.1910010141581780305.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <1db67b1d-36ef-5cc6-425f-7e22de7e80ae@cisco.com> <20161220.210335.1870203216124697421.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 09:32:12 -0000 Ladislav Lhotka wrote: > Martin Bjorklund writes: > > > Robert Wilton wrote: > >> Hi, > >> > >> The definition of "status" in RFC 7950 in section 7.21.2 (full text > >> below), states: > >> > >> If no status is specified, the default is "current". > >> > >> From my interpretation of the text in the draft, this implies that the > >> status of the "new" child leaf in the following example is "current", > >> and that this example is allowed! > >> > >> My questions are: > >> - Is my interpretation of the current text correct? > > > > Yes. > > > >> - Is this actually the best behaviour, or should it inherit like the > >> config statement? > > > > I think the idea was that if the status != current, it is better for > > the reader if it is explicitly stated. > > > >> Should I raise an errata for this? > > > > No. > > > > However, we could have said that a current node under a deprecated > > node (etc) in the same module is an error, in order to force people > > (through the useage of YANG validators) to detect and fix this. > > Since "current" is the default, correctly deprecating a subtree would > mean to explicitly add the "status" statement to every single node in > the subtree. Yes. > I think that "obsolete" should apply to the whole subtree, no matter > what status descendants have, and "deprecated" should apply to the whole > subtree except for parts that are obsolete. Maybe, but this is not how it works in YANG 1 and 1.1. For the reasoning behind this, see above. Maybe this is not perfect, and something that we should look into if we update YANG. But I don't think this is a problem. /martin > > Lada > > > > > > > /martin > > > > > > > >> > >> container old { > >> status deprecated; > >> leaf new { > >> description "what status do I have?"; > >> } > >> } > >> > >> Thanks, > >> Rob > >> > >> > >> Full 7.21.2 text from 7950: > >> > >> 7.21.2. The "status" Statement > >> > >> The "status" statement takes as an argument one of the strings > >> "current", "deprecated", or "obsolete". > >> > >> o "current" means that the definition is current and valid. > >> > >> o "deprecated" indicates an obsolete definition, but it permits > >> new/continued implementation in order to foster interoperability > >> with older/existing implementations. > >> > >> o "obsolete" means that the definition is obsolete and SHOULD NOT be > >> implemented and/or can be removed from implementations. > >> > >> If no status is specified, the default is "current". > >> > >> If a definition is "current", it MUST NOT reference a "deprecated" or > >> "obsolete" definition within the same module. > >> > >> If a definition is "deprecated", it MUST NOT reference an "obsolete" > >> definition within the same module. > >> > >> For example, the following is illegal: > >> > >> typedef my-type { > >> status deprecated; > >> type int32; > >> } > >> > >> leaf my-leaf { > >> status current; > >> type my-type; // illegal, since my-type is deprecated > >> } > >> > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > From nobody Wed Dec 21 01:52:35 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45708129412 for ; Wed, 21 Dec 2016 01:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZiwVagVYw1e for ; Wed, 21 Dec 2016 01:52:31 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85B58126B6D for ; Wed, 21 Dec 2016 01:52:31 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id u25so65425690qki.2 for ; Wed, 21 Dec 2016 01:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rYVVGOyLcMMAGfQvVLKMZyEQRNkbZ4iCEzIetmVHiVs=; b=TAu103kEsGxWzZp1F8/i8lJvksSgu79IR6nqwD38kDJx9YGSDJMAnJcK93ALdYLmga Eb0Gelxo3ttMs183I74fgQq4QDy8AtKAlT6DwUnHifr0TGEvFJF+tsEjpTSgLSxy4Upk 87OFMBhEK5H3iuA+2M7YZDT5+YPboq28IHeFMCuK1J3m4EWvrlPH3uNcAqN6ATWkK80S NZUPzaYKHHuyVJkfgZU0svBJOv1hh5Mdk41tgXakQBp2Y3kgzU17rHkAglwtHbZy5nvN Gk0IOuiCabjqx+Q3+4RvZxpwY+7SUmrYnTaD5hKG/aaKrntGSwxJmpsGzALazBfSy9xY L/5A== 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=rYVVGOyLcMMAGfQvVLKMZyEQRNkbZ4iCEzIetmVHiVs=; b=FQRFy9jJEstvhGDBtk4zQ3TwWMU4BvoeuzRsTGMI279ngpmVgnk4uY8Cj1xH577wlP dI2jV66Om5VyjiIxHou5AFtkHRm6hPKJUfUTqc00lC40c7pb2DM+FGEGCfnC7blNsOL0 EehxmDAkEaxMlFe1GXs3+gM9DOnHNgbUJExtmqS8Y3O3J4P0VtFnSfa6w5T+aS021PDZ g3WV5ySpcqx2I+Z7tmkrBWe+4AULg/rt6YkUD4fmlfxsZnL+igw1KzDSe7K+x1WzMG5O V+yipG4jpwMw8yGr4cm/DOAocsROqaUNy7etgNlkqn58bmDqgo+gs9kHAs0qvcCghCKS 2Hpw== X-Gm-Message-State: AIkVDXLEZ4dHNe2vggbuyfoMRrHlizNTTEIJGvF9nT2v7+H+ITMuh+REKtE06yHC+GGtQElE3NoTnBPFpRms7g== X-Received: by 10.55.135.197 with SMTP id j188mr3782996qkd.71.1482313950571; Wed, 21 Dec 2016 01:52:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.113 with HTTP; Wed, 21 Dec 2016 01:52:30 -0800 (PST) In-Reply-To: <20161221.103208.1910010141581780305.mbj@tail-f.com> References: <1db67b1d-36ef-5cc6-425f-7e22de7e80ae@cisco.com> <20161220.210335.1870203216124697421.mbj@tail-f.com> <20161221.103208.1910010141581780305.mbj@tail-f.com> From: Andy Bierman Date: Wed, 21 Dec 2016 01:52:30 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=94eb2c0777e6787e560544281cd7 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 09:52:33 -0000 --94eb2c0777e6787e560544281cd7 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 21, 2016 at 1:32 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > Martin Bjorklund writes: > > > > > Robert Wilton wrote: > > >> Hi, > > >> > > >> The definition of "status" in RFC 7950 in section 7.21.2 (full text > > >> below), states: > > >> > > >> If no status is specified, the default is "current". > > >> > > >> From my interpretation of the text in the draft, this implies that the > > >> status of the "new" child leaf in the following example is "current", > > >> and that this example is allowed! > > >> > > >> My questions are: > > >> - Is my interpretation of the current text correct? > > > > > > Yes. > > > > > >> - Is this actually the best behaviour, or should it inherit like the > > >> config statement? > > > > > > I think the idea was that if the status != current, it is better for > > > the reader if it is explicitly stated. > > > > > >> Should I raise an errata for this? > > > > > > No. > > > > > > However, we could have said that a current node under a deprecated > > > node (etc) in the same module is an error, in order to force people > > > (through the useage of YANG validators) to detect and fix this. > > > > Since "current" is the default, correctly deprecating a subtree would > > mean to explicitly add the "status" statement to every single node in > > the subtree. > > Yes. > Please explain what it means for YANG to say "The parent node is deprecated and going away but the child nodes are not. They are current and are staying around." This does not seem to make any sense. Clearly an obsolete node removes all access of its descendant nodes. There is no way to access /foo/child if /foo has been removed from the server. So how do I access a deprecated /foo/child node inside an obsolete /foo container? Andy > > > I think that "obsolete" should apply to the whole subtree, no matter > > what status descendants have, and "deprecated" should apply to the whole > > subtree except for parts that are obsolete. > > Maybe, but this is not how it works in YANG 1 and 1.1. For the > reasoning behind this, see above. Maybe this is not perfect, and > something that we should look into if we update YANG. But I don't > think this is a problem. > > > /martin > > > > > > > Lada > > > > > > > > > > > /martin > > > > > > > > > > > >> > > >> container old { > > >> status deprecated; > > >> leaf new { > > >> description "what status do I have?"; > > >> } > > >> } > > >> > > >> Thanks, > > >> Rob > > >> > > >> > > >> Full 7.21.2 text from 7950: > > >> > > >> 7.21.2. The "status" Statement > > >> > > >> The "status" statement takes as an argument one of the strings > > >> "current", "deprecated", or "obsolete". > > >> > > >> o "current" means that the definition is current and valid. > > >> > > >> o "deprecated" indicates an obsolete definition, but it permits > > >> new/continued implementation in order to foster interoperability > > >> with older/existing implementations. > > >> > > >> o "obsolete" means that the definition is obsolete and SHOULD NOT > be > > >> implemented and/or can be removed from implementations. > > >> > > >> If no status is specified, the default is "current". > > >> > > >> If a definition is "current", it MUST NOT reference a "deprecated" > or > > >> "obsolete" definition within the same module. > > >> > > >> If a definition is "deprecated", it MUST NOT reference an > "obsolete" > > >> definition within the same module. > > >> > > >> For example, the following is illegal: > > >> > > >> typedef my-type { > > >> status deprecated; > > >> type int32; > > >> } > > >> > > >> leaf my-leaf { > > >> status current; > > >> type my-type; // illegal, since my-type is deprecated > > >> } > > >> > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --94eb2c0777e6787e560544281cd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 21, 2016 at 1:32 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:
> Martin Bjorklund <mbj@tail-f.com<= /a>> writes:
>
> > Robert Wilton <rwilton@ci= sco.com> wrote:
> >> Hi,
> >>
> >> The definition of "status" in RFC 7950 in section 7= .21.2 (full text
> >> below), states:
> >>
> >> If no status is specified, the default is "current"= .
> >>
> >> From my interpretation of the text in the draft, this implies= that the
> >> status of the "new" child leaf in the following exa= mple is "current",
> >> and that this example is allowed!
> >>
> >> My questions are:
> >>=C2=A0 - Is my interpretation of the current text correct?
> >
> > Yes.
> >
> >>=C2=A0 - Is this actually the best behaviour, or should it inh= erit like the
> >>=C2=A0 =C2=A0 config statement?
> >
> > I think the idea was that if the status !=3D current, it is bette= r for
> > the reader if it is explicitly stated.
> >
> >>=C2=A0 Should I raise an errata for this?
> >
> > No.
> >
> > However, we could have said that a current node under a deprecate= d
> > node (etc) in the same module is an error, in order to force peop= le
> > (through the useage of YANG validators) to detect and fix this. >
> Since "current" is the default, correctly deprecating a subt= ree would
> mean to explicitly add the "status" statement to every singl= e node in
> the subtree.

Yes.

Please explain what it means for Y= ANG to say
"The parent node is deprecated and going away but= the child nodes are not.
They are current and are staying around= ." =C2=A0This does not seem to make any sense.

Clearly an obsolete node removes all access of its descendant nodes.
There is no way to access /foo/child if /foo has been removed from th= e server.
So how do I access a deprecated /foo/child node inside = an obsolete /foo container?


Andy

=C2=A0

> I think that "obsolete" should apply to the whole subtree, n= o matter
> what status descendants have, and "deprecated" should apply = to the whole
> subtree except for parts that are obsolete.

Maybe, but this is not how it works in YANG 1 and 1.1.=C2=A0 For the
reasoning behind this, see above.=C2=A0 Maybe this is not perfect, and
something that we should look into if we update YANG.=C2=A0 But I don't=
think this is a problem.


/martin



>
> Lada
>
> >
> >
> > /martin
> >
> >
> >
> >>
> >> container old {
> >>=C2=A0 =C2=A0status deprecated;
> >>=C2=A0 =C2=A0leaf new {
> >>=C2=A0 =C2=A0 =C2=A0description "what status do I have?&q= uot;;
> >>=C2=A0 =C2=A0}
> >> }
> >>
> >> Thanks,
> >> Rob
> >>
> >>
> >> Full 7.21.2 text from 7950:
> >>
> >> 7.21.2.=C2=A0 The "status" Statement
> >>
> >>=C2=A0 =C2=A0 The "status" statement takes as an arg= ument one of the strings
> >>=C2=A0 =C2=A0 "current", "deprecated", or = "obsolete".
> >>
> >>=C2=A0 =C2=A0 o=C2=A0 "current" means that the defin= ition is current and valid.
> >>
> >>=C2=A0 =C2=A0 o=C2=A0 "deprecated" indicates an obso= lete definition, but it permits
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0new/continued implementation in ord= er to foster interoperability
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0with older/existing implementations= .
> >>
> >>=C2=A0 =C2=A0 o=C2=A0 "obsolete" means that the defi= nition is obsolete and SHOULD NOT be
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0implemented and/or can be removed f= rom implementations.
> >>
> >>=C2=A0 =C2=A0 If no status is specified, the default is "= current".
> >>
> >>=C2=A0 =C2=A0 If a definition is "current", it MUST = NOT reference a "deprecated" or
> >>=C2=A0 =C2=A0 "obsolete" definition within the same = module.
> >>
> >>=C2=A0 =C2=A0 If a definition is "deprecated", it MU= ST NOT reference an "obsolete"
> >>=C2=A0 =C2=A0 definition within the same module.
> >>
> >>=C2=A0 =C2=A0 For example, the following is illegal:
> >>
> >>=C2=A0 =C2=A0 =C2=A0 typedef my-type {
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 status deprecated;
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 type int32;
> >>=C2=A0 =C2=A0 =C2=A0 }
> >>
> >>=C2=A0 =C2=A0 =C2=A0 leaf my-leaf {
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 status current;
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 type my-type; // illegal, since my= -type is deprecated
> >>=C2=A0 =C2=A0 =C2=A0 }
> >>
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/net= mod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>

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

--94eb2c0777e6787e560544281cd7-- From nobody Wed Dec 21 01:52:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E8012941E for ; Wed, 21 Dec 2016 01:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 UDYc6ITZ40_Y for ; Wed, 21 Dec 2016 01:52:52 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 352EF126B6D for ; Wed, 21 Dec 2016 01:52:52 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:a433:9391:e4ad:aa3f] (unknown [IPv6:2001:718:1a02:1:a433:9391:e4ad:aa3f]) by mail.nic.cz (Postfix) with ESMTPSA id B587A6A84F; Wed, 21 Dec 2016 10:52:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1482313970; bh=YERhyDxlCpFHWdSE3BtJS+3ertji2gNk7z/gyo1hZBY=; h=From:Date:To; b=Td5vdKQsrq8MfTsCH/WoNYBBjocZFN+0rhCqQNjucGy5cuAbo7ChFcbm+2IhJ/hKd HLSnfnSbH8Vz0JhctephlqX/EGrD0afRpFIfnNVvPLFubWG6HwZXeAC5F8OuiZZKT9 eSmQfq/l2yQ0wukl2cUcva+2HzKdC04F76VWFakI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20161221.103208.1910010141581780305.mbj@tail-f.com> Date: Wed, 21 Dec 2016 10:52:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5DD58CAA-BDA7-4859-B69F-8BF24B048FA7@nic.cz> References: <1db67b1d-36ef-5cc6-425f-7e22de7e80ae@cisco.com> <20161220.210335.1870203216124697421.mbj@tail-f.com> <20161221.103208.1910010141581780305.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 09:52:55 -0000 > On 21 Dec 2016, at 10:32, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >> Martin Bjorklund writes: >>=20 >>> Robert Wilton wrote: >>>> Hi, >>>>=20 >>>> The definition of "status" in RFC 7950 in section 7.21.2 (full text >>>> below), states: >>>>=20 >>>> If no status is specified, the default is "current". >>>>=20 >>>> =46rom my interpretation of the text in the draft, this implies = that the >>>> status of the "new" child leaf in the following example is = "current", >>>> and that this example is allowed! >>>>=20 >>>> My questions are: >>>> - Is my interpretation of the current text correct? >>>=20 >>> Yes. >>>=20 >>>> - Is this actually the best behaviour, or should it inherit like = the >>>> config statement? >>>=20 >>> I think the idea was that if the status !=3D current, it is better = for >>> the reader if it is explicitly stated. >>>=20 >>>> Should I raise an errata for this? >>>=20 >>> No. >>>=20 >>> However, we could have said that a current node under a deprecated >>> node (etc) in the same module is an error, in order to force people >>> (through the useage of YANG validators) to detect and fix this. >>=20 >> Since "current" is the default, correctly deprecating a subtree would >> mean to explicitly add the "status" statement to every single node in >> the subtree. >=20 > Yes. >=20 >> I think that "obsolete" should apply to the whole subtree, no matter >> what status descendants have, and "deprecated" should apply to the = whole >> subtree except for parts that are obsolete. >=20 > Maybe, but this is not how it works in YANG 1 and 1.1. For the > reasoning behind this, see above. Maybe this is not perfect, and > something that we should look into if we update YANG. But I don't > think this is a problem. I think it is a problem. We can see a lot of these things before long = because of the update rules. For example, it may apply to all the = *-state trees, and tagging every single node therein with "deprecated" = or "obsolete" is a useless exercise. Lada >=20 >=20 > /martin >=20 >=20 >=20 >>=20 >> Lada >>=20 >>>=20 >>>=20 >>> /martin >>>=20 >>>=20 >>>=20 >>>>=20 >>>> container old { >>>> status deprecated; >>>> leaf new { >>>> description "what status do I have?"; >>>> } >>>> } >>>>=20 >>>> Thanks, >>>> Rob >>>>=20 >>>>=20 >>>> Full 7.21.2 text from 7950: >>>>=20 >>>> 7.21.2. The "status" Statement >>>>=20 >>>> The "status" statement takes as an argument one of the strings >>>> "current", "deprecated", or "obsolete". >>>>=20 >>>> o "current" means that the definition is current and valid. >>>>=20 >>>> o "deprecated" indicates an obsolete definition, but it permits >>>> new/continued implementation in order to foster = interoperability >>>> with older/existing implementations. >>>>=20 >>>> o "obsolete" means that the definition is obsolete and SHOULD = NOT be >>>> implemented and/or can be removed from implementations. >>>>=20 >>>> If no status is specified, the default is "current". >>>>=20 >>>> If a definition is "current", it MUST NOT reference a = "deprecated" or >>>> "obsolete" definition within the same module. >>>>=20 >>>> If a definition is "deprecated", it MUST NOT reference an = "obsolete" >>>> definition within the same module. >>>>=20 >>>> For example, the following is illegal: >>>>=20 >>>> typedef my-type { >>>> status deprecated; >>>> type int32; >>>> } >>>>=20 >>>> leaf my-leaf { >>>> status current; >>>> type my-type; // illegal, since my-type is deprecated >>>> } >>>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> --=20 >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Dec 21 02:54:45 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74015129554 for ; Wed, 21 Dec 2016 02:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 yPRSDEADc-gQ for ; Wed, 21 Dec 2016 02:54:42 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 29F6512954F for ; Wed, 21 Dec 2016 02:54:42 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 4CE1E1AE030A; Wed, 21 Dec 2016 11:54:40 +0100 (CET) Date: Wed, 21 Dec 2016 11:54:38 +0100 (CET) Message-Id: <20161221.115438.163227970004322277.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20161221.103208.1910010141581780305.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 10:54:43 -0000 Andy Bierman wrote: > On Wed, Dec 21, 2016 at 1:32 AM, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > > > Martin Bjorklund writes: > > > > > > > Robert Wilton wrote: > > > >> Hi, > > > >> > > > >> The definition of "status" in RFC 7950 in section 7.21.2 (full text > > > >> below), states: > > > >> > > > >> If no status is specified, the default is "current". > > > >> > > > >> From my interpretation of the text in the draft, this implies that the > > > >> status of the "new" child leaf in the following example is "current", > > > >> and that this example is allowed! > > > >> > > > >> My questions are: > > > >> - Is my interpretation of the current text correct? > > > > > > > > Yes. > > > > > > > >> - Is this actually the best behaviour, or should it inherit like the > > > >> config statement? > > > > > > > > I think the idea was that if the status != current, it is better for > > > > the reader if it is explicitly stated. > > > > > > > >> Should I raise an errata for this? > > > > > > > > No. > > > > > > > > However, we could have said that a current node under a deprecated > > > > node (etc) in the same module is an error, in order to force people > > > > (through the useage of YANG validators) to detect and fix this. > > > > > > Since "current" is the default, correctly deprecating a subtree would > > > mean to explicitly add the "status" statement to every single node in > > > the subtree. > > > > Yes. > > > > Please explain what it means for YANG to say > "The parent node is deprecated and going away but the child nodes are not. > They are current and are staying around." This does not seem to make any > sense. Agreed. But this should be invalid also if the status statements are given explicitly: container a { status deprecated; container b { status current; } } > Clearly an obsolete node removes all access of its descendant nodes. > There is no way to access /foo/child if /foo has been removed from the > server. Yes. > So how do I access a deprecated /foo/child node inside an obsolete /foo > container? You can't. /martin From nobody Wed Dec 21 03:03:12 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13E8129D3F for ; Wed, 21 Dec 2016 03:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 5D-SDJfgFtXe for ; Wed, 21 Dec 2016 03:03:09 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 392CC1295AD for ; Wed, 21 Dec 2016 03:03:09 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 4DA631AE030A; Wed, 21 Dec 2016 12:03:08 +0100 (CET) Date: Wed, 21 Dec 2016 12:03:06 +0100 (CET) Message-Id: <20161221.120306.112146375388438232.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <5DD58CAA-BDA7-4859-B69F-8BF24B048FA7@nic.cz> References: <20161221.103208.1910010141581780305.mbj@tail-f.com> <5DD58CAA-BDA7-4859-B69F-8BF24B048FA7@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: Cc: netmod@ietf.org Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 11:03:11 -0000 Ladislav Lhotka wrote: > > > On 21 Dec 2016, at 10:32, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> Martin Bjorklund writes: > >> > >>> Robert Wilton wrote: > >>>> Hi, > >>>> > >>>> The definition of "status" in RFC 7950 in section 7.21.2 (full text > >>>> below), states: > >>>> > >>>> If no status is specified, the default is "current". > >>>> > >>>> From my interpretation of the text in the draft, this implies that the > >>>> status of the "new" child leaf in the following example is "current", > >>>> and that this example is allowed! > >>>> > >>>> My questions are: > >>>> - Is my interpretation of the current text correct? > >>> > >>> Yes. > >>> > >>>> - Is this actually the best behaviour, or should it inherit like the > >>>> config statement? > >>> > >>> I think the idea was that if the status != current, it is better for > >>> the reader if it is explicitly stated. > >>> > >>>> Should I raise an errata for this? > >>> > >>> No. > >>> > >>> However, we could have said that a current node under a deprecated > >>> node (etc) in the same module is an error, in order to force people > >>> (through the useage of YANG validators) to detect and fix this. > >> > >> Since "current" is the default, correctly deprecating a subtree would > >> mean to explicitly add the "status" statement to every single node in > >> the subtree. > > > > Yes. > > > >> I think that "obsolete" should apply to the whole subtree, no matter > >> what status descendants have, and "deprecated" should apply to the whole > >> subtree except for parts that are obsolete. > > > > Maybe, but this is not how it works in YANG 1 and 1.1. For the > > reasoning behind this, see above. Maybe this is not perfect, and > > something that we should look into if we update YANG. But I don't > > think this is a problem. > > I think it is a problem. We can see a lot of these things before > long because of the update rules. For example, it may apply to all > the *-state trees, and tagging every single node therein with > "deprecated" or "obsolete" is a useless exercise. I don't think it is a useless exercise. It helps the reader to quickly see that a node is deprecated, without having to search the text for all ancestors' status. /martin From nobody Wed Dec 21 05:08:14 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714B1129D91 for ; Wed, 21 Dec 2016 05:08:13 -0800 (PST) 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 Z62nMm9fdnGQ for ; Wed, 21 Dec 2016 05:08:12 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C9FD0129D88 for ; Wed, 21 Dec 2016 05:08:11 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 9F57D1CC0317 for ; Wed, 21 Dec 2016 14:08:10 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org Date: Wed, 21 Dec 2016 14:08:09 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [netmod] LL review of draft-ietf-netmod-intf-ext-yang-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 13:08:13 -0000 Hi, I think this is a very useful addition to ietf-interfaces. In general, the document is clearly written and YANG modules nicely designed. Here are my comments: *** Sec. 1 - "This document defines two YANG RFC 7950 [RFC7950] modules =E2=80=A6" looks weird. I'd suggest "=E2=80=A6 YANG 1.1 [RFC7950] =E2=80=A6" ins= tead. *** Sec. 2 - first line: s/of of/of/ *** Sec. 3.1 - If the "bandwidth" parameter is only used for tuning routing algorithms and has nothing to do with real bandwidth on the interface, I would suggest to use a different name (metric?). Perhaps it may indeed be better to leave this to routing protocol modules because they can also specify how exactly such a parameter is used. *** Sec. 3.6 - The "l3-mtu" parameter is probably the same as "mtu" defined in ietf-ip. Again, I would suggest to leave the definition of MTU to each L3 protocol because there may be specific aspects and constraints. *** Sec. 3.8 - I think that "transport-layer" is not a good name because in the ISO OSI model it denotes a particular layer (L4). How about "iso-osi-layer"? - The type of "transport-layer" has three enums, namely "layer-[123]". I would suggest to use descriptive names ("physical-layer" etc.), include the remaining layers of the ISO OSI model, and maybe also define it as a typedef - or does this belong to ietf-inet-types? - Is a leaf sufficient? I think some interfaces can be in multiple layers at the same time (e.g. an ATM interface is L3 but can also be L2 for Classical IP over ATM). Or is the idea that such an interface will be split into two entries of the "interface" list? *** YANG modules - Descriptions are not consistently formatted. I think that the current BCP is to start description text on the same line as the "description" keyword only if it all fits on one line. - I don't have a strong opinion on this but it might increase readability if the number of augments is reduced. Perhaps at least augments that contain only one node could be made into one (and the "feature" and "when" statements moved to the nodes' definitions. Lada --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Dec 21 05:08:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04DB3129D92 for ; Wed, 21 Dec 2016 05:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 M0rs1yKhSSRk for ; Wed, 21 Dec 2016 05:08:38 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECCB129D88 for ; Wed, 21 Dec 2016 05:08:38 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 6562E1AE030A; Wed, 21 Dec 2016 14:08:36 +0100 (CET) Date: Wed, 21 Dec 2016 14:08:34 +0100 (CET) Message-Id: <20161221.140834.1797282783596629756.mbj@tail-f.com> To: bart.bogaert@nokia.com From: Martin Bjorklund In-Reply-To: References: <20161216.103131.190811205717956437.mbj@tail-f.com> <20161216112728.GA9710@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-entity issue #13 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 13:08:40 -0000 "Bogaert, Bart (Nokia - BE)" wrote: > Hi, > > --- snip --- > > > > Well, this is not what I read out of > > > > > > https://www.ietf.org/mail-archive/web/netmod/current/msg17039.html > > > > > > since there are leafs like mfg-name and model-name that seem to be > > > hardware component properties. > > > > The description statements in this email are just copied from the > > corresponding config false nodes. I think they need to be rewritten; > > compare with serial-num. This text can probably be further improved. > > The idea is that the user probably would configure say mfg-name only > > if the system cannot detect it automatically. > > I still wonder why it could be useful to provision things like the mfg-name > or the serial-num. I would rather like to know what is really there instead > of overwriting these properties. > [Bart Bogaert] BBF did not propose to add serial-num, this is in the base > ietf-entity YANG model. For pluggable items it makes sense to add the model > name and mfg-name. In case of pre-provisioning (so preparing and sending a > configuration to the device while the HW entity is actually not there yet) > it makes sense to indicate what is the intended configuration. When the HW > entity is inserted at a later point in time the device could raise a > mismatch alarm in case another entity is detected then the one that was > "predicted" to be inserted at that position. It would be very useful if you could comment explicitly on the pre-provisioning algorithm I described in https://mailarchive.ietf.org/arch/msg/netmod/j0lbdkul9f_jJFVGz3aAAmqrEzs (also cited below). >From you text above it seems that you do not agree with my algorithm. /martin > Best regards, > Bart > > > > And the config list is still indexed by a name; so for list elements > > > that have a (class, parent, position) triple, the name would be > > > arbitrary and not necessarily matching the component name. > > > > I think that the idea is that if there is a matching triple, then the > > system MUST use the configured 'name' as the 'name' also in the state > > list. One reason for pre-confiugring these components is to be able > > to refer to them in other config. > > This may make sense. > > > > Well, if you understand the edits,... > > > > I think the idea would be explained along these lines: > > > > The sytem conceptually behaves like this: > > > > 1. When a physical component is detected, the system will initialize > > an entry in the /hardware-state/component list. > > > > If there is an entry in /hardare/component list with a matching > > (class,parent,parent-rel-pos) triple, then the state entry is > > initialized with the configured values for all configured leafs > > (name, mfg-name, ...). > > > > If there is no such matching entry, the system assigns a 'name' > > in an implementation-specific manner. > > > > If there is an entry in /hardare/component list with a matching > > 'name' and where the triple (class,parent,parent-rel-pos) is not > > set, then the state entry is initialized with the configured > > values for all configured leafs (name, mfg-name, ...). > > > > Otherwise, the state entry is initialized with the detected values > > for all leafs. > > > > 2. If the /hardware/component list is modified (i.e., someone changed > > the config), then the system MUST behave as if it was restarted > > and followed the procedure in (1). > > This way of pre-configuring that name may indeed make sense. Lets see if > this is what BBF really wanted. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Dec 21 05:37:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7865412962C for ; Wed, 21 Dec 2016 05:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxUvFt3fvNL2 for ; Wed, 21 Dec 2016 05:37:06 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADDF612959D for ; Wed, 21 Dec 2016 05:37:05 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 3422A2BE2AE72; Wed, 21 Dec 2016 13:37:00 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uBLDb1Lc019531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Dec 2016 13:37:03 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uBLDZkn4030114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Dec 2016 13:36:59 GMT Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.164]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Wed, 21 Dec 2016 14:36:16 +0100 From: "Bogaert, Bart (Nokia - BE)" To: Martin Bjorklund Thread-Topic: [netmod] draft-ietf-netmod-entity issue #13 Thread-Index: AQHSV4/zI+GWx4JDRkGCqJt+vJdcKqESGQyggAA9uwCAABYP8A== Date: Wed, 21 Dec 2016 13:36:15 +0000 Message-ID: References: <20161216.103131.190811205717956437.mbj@tail-f.com> <20161216112728.GA9710@elstar.local> <20161221.140834.1797282783596629756.mbj@tail-f.com> In-Reply-To: <20161221.140834.1797282783596629756.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02D9_01D25B97.94D65730" MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-ietf-netmod-entity issue #13 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 13:37:08 -0000 ------=_NextPart_000_02D9_01D25B97.94D65730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please find response interleaved --- snip --- It would be very useful if you could comment explicitly on the pre-provisioning algorithm I described in https://mailarchive.ietf.org/arch/msg/netmod/j0lbdkul9f_jJFVGz3aAAmqrEzs (also cited below). >From you text above it seems that you do not agree with my algorithm. /martin > Best regards, > Bart > > > > And the config list is still indexed by a name; so for list > > > elements that have a (class, parent, position) triple, the name > > > would be arbitrary and not necessarily matching the component name. > > > > I think that the idea is that if there is a matching triple, then > > the system MUST use the configured 'name' as the 'name' also in the > > state list. One reason for pre-confiugring these components is to > > be able to refer to them in other config. > > This may make sense. > > > > Well, if you understand the edits,... > > > > I think the idea would be explained along these lines: > > > > The sytem conceptually behaves like this: > > > > 1. When a physical component is detected, the system will initialize > > an entry in the /hardware-state/component list. > > > > If there is an entry in /hardare/component list with a matching > > (class,parent,parent-rel-pos) triple, then the state entry is > > initialized with the configured values for all configured leafs > > (name, mfg-name, ...). [Bart Bogaert] this is correct > > > > If there is no such matching entry, the system assigns a 'name' > > in an implementation-specific manner. [Bart Bogaert] This is correct > > > > If there is an entry in /hardare/component list with a matching > > 'name' and where the triple (class,parent,parent-rel-pos) is not > > set, then the state entry is initialized with the configured > > values for all configured leafs (name, mfg-name, ...). [Bart Bogaert] We currently expect that these leafs contain meaningful values but we will not copy the leaf values from config to state but populate the state fields with what is detected from the HW and raise a mismatch alarm. Possibly the operational state is set to disabled. So when a mismatch Is found between what is set in /hardware/component and what is detected a mismatch alarm is raised. > > > > Otherwise, the state entry is initialized with the detected values > > for all leafs. [Bart Bogaert] This is correct > > > > 2. If the /hardware/component list is modified (i.e., someone changed > > the config), then the system MUST behave as if it was restarted > > and followed the procedure in (1). [Bart Bogaert] This is correct Regards, Bart > > This way of pre-configuring that name may indeed make sense. Lets see > if this is what BBF really wanted. > > /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 ------=_NextPart_000_02D9_01D25B97.94D65730 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/TCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr 4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0 ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3 dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93 d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy 7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6 /XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYzCCBkugAwIBAgIKXRYRuwAAAADQ8TANBgkq hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDE2MDU1MjI4WhcNMTcwNDE1 MDU1MjI4WjBDMREwDwYDVQQDEwhib2dhZXJ0YjEuMCwGCSqGSIb3DQEJARYfYmFydC5ib2dhZXJ0 QGFsY2F0ZWwtbHVjZW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJBS7alw mZfOimfXIdJjyp1G8U+E4Rs5y+eXtDfKWEuy6UOCstRCUiSz+eljCu737ZPkMHmPMdXDHZGnsV9y HsInD5cZHBTNnboc8lV7zLVpTrtrnflClsOiRD75CS1Vvehx+JnFuW4Mo/VeWjQtUD4tUU67W7b0 QPOkcB3KkZixozjERSxPUFHf6pMShshwQlKtvV6YLdhnNePiuFimfYqUDiOQs1LR8C+r3eSMHi8o lyWTHf49vFPL7z62HWSldeEkf6vhtuZuWLfH7xqO3CIQH63zUJF9p23ko2/Gtc1MpAcdWMwV3ymj V8ef+gZac/SFwFgA547zeawhhvtdiOUCAwEAAaOCBBQwggQQMD0GCSsGAQQBgjcVBwQwMC4GJisG AQQBgjcVCIW9xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisG AQQBgjcKAwQGCCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQB gjcKAwQwCgYIKwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZI hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBTzjeedsBUMWk5eyOwD8/c9 1B1G8jAfBgNVHSMEGDAWgBTZ7Gu9llgi99imd83+TYHvupe9EjCCAV0GA1UdHwSCAVQwggFQMIIB TKCCAUigggFEhoHZbGRhcDovLy9DTj1BbGNhdGVsJTIwTHVjZW50JTIwSW50ZXJuYWwlMjBTdWIl MjBDQSxDTj11c25hdnNwa2kwM3AsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NlcnRp ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu dIYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmyGOGh0dHA6Ly9z ZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0EuY3JsMIIBYQYIKwYB BQUHAQEEggFTMIIBTzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQl MjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWx1YWQsREM9bHVjZW50LERDPWNvbT9jQUNl cnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA4BggrBgEF BQcwAoYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwRAYIKwYB BQUHMAKGOGh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3Vi Q0EuY3J0MCoGA1UdEQQjMCGBH2JhcnQuYm9nYWVydEBhbGNhdGVsLWx1Y2VudC5jb20wDQYJKoZI hvcNAQEFBQADggEBAEARoPJfuwXhstAQ/fAz/XKDC//Je9A0RG9Q5XV7+URvR5GxhwuikL/MEtXs Dspufv0eHG/b92AVZxaSgdpzC6neLoW2Q/Rdeavuifm7H/Ob645vIufqDQEqRqsyt9xRP+31VphA do994d7kU6v5BI7DAA8s5rl6h4PFbtvY5qe8VLNiTnon1dCwPQ+mRSrLfgjlZUw+WsMh69JEOWZX EufZMg0oUvCboUe3LNNvh8+DtLafaT1gS/kpv3c+dXVApTjb1tPbeZHc5L85AVQBsbq/vYpWhiZR qDiyVyPh+dh7vTa/GBJx/UVLwv6IswAwtCWZ/r9aReHssqkgMH9evF8xggQpMIIEJQIBATCBlDCB hTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT 8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1 Y2VudCBJbnRlcm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwCQYFKw4DAhoFAKCCAmkwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMjIxMTMzNjE0WjAjBgkqhkiG9w0B CQQxFgQU0EAHJgZ4CUOqNg6BTfJYcC0Gd7MwgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQBt sCgXkZp9LZLad0Bz9f4QYPkxwwAT+3yoGG/6CzTzA0Fl/kEqFPYgyP4ZcBILDq0yK7oZ4Cd6Xba+ YB+caOCre+S09ixDECoG7i3ABaIL7uMzCkrBGayBYRQyujBf1P9gMmgs4yJgpO8qdRLCSC9ttReO fmQsIjFCE+LVt6zkB6vxLQRkRv2ygCBtuW3eoAxQkFDVgjTAogqWyZrxmwFgCtgpWM2BYV2a8kI+ rsHcXAOZz7vWGSLy7JtqR3qpAT6mcVveqJ+99Kv4SkjAXD1scT3oU2Qe+A4C4Kpf9xjDml+hXZnt u4cbQ6Y1ACp5OC25Ti/ba0CiWMmcjgWa6OZyAAAAAAAA ------=_NextPart_000_02D9_01D25B97.94D65730-- From nobody Wed Dec 21 05:47:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4873129561 for ; Wed, 21 Dec 2016 05:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IabtQ1FHycIg for ; Wed, 21 Dec 2016 05:47:07 -0800 (PST) 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 00AA21295BB for ; Wed, 21 Dec 2016 05:47:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1809; q=dns/txt; s=iport; t=1482328026; x=1483537626; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=NARkPoAzI5OW6oo36Xu/9VijC36kk6qv3AvS3z5HZ2w=; b=MICrAZWf2a5VkDAUV1Rru4pO9eu/wcut39NEGux4/5Et4OSvZrPpl6iL y+gozN19FgYGz19IYqCepqhs+QTrXJVj1kWpXn2Wj+uTtUE67xpI14ehM yKESoEvYcqsiO6wXZlOlD4twXorPeOFkgNoimdcyriV4hiQx8tLBzAAZH E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAgAxh1pY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzUBAQEBAZBDlWCTBIIPggqGIgKCHBIBAgEBAQEBAQFiKIRpAQU?= =?us-ascii?q?4UQsOCi5XBgEMCAEBiGeqf4sRAQEBAQEBAQEBAQEBAQEBAQEBIIY2gX2CXIohA?= =?us-ascii?q?QSGPJQ7iWSDFYRAiiKGL4o/g2WEDyYGKoEHFg2EExyBXT6GUSuCEAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,383,1477958400"; d="scan'208";a="648064802" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Dec 2016 13:47:01 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uBLDl1LO003399; Wed, 21 Dec 2016 13:47:01 GMT To: Martin Bjorklund , netmod@ietf.org References: <1db67b1d-36ef-5cc6-425f-7e22de7e80ae@cisco.com> <20161220.210335.1870203216124697421.mbj@tail-f.com> <20161220201527.GA3897@elstar.local> From: Robert Wilton Message-ID: Date: Wed, 21 Dec 2016 13:47:01 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161220201527.GA3897@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 13:47:09 -0000 I think that it should be a error to have a current node under a deprecated node in the same module, and similarly for deprecated/obsolete. I.e. to be consistent with the following text from 7950 sec 7.21.2: 'If a definition is "current", it MUST NOT reference a "deprecated" or"obsolete" definition within the same module.' I agree that it is useful if tools generate warnings if a module augments (or references) a deprecated or obsolete node (as per Juergen's comments below). I don't have an issue with explicitly marking the child nodes as deprecated/obsolete, but intuitively I would have expected this to inherit like the config statement. Rob On 20/12/2016 20:15, Juergen Schoenwaelder wrote: > On Tue, Dec 20, 2016 at 09:03:35PM +0100, Martin Bjorklund wrote: >> However, we could have said that a current node under a deprecated >> node (etc) in the same module is an error, in order to force people >> (through the useage of YANG validators) to detect and fix this. >> > Is it an error or just something that deserves a warning and the > author's attention? I am asking since we also have augmentations and > if I mark a container as deprecated, this will not immediately cause > an module augmenting the containter to get updated, hence I end up > with definitions marked current in a deprecated container. And there > are other situations where definitions may not be of the same status, > i.e., a module (without import by revision) uses a type or grouping > that in later revisions got marked deprecated. I think all of these > status mismatches are things tools should warn about but I am not sure > these are hard errors, in particular for 'deprecated'. Things may lead > to stronger warnings for definitions marked 'obsolete'. > > /js > From nobody Wed Dec 21 05:57:36 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B19129668 for ; Wed, 21 Dec 2016 05:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 UaJbZGnKOni2 for ; Wed, 21 Dec 2016 05:57:32 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 560D7129561 for ; Wed, 21 Dec 2016 05:57:29 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:a433:9391:e4ad:aa3f] (unknown [IPv6:2001:718:1a02:1:a433:9391:e4ad:aa3f]) by mail.nic.cz (Postfix) with ESMTPSA id B38EC60AD4; Wed, 21 Dec 2016 14:57:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1482328647; bh=gX5Ah8t86yEbVQzqZPKNHiUtFYu8oLNSitij/fEUaZw=; h=From:Date:To; b=fIcGt7fimqIz8cvFZ7DxZ1u141KQy4kMdqvEsN3ngq5qj6nsZ14mepW000nkBd7zC niWra9B49nSagpuqlUt2KPvVT8zl3raQMamqSBK9JwKef/ms6B5v67TsfOg7+pP9qW LOFWX4avCE9NtICdtzytO9ulntcig/0Xya4KY7/A= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 21 Dec 2016 14:57:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6BBBB0DE-8322-4DCF-BEF6-1B4A97BA1712@nic.cz> References: <1db67b1d-36ef-5cc6-425f-7e22de7e80ae@cisco.com> <20161220.210335.1870203216124697421.mbj@tail-f.com> <20161220201527.GA3897@elstar.local> To: Robert Wilton X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 13:57:35 -0000 > On 21 Dec 2016, at 14:47, Robert Wilton wrote: >=20 > I think that it should be a error to have a current node under a = deprecated node in the same module, and similarly for = deprecated/obsolete. I.e. to be consistent with the following text from = 7950 sec 7.21.2: >=20 > 'If a definition is "current", it MUST NOT reference a "deprecated" = or"obsolete" definition within the same module.' >=20 > I agree that it is useful if tools generate warnings if a module = augments (or references) a deprecated or obsolete node (as per Juergen's = comments below). >=20 > I don't have an issue with explicitly marking the child nodes as = deprecated/obsolete, but intuitively I would have expected this to = inherit like the config statement. +1 If everybody agrees that "current" under "deprecated"/"obsolete" is an = error, then "current" shouldn't be the default in such situations. Lada >=20 > Rob >=20 >=20 > On 20/12/2016 20:15, Juergen Schoenwaelder wrote: >> On Tue, Dec 20, 2016 at 09:03:35PM +0100, Martin Bjorklund wrote: >>> However, we could have said that a current node under a deprecated >>> node (etc) in the same module is an error, in order to force people >>> (through the useage of YANG validators) to detect and fix this. >>>=20 >> Is it an error or just something that deserves a warning and the >> author's attention? I am asking since we also have augmentations and >> if I mark a container as deprecated, this will not immediately cause >> an module augmenting the containter to get updated, hence I end up >> with definitions marked current in a deprecated container. And there >> are other situations where definitions may not be of the same status, >> i.e., a module (without import by revision) uses a type or grouping >> that in later revisions got marked deprecated. I think all of these >> status mismatches are things tools should warn about but I am not = sure >> these are hard errors, in particular for 'deprecated'. Things may = lead >> to stronger warnings for definitions marked 'obsolete'. >>=20 >> /js >>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Dec 21 06:57:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0A3129493 for ; Wed, 21 Dec 2016 06:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 6OzbnFF_374Q for ; Wed, 21 Dec 2016 06:57:00 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCB5128AC9 for ; Wed, 21 Dec 2016 06:57:00 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 988ED1AE030A; Wed, 21 Dec 2016 15:56:58 +0100 (CET) Date: Wed, 21 Dec 2016 15:56:56 +0100 (CET) Message-Id: <20161221.155656.206709286026641192.mbj@tail-f.com> To: bart.bogaert@nokia.com From: Martin Bjorklund In-Reply-To: References: <20161221.140834.1797282783596629756.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-entity issue #13 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 14:57:02 -0000 "Bogaert, Bart (Nokia - BE)" wrote: > Please find response interleaved > > --- snip --- > > It would be very useful if you could comment explicitly on the > pre-provisioning algorithm I described in > https://mailarchive.ietf.org/arch/msg/netmod/j0lbdkul9f_jJFVGz3aAAmqrEzs > (also cited below). > > From you text above it seems that you do not agree with my algorithm. > > > /martin > > > > Best regards, > > Bart > > > > > > And the config list is still indexed by a name; so for list > > > > elements that have a (class, parent, position) triple, the name > > > > would be arbitrary and not necessarily matching the component name. > > > > > > I think that the idea is that if there is a matching triple, then > > > the system MUST use the configured 'name' as the 'name' also in the > > > state list. One reason for pre-confiugring these components is to > > > be able to refer to them in other config. > > > > This may make sense. > > > > > > Well, if you understand the edits,... > > > > > > I think the idea would be explained along these lines: > > > > > > The sytem conceptually behaves like this: > > > > > > 1. When a physical component is detected, the system will initialize > > > an entry in the /hardware-state/component list. > > > > > > If there is an entry in /hardare/component list with a matching > > > (class,parent,parent-rel-pos) triple, then the state entry is > > > initialized with the configured values for all configured leafs > > > (name, mfg-name, ...). > [Bart Bogaert] this is correct I assume that you do the validation check that you describe below also in this case? > > > > > > If there is no such matching entry, the system assigns a 'name' > > > in an implementation-specific manner. > [Bart Bogaert] This is correct > > > > > > If there is an entry in /hardare/component list with a matching > > > 'name' and where the triple (class,parent,parent-rel-pos) is not > > > set, then the state entry is initialized with the configured > > > values for all configured leafs (name, mfg-name, ...). > [Bart Bogaert] We currently expect that these leafs contain meaningful > values but we will not copy the leaf values from config to state but > populate the state fields with what is detected from the HW and raise a > mismatch alarm. Do you expect all configured leafs to contain meaningful values, i.e., do you validate that all leafs (serial-num, mfg-name, model-name) match? This procedure would change how serial-num currently is handled. I don't have a strong opinion on this, but I note that serial-num is writable in the ENTITY-MIB. Maybe someone can comment on why it is writable in the MIB, and if this is a use case that we want to support? > Possibly the operational state is set to disabled. So when > a mismatch Is found between what is set in /hardware/component and what is > detected a mismatch alarm is raised. > > > > > > Otherwise, the state entry is initialized with the detected values > > > for all leafs. > [Bart Bogaert] This is correct > > > > > > 2. If the /hardware/component list is modified (i.e., someone changed > > > the config), then the system MUST behave as if it was restarted > > > and followed the procedure in (1). > [Bart Bogaert] This is correct > > Regards, > Bart > > > > This way of pre-configuring that name may indeed make sense. Lets see > > if this is what BBF really wanted. > > > > /js /martin From nobody Wed Dec 21 07:13:08 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820681296CB for ; Wed, 21 Dec 2016 07:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 g-OrWZtwfHGD for ; Wed, 21 Dec 2016 07:13:06 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2AA1294ED for ; Wed, 21 Dec 2016 07:13:06 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id CA4061AE030A; Wed, 21 Dec 2016 16:13:05 +0100 (CET) Date: Wed, 21 Dec 2016 16:13:04 +0100 (CET) Message-Id: <20161221.161304.449753643213126810.mbj@tail-f.com> To: lhotka@nic.cz 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: Cc: netmod@ietf.org Subject: Re: [netmod] LL review of draft-ietf-netmod-intf-ext-yang-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 15:13:07 -0000 Ladislav Lhotka wrote: > *** YANG modules > - Descriptions are not consistently formatted. I think that the > current BCP is to start description text on the same line as the > "description" keyword only if it all fits on one line. Just a FYI. Try using: pyang --keep-comments -f yang ietf-interfaces-common\@2016-10-27.yang It will format descriptions etc consistently. /martin From nobody Wed Dec 21 07:29:17 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A64F12949D for ; Wed, 21 Dec 2016 07:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EVVsQ3ImK1V for ; Wed, 21 Dec 2016 07:29:14 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAA4F12941A for ; Wed, 21 Dec 2016 07:29:13 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 83F6C549FA6FE; Wed, 21 Dec 2016 15:29:06 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uBLFT7S6019461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Dec 2016 15:29:09 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id uBLFSrTk008349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Dec 2016 15:29:05 GMT Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.164]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Wed, 21 Dec 2016 16:29:00 +0100 From: "Bogaert, Bart (Nokia - BE)" To: Martin Bjorklund Thread-Topic: [netmod] draft-ietf-netmod-entity issue #13 Thread-Index: AQHSV4/zI+GWx4JDRkGCqJt+vJdcKqESGQyggAA9uwCAABYP8IAACDgAgAAXmSA= Date: Wed, 21 Dec 2016 15:28:59 +0000 Message-ID: References: <20161221.140834.1797282783596629756.mbj@tail-f.com> <20161221.155656.206709286026641192.mbj@tail-f.com> In-Reply-To: <20161221.155656.206709286026641192.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_033C_01D25BA7.5482F3E0" MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-ietf-netmod-entity issue #13 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 15:29:16 -0000 ------=_NextPart_000_033C_01D25BA7.5482F3E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit --- snip --- > > > I think the idea would be explained along these lines: > > > > > > The sytem conceptually behaves like this: > > > > > > 1. When a physical component is detected, the system will initialize > > > an entry in the /hardware-state/component list. > > > > > > If there is an entry in /hardare/component list with a matching > > > (class,parent,parent-rel-pos) triple, then the state entry is > > > initialized with the configured values for all configured leafs > > > (name, mfg-name, ...). > [Bart Bogaert] this is correct I assume that you do the validation check that you describe below also in this case? [Bart Bogaert] Indeed > > > > > > If there is no such matching entry, the system assigns a 'name' > > > in an implementation-specific manner. > [Bart Bogaert] This is correct > > > > > > If there is an entry in /hardare/component list with a matching > > > 'name' and where the triple (class,parent,parent-rel-pos) is not > > > set, then the state entry is initialized with the configured > > > values for all configured leafs (name, mfg-name, ...). > [Bart Bogaert] We currently expect that these leafs contain meaningful > values but we will not copy the leaf values from config to state but > populate the state fields with what is detected from the HW and raise > a mismatch alarm. Do you expect all configured leafs to contain meaningful values, i.e., do you validate that all leafs (serial-num, mfg-name, model-name) match? This procedure would change how serial-num currently is handled. I don't have a strong opinion on this, but I note that serial-num is writable in the ENTITY-MIB. Maybe someone can comment on why it is writable in the MIB, and if this is a use case that we want to support? [Bart Bogaert] No, in this case we expect the triplet to be meaningful (class,parent,parent-rel-pos) as this identifies the HW entity and on top of that the mfg-name and model-name are checked. In case there is a mismatch an alarm is generated. The other leafs (defined in ietf-entity) are implemented as described in the entity YANG model. Regards, Bart > Possibly the operational state is set to disabled. So when a mismatch > Is found between what is set in /hardware/component and what is > detected a mismatch alarm is raised. > > > > > > Otherwise, the state entry is initialized with the detected values > > > for all leafs. > [Bart Bogaert] This is correct > > > > > > 2. If the /hardware/component list is modified (i.e., someone changed > > > the config), then the system MUST behave as if it was restarted > > > and followed the procedure in (1). > [Bart Bogaert] This is correct > > Regards, > Bart > > > > This way of pre-configuring that name may indeed make sense. Lets > > see if this is what BBF really wanted. > > > > /js /martin ------=_NextPart_000_033C_01D25BA7.5482F3E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/TCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr 4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0 ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3 dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93 d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy 7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6 /XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYzCCBkugAwIBAgIKXRYRuwAAAADQ8TANBgkq hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDE2MDU1MjI4WhcNMTcwNDE1 MDU1MjI4WjBDMREwDwYDVQQDEwhib2dhZXJ0YjEuMCwGCSqGSIb3DQEJARYfYmFydC5ib2dhZXJ0 QGFsY2F0ZWwtbHVjZW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJBS7alw mZfOimfXIdJjyp1G8U+E4Rs5y+eXtDfKWEuy6UOCstRCUiSz+eljCu737ZPkMHmPMdXDHZGnsV9y HsInD5cZHBTNnboc8lV7zLVpTrtrnflClsOiRD75CS1Vvehx+JnFuW4Mo/VeWjQtUD4tUU67W7b0 QPOkcB3KkZixozjERSxPUFHf6pMShshwQlKtvV6YLdhnNePiuFimfYqUDiOQs1LR8C+r3eSMHi8o lyWTHf49vFPL7z62HWSldeEkf6vhtuZuWLfH7xqO3CIQH63zUJF9p23ko2/Gtc1MpAcdWMwV3ymj V8ef+gZac/SFwFgA547zeawhhvtdiOUCAwEAAaOCBBQwggQQMD0GCSsGAQQBgjcVBwQwMC4GJisG AQQBgjcVCIW9xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisG AQQBgjcKAwQGCCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQB gjcKAwQwCgYIKwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZI hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBTzjeedsBUMWk5eyOwD8/c9 1B1G8jAfBgNVHSMEGDAWgBTZ7Gu9llgi99imd83+TYHvupe9EjCCAV0GA1UdHwSCAVQwggFQMIIB TKCCAUigggFEhoHZbGRhcDovLy9DTj1BbGNhdGVsJTIwTHVjZW50JTIwSW50ZXJuYWwlMjBTdWIl MjBDQSxDTj11c25hdnNwa2kwM3AsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NlcnRp ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu dIYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmyGOGh0dHA6Ly9z ZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0EuY3JsMIIBYQYIKwYB BQUHAQEEggFTMIIBTzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQl MjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWx1YWQsREM9bHVjZW50LERDPWNvbT9jQUNl cnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA4BggrBgEF BQcwAoYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwRAYIKwYB BQUHMAKGOGh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3Vi Q0EuY3J0MCoGA1UdEQQjMCGBH2JhcnQuYm9nYWVydEBhbGNhdGVsLWx1Y2VudC5jb20wDQYJKoZI hvcNAQEFBQADggEBAEARoPJfuwXhstAQ/fAz/XKDC//Je9A0RG9Q5XV7+URvR5GxhwuikL/MEtXs Dspufv0eHG/b92AVZxaSgdpzC6neLoW2Q/Rdeavuifm7H/Ob645vIufqDQEqRqsyt9xRP+31VphA do994d7kU6v5BI7DAA8s5rl6h4PFbtvY5qe8VLNiTnon1dCwPQ+mRSrLfgjlZUw+WsMh69JEOWZX EufZMg0oUvCboUe3LNNvh8+DtLafaT1gS/kpv3c+dXVApTjb1tPbeZHc5L85AVQBsbq/vYpWhiZR qDiyVyPh+dh7vTa/GBJx/UVLwv6IswAwtCWZ/r9aReHssqkgMH9evF8xggQpMIIEJQIBATCBlDCB hTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT 8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1 Y2VudCBJbnRlcm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwCQYFKw4DAhoFAKCCAmkwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMjIxMTUyODU4WjAjBgkqhkiG9w0B CQQxFgQUeE7gwWZ+M2gRwtC0qllA7N77xeQwgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQAc TeSWTdV/87J/NuIcBojp6DJmpWQAbeN1xjIpbuNz5AExxs61PSkBHWCwPm/L4cZOrtYHNzjU9u/+ mseBLLyKLQ8D3rLKN3rRByLxY02BWgPF24aDF9nG/1VcTtHPD045C/4a7X4KN005ayUWVxI0+Wcj ae7WT5u7/+FbGL9mLvGZERmhjHX/A6K56uGt0Tslsosux1oisGhd1LMg6v4KdNudP6JeNQAHqCs7 l9fKye7NzEAkt4iXh1FCbElJ0xy38Fsbfi2EeX+eKHUCEDx2zeZspkAcsBeQCCUvWgX2U6/YzJDi XHZQ9b5KJZAuLhXv7tkOAYZZTjY++2oO4qLgAAAAAAAA ------=_NextPart_000_033C_01D25BA7.5482F3E0-- From nobody Wed Dec 21 08:21:15 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3D5129713 for ; Wed, 21 Dec 2016 08:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lONxlL2XrWXh for ; Wed, 21 Dec 2016 08:21:12 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 067AB12944E for ; Wed, 21 Dec 2016 08:21:09 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id c47so210434086qtc.2 for ; Wed, 21 Dec 2016 08:21:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rpY6BtlBOIEEsSlzxTnCCNX07k9q6BlTiRNhSm3l86I=; b=WIilTFA+wftGJWT5MbAcdq+bpzfxuSP853IarAgRSsouq2BuMo+mbQy/xzesgX/a5e gGR4AT+CzgfxKi25Jk7Ylnw43zDnjRbLMCWM6laVaWL+LF7nfzytghAjqRUX+m4N5PJE j1YeQX7evNlWrwcKWrxvdDZZMQe0fn2ej/Erhg4Tem3sHec2EgX/e4t3L6O+eDovd3zG xZqfh3euVDKPfgfDjQvDzVguedr+VFaeg1lqV3W3l929l3dl0+WY6FQPRdAiB1CGp2KH YiG13zwMzr++xZ4j6Lq+tgJZnXdzPX+F1q2ViO1RV+5+HILyxUPKc3f4XnxFrf/oNvja wZ7A== 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=rpY6BtlBOIEEsSlzxTnCCNX07k9q6BlTiRNhSm3l86I=; b=rrgjrPFD+TUy1ls6+3OtgPtDHWdS8TK7VGtW0gjhssgJ/ZMZEbse1iFSFYH/PG7Wst wAuPRHRLtlKc0a6rOn65Ky467OdK9jGG5j9gfWeD2qbEz1fD/5fdnqIIhIbSIsIifhq5 Oa7WHj/qtdYWtGBu81j3xOvHeOTmz9KjlvkDHTCQ0PjHZeg15J9Ka5YGZL+5c7iZt6NR fZgHp2vUmqAfUF3gz1DA8J4F5A+6yqtZoF50fOvcUBxS8YDcov8i8pwz5n4sl2xintzE dcNJ6oJaleV/YNd3DdDccmE/FUDYMz/uZxTqBj99yWT6yEs6YZ3foc+9ZpXiG2CYT/ps h3xA== X-Gm-Message-State: AIkVDXKLigmBPAP90F1BVLpa/Vf1aC/XmoycnWDpxf9v5O9sUguK9gRl0CuILUzObt9QEVxBzrIZbruKT+z+kQ== X-Received: by 10.200.40.211 with SMTP id j19mr5971996qtj.72.1482337268787; Wed, 21 Dec 2016 08:21:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.113 with HTTP; Wed, 21 Dec 2016 08:21:08 -0800 (PST) In-Reply-To: <20161221.115438.163227970004322277.mbj@tail-f.com> References: <20161221.103208.1910010141581780305.mbj@tail-f.com> <20161221.115438.163227970004322277.mbj@tail-f.com> From: Andy Bierman Date: Wed, 21 Dec 2016 08:21:08 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a1149e9545808a905442d8a98 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 16:21:13 -0000 --001a1149e9545808a905442d8a98 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 21, 2016 at 2:54 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Wed, Dec 21, 2016 at 1:32 AM, Martin Bjorklund > wrote: > > > > > Ladislav Lhotka wrote: > > > > Martin Bjorklund writes: > > > > > > > > > Robert Wilton wrote: > > > > >> Hi, > > > > >> > > > > >> The definition of "status" in RFC 7950 in section 7.21.2 (full > text > > > > >> below), states: > > > > >> > > > > >> If no status is specified, the default is "current". > > > > >> > > > > >> From my interpretation of the text in the draft, this implies > that the > > > > >> status of the "new" child leaf in the following example is > "current", > > > > >> and that this example is allowed! > > > > >> > > > > >> My questions are: > > > > >> - Is my interpretation of the current text correct? > > > > > > > > > > Yes. > > > > > > > > > >> - Is this actually the best behaviour, or should it inherit like > the > > > > >> config statement? > > > > > > > > > > I think the idea was that if the status != current, it is better > for > > > > > the reader if it is explicitly stated. > > > > > > > > > >> Should I raise an errata for this? > > > > > > > > > > No. > > > > > > > > > > However, we could have said that a current node under a deprecated > > > > > node (etc) in the same module is an error, in order to force people > > > > > (through the useage of YANG validators) to detect and fix this. > > > > > > > > Since "current" is the default, correctly deprecating a subtree would > > > > mean to explicitly add the "status" statement to every single node in > > > > the subtree. > > > > > > Yes. > > > > > > > Please explain what it means for YANG to say > > "The parent node is deprecated and going away but the child nodes are > not. > > They are current and are staying around." This does not seem to make any > > sense. > > Agreed. But this should be invalid also if the status statements are > given explicitly: > IMO the default should be inherit from parent, like the config-stmt. It clutters the YANG module to add a status-stmt to every descendant node. The status also applies to augment. If /foo is deprecated than any external augments that adds nodes under /foo is also deprecated. (Most obvious when you change deprecated to obsolete). > > container a { > status deprecated; > container b { > status current; > } > } > > I tested pyang with explicit statements and no warnings are given: container A { status deprecated; leaf AA { type string; status current; } } container B { status obsolete; leaf BB { type string; status current; } } > Clearly an obsolete node removes all access of its descendant nodes. > > There is no way to access /foo/child if /foo has been removed from the > > server. > > Yes. > > > So how do I access a deprecated /foo/child node inside an obsolete /foo > > container? > > You can't. > So the status-stmt clearly applies to descendant-or-self. > > > /martin > Andy --001a1149e9545808a905442d8a98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 21, 2016 at 2:54 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Wed, Dec 21, 2016 at 1:32 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Ladislav Lhotka <lhotka@nic.c= z> wrote:
> > > Martin Bjorklund <mbj@t= ail-f.com> writes:
> > >
> > > > Robert Wilton <= rwilton@cisco.com> wrote:
> > > >> Hi,
> > > >>
> > > >> The definition of "status" in RFC 7950 in= section 7.21.2 (full text
> > > >> below), states:
> > > >>
> > > >> If no status is specified, the default is "cur= rent".
> > > >>
> > > >> From my interpretation of the text in the draft, th= is implies that the
> > > >> status of the "new" child leaf in the fol= lowing example is "current",
> > > >> and that this example is allowed!
> > > >>
> > > >> My questions are:
> > > >>=C2=A0 - Is my interpretation of the current text co= rrect?
> > > >
> > > > Yes.
> > > >
> > > >>=C2=A0 - Is this actually the best behaviour, or sho= uld it inherit like the
> > > >>=C2=A0 =C2=A0 config statement?
> > > >
> > > > I think the idea was that if the status !=3D current, i= t is better for
> > > > the reader if it is explicitly stated.
> > > >
> > > >>=C2=A0 Should I raise an errata for this?
> > > >
> > > > No.
> > > >
> > > > However, we could have said that a current node under a= deprecated
> > > > node (etc) in the same module is an error, in order to = force people
> > > > (through the useage of YANG validators) to detect and f= ix this.
> > >
> > > Since "current" is the default, correctly deprecat= ing a subtree would
> > > mean to explicitly add the "status" statement to e= very single node in
> > > the subtree.
> >
> > Yes.
> >
>
> Please explain what it means for YANG to say
> "The parent node is deprecated and going away but the child nodes= are not.
> They are current and are staying around."=C2=A0 This does not see= m to make any
> sense.

Agreed.=C2=A0 But this should be invalid also if the status statements are<= br> given explicitly:

IMO the default shoul= d be inherit from parent, like the config-stmt.
It clutters the Y= ANG module to add a status-stmt to every descendant node.
The sta= tus also applies to augment.=C2=A0 If /foo is deprecated than any external = augments
that adds nodes under /foo is also deprecated. =C2=A0(Mo= st obvious when you change deprecated
to obsolete).
=C2=A0

=C2=A0 container a {
=C2=A0 =C2=A0 status deprecated;
=C2=A0 =C2=A0 container b {
=C2=A0 =C2=A0 =C2=A0 status current;
=C2=A0 =C2=A0 }
=C2=A0 }



I tested pyang with exp= licit statements and no warnings are given:

<= br>
=C2=A0 container A {
=C2=A0 =C2=A0 status deprecate= d;
=C2=A0 =C2=A0 leaf AA {
=C2=A0 =C2=A0 =C2=A0 type st= ring;
=C2=A0 =C2=A0 =C2=A0 status current;
=C2=A0 =C2= =A0 }
=C2=A0 }

=C2=A0 container B {
=C2=A0 =C2=A0 status obsolete;
=C2=A0 =C2=A0 leaf BB {
=C2=A0 =C2=A0 =C2=A0 type string;
=C2=A0 =C2=A0 =C2=A0 stat= us current;
=C2=A0 =C2=A0 }
=C2=A0 }


> Clearly an obsolete node removes all access of its descendant nodes. > There is no way to access /foo/child if /foo has been removed from the=
> server.

Yes.

> So how do I access a deprecated /foo/child node inside an obsolete /fo= o
> container?

You can't.

So the status-stmt clear= ly applies to descendant-or-self.

=C2=A0


/martin


<= /div>
Andy

--001a1149e9545808a905442d8a98-- From nobody Wed Dec 21 13:46:13 2016 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A103B1294B6; Wed, 21 Dec 2016 13:46:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148235677161.12736.15888156079931586369.idtracker@ietfa.amsl.com> Date: Wed, 21 Dec 2016 13:46:11 -0800 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-revised-datastores-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 21:46:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : A Revised Conceptual Model for YANG Datastores Authors : Martin Bjorklund Juergen Schoenwaelder Phil Shafer Kent Watsen Rob Wilton Filename : draft-ietf-netmod-revised-datastores-00.txt Pages : 20 Date : 2016-12-19 Abstract: Datastores are a fundamental concept binding the YANG data modeling language to protocols transporting data defined in YANG data models, such as NETCONF or RESTCONF. This document defines a revised conceptual model of datastores based on the experience gained with the initial simpler model and addressing requirements that were not well supported in the initial model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 21 14:30:48 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38B112943D for ; Wed, 21 Dec 2016 14:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] 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 UwWNSACpZ946 for ; Wed, 21 Dec 2016 14:30:43 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E1781293FD for ; Wed, 21 Dec 2016 14:30:43 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5E09F76C; Wed, 21 Dec 2016 23:30:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Vjqx1AJNu2TD; Wed, 21 Dec 2016 23:30:38 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 21 Dec 2016 23:30:40 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D6CA12007A; Wed, 21 Dec 2016 23:30:40 +0100 (CET) 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 SxZYPIB7XO_C; Wed, 21 Dec 2016 23:30:39 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 488A620079; Wed, 21 Dec 2016 23:30:39 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0C34E3DD94D3; Wed, 21 Dec 2016 23:30:39 +0100 (CET) Date: Wed, 21 Dec 2016 23:30:38 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20161221223038.GB4526@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <20161221.103208.1910010141581780305.mbj@tail-f.com> <20161221.115438.163227970004322277.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 22:30:46 -0000 On Wed, Dec 21, 2016 at 08:21:08AM -0800, Andy Bierman wrote: > > IMO the default should be inherit from parent, like the config-stmt. > It clutters the YANG module to add a status-stmt to every descendant node. Yes, explicit status statements clutter the module but they make it very explicit for the reader that stuff is deprecated or obsolete. In SMIv2, we had explicit status clauses everywhere and I have been a big fan of making current a default so this does not clutter the module. But I am also a big fan of making a status != current very explicit so a reader knows for sure which definitions can be ignored. (Perhaps it is just me but I often search in RFCs and/or YANG modules and then having to track back the tree to find out whether something I hit is deprecated or obsolete is a real burden. (In hindsight, I probably would have preferred to have config true not inherited but work like the status statement - having to search along the nesting structure to find out what something means is actually not that reader friendly - and bits are cheap these days. And the priority order back in a day was 'readers first, writers second, tool makers last'.) > The status also applies to augment. If /foo is deprecated than any > external augments that adds nodes under /foo is also deprecated. > (Most obvious when you change deprecated to obsolete). I may disagree with this, in particular for 'deprecated'. Assuming there are multiple organizations involved, I think we have a problem if one organization can deprecate augmentations maintained by another organization. Deprecated essentially says 'this will go away, stop using it if you can'. > > container a { > > status deprecated; > > container b { > > status current; > > } > > } I think this example is actually not complete non-sense. It says 'this container will go away, stop using it if you can'. There is still something current under it and this should be fixed. And this is in particular true for augmentations, e.g., augment /a { container c { } } should be OK - tools may generate warnings to tell the maintainer of the augmentation to pay attention to the fact that /a may get retired. Now, the IETF may decide that for published modules, something current in a deprecated container is to be avoided. But this is then a policy decision, from the language point of view I consider the case of something current under a deprecated container not a real error. /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 Dec 21 14:47:54 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334F5129627 for ; Wed, 21 Dec 2016 14:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzVsY4kIXpz7 for ; Wed, 21 Dec 2016 14:47:51 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 EF74512957F for ; Wed, 21 Dec 2016 14:47:50 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id t184so96697227qkd.0 for ; Wed, 21 Dec 2016 14:47:50 -0800 (PST) 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=7flMbnDvREEeCEQhVHTlJLLrAjoRpXdCaxW/vZmE03E=; b=M+ZIxx3RUmOPShvvVSDkjX2FFqLzHRq9uyGUFVBxPRBLCFKCO8oGF6xfZmbfwPwSx5 PRsMxmB69BpFKLtlglosOGjgo8saEOCBgz8c3aCg9f0qowx7miM+/aQcKBfEqslHdWYe 1N7t6dyj7YFvH0Hg5c8IrV43PpCS+JViN6w1yvIdyN33gL2/DsI1tiSOEKoOpFfSOgn2 M0dWCDiVl7F4ppeP4K+tRbDvI6Fnf9YO8COanLXV9/GfEg3uB3wNedPtwgQqWZ5+CReT qPtqqEw+ythMBWY2V0Gkb7wGYe8p6OqKHekcSO/4AjULgjyqt6MvwkYIfwc4aqBSjU7a 34eg== 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=7flMbnDvREEeCEQhVHTlJLLrAjoRpXdCaxW/vZmE03E=; b=a9kJPZ/XO1voDGkkjtPtMDzyuVLDTcfyRFRzOLkQIHp88/D4BPDU3EE/mCtWdKE9Zq dXCjAZVy4hCU5IjqxfPyCKxDAagf1hwyNttb4qVzFCZwSdmbh2dK9Ej7k2g9P9BaN0mC AbOctMBs/cNc9O1h+moVoaI/qtBemRTjSiroIJb9rLIVyaSIhwJJpYZKbKZSr7DJg4tv +225YrIo3wgN9KfbyQI8a6KT2eUcTmpjds4bbb7HovwuGPZYP3adx/qDwHQrfE4yo1ua nbVEikHpT1tg4tt84awJS2ac5Mjj9UQETECJqaJ6za4AwtgOY98ZPqo4tRT2ul8DJ6vJ oT8w== X-Gm-Message-State: AIkVDXLL/P9htcPb4iPQigIKMsGGkFHTxu681bClMVU67QENNUfelbZTcmWVviEroiRzCC5hAkN4bc558uMH4g== X-Received: by 10.55.7.2 with SMTP id 2mr6163890qkh.228.1482360470059; Wed, 21 Dec 2016 14:47:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.113 with HTTP; Wed, 21 Dec 2016 14:47:49 -0800 (PST) In-Reply-To: <20161221223038.GB4526@elstar.local> References: <20161221.103208.1910010141581780305.mbj@tail-f.com> <20161221.115438.163227970004322277.mbj@tail-f.com> <20161221223038.GB4526@elstar.local> From: Andy Bierman Date: Wed, 21 Dec 2016 14:47:49 -0800 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a114c877c3f668b054432f1f6 Archived-At: Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 22:47:53 -0000 --001a114c877c3f668b054432f1f6 Content-Type: text/plain; charset=UTF-8 Hi, YANG data is hierarchical. It makes no sense at all the consider the descendant nodes current when the parent is deprecated or obsolete. If the parent goes away then it is impossible to access any descendant nodes, so the default status of 'current' is meaningless in this case. If you augment somebody else's subtree and they decide to deprecate or obsolete it, your data is also deprecated or obsolete. That's how hierarchcal data works. Andy On Wed, Dec 21, 2016 at 2:30 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Dec 21, 2016 at 08:21:08AM -0800, Andy Bierman wrote: > > > > IMO the default should be inherit from parent, like the config-stmt. > > It clutters the YANG module to add a status-stmt to every descendant > node. > > Yes, explicit status statements clutter the module but they make it > very explicit for the reader that stuff is deprecated or obsolete. In > SMIv2, we had explicit status clauses everywhere and I have been a big > fan of making current a default so this does not clutter the > module. But I am also a big fan of making a status != current very > explicit so a reader knows for sure which definitions can be ignored. > (Perhaps it is just me but I often search in RFCs and/or YANG modules > and then having to track back the tree to find out whether something I > hit is deprecated or obsolete is a real burden. (In hindsight, I > probably would have preferred to have config true not inherited but > work like the status statement - having to search along the nesting > structure to find out what something means is actually not that reader > friendly - and bits are cheap these days. And the priority order back > in a day was 'readers first, writers second, tool makers last'.) > > > The status also applies to augment. If /foo is deprecated than any > > external augments that adds nodes under /foo is also deprecated. > > (Most obvious when you change deprecated to obsolete). > > I may disagree with this, in particular for 'deprecated'. Assuming > there are multiple organizations involved, I think we have a problem > if one organization can deprecate augmentations maintained by another > organization. > > Deprecated essentially says 'this will go away, stop using it if you > can'. > > > > container a { > > > status deprecated; > > > container b { > > > status current; > > > } > > > } > > I think this example is actually not complete non-sense. It says 'this > container will go away, stop using it if you can'. There is still > something current under it and this should be fixed. And this is in > particular true for augmentations, e.g., > > augment /a { > container c { > } > } > > should be OK - tools may generate warnings to tell the maintainer of > the augmentation to pay attention to the fact that /a may get retired. > > Now, the IETF may decide that for published modules, something current > in a deprecated container is to be avoided. But this is then a policy > decision, from the language point of view I consider the case of > something current under a deprecated container not a real error. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a114c877c3f668b054432f1f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

YANG data is hierarchical.
It makes no sense at all the consider the descendant nodes current
<= div>when the parent is deprecated or obsolete.=C2=A0 If the parent goes awa= y
then it is impossible to access any descendant nodes, so the
default status of 'current' is meaningless in this case.

If you augment somebody else's subtree and they = decide to deprecate
or obsolete it, your data is also deprecated = or obsolete.
That's how hierarchcal data works.


Andy


On W= ed, Dec 21, 2016 at 2:30 PM, Juergen Schoenwaelder <j.s= choenwaelder@jacobs-university.de> wrote:
On Wed, Dec 21, 2016 at 08:21:08AM -0800, Andy Bierman wrote= :
>
> IMO the default should be inherit from parent, like the config-stmt. > It clutters the YANG module to add a status-stmt to every descendant n= ode.

Yes, explicit status statements clutter the module but they make it
very explicit for the reader that stuff is deprecated or obsolete.=C2=A0 In=
SMIv2, we had explicit status clauses everywhere and I have been a big
fan of making current a default so this does not clutter the
module. But I am also a big fan of making a status !=3D current very
explicit so a reader knows for sure which definitions can be ignored.
(Perhaps it is just me but I often search in RFCs and/or YANG modules
and then having to track back the tree to find out whether something I
hit is deprecated or obsolete is a real burden. (In hindsight, I
probably would have preferred to have config true not inherited but
work like the status statement - having to search along the nesting
structure to find out what something means is actually not that reader
friendly - and bits are cheap these days. And the priority order back
in a day was 'readers first, writers second, tool makers last'.)
> The status also applies to augment.=C2=A0 If /foo is deprecated than a= ny
> external augments that adds nodes under /foo is also deprecated.
> (Most obvious when you change deprecated to obsolete).

I may disagree with this, in particular for 'deprecated'. Assuming<= br> there are multiple organizations involved, I think we have a problem
if one organization can deprecate augmentations maintained by another
organization.

Deprecated essentially says 'this will go away, stop using it if you can'.

> >=C2=A0 =C2=A0container a {
> >=C2=A0 =C2=A0 =C2=A0status deprecated;
> >=C2=A0 =C2=A0 =C2=A0container b {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0status current;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}

I think this example is actually not complete non-sense. It says 'this<= br> container will go away, stop using it if you can'. There is still
something current under it and this should be fixed. And this is in
particular true for augmentations, e.g.,

augment /a {
=C2=A0 container c {
=C2=A0 }
}

should be OK - tools may generate warnings to tell the maintainer of
the augmentation to pay attention to the fact that /a may get retired.

Now, the IETF may decide that for published modules, something current
in a deprecated container is to be avoided. But this is then a policy
decision, from the language point of view I consider the case of
something current under a deprecated container not a real error.

/js

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

--001a114c877c3f668b054432f1f6-- From nobody Wed Dec 21 15:41:42 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CE4129573 for ; Wed, 21 Dec 2016 15:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] 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 PKBXmO2aJru8 for ; Wed, 21 Dec 2016 15:41:39 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E98A612951D for ; Wed, 21 Dec 2016 15:41:38 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BFC22A65; Thu, 22 Dec 2016 00:41:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 2XipRJFi8vdn; Thu, 22 Dec 2016 00:41:34 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 22 Dec 2016 00:41:37 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 610462007A; Thu, 22 Dec 2016 00:41:37 +0100 (CET) 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 Q6yNDVo-ajeq; Thu, 22 Dec 2016 00:41:36 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 22CAA20079; Thu, 22 Dec 2016 00:41:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E120A3DD960C; Thu, 22 Dec 2016 00:41:35 +0100 (CET) Date: Thu, 22 Dec 2016 00:41:35 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20161221234135.GA4630@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <20161221.103208.1910010141581780305.mbj@tail-f.com> <20161221.115438.163227970004322277.mbj@tail-f.com> <20161221223038.GB4526@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 23:41:41 -0000 On Wed, Dec 21, 2016 at 02:47:49PM -0800, Andy Bierman wrote: > Hi, > > YANG data is hierarchical. > It makes no sense at all the consider the descendant nodes current > when the parent is deprecated or obsolete. If the parent goes away > then it is impossible to access any descendant nodes, so the > default status of 'current' is meaningless in this case. > > If you augment somebody else's subtree and they decide to deprecate > or obsolete it, your data is also deprecated or obsolete. > That's how hierarchcal data works. > We disagree, in particular when it comes to deprecated. And as I mentioned in a previous email, the bigger picture is not just about containers and nesting hierarchies. We can deprecate typedefs, groupings, we may deprecate a leaf that is referred to by other leafrefs etc. With your idea that deprecating something means that everything that directly or indirectly refers to this something gets automatically deprecated as well, we may turn 'deprecated' into a pointless tool. In general, it is impossible to determine what all directly or indirectly refers to a certain definition unless you have access to all YANG modules in the world. So how can you ever take a decision to deprecate something if there is no reliable way to assess the impact? Hence, the deprecate status becomes effectively pointless. I rather have an interpretation of deprecated that actually serves a purpose, namely making maintainers of current definitions aware that their current definitions depend on something now deprecated. Perhaps I am blinded by the way @deprecate or __attribute__ ((deprecated)) or [[deprecated]] work in various programming languages. All these annotations do not deprecate my code, they just cause the generation of warnings so that I get aware of the issue and can do my homework. /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 Dec 21 15:55:21 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218ED129573 for ; Wed, 21 Dec 2016 15:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkuqYBJ4DVZk for ; Wed, 21 Dec 2016 15:55:18 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 582CB129516 for ; Wed, 21 Dec 2016 15:55:18 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id c47so220889488qtc.2 for ; Wed, 21 Dec 2016 15:55:18 -0800 (PST) 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=om+9ADc0ivVItIEF0AQN/vz960VfY7WPMVyl5C/ILVM=; b=1wXSSzeIyob5/vhVD5dsFgC+VAjh9f+w8/NgMIg4coHsX0AQRrZOpGKttHpT69OTjg 81oLawmk4Uisr5yBAutNkFqCrQEEBR4Cufx4j7rgms5tHz6btu9esqROHsoK+qSrRJyF Of4/yl5Tz9Gr5ljxhv9hZT0e+/s1W1NOLcWbU6JtbcB2CXphAJ3qL0rcplAYgqcKYU8N QUdux4qqfT/Ncd8wQPp99sbkPuLlFETINOL/65cmf6jEuOL/oUsbPzWwdZrcU9lTqhFe TIWJ1ADG0oLzrdGLDMr277OzT1PON6EBhnWPcaJTqyP0eDWQP3s9ItjCzxdfw0dVkYXw /gdA== 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=om+9ADc0ivVItIEF0AQN/vz960VfY7WPMVyl5C/ILVM=; b=R3hdsBvxh2qH3bfD/aTV2bS/KCFCJuMlsmdm34kiipqvOOfg0uh/NnfgTCGc1XzY5E z4od7gwxcLPFm6SoxfxzyNw+bG/rrp5RThCbvpsNSD8ndB210QcPXXk+iKe/fYY8zLJx 8zHKlOnyR7Q2r6kcDs3p6AWAOcp6iq2Es8EemOx8CCTIPMSukUBGnbubrgoKjr1GjWOU syJbvl0rgHDHF7RY5m5xCEPeYmzup/Y9JNhd6YmXN05N6ocPf31qaPi0X227EKYn3FER nbYrZstEP2+70od3k7jd28vvDvBqCvl5LPxBg3VSsjxKqGzVSXHCWmk94FyOqU8f1VOY 4VfA== X-Gm-Message-State: AIkVDXJfnF8lNhoAwPLy6qECjE4JeEyaigOUZzSCv5x9IAesSgX5QzOv1sN+P1sTaniFK1VolUaCOuPKehlhLg== X-Received: by 10.237.51.167 with SMTP id v36mr7929435qtd.46.1482364517455; Wed, 21 Dec 2016 15:55:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.113 with HTTP; Wed, 21 Dec 2016 15:55:16 -0800 (PST) In-Reply-To: <20161221234135.GA4630@elstar.local> References: <20161221.103208.1910010141581780305.mbj@tail-f.com> <20161221.115438.163227970004322277.mbj@tail-f.com> <20161221223038.GB4526@elstar.local> <20161221234135.GA4630@elstar.local> From: Andy Bierman Date: Wed, 21 Dec 2016 15:55:16 -0800 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1256667e412b054433e2b1 Archived-At: Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 23:55:20 -0000 --94eb2c1256667e412b054433e2b1 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 21, 2016 at 3:41 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Dec 21, 2016 at 02:47:49PM -0800, Andy Bierman wrote: > > Hi, > > > > YANG data is hierarchical. > > It makes no sense at all the consider the descendant nodes current > > when the parent is deprecated or obsolete. If the parent goes away > > then it is impossible to access any descendant nodes, so the > > default status of 'current' is meaningless in this case. > > > > If you augment somebody else's subtree and they decide to deprecate > > or obsolete it, your data is also deprecated or obsolete. > > That's how hierarchcal data works. > > > > We disagree, in particular when it comes to deprecated. And as I > mentioned in a previous email, the bigger picture is not just about > containers and nesting hierarchies. We can deprecate typedefs, > groupings, we may deprecate a leaf that is referred to by other > leafrefs etc. With your idea that deprecating something means that > everything that directly or indirectly refers to this something gets > automatically deprecated as well, we may turn 'deprecated' into a > pointless tool. > > In general, it is impossible to determine what all directly or > indirectly refers to a certain definition unless you have access to > all YANG modules in the world. So how can you ever take a decision to > deprecate something if there is no reliable way to assess the impact? > Hence, the deprecate status becomes effectively pointless. I rather > have an interpretation of deprecated that actually serves a purpose, > namely making maintainers of current definitions aware that their > current definitions depend on something now deprecated. > > Perhaps I am blinded by the way @deprecate or __attribute__ > ((deprecated)) or [[deprecated]] work in various programming > languages. All these annotations do not deprecate my code, they just > cause the generation of warnings so that I get aware of the issue and > can do my homework. > > There are no protocols that let you manage orphaned data nodes without any parent. No way to represent it in XML or JSON either. No way to specify a RESTCONF target resource that leaves out some intermediate data nodes. It seems obvious that the deprecated warning (this node may go away) also applies to all descendant nodes. Once the node is changed from deprecated to obsolete, all the descendant nodes are gone as well, so ignoring the warning because YANG says the default is current seems unwise. /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --94eb2c1256667e412b054433e2b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 21, 2016 at 3:41 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Dec 21, 2016 at 02:47:49PM -0800, Andy Bierm= an wrote:
> Hi,
>
> YANG data is hierarchical.
> It makes no sense at all the consider the descendant nodes current
> when the parent is deprecated or obsolete.=C2=A0 If the parent goes aw= ay
> then it is impossible to access any descendant nodes, so the
> default status of 'current' is meaningless in this case.
>
> If you augment somebody else's subtree and they decide to deprecat= e
> or obsolete it, your data is also deprecated or obsolete.
> That's how hierarchcal data works.
>

We disagree, in particular when it comes to deprecated. And as I
mentioned in a previous email, the bigger picture is not just about
containers and nesting hierarchies. We can deprecate typedefs,
groupings, we may deprecate a leaf that is referred to by other
leafrefs etc. With your idea that deprecating something means that
everything that directly or indirectly refers to this something gets
automatically deprecated as well, we may turn 'deprecated' into a pointless tool.

In general, it is impossible to determine what all directly or
indirectly refers to a certain definition unless you have access to
all YANG modules in the world. So how can you ever take a decision to
deprecate something if there is no reliable way to assess the impact?
Hence, the deprecate status becomes effectively pointless. I rather
have an interpretation of deprecated that actually serves a purpose,
namely making maintainers of current definitions aware that their
current definitions depend on something now deprecated.

Perhaps I am blinded by the way @deprecate or __attribute__
((deprecated)) or [[deprecated]] work in various programming
languages. All these annotations do not deprecate my code, they just
cause the generation of warnings so that I get aware of the issue and
can do my homework.


There are no protocols that let you manage orphaned = data nodes
without any parent.=C2=A0 No way to represent it in XM= L or JSON either.
No way to specify a RESTCONF target resource th= at leaves out
some intermediate data nodes.

<= div>It seems obvious that the deprecated warning (this node may go away)
also applies to all descendant nodes.=C2=A0 Once the node is change= d from
deprecated to obsolete, all the descendant nodes are gone = as well,
so ignoring the warning because YANG says the default is= current seems unwise.



/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<http://www.jacobs-university.de/>

--94eb2c1256667e412b054433e2b1-- From nobody Wed Dec 21 16:13:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F88E129573 for ; Wed, 21 Dec 2016 16:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] 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 woIzheBM_n-9 for ; Wed, 21 Dec 2016 16:13:49 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C98129498 for ; Wed, 21 Dec 2016 16:13:48 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A893D6B3; Thu, 22 Dec 2016 01:13:47 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id M8XKoI9qu9v6; Thu, 22 Dec 2016 01:13:44 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 22 Dec 2016 01:13:47 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A3232007A; Thu, 22 Dec 2016 01:13:47 +0100 (CET) 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 D1obtRM-4fDD; Thu, 22 Dec 2016 01:13:46 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7365420079; Thu, 22 Dec 2016 01:13:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3A5CC3DD9755; Thu, 22 Dec 2016 01:13:46 +0100 (CET) Date: Thu, 22 Dec 2016 01:13:46 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20161222001346.GA4679@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <20161221.103208.1910010141581780305.mbj@tail-f.com> <20161221.115438.163227970004322277.mbj@tail-f.com> <20161221223038.GB4526@elstar.local> <20161221234135.GA4630@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 00:13:50 -0000 On Wed, Dec 21, 2016 at 03:55:16PM -0800, Andy Bierman wrote: > On Wed, Dec 21, 2016 at 3:41 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Wed, Dec 21, 2016 at 02:47:49PM -0800, Andy Bierman wrote: > > > Hi, > > > > > > YANG data is hierarchical. > > > It makes no sense at all the consider the descendant nodes current > > > when the parent is deprecated or obsolete. If the parent goes away > > > then it is impossible to access any descendant nodes, so the > > > default status of 'current' is meaningless in this case. > > > > > > If you augment somebody else's subtree and they decide to deprecate > > > or obsolete it, your data is also deprecated or obsolete. > > > That's how hierarchcal data works. > > > > > > > We disagree, in particular when it comes to deprecated. And as I > > mentioned in a previous email, the bigger picture is not just about > > containers and nesting hierarchies. We can deprecate typedefs, > > groupings, we may deprecate a leaf that is referred to by other > > leafrefs etc. With your idea that deprecating something means that > > everything that directly or indirectly refers to this something gets > > automatically deprecated as well, we may turn 'deprecated' into a > > pointless tool. > > > > In general, it is impossible to determine what all directly or > > indirectly refers to a certain definition unless you have access to > > all YANG modules in the world. So how can you ever take a decision to > > deprecate something if there is no reliable way to assess the impact? > > Hence, the deprecate status becomes effectively pointless. I rather > > have an interpretation of deprecated that actually serves a purpose, > > namely making maintainers of current definitions aware that their > > current definitions depend on something now deprecated. > > > > Perhaps I am blinded by the way @deprecate or __attribute__ > > ((deprecated)) or [[deprecated]] work in various programming > > languages. All these annotations do not deprecate my code, they just > > cause the generation of warnings so that I get aware of the issue and > > can do my homework. > > > > > There are no protocols that let you manage orphaned data nodes > without any parent. No way to represent it in XML or JSON either. > No way to specify a RESTCONF target resource that leaves out > some intermediate data nodes. > > It seems obvious that the deprecated warning (this node may go away) > also applies to all descendant nodes. Once the node is changed from > deprecated to obsolete, all the descendant nodes are gone as well, > so ignoring the warning because YANG says the default is current seems > unwise. I have been writing about 'deprecated'. I can't say it more clearly. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Dec 21 16:15:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF54129498 for ; Wed, 21 Dec 2016 16:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19_BfU99o5D0 for ; Wed, 21 Dec 2016 16:15:53 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 5BABA129477 for ; Wed, 21 Dec 2016 16:15:53 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id p16so218692972qta.0 for ; Wed, 21 Dec 2016 16:15:53 -0800 (PST) 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=zW8m9B4np/UxStjpk3LAEg8/TG8tFQXfPkA5mRjHWVs=; b=cJhk3e5Y0qsV8G02yHoYropGbsSAYOeQ+0DmxzPrEQwxXGyZMuIu9Elu7p+/0IUGzx x8oXPM6Dc/4X8XAvc9NmEISn1/IO6A+7+OQa3CpOq6ZqrgFVs1/KxVFdAmGwf9Gt8cxt YLcjxBYqcbnnVlt9LZmZ5fjtFkNMci5RmwDMjEjW2PJW1MJxP2GvuR0x9wvCTDyEuj3g P3uS5SnGkcAZKfjCx0SvFm6bXPGncSyRzL0K8FySjRg56tSRptA7RDtkOHq8mAZfhZQw /ZijaOYicVW8zG4miFGI4QX3E41xLQDPey5EdzeLMIKjTIDcEqFd7L6FXcgDWWGV6oQ6 1mQA== 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=zW8m9B4np/UxStjpk3LAEg8/TG8tFQXfPkA5mRjHWVs=; b=QYMftOdrQ0mEXKqtBMQpek4cd7AlqV9ntQnrW7lhBVwR/AhzmOXn4SFvVGfiWWEaU4 3VR61mn1FD1TDsD/MryMu0ItmVmbrIHBVXgq2YSin2dPkEnAONoc1j/R5Q6rhLGGtYXq gyQWfXrh8As6GzP24qZmQplw2DfZB/f2aI2NAOHKSwW8zsmoC9Ndc0i29c5XS6mPvPuE FrGaZvUxdqyZZfwzxBE+dboH3JV3sd2pbmHbxSPR/BPpIOQ61mspU26t5HnuZrezN+j9 AH+5SAgDOd3vWo1P5+V1UCH1+RCjydPTLh2OJunRpbA6FeBgxx+n+hxoAO0v8mA7JCCI /XpQ== X-Gm-Message-State: AIkVDXKFQ/U5c1VIhaBc9AywK1EN4oR7GoHHKV3ZHM9B911oT6b2ovPsr8KeVeMgjjJqHwK2WcXKTpf2ctMllQ== X-Received: by 10.237.51.167 with SMTP id v36mr8005495qtd.46.1482365752524; Wed, 21 Dec 2016 16:15:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.113 with HTTP; Wed, 21 Dec 2016 16:15:51 -0800 (PST) In-Reply-To: <20161222001346.GA4679@elstar.local> References: <20161221.103208.1910010141581780305.mbj@tail-f.com> <20161221.115438.163227970004322277.mbj@tail-f.com> <20161221223038.GB4526@elstar.local> <20161221234135.GA4630@elstar.local> <20161222001346.GA4679@elstar.local> From: Andy Bierman Date: Wed, 21 Dec 2016 16:15:51 -0800 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1256661b5e1d0544342c34 Archived-At: Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 00:15:55 -0000 --94eb2c1256661b5e1d0544342c34 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 21, 2016 at 4:13 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Dec 21, 2016 at 03:55:16PM -0800, Andy Bierman wrote: > > On Wed, Dec 21, 2016 at 3:41 PM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Wed, Dec 21, 2016 at 02:47:49PM -0800, Andy Bierman wrote: > > > > Hi, > > > > > > > > YANG data is hierarchical. > > > > It makes no sense at all the consider the descendant nodes current > > > > when the parent is deprecated or obsolete. If the parent goes away > > > > then it is impossible to access any descendant nodes, so the > > > > default status of 'current' is meaningless in this case. > > > > > > > > If you augment somebody else's subtree and they decide to deprecate > > > > or obsolete it, your data is also deprecated or obsolete. > > > > That's how hierarchcal data works. > > > > > > > > > > We disagree, in particular when it comes to deprecated. And as I > > > mentioned in a previous email, the bigger picture is not just about > > > containers and nesting hierarchies. We can deprecate typedefs, > > > groupings, we may deprecate a leaf that is referred to by other > > > leafrefs etc. With your idea that deprecating something means that > > > everything that directly or indirectly refers to this something gets > > > automatically deprecated as well, we may turn 'deprecated' into a > > > pointless tool. > > > > > > In general, it is impossible to determine what all directly or > > > indirectly refers to a certain definition unless you have access to > > > all YANG modules in the world. So how can you ever take a decision to > > > deprecate something if there is no reliable way to assess the impact? > > > Hence, the deprecate status becomes effectively pointless. I rather > > > have an interpretation of deprecated that actually serves a purpose, > > > namely making maintainers of current definitions aware that their > > > current definitions depend on something now deprecated. > > > > > > Perhaps I am blinded by the way @deprecate or __attribute__ > > > ((deprecated)) or [[deprecated]] work in various programming > > > languages. All these annotations do not deprecate my code, they just > > > cause the generation of warnings so that I get aware of the issue and > > > can do my homework. > > > > > > > > There are no protocols that let you manage orphaned data nodes > > without any parent. No way to represent it in XML or JSON either. > > No way to specify a RESTCONF target resource that leaves out > > some intermediate data nodes. > > > > It seems obvious that the deprecated warning (this node may go away) > > also applies to all descendant nodes. Once the node is changed from > > deprecated to obsolete, all the descendant nodes are gone as well, > > so ignoring the warning because YANG says the default is current seems > > unwise. > > I have been writing about 'deprecated'. I can't say it more clearly. > > So have I ... This is hierarchical data. If the parent goes away, so do the child nodes. Seems quite simple to understand. > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --94eb2c1256661b5e1d0544342c34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 21, 2016 at 4:13 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Dec 21, 2016 at 03:55:16PM -0800, Andy Bierm= an wrote:
> On Wed, Dec 21, 2016 at 3:41 PM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > On Wed, Dec 21, 2016 at 02:47:49PM -0800, Andy Bierman wrote:
> > > Hi,
> > >
> > > YANG data is hierarchical.
> > > It makes no sense at all the consider the descendant nodes c= urrent
> > > when the parent is deprecated or obsolete.=C2=A0 If the pare= nt goes away
> > > then it is impossible to access any descendant nodes, so the=
> > > default status of 'current' is meaningless in this c= ase.
> > >
> > > If you augment somebody else's subtree and they decide t= o deprecate
> > > or obsolete it, your data is also deprecated or obsolete. > > > That's how hierarchcal data works.
> > >
> >
> > We disagree, in particular when it comes to deprecated. And as I<= br> > > mentioned in a previous email, the bigger picture is not just abo= ut
> > containers and nesting hierarchies. We can deprecate typedefs, > > groupings, we may deprecate a leaf that is referred to by other > > leafrefs etc. With your idea that deprecating something means tha= t
> > everything that directly or indirectly refers to this something g= ets
> > automatically deprecated as well, we may turn 'deprecated'= ; into a
> > pointless tool.
> >
> > In general, it is impossible to determine what all directly or > > indirectly refers to a certain definition unless you have access = to
> > all YANG modules in the world. So how can you ever take a decisio= n to
> > deprecate something if there is no reliable way to assess the imp= act?
> > Hence, the deprecate status becomes effectively pointless. I rath= er
> > have an interpretation of deprecated that actually serves a purpo= se,
> > namely making maintainers of current definitions aware that their=
> > current definitions depend on something now deprecated.
> >
> > Perhaps I am blinded by the way @deprecate or __attribute__
> > ((deprecated)) or [[deprecated]] work in various programming
> > languages. All these annotations do not deprecate my code, they j= ust
> > cause the generation of warnings so that I get aware of the issue= and
> > can do my homework.
> >
> >
> There are no protocols that let you manage orphaned data nodes
> without any parent.=C2=A0 No way to represent it in XML or JSON either= .
> No way to specify a RESTCONF target resource that leaves out
> some intermediate data nodes.
>
> It seems obvious that the deprecated warning (this node may go away) > also applies to all descendant nodes.=C2=A0 Once the node is changed f= rom
> deprecated to obsolete, all the descendant nodes are gone as well,
> so ignoring the warning because YANG says the default is current seems=
> unwise.

I have been writing about 'deprecated'. I can't say it more cle= arly.


So have I ...
This is hierarchical data.
If the parent goes away, so do the child nodes.
Seems qu= ite simple to understand.

=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<http://www.jacobs-university.de/>

--94eb2c1256661b5e1d0544342c34-- From nobody Wed Dec 21 21:14:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0617212946D for ; Wed, 21 Dec 2016 21:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00eaJzU7xit9 for ; Wed, 21 Dec 2016 21:14:18 -0800 (PST) Received: from mail-pg0-f54.google.com (mail-pg0-f54.google.com [74.125.83.54]) (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 72D4E127A90 for ; Wed, 21 Dec 2016 21:14:18 -0800 (PST) Received: by mail-pg0-f54.google.com with SMTP id g1so54135291pgn.0 for ; Wed, 21 Dec 2016 21:14:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=B/uI0ChFTcPYwenUOWL6w2HlQtg/GTaoGrinlHkkfu8=; b=DY1ZksjKkKwGCohzqediavgQT7+u/CQ/mUVRHA3VovmpI9gqkDm39JQDwHCuROxTKV gUwlZ7JkEi53lGBzJ/kWBV4u0NPOnaK3kswSHU2EYr2qWirGrZgES4CFc+aQIODGNvME 0OgfxTI6moD7GdBm9kI0ipkyhwmSnhfHJkYfxMpRXt1FlHCXwWdJ2CmLunWnx2kttO3w dX9shF8G/6Fsg/vLYYYWK30lbLhdpfioDR48H8/cF4vggONcLKK+Gkx2PRtfsnTIanqp RiIFal7C2J5itVCJ7WR98NFp19A3BVCqmiZsPqC6jXC9VaiYvgmNUhf78Qa1giJWJO1/ TDUQ== X-Gm-Message-State: AIkVDXJc3vDByduV2Bi3IEdtOniav7O61p5SpFuBSYXsYtTK6iqmewk2HRYVhMsdbuKDNfAb X-Received: by 10.84.210.5 with SMTP id z5mr5488519plh.32.1482383657488; Wed, 21 Dec 2016 21:14:17 -0800 (PST) Received: from [192.168.1.114] (c-50-168-48-150.hsd1.ca.comcast.net. [50.168.48.150]) by smtp.gmail.com with ESMTPSA id n8sm29742349pgc.0.2016.12.21.21.14.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Dec 2016 21:14:16 -0800 (PST) To: netmod@ietf.org References: <20161221.140834.1797282783596629756.mbj@tail-f.com> <20161221.155656.206709286026641192.mbj@tail-f.com> From: Randy Presuhn Message-ID: <926b40aa-9d1d-2441-a8fb-4d8e4234a7f3@alumni.stanford.edu> Date: Wed, 21 Dec 2016 21:14:16 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161221.155656.206709286026641192.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] draft-ietf-netmod-entity issue #13 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 05:14:19 -0000 Hi - On 12/21/2016 6:56 AM, Martin Bjorklund wrote: ... > This procedure would change how serial-num currently is handled. I > don't have a strong opinion on this, but I note that serial-num is > writable in the ENTITY-MIB. Maybe someone can comment on why it is > writable in the MIB, and if this is a use case that we want to > support? I *think* this is an example of what were known as "post-it note" objects. Their values could be set by management action to accommodate implementations in which, for example, the hardware provided no way for software to access the information printed on an inventory sticker affixed to a card. Randy From nobody Wed Dec 21 22:22:16 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DCC1294B7 for ; Wed, 21 Dec 2016 22:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmBVoUeiqnx1 for ; Wed, 21 Dec 2016 22:22:13 -0800 (PST) Received: from mail-pf0-f171.google.com (mail-pf0-f171.google.com [209.85.192.171]) (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 97F461294BE for ; Wed, 21 Dec 2016 22:22:13 -0800 (PST) Received: by mail-pf0-f171.google.com with SMTP id d2so38357765pfd.0 for ; Wed, 21 Dec 2016 22:22:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=8bGHi27Uk5krgJxHhsOrFd0eomJw+mfILQhlqHkMbAA=; b=WLZFjBsm/5z3+20OnE2Iw7MuWgOyKx1W/t6kY/V0XVd7HNqUFl13L+9J295XrWLxUg OTQBy2etcngFsJ3XrbJ8QZcYhhTRIVwbcyyEqvQJfhn8nve4Z1FR5uHlAi8gCXyr0v8h rVz3i5xkiEs+4tVLwopFgabKu+KwJa6yRTv8XfET9WrnYj/IvFtQ74XubjKtq8N/ez8z bzcI/jHvTeNyW0z4Y1Tu44INzirYVkL+FNuyW+aD0qb6vAcwI1D3RV7J0fOHOQ3tCE2I Be15Uy0A0hPfdLRpCRz35PHCK9OagFUNXqD6S5ysmxRJxtLkEYanFJd0wSRo3BMy9/40 BOWA== X-Gm-Message-State: AIkVDXI4yMuFNqkG6DR6SavsruExgz7Zc+M7Df2At+DoxI2gB994Yy1JrXPR6BTvCZ89mynq X-Received: by 10.98.68.84 with SMTP id r81mr7471633pfa.174.1482387732783; Wed, 21 Dec 2016 22:22:12 -0800 (PST) Received: from [192.168.1.114] (c-50-168-48-150.hsd1.ca.comcast.net. [50.168.48.150]) by smtp.gmail.com with ESMTPSA id s8sm51255749pfj.45.2016.12.21.22.22.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Dec 2016 22:22:12 -0800 (PST) To: netmod@ietf.org References: <20161221.103208.1910010141581780305.mbj@tail-f.com> <20161221.115438.163227970004322277.mbj@tail-f.com> <20161221223038.GB4526@elstar.local> <20161221234135.GA4630@elstar.local> From: Randy Presuhn Message-ID: <75ad1f98-c927-ba4b-ea35-7197c89c0759@alumni.stanford.edu> Date: Wed, 21 Dec 2016 22:22:11 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 06:22:15 -0000 Hi - On 12/21/2016 3:55 PM, Andy Bierman wrote: > > > On Wed, Dec 21, 2016 at 3:41 PM, Juergen Schoenwaelder > > wrote: ... > Perhaps I am blinded by the way @deprecate or __attribute__ > ((deprecated)) or [[deprecated]] work in various programming > languages. All these annotations do not deprecate my code, they just > cause the generation of warnings so that I get aware of the issue and > can do my homework. > > > There are no protocols that let you manage orphaned data nodes > without any parent. No way to represent it in XML or JSON either. > No way to specify a RESTCONF target resource that leaves out > some intermediate data nodes. Deprecating (or obsoleting) a definition does not orphan data nodes. Perhaps I'm blinded by the way SNMP works, but it seems to me that a robust client will need to be able to process data corresponding to deprecated (or obsolete) definitions. Likewise, developers of server-side software may find themselves in situations where supporting obsolete definitions is a commercial necessity. Things certainly played out that way in the SNMP world. I agree with Juergen that tool-generated warnings seem to be the correct way to go. > It seems obvious that the deprecated warning (this node may go away) > also applies to all descendant nodes. Once the node is changed from > deprecated to obsolete, all the descendant nodes are gone as well, No, they're not *gone*. The *advisability* of implementing them has changed, but the definitions still exist, and implementer judgement is still needed. The change in status only means that a client is less able to rely on the assumption that those definitions will be supported by a given system - but there's very little that it can rely on being implemented anyway, so it doesn't really change much for a robust client. > so ignoring the warning because YANG says the default is current seems > unwise. I do agree with this bit of conclusion, but sometimes after looking at a warning and considering the larger context, ignoring the warning *is* the right thing to do. Randy From nobody Wed Dec 21 23:49:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168CC1294E5 for ; Wed, 21 Dec 2016 23:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 AtVh-13OGvnM for ; Wed, 21 Dec 2016 23:49:48 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF76F1294C3 for ; Wed, 21 Dec 2016 23:49:47 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:2dff:d8c3:f897:773] (unknown [IPv6:2001:718:1a02:1:2dff:d8c3:f897:773]) by mail.nic.cz (Postfix) with ESMTPSA id 5D2E364209; Thu, 22 Dec 2016 08:49:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1482392985; bh=YVWRfTHlw+5gMbu4/hKOyntJCRiesmzxrno3Tcpgrkw=; h=From:Date:To; b=tO0LaAN7OxdTyqwnLLMUB3AUK30CpxQo2sH/ivGt318M320qyVy8Bqh1csD7406kz JUTewOmueWKqv/vkysyWNATrc9WoUGcua1vpb8dd3Urs2xgQNzE4d5n2pYidGJrlfC C4VUtYRJTOmQtra43jGFL4BTQnGENothvW66dS+Y= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <75ad1f98-c927-ba4b-ea35-7197c89c0759@alumni.stanford.edu> Date: Thu, 22 Dec 2016 08:49:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20161221.103208.1910010141581780305.mbj@tail-f.com> <20161221.115438.163227970004322277.mbj@tail-f.com> <20161221223038.GB4526@elstar.local> <20161221234135.GA4630@elstar.local> <75ad1f98-c927-ba4b-ea35-7197c89c0759@alumni.stanford.edu> To: Randy Presuhn X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 07:49:50 -0000 > On 22 Dec 2016, at 07:22, Randy Presuhn = wrote: >=20 > Hi - >=20 > On 12/21/2016 3:55 PM, Andy Bierman wrote: >>=20 >>=20 >> On Wed, Dec 21, 2016 at 3:41 PM, Juergen Schoenwaelder >> > > wrote: > ... >> Perhaps I am blinded by the way @deprecate or __attribute__ >> ((deprecated)) or [[deprecated]] work in various programming >> languages. All these annotations do not deprecate my code, they = just >> cause the generation of warnings so that I get aware of the issue = and >> can do my homework. >>=20 >>=20 >> There are no protocols that let you manage orphaned data nodes >> without any parent. No way to represent it in XML or JSON either. >> No way to specify a RESTCONF target resource that leaves out >> some intermediate data nodes. >=20 > Deprecating (or obsoleting) a definition does not orphan data nodes. > Perhaps I'm blinded by the way SNMP works, but it seems to me that > a robust client will need to be able to process data corresponding > to deprecated (or obsolete) definitions. Likewise, developers > of server-side software may find themselves in situations where > supporting obsolete definitions is a commercial necessity. Things > certainly played out that way in the SNMP world. I agree with Juergen > that tool-generated warnings seem to be the correct way to go. I agree that making a node deprecated or obsolete doesn't mean that its = descendants are orphaned, it just means they cannot be current, and then = "current" shouldn't be the default status for them - also because the = descendants may come from other modules (via groupings and augments) = that cannot be changed. Even if the default status is inherited, tools can still generate = warnings. A data modeller can decide whether and where it makes sense to = have the "status" statement explicitly, but isn't forced to do it = everywhere. Lada >=20 >> It seems obvious that the deprecated warning (this node may go away) >> also applies to all descendant nodes. Once the node is changed from >> deprecated to obsolete, all the descendant nodes are gone as well, >=20 > No, they're not *gone*. The *advisability* of implementing them has > changed, but the definitions still exist, and implementer judgement > is still needed. The change in status only means that a client is > less able to rely on the assumption that those definitions will be > supported by a given system - but there's very little that it can > rely on being implemented anyway, so it doesn't really change much > for a robust client. >=20 >> so ignoring the warning because YANG says the default is current = seems >> unwise. >=20 > I do agree with this bit of conclusion, but sometimes after looking > at a warning and considering the larger context, ignoring the > warning *is* the right thing to do. >=20 > Randy >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Dec 22 02:00:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4E31297C5 for ; Thu, 22 Dec 2016 02:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pow1xLonxNs for ; Thu, 22 Dec 2016 02:00:24 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B849E1297BE for ; Thu, 22 Dec 2016 02:00:23 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id d45so8023278qta.1 for ; Thu, 22 Dec 2016 02:00:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UMbU2tlxd3bsR+sOZNVzbCa1QT2VJ1v0GK8V+8WBKWI=; b=u40BzKuslUMWipbr0Gmv0OotifhREC/wjVxM1OZdnha6yMz1tIPKHDRrreRRZu6FW3 SoFlgBrJtDb2pGD2bJKlL0gJumWArq4HDnMMGFgtjplj0UQN7nFIB0OS0m5/xb5RMXEL zdtJ9rKMoh0xM9X9FrVSbFn6ibwILTG9uYazqFmisVnU55JR4OvMwhGX4F1RM3SMYBzo E4jGxs5RWU+v9IfpbV63vIZJGSeebEW3eJ8GnoEuu45+q1e9NjLAq+ZxKLtJjj2GWrXT Wx43E7AZs44UIycmeTvlLI1Z2WQhk6gHBtGDYqkjbIgk4i7wwwxGMrAf1/SIGPKxPvAb DylA== 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=UMbU2tlxd3bsR+sOZNVzbCa1QT2VJ1v0GK8V+8WBKWI=; b=mnZ9qxkOSO1wuVtrgu8wmV9GH/qmMvDx9Qa37SqA0KQUcfn8NKdDrcMLZ00hbrF+2d k3j5mrJei6rLBWoc0/cHKDSgyUPy1KVLaGb9S7gpJhbWRacV3YR29ERHLpEFucxryovT hO38b/8shkioDFXPJ9gxgCaRwcX3CaOYmYJ2Mks6ULUuodm/XDIm3dd6vhztYd+qr570 GiU9KBYlgxjRsyIsl2ad6g4kCld4UUsgi5aMhyCzR6ionFY4pEXsM7SwD19DLCiUnzUj p+v4gOVIOeYCIdEFvAtn7QNhXTMzEBvsGA7jiMUGdv19HqmZBa9CiB3z6TkchIAE3pqu 85mw== X-Gm-Message-State: AIkVDXL9hUnaLsiLTPbhTgIZG6c6r3S2fHZ0vGH7cB2GYDjyl8wGuRDDtqQ3Q4fmJAbC5CNPU5F2POVcRva5Ew== X-Received: by 10.200.37.52 with SMTP id 49mr8592477qtm.240.1482400822860; Thu, 22 Dec 2016 02:00:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.113 with HTTP; Thu, 22 Dec 2016 02:00:22 -0800 (PST) In-Reply-To: References: <20161221.103208.1910010141581780305.mbj@tail-f.com> <20161221.115438.163227970004322277.mbj@tail-f.com> <20161221223038.GB4526@elstar.local> <20161221234135.GA4630@elstar.local> <75ad1f98-c927-ba4b-ea35-7197c89c0759@alumni.stanford.edu> From: Andy Bierman Date: Thu, 22 Dec 2016 02:00:22 -0800 Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1135b1ec764e3f05443c5601 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 10:00:26 -0000 --001a1135b1ec764e3f05443c5601 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 21, 2016 at 11:49 PM, Ladislav Lhotka wrote: > > > On 22 Dec 2016, at 07:22, Randy Presuhn stanford.edu> wrote: > > > > Hi - > > > > On 12/21/2016 3:55 PM, Andy Bierman wrote: > >> > >> > >> On Wed, Dec 21, 2016 at 3:41 PM, Juergen Schoenwaelder > >> >> > wrote: > > ... > >> Perhaps I am blinded by the way @deprecate or __attribute__ > >> ((deprecated)) or [[deprecated]] work in various programming > >> languages. All these annotations do not deprecate my code, they just > >> cause the generation of warnings so that I get aware of the issue and > >> can do my homework. > >> > >> > >> There are no protocols that let you manage orphaned data nodes > >> without any parent. No way to represent it in XML or JSON either. > >> No way to specify a RESTCONF target resource that leaves out > >> some intermediate data nodes. > > > > Deprecating (or obsoleting) a definition does not orphan data nodes. > > Perhaps I'm blinded by the way SNMP works, but it seems to me that > > a robust client will need to be able to process data corresponding > > to deprecated (or obsolete) definitions. Likewise, developers > > of server-side software may find themselves in situations where > > supporting obsolete definitions is a commercial necessity. Things > > certainly played out that way in the SNMP world. I agree with Juergen > > that tool-generated warnings seem to be the correct way to go. > > I agree that making a node deprecated or obsolete doesn't mean that its > descendants are orphaned, it just means they cannot be current, and then > "current" shouldn't be the default status for them - also because the > descendants may come from other modules (via groupings and augments) that > cannot be changed. > > Even if the default status is inherited, tools can still generate > warnings. A data modeller can decide whether and where it makes sense to > have the "status" statement explicitly, but isn't forced to do it > everywhere. > > NETCONF and RESTCONF have no mechanisms for accessing data other than top-down from the top-level YANG data node to the target node. Removing an ancestor node from the server implementation effectively removes the entire subtree from the implementation. (The value of the YANG status-stmt of the descendant nodes has nothing to do with it) > Lada > Andy > > > > >> It seems obvious that the deprecated warning (this node may go away) > >> also applies to all descendant nodes. Once the node is changed from > >> deprecated to obsolete, all the descendant nodes are gone as well, > > > > No, they're not *gone*. The *advisability* of implementing them has > > changed, but the definitions still exist, and implementer judgement > > is still needed. The change in status only means that a client is > > less able to rely on the assumption that those definitions will be > > supported by a given system - but there's very little that it can > > rely on being implemented anyway, so it doesn't really change much > > for a robust client. > > > >> so ignoring the warning because YANG says the default is current seems > >> unwise. > > > > I do agree with this bit of conclusion, but sometimes after looking > > at a warning and considering the larger context, ignoring the > > warning *is* the right thing to do. > > > > Randy > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1135b1ec764e3f05443c5601 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 21, 2016 at 11:49 PM, Ladislav Lhotka <= ;lhotka@nic.cz> wrote:

> On 22 Dec 2016, at 07:22, Randy Presuhn <randy_presuhn@alumni.stanford.edu> w= rote:
>
> Hi -
>
> On 12/21/2016 3:55 PM, Andy Bierman wrote:
>>
>>
>> On Wed, Dec 21, 2016 at 3:41 PM, Juergen Schoenwaelder
>> <j.scho= enwaelder@jacobs-university.de
>> <mailto:j.schoenwaelder@jacobs-university.de>> wrote:
> ...
>>=C2=A0 =C2=A0 Perhaps I am blinded by the way @deprecate or __attri= bute__
>>=C2=A0 =C2=A0 ((deprecated)) or [[deprecated]] work in various prog= ramming
>>=C2=A0 =C2=A0 languages. All these annotations do not deprecate my = code, they just
>>=C2=A0 =C2=A0 cause the generation of warnings so that I get aware = of the issue and
>>=C2=A0 =C2=A0 can do my homework.
>>
>>
>> There are no protocols that let you manage orphaned data nodes
>> without any parent.=C2=A0 No way to represent it in XML or JSON ei= ther.
>> No way to specify a RESTCONF target resource that leaves out
>> some intermediate data nodes.
>
> Deprecating (or obsoleting) a definition does not orphan data nodes. > Perhaps I'm blinded by the way SNMP works, but it seems to me that=
> a robust client will need to be able to process data corresponding
> to deprecated (or obsolete) definitions.=C2=A0 Likewise, developers > of server-side software may find themselves in situations where
> supporting obsolete definitions is a commercial necessity.=C2=A0 Thing= s
> certainly played out that way in the SNMP world.=C2=A0 I agree with Ju= ergen
> that tool-generated warnings seem to be the correct way to go.

I agree that making a node deprecated or obsolete doesn't mean that its= descendants are orphaned, it just means they cannot be current, and then &= quot;current" shouldn't be the default status for them - also beca= use the descendants may come from other modules (via groupings and augments= ) that cannot be changed.

Even if the default status is inherited, tools can still generate warnings.= A data modeller can decide whether and where it makes sense to have the &q= uot;status" statement explicitly, but isn't forced to do it everyw= here.



NETCONF and RESTCONF ha= ve no mechanisms for accessing data other than
top-down from the = top-level YANG data node to the target node.
Removing an ancestor= node from the server implementation effectively removes
the enti= re subtree from the implementation. =C2=A0(The value of the YANG status-stm= t
of the descendant nodes has nothing to do with it)
=C2=A0
Lada

Andy
=C2=A0

>
>> It seems obvious that the deprecated warning (this node may go awa= y)
>> also applies to all descendant nodes.=C2=A0 Once the node is chang= ed from
>> deprecated to obsolete, all the descendant nodes are gone as well,=
>
> No, they're not *gone*.=C2=A0 The *advisability* of implementing t= hem has
> changed, but the definitions still exist, and implementer judgement > is still needed.=C2=A0 The change in status only means that a client i= s
> less able to rely on the assumption that those definitions will be
> supported by a given system - but there's very little that it can<= br> > rely on being implemented anyway, so it doesn't really change much=
> for a robust client.
>
>> so ignoring the warning because YANG says the default is current s= eems
>> unwise.
>
> I do agree with this bit of conclusion, but sometimes after looking > at a warning and considering the larger context, ignoring the
> warning *is* the right thing to do.
>
> Randy
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





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

--001a1135b1ec764e3f05443c5601-- From nobody Thu Dec 22 02:12:55 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC881296FF for ; Thu, 22 Dec 2016 02:12:54 -0800 (PST) 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 ivHFTULjIfwq for ; Thu, 22 Dec 2016 02:12:53 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 921181294E9 for ; Thu, 22 Dec 2016 02:12:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 7D7C11E5660; Thu, 22 Dec 2016 02:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4-fglNVQ8z4I; Thu, 22 Dec 2016 02:12:37 -0800 (PST) Received: from [192.168.1.127] (host5-81-223-185.range5-81.btcentralplus.com [5.81.223.185]) by c8a.amsl.com (Postfix) with ESMTPSA id C12C91E565D; Thu, 22 Dec 2016 02:12:36 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: William Lupton In-Reply-To: <926b40aa-9d1d-2441-a8fb-4d8e4234a7f3@alumni.stanford.edu> Date: Thu, 22 Dec 2016 10:12:54 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <973C3B10-AA08-460E-A3D2-E43377479DB7@broadband-forum.org> References: <20161221.140834.1797282783596629756.mbj@tail-f.com> <20161221.155656.206709286026641192.mbj@tail-f.com> <926b40aa-9d1d-2441-a8fb-4d8e4234a7f3@alumni.stanford.edu> To: Randy Presuhn X-Mailer: Apple Mail (2.3124) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-entity issue #13 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 10:12:54 -0000 So could =E2=80=9Cbeing writable=E2=80=9D be associated with a feature = (which might potentially apply to multiple such nodes)? W. (and if so, what=E2=80=99s the cleanest way to achieve this? it seems = that =E2=80=9Cif-feature=E2=80=9D can=E2=80=99t be used with = =E2=80=9Cconfig=E2=80=9D but that it could be used by refining a = grouping?) > On 22 Dec 2016, at 05:14, Randy Presuhn = wrote: >=20 > Hi - >=20 > On 12/21/2016 6:56 AM, Martin Bjorklund wrote: > ... >> This procedure would change how serial-num currently is handled. I >> don't have a strong opinion on this, but I note that serial-num is >> writable in the ENTITY-MIB. Maybe someone can comment on why it is >> writable in the MIB, and if this is a use case that we want to >> support? >=20 > I *think* this is an example of what were known as "post-it note" > objects. Their values could be set by management action > to accommodate implementations in which, for example, the hardware > provided no way for software to access the information printed on an > inventory sticker affixed to a card. >=20 > Randy >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From nobody Thu Dec 22 02:16:26 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6701294E9 for ; Thu, 22 Dec 2016 02:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6J_TV8rkhzu for ; Thu, 22 Dec 2016 02:16:23 -0800 (PST) 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 773B3129469 for ; Thu, 22 Dec 2016 02:16:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8951; q=dns/txt; s=iport; t=1482401782; x=1483611382; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=CT9hLnA4OJlfrhCc8fdo6odbGcp5ITCZ1+zawFyJ+sY=; b=QAUbugJTINr1uh1QKGk/sA3j4OtSLRDinnHBck2IegAEr5I2H6ds3MHm +mQnb4Xf4QmDVpZvvFovii6qxguDxx9JL4uWOk6cOwPJVLL9xG18bCnJX VE4rSnoDvqI+2dS0A7M081NtxYlK3Cxi8qegYi42Za9+gRCyXdfdjid2A A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AgBgp1tY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzUBAQEBAYIDjkOVXo9ugxeCD4IJgmyDNgKCKBMBAgEBAQEBAQF?= =?us-ascii?q?iKIRoAQEBAwF5BQsLEAgnB0YRBgEMBgIBAYhgCKtTLopUAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBHYY2gX2CXIQIIoV3BZp3kTmKIoYvij+DZYQPIQE0gQcWDYYPPjS?= =?us-ascii?q?GLIIuAQEB?= X-IronPort-AV: E=Sophos;i="5.33,387,1477958400"; d="scan'208,217";a="648088176" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Dec 2016 10:16:17 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uBMAGHb3028991; Thu, 22 Dec 2016 10:16:17 GMT To: Andy Bierman , Ladislav Lhotka References: <20161221.103208.1910010141581780305.mbj@tail-f.com> <20161221.115438.163227970004322277.mbj@tail-f.com> <20161221223038.GB4526@elstar.local> <20161221234135.GA4630@elstar.local> <75ad1f98-c927-ba4b-ea35-7197c89c0759@alumni.stanford.edu> From: Robert Wilton Message-ID: <8ac64b13-469c-31fe-9d2b-ad0487204d69@cisco.com> Date: Thu, 22 Dec 2016 10:16:17 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DA0915351443F078FEE411DE" Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 10:16:25 -0000 This is a multi-part message in MIME format. --------------DA0915351443F078FEE411DE Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 22/12/2016 10:00, Andy Bierman wrote: > > > On Wed, Dec 21, 2016 at 11:49 PM, Ladislav Lhotka > wrote: > > > > On 22 Dec 2016, at 07:22, Randy Presuhn > > wrote: > > > > Hi - > > > > On 12/21/2016 3:55 PM, Andy Bierman wrote: > >> > >> > >> On Wed, Dec 21, 2016 at 3:41 PM, Juergen Schoenwaelder > >> > >> >> wrote: > > ... > >> Perhaps I am blinded by the way @deprecate or __attribute__ > >> ((deprecated)) or [[deprecated]] work in various programming > >> languages. All these annotations do not deprecate my code, > they just > >> cause the generation of warnings so that I get aware of the > issue and > >> can do my homework. > >> > >> > >> There are no protocols that let you manage orphaned data nodes > >> without any parent. No way to represent it in XML or JSON either. > >> No way to specify a RESTCONF target resource that leaves out > >> some intermediate data nodes. > > > > Deprecating (or obsoleting) a definition does not orphan data nodes. > > Perhaps I'm blinded by the way SNMP works, but it seems to me that > > a robust client will need to be able to process data corresponding > > to deprecated (or obsolete) definitions. Likewise, developers > > of server-side software may find themselves in situations where > > supporting obsolete definitions is a commercial necessity. Things > > certainly played out that way in the SNMP world. I agree with > Juergen > > that tool-generated warnings seem to be the correct way to go. > > I agree that making a node deprecated or obsolete doesn't mean > that its descendants are orphaned, it just means they cannot be > current, and then "current" shouldn't be the default status for > them - also because the descendants may come from other modules > (via groupings and augments) that cannot be changed. > > Even if the default status is inherited, tools can still generate > warnings. A data modeller can decide whether and where it makes > sense to have the "status" statement explicitly, but isn't forced > to do it everywhere. > > > > NETCONF and RESTCONF have no mechanisms for accessing data other than > top-down from the top-level YANG data node to the target node. > Removing an ancestor node from the server implementation effectively > removes > the entire subtree from the implementation. (The value of the YANG > status-stmt > of the descendant nodes has nothing to do with it) I agree that this certainly seems to be the case if a node is marked as obsolete. It seems that it implicitly forces all child nodes to be obsolete as well regardless of which module they were defined in. Rob --------------DA0915351443F078FEE411DE Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 22/12/2016 10:00, Andy Bierman wrote:


On Wed, Dec 21, 2016 at 11:49 PM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> On 22 Dec 2016, at 07:22, Randy Presuhn <randy_presuhn@alumni.stanford.edu> wrote:
>
> Hi -
>
> On 12/21/2016 3:55 PM, Andy Bierman wrote:
>>
>>
>> On Wed, Dec 21, 2016 at 3:41 PM, Juergen Schoenwaelder
>> <j.schoenwaelder@jacobs-university.de
>> <mailto:j.schoenwaelder@jacobs-university.de>> wrote:
> ...
>> Perhaps I am blinded by the way @deprecate or __attribute__
>> ((deprecated)) or [[deprecated]] work in various programming
>> languages. All these annotations do not deprecate my code, they just
>> cause the generation of warnings so that I get aware of the issue and
>> can do my homework.
>>
>>
>> There are no protocols that let you manage orphaned data nodes
>> without any parent. No way to represent it in XML or JSON either.
>> No way to specify a RESTCONF target resource that leaves out
>> some intermediate data nodes.
>
> Deprecating (or obsoleting) a definition does not orphan data nodes.
> Perhaps I'm blinded by the way SNMP works, but it seems to me that
> a robust client will need to be able to process data corresponding
> to deprecated (or obsolete) definitions. Likewise, developers
> of server-side software may find themselves in situations where
> supporting obsolete definitions is a commercial necessity. Things
> certainly played out that way in the SNMP world. I agree with Juergen
> that tool-generated warnings seem to be the correct way to go.

I agree that making a node deprecated or obsolete doesn't mean that its descendants are orphaned, it just means they cannot be current, and then "current" shouldn't be the default status for them - also because the descendants may come from other modules (via groupings and augments) that cannot be changed.

Even if the default status is inherited, tools can still generate warnings. A data modeller can decide whether and where it makes sense to have the "status" statement explicitly, but isn't forced to do it everywhere.



NETCONF and RESTCONF have no mechanisms for accessing data other than
top-down from the top-level YANG data node to the target node.
Removing an ancestor node from the server implementation effectively removes
the entire subtree from the implementation. (The value of the YANG status-stmt
of the descendant nodes has nothing to do with it)

I agree that this certainly seems to be the case if a node is marked as obsolete. It seems that it implicitly forces all child nodes to be obsolete as well regardless of which module they were defined in.

Rob

--------------DA0915351443F078FEE411DE-- From nobody Thu Dec 22 02:22:46 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360051296FF for ; Thu, 22 Dec 2016 02:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 8q-rb_JeTNYF for ; Thu, 22 Dec 2016 02:22:44 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D1B27129469 for ; Thu, 22 Dec 2016 02:22:43 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id B881F1AE028C; Thu, 22 Dec 2016 11:22:42 +0100 (CET) Date: Thu, 22 Dec 2016 11:22:42 +0100 (CET) Message-Id: <20161222.112242.1766522035191268644.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <8ac64b13-469c-31fe-9d2b-ad0487204d69@cisco.com> References: <8ac64b13-469c-31fe-9d2b-ad0487204d69@cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 10:22:45 -0000 Robert Wilton wrote: > > > On 22/12/2016 10:00, Andy Bierman wrote: > > > > > > On Wed, Dec 21, 2016 at 11:49 PM, Ladislav Lhotka > > wrote: > > > > > > > On 22 Dec 2016, at 07:22, Randy Presuhn > > > > wrote: > > > > > > Hi - > > > > > > On 12/21/2016 3:55 PM, Andy Bierman wrote: > > >> > > >> > > >> On Wed, Dec 21, 2016 at 3:41 PM, Juergen Schoenwaelder > > >> > > > >> > >> wrote: > > > ... > > >> Perhaps I am blinded by the way @deprecate or __attribute__ > > >> ((deprecated)) or [[deprecated]] work in various programming > > >> languages. All these annotations do not deprecate my code, > > they just > > >> cause the generation of warnings so that I get aware of the > > issue and > > >> can do my homework. > > >> > > >> > > >> There are no protocols that let you manage orphaned data nodes > > >> without any parent. No way to represent it in XML or JSON either. > > >> No way to specify a RESTCONF target resource that leaves out > > >> some intermediate data nodes. > > > > > > Deprecating (or obsoleting) a definition does not orphan data nodes. > > > Perhaps I'm blinded by the way SNMP works, but it seems to me that > > > a robust client will need to be able to process data corresponding > > > to deprecated (or obsolete) definitions. Likewise, developers > > > of server-side software may find themselves in situations where > > > supporting obsolete definitions is a commercial necessity. Things > > > certainly played out that way in the SNMP world. I agree with > > Juergen > > > that tool-generated warnings seem to be the correct way to go. > > > > I agree that making a node deprecated or obsolete doesn't mean > > that its descendants are orphaned, it just means they cannot be > > current, and then "current" shouldn't be the default status for > > them - also because the descendants may come from other modules > > (via groupings and augments) that cannot be changed. > > > > Even if the default status is inherited, tools can still generate > > warnings. A data modeller can decide whether and where it makes > > sense to have the "status" statement explicitly, but isn't forced > > to do it everywhere. > > > > > > > > NETCONF and RESTCONF have no mechanisms for accessing data other than > > top-down from the top-level YANG data node to the target node. > > Removing an ancestor node from the server implementation effectively > > removes > > the entire subtree from the implementation. (The value of the YANG > > status-stmt > > of the descendant nodes has nothing to do with it) > > I agree that this certainly seems to be the case if a node is marked > as obsolete. It seems that it implicitly forces all child nodes to be > obsolete as well regardless of which module they were defined in. No I don't think this is correct. If module B augment X in module A, and X is obsolete, it does NOT mean that the augmented nodes in B are automatically obsolete. However, in an implementation that doesn't implement X, the augmented nodes from B are obviously also not implemented. /martin From nobody Thu Dec 22 02:40:07 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3858B1297F1 for ; Thu, 22 Dec 2016 02:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNp2EiYkFMhG for ; Thu, 22 Dec 2016 02:40:04 -0800 (PST) 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 36A3912952C for ; Thu, 22 Dec 2016 02:40:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4242; q=dns/txt; s=iport; t=1482403204; x=1483612804; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=6Ag4QVsE9/O6PpNQzJ4zQWBuZLbqiMY0v3SPoDn+lVc=; b=HtaYaIDZn8f7VqJUnqJ2371MOE8zXO8Uzt50q2eYAdp7VcaeqHSpCDFb kb7+BtipaYxLifv8zX0FDHC05JqcrM2erRWaZ6P7Z648klzM0i88QV3N+ cXEMQed0w9DlYN7r/JPm/idJX/X18rTt4oRoTTZBPPwiI79Au/CbKO9YW M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVAgBNrVtY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzUBAQEBAYEqWY5DlV6TBoQYgmyDNgKCKhEBAgEBAQEBAQFiKIR?= =?us-ascii?q?pAQU4QRALDgIIJwdGEQYNBgIBAYhpq0+LAgEBAQEBAQEBAQEBAQEBAQEBASCGS?= =?us-ascii?q?IICCIJZhBMihXcFmnmROoojhi+KQINmhA81IYEHFg2GDz40hjuCLgEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,387,1477958400"; d="scan'208";a="649108830" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Dec 2016 10:39:46 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uBMAdjnl028768; Thu, 22 Dec 2016 10:39:46 GMT To: Martin Bjorklund References: <8ac64b13-469c-31fe-9d2b-ad0487204d69@cisco.com> <20161222.112242.1766522035191268644.mbj@tail-f.com> From: Robert Wilton Message-ID: <8d2df0d5-b662-23a6-8339-1acf5086ae62@cisco.com> Date: Thu, 22 Dec 2016 10:39:45 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161222.112242.1766522035191268644.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 10:40:06 -0000 On 22/12/2016 10:22, Martin Bjorklund wrote: > Robert Wilton wrote: >> >> On 22/12/2016 10:00, Andy Bierman wrote: >>> >>> On Wed, Dec 21, 2016 at 11:49 PM, Ladislav Lhotka >> > wrote: >>> >>> >>> > On 22 Dec 2016, at 07:22, Randy Presuhn >>> >> > wrote: >>> > >>> > Hi - >>> > >>> > On 12/21/2016 3:55 PM, Andy Bierman wrote: >>> >> >>> >> >>> >> On Wed, Dec 21, 2016 at 3:41 PM, Juergen Schoenwaelder >>> >> >> >>> >> >> >> wrote: >>> > ... >>> >> Perhaps I am blinded by the way @deprecate or __attribute__ >>> >> ((deprecated)) or [[deprecated]] work in various programming >>> >> languages. All these annotations do not deprecate my code, >>> they just >>> >> cause the generation of warnings so that I get aware of the >>> issue and >>> >> can do my homework. >>> >> >>> >> >>> >> There are no protocols that let you manage orphaned data nodes >>> >> without any parent. No way to represent it in XML or JSON either. >>> >> No way to specify a RESTCONF target resource that leaves out >>> >> some intermediate data nodes. >>> > >>> > Deprecating (or obsoleting) a definition does not orphan data nodes. >>> > Perhaps I'm blinded by the way SNMP works, but it seems to me that >>> > a robust client will need to be able to process data corresponding >>> > to deprecated (or obsolete) definitions. Likewise, developers >>> > of server-side software may find themselves in situations where >>> > supporting obsolete definitions is a commercial necessity. Things >>> > certainly played out that way in the SNMP world. I agree with >>> Juergen >>> > that tool-generated warnings seem to be the correct way to go. >>> >>> I agree that making a node deprecated or obsolete doesn't mean >>> that its descendants are orphaned, it just means they cannot be >>> current, and then "current" shouldn't be the default status for >>> them - also because the descendants may come from other modules >>> (via groupings and augments) that cannot be changed. >>> >>> Even if the default status is inherited, tools can still generate >>> warnings. A data modeller can decide whether and where it makes >>> sense to have the "status" statement explicitly, but isn't forced >>> to do it everywhere. >>> >>> >>> >>> NETCONF and RESTCONF have no mechanisms for accessing data other than >>> top-down from the top-level YANG data node to the target node. >>> Removing an ancestor node from the server implementation effectively >>> removes >>> the entire subtree from the implementation. (The value of the YANG >>> status-stmt >>> of the descendant nodes has nothing to do with it) >> I agree that this certainly seems to be the case if a node is marked >> as obsolete. It seems that it implicitly forces all child nodes to be >> obsolete as well regardless of which module they were defined in. > No I don't think this is correct. If module B augment X in module A, > and X is obsolete, it does NOT mean that the augmented nodes in B are > automatically obsolete. However, in an implementation that doesn't > implement X, the augmented nodes from B are obviously also not > implemented. I can get where you are coming from, but if you had a GUI viewer that was looking at the combined schema tree, I think that you would to see those descendant children nodes marked in some way to indicate that implementations may validly not return them. Reporting them as current when one of their parent nodes was obsolete would seem to be deceptive. Is it that you are trying to differentiate between being explicitly obsolete vs 'implicitly obsolete' through parentage? Rob > > > /martin > . > From nobody Thu Dec 22 02:41:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A93312952C for ; Thu, 22 Dec 2016 02:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 rXH65821NnhZ for ; Thu, 22 Dec 2016 02:41:35 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C2C511297F7 for ; Thu, 22 Dec 2016 02:41:35 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 04F4F1AE028C; Thu, 22 Dec 2016 11:41:35 +0100 (CET) Date: Thu, 22 Dec 2016 11:41:34 +0100 (CET) Message-Id: <20161222.114134.1191298617406397998.mbj@tail-f.com> To: wlupton@broadband-forum.org From: Martin Bjorklund In-Reply-To: <973C3B10-AA08-460E-A3D2-E43377479DB7@broadband-forum.org> References: <20161221.155656.206709286026641192.mbj@tail-f.com> <926b40aa-9d1d-2441-a8fb-4d8e4234a7f3@alumni.stanford.edu> <973C3B10-AA08-460E-A3D2-E43377479DB7@broadband-forum.org> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-entity issue #13 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 10:41:37 -0000 V2lsbGlhbSBMdXB0b24gPHdsdXB0b25AYnJvYWRiYW5kLWZvcnVtLm9yZz4gd3JvdGU6DQo+IFNv IGNvdWxkIOKAnGJlaW5nIHdyaXRhYmxl4oCdIGJlIGFzc29jaWF0ZWQgd2l0aCBhIGZlYXR1cmUg KHdoaWNoIG1pZ2h0DQo+IHBvdGVudGlhbGx5IGFwcGx5IHRvIG11bHRpcGxlIHN1Y2ggbm9kZXMp PyBXLg0KDQpXZSBjYW4gcHV0IGEgaWYtZmVhdHVyZSBzdGF0ZW1lbnQgb24gdGhlIG5vZGUgJ21m Zy1uYW1lJyBpbiB0aGUgY29uZmlnDQp0cmVlLCBidXQgbm90IGluIHRoZSBzdGF0ZSB0cmVlLg0K DQpCdXQgdGhlIGlzc3VlIGlzIHRoYXQgdGhlcmUgYXJlIHR3byBjb25mbGljdGluZyB1c2UgY2Fz ZXM6DQoNCiAgMSkgIHVzZSB0aGUgd3JpdGFibGUgbm9kZXMgZm9yIHZhbGlkYXRpb24gd2l0aCB0 aGUgcmVhbCBodw0KICAyKSAgdXNlIHRoZSB3cml0YWJsZSBub2RlcyBhcyBhICJwb3N0LWl0IiBm dW5jdGlvbg0KDQpDdXJyZW50bHkgdGhlIG9ubHkgc3VjaCBub2RlIGlzICdzZXJpYWwtbnVtJywg YW5kIGl0IGlzIHVzZWQgYXMgKDIpLg0KDQpCdXQgbWF5YmUgd2UgY2FuIGFjdHVhbGx5IGNvbWJp bmUgdGhlc2UgdHdvIGNhc2VzLg0KDQogIElmIHRoZSBub2RlIGhhcyBhIHZhbHVlIGluIHRoZSBj b25maWcsIGFuZCB0aGUgc3lzdGVtIGNhbiBkZXRlY3QgdGhlDQogIHJlYWwgdmFsdWUgZnJvbSB0 aGUgaGFyZHdhcmUsIHRoZW4gdGhleSBNVVNUIGJlIGVxdWFsLCBvdGhlcndpc2UgdGhlDQogIGNv bmZpZyBpcyBub3QgYXBwbGllZC4gKGNhc2UgKDEpIGFib3ZlKQ0KDQogIElmIHRoZSBub2RlIGhh cyBhIHZhbHVlIGluIHRoZSBjb25maWcsIGFuZCB0aGUgc3lzdGVtIGNhbm5vdCBkZXRlY3QNCiAg dGhlIHJlYWwgdmFsdWUgZnJvbSB0aGUgaGFyZHdhcmUsIHRoZSBjb25maWcgaXMgYXBwbGllZCBh bmQgdGhlDQogIHN0YXRlIHZhbHVlIHdpbGwgYmUgdGhlIGNvbmZpZyB2YWx1ZS4gKGNhc2UgKDIp IGFib3ZlKQ0KDQpNYXliZSB0aGlzIHZpb2xhdGVzIHRoZSBwcmluY2lwbGUgb2YgbGVhc3QgYXN0 b25pc2htZW50IHRob3VnaC4uLg0KDQoNCi9tYXJ0aW4NCg0KDQo+IA0KPiAoYW5kIGlmIHNvLCB3 aGF04oCZcyB0aGUgY2xlYW5lc3Qgd2F5IHRvIGFjaGlldmUgdGhpcz8gaXQgc2VlbXMgdGhhdA0K PiDigJxpZi1mZWF0dXJl4oCdIGNhbuKAmXQgYmUgdXNlZCB3aXRoIOKAnGNvbmZpZ+KAnSBidXQg dGhhdCBpdCBjb3VsZCBiZSB1c2VkIGJ5DQo+IHJlZmluaW5nIGEgZ3JvdXBpbmc/KQ0KPiANCj4g PiBPbiAyMiBEZWMgMjAxNiwgYXQgMDU6MTQsIFJhbmR5IFByZXN1aG4NCj4gPiA8cmFuZHlfcHJl c3VobkBhbHVtbmkuc3RhbmZvcmQuZWR1PiB3cm90ZToNCj4gPiANCj4gPiBIaSAtDQo+ID4gDQo+ ID4gT24gMTIvMjEvMjAxNiA2OjU2IEFNLCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KPiA+IC4u Lg0KPiA+PiBUaGlzIHByb2NlZHVyZSB3b3VsZCBjaGFuZ2UgaG93IHNlcmlhbC1udW0gY3VycmVu dGx5IGlzIGhhbmRsZWQuICBJDQo+ID4+IGRvbid0IGhhdmUgYSBzdHJvbmcgb3BpbmlvbiBvbiB0 aGlzLCBidXQgSSBub3RlIHRoYXQgc2VyaWFsLW51bSBpcw0KPiA+PiB3cml0YWJsZSBpbiB0aGUg RU5USVRZLU1JQi4gIE1heWJlIHNvbWVvbmUgY2FuIGNvbW1lbnQgb24gd2h5IGl0IGlzDQo+ID4+ IHdyaXRhYmxlIGluIHRoZSBNSUIsIGFuZCBpZiB0aGlzIGlzIGEgdXNlIGNhc2UgdGhhdCB3ZSB3 YW50IHRvDQo+ID4+IHN1cHBvcnQ/DQo+ID4gDQo+ID4gSSAqdGhpbmsqIHRoaXMgaXMgYW4gZXhh bXBsZSBvZiB3aGF0IHdlcmUga25vd24gYXMgInBvc3QtaXQgbm90ZSINCj4gPiBvYmplY3RzLiAg VGhlaXIgdmFsdWVzIGNvdWxkIGJlIHNldCBieSBtYW5hZ2VtZW50IGFjdGlvbg0KPiA+IHRvIGFj Y29tbW9kYXRlIGltcGxlbWVudGF0aW9ucyBpbiB3aGljaCwgZm9yIGV4YW1wbGUsIHRoZSBoYXJk d2FyZQ0KPiA+IHByb3ZpZGVkIG5vIHdheSBmb3Igc29mdHdhcmUgdG8gYWNjZXNzIHRoZSBpbmZv cm1hdGlvbiBwcmludGVkIG9uIGFuDQo+ID4gaW52ZW50b3J5IHN0aWNrZXIgYWZmaXhlZCB0byBh IGNhcmQuDQo+ID4gDQo+ID4gUmFuZHkNCj4gPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiBu ZXRtb2RAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldG1vZA0KPiA+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== From nobody Thu Dec 22 02:49:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E32B129842 for ; Thu, 22 Dec 2016 02:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 Y2u8YCM0TCL7 for ; Thu, 22 Dec 2016 02:49:41 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 455EF1297F7 for ; Thu, 22 Dec 2016 02:49:41 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 7FEF31AE028C; Thu, 22 Dec 2016 11:49:40 +0100 (CET) Date: Thu, 22 Dec 2016 11:49:40 +0100 (CET) Message-Id: <20161222.114940.1495001277375813904.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <8d2df0d5-b662-23a6-8339-1acf5086ae62@cisco.com> References: <8ac64b13-469c-31fe-9d2b-ad0487204d69@cisco.com> <20161222.112242.1766522035191268644.mbj@tail-f.com> <8d2df0d5-b662-23a6-8339-1acf5086ae62@cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 10:49:42 -0000 Robert Wilton wrote: > > > On 22/12/2016 10:22, Martin Bjorklund wrote: > > Robert Wilton wrote: > >> > >> On 22/12/2016 10:00, Andy Bierman wrote: > >>> > >>> On Wed, Dec 21, 2016 at 11:49 PM, Ladislav Lhotka >>> > wrote: > >>> > >>> > >>> > On 22 Dec 2016, at 07:22, Randy Presuhn > >>> >>> > wrote: > >>> > > >>> > Hi - > >>> > > >>> > On 12/21/2016 3:55 PM, Andy Bierman wrote: > >>> >> > >>> >> > >>> >> On Wed, Dec 21, 2016 at 3:41 PM, Juergen Schoenwaelder > >>> >> >>> > >>> >> >>> >> wrote: > >>> > ... > >>> >> Perhaps I am blinded by the way @deprecate or __attribute__ > >>> >> ((deprecated)) or [[deprecated]] work in various programming > >>> >> languages. All these annotations do not deprecate my code, > >>> they just > >>> >> cause the generation of warnings so that I get aware of the > >>> issue and > >>> >> can do my homework. > >>> >> > >>> >> > >>> >> There are no protocols that let you manage orphaned data nodes > >>> >> without any parent. No way to represent it in XML or JSON either. > >>> >> No way to specify a RESTCONF target resource that leaves out > >>> >> some intermediate data nodes. > >>> > > >>> > Deprecating (or obsoleting) a definition does not orphan data nodes. > >>> > Perhaps I'm blinded by the way SNMP works, but it seems to me that > >>> > a robust client will need to be able to process data corresponding > >>> > to deprecated (or obsolete) definitions. Likewise, developers > >>> > of server-side software may find themselves in situations where > >>> > supporting obsolete definitions is a commercial necessity. Things > >>> > certainly played out that way in the SNMP world. I agree with > >>> Juergen > >>> > that tool-generated warnings seem to be the correct way to go. > >>> > >>> I agree that making a node deprecated or obsolete doesn't mean > >>> that its descendants are orphaned, it just means they cannot be > >>> current, and then "current" shouldn't be the default status for > >>> them - also because the descendants may come from other modules > >>> (via groupings and augments) that cannot be changed. > >>> > >>> Even if the default status is inherited, tools can still generate > >>> warnings. A data modeller can decide whether and where it makes > >>> sense to have the "status" statement explicitly, but isn't forced > >>> to do it everywhere. > >>> > >>> > >>> > >>> NETCONF and RESTCONF have no mechanisms for accessing data other than > >>> top-down from the top-level YANG data node to the target node. > >>> Removing an ancestor node from the server implementation effectively > >>> removes > >>> the entire subtree from the implementation. (The value of the YANG > >>> status-stmt > >>> of the descendant nodes has nothing to do with it) > >> I agree that this certainly seems to be the case if a node is marked > >> as obsolete. It seems that it implicitly forces all child nodes to be > >> obsolete as well regardless of which module they were defined in. > > No I don't think this is correct. If module B augment X in module A, > > and X is obsolete, it does NOT mean that the augmented nodes in B are > > automatically obsolete. However, in an implementation that doesn't > > implement X, the augmented nodes from B are obviously also not > > implemented. > I can get where you are coming from, but if you had a GUI viewer that > was looking at the combined schema tree, I think that you would to see > those descendant children nodes marked in some way to indicate that > implementations may validly not return them. Reporting them as current > when one of their parent nodes was obsolete would seem to be > deceptive. > > Is it that you are trying to differentiate between being explicitly > obsolete vs 'implicitly obsolete' through parentage? I think that within a module, if a parent is obsolete, then all its child should also be obsolete (*). But I do think that the status should be explicitly stated. But marking definition as obsolete in one module cannot automatically make definitions in *other* modules obsolete. (*) _maybe_ 7950 can be interpreted in this way when it says: If a definition is "current", it MUST NOT reference a "deprecated" or "obsolete" definition within the same module If you're in a good mood, you could argue that a child always "references" its parent. /martin From nobody Thu Dec 22 02:53:53 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4465129622 for ; Thu, 22 Dec 2016 02:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 28hJrqc0WUVN for ; Thu, 22 Dec 2016 02:53:50 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 504D8129471 for ; Thu, 22 Dec 2016 02:53:49 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:2dff:d8c3:f897:773] (unknown [IPv6:2001:718:1a02:1:2dff:d8c3:f897:773]) by mail.nic.cz (Postfix) with ESMTPSA id 6C9F262451; Thu, 22 Dec 2016 11:53:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1482404028; bh=DoLoDZGcZaLQ8y6Iejy+xUDwPJScZEqOAitmwP6Drr4=; h=From:Date:To; b=lxHm39BaD7njPvKvfd29jXBEe1GjZC7IilrppvtbrbYGINS2Vl1ix6MX37c0KihAq 9wco8OoywrBxTJL1+S+JldvQ5ZMpEhZjI2+0U/pNKG/xhipcovDgIyPi3+iU7fcIl6 lneYprZ0Z9mCAT2IeKi1GQ/Gzk4GR0EV4ZRB6bzs= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 22 Dec 2016 11:53:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20161221.103208.1910010141581780305.mbj@tail-f.com> <20161221.115438.163227970004322277.mbj@tail-f.com> <20161221223038.GB4526@elstar.local> <20161221234135.GA4630@elstar.local> <75ad1f98-c927-ba4b-ea35-7197c89c0759@alumni.stanford.edu> To: Andy Bierman X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 10:53:52 -0000 > On 22 Dec 2016, at 11:00, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, Dec 21, 2016 at 11:49 PM, Ladislav Lhotka = wrote: >=20 > > On 22 Dec 2016, at 07:22, Randy Presuhn = wrote: > > > > Hi - > > > > On 12/21/2016 3:55 PM, Andy Bierman wrote: > >> > >> > >> On Wed, Dec 21, 2016 at 3:41 PM, Juergen Schoenwaelder > >> >> > wrote: > > ... > >> Perhaps I am blinded by the way @deprecate or __attribute__ > >> ((deprecated)) or [[deprecated]] work in various programming > >> languages. All these annotations do not deprecate my code, they = just > >> cause the generation of warnings so that I get aware of the = issue and > >> can do my homework. > >> > >> > >> There are no protocols that let you manage orphaned data nodes > >> without any parent. No way to represent it in XML or JSON either. > >> No way to specify a RESTCONF target resource that leaves out > >> some intermediate data nodes. > > > > Deprecating (or obsoleting) a definition does not orphan data nodes. > > Perhaps I'm blinded by the way SNMP works, but it seems to me that > > a robust client will need to be able to process data corresponding > > to deprecated (or obsolete) definitions. Likewise, developers > > of server-side software may find themselves in situations where > > supporting obsolete definitions is a commercial necessity. Things > > certainly played out that way in the SNMP world. I agree with = Juergen > > that tool-generated warnings seem to be the correct way to go. >=20 > I agree that making a node deprecated or obsolete doesn't mean that = its descendants are orphaned, it just means they cannot be current, and = then "current" shouldn't be the default status for them - also because = the descendants may come from other modules (via groupings and augments) = that cannot be changed. >=20 > Even if the default status is inherited, tools can still generate = warnings. A data modeller can decide whether and where it makes sense to = have the "status" statement explicitly, but isn't forced to do it = everywhere. >=20 >=20 >=20 > NETCONF and RESTCONF have no mechanisms for accessing data other than > top-down from the top-level YANG data node to the target node. > Removing an ancestor node from the server implementation effectively = removes > the entire subtree from the implementation. (The value of the YANG = status-stmt > of the descendant nodes has nothing to do with it) Expected server/protocol behaviour for nodes of a given status is = specified in sec. 7.21.2 and IMO it is a different issue. What may need = to be clarified wrt YANG is how to figure out the status of each node = from the data model. In particular, - what ancestor/descendant combinations of statuses are permitted - what is the default if "status" statement is omitted. Lada >=20 > =20 > Lada >=20 > Andy > =20 >=20 > > > >> It seems obvious that the deprecated warning (this node may go = away) > >> also applies to all descendant nodes. Once the node is changed = from > >> deprecated to obsolete, all the descendant nodes are gone as well, > > > > No, they're not *gone*. The *advisability* of implementing them has > > changed, but the definitions still exist, and implementer judgement > > is still needed. The change in status only means that a client is > > less able to rely on the assumption that those definitions will be > > supported by a given system - but there's very little that it can > > rely on being implemented anyway, so it doesn't really change much > > for a robust client. > > > >> so ignoring the warning because YANG says the default is current = seems > >> unwise. > > > > I do agree with this bit of conclusion, but sometimes after looking > > at a warning and considering the larger context, ignoring the > > warning *is* the right thing to do. > > > > Randy > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Dec 22 03:24:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2BF1294D8 for ; Thu, 22 Dec 2016 03:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXUlZE3SzK-3 for ; Thu, 22 Dec 2016 03:24:34 -0800 (PST) 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 7876D129412 for ; Thu, 22 Dec 2016 03:24:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6125; q=dns/txt; s=iport; t=1482405873; x=1483615473; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=2x4+VydjDStCTS/bgpDPT7qi334qCU45uYRy505CLTI=; b=f6NQDtkMXt9dlKBeHcvIgNOCkDorAYCIWKpNc5qRZPmXpf67aByFc8iI gPpfhUj7SqlMXbHnmoHL+70Vp2IgU8sGeanLQHuZ+f2IDUW1XKPZSafLT SeKCZlGxdOfaiksX++gyEL9Jk4AxQDNaoSi4n0JCP7uB7n43u5Heq0yxm A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVAgDOtltY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzUBAQEBAYEqWY5DlV6TBoQYgmyDNgKCKhEBAgEBAQEBAQFiKIR?= =?us-ascii?q?oAQEBAwE4QRALDgIIJwdGEQYNBgIBAYhhCKtOiwMBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEghkiCAoJhhBMihXcFmnmROoojhi+KQINmhA81IYEHFg2GDz40hjuCLgEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,388,1477958400"; d="scan'208";a="690653855" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Dec 2016 11:24:31 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uBMBOVxX021348; Thu, 22 Dec 2016 11:24:31 GMT To: Martin Bjorklund References: <8ac64b13-469c-31fe-9d2b-ad0487204d69@cisco.com> <20161222.112242.1766522035191268644.mbj@tail-f.com> <8d2df0d5-b662-23a6-8339-1acf5086ae62@cisco.com> <20161222.114940.1495001277375813904.mbj@tail-f.com> From: Robert Wilton Message-ID: <5ab58f5f-25d4-5cf9-f46c-c144da8e5597@cisco.com> Date: Thu, 22 Dec 2016 11:24:31 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161222.114940.1495001277375813904.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 11:24:40 -0000 On 22/12/2016 10:49, Martin Bjorklund wrote: > Robert Wilton wrote: >> >> On 22/12/2016 10:22, Martin Bjorklund wrote: >>> Robert Wilton wrote: >>>> On 22/12/2016 10:00, Andy Bierman wrote: >>>>> On Wed, Dec 21, 2016 at 11:49 PM, Ladislav Lhotka >>>> > wrote: >>>>> >>>>> >>>>> > On 22 Dec 2016, at 07:22, Randy Presuhn >>>>> >>>> > wrote: >>>>> > >>>>> > Hi - >>>>> > >>>>> > On 12/21/2016 3:55 PM, Andy Bierman wrote: >>>>> >> >>>>> >> >>>>> >> On Wed, Dec 21, 2016 at 3:41 PM, Juergen Schoenwaelder >>>>> >> >>>> >>>>> >> >>>> >> wrote: >>>>> > ... >>>>> >> Perhaps I am blinded by the way @deprecate or __attribute__ >>>>> >> ((deprecated)) or [[deprecated]] work in various programming >>>>> >> languages. All these annotations do not deprecate my code, >>>>> they just >>>>> >> cause the generation of warnings so that I get aware of the >>>>> issue and >>>>> >> can do my homework. >>>>> >> >>>>> >> >>>>> >> There are no protocols that let you manage orphaned data nodes >>>>> >> without any parent. No way to represent it in XML or JSON either. >>>>> >> No way to specify a RESTCONF target resource that leaves out >>>>> >> some intermediate data nodes. >>>>> > >>>>> > Deprecating (or obsoleting) a definition does not orphan data nodes. >>>>> > Perhaps I'm blinded by the way SNMP works, but it seems to me that >>>>> > a robust client will need to be able to process data corresponding >>>>> > to deprecated (or obsolete) definitions. Likewise, developers >>>>> > of server-side software may find themselves in situations where >>>>> > supporting obsolete definitions is a commercial necessity. Things >>>>> > certainly played out that way in the SNMP world. I agree with >>>>> Juergen >>>>> > that tool-generated warnings seem to be the correct way to go. >>>>> >>>>> I agree that making a node deprecated or obsolete doesn't mean >>>>> that its descendants are orphaned, it just means they cannot be >>>>> current, and then "current" shouldn't be the default status for >>>>> them - also because the descendants may come from other modules >>>>> (via groupings and augments) that cannot be changed. >>>>> >>>>> Even if the default status is inherited, tools can still generate >>>>> warnings. A data modeller can decide whether and where it makes >>>>> sense to have the "status" statement explicitly, but isn't forced >>>>> to do it everywhere. >>>>> >>>>> >>>>> >>>>> NETCONF and RESTCONF have no mechanisms for accessing data other than >>>>> top-down from the top-level YANG data node to the target node. >>>>> Removing an ancestor node from the server implementation effectively >>>>> removes >>>>> the entire subtree from the implementation. (The value of the YANG >>>>> status-stmt >>>>> of the descendant nodes has nothing to do with it) >>>> I agree that this certainly seems to be the case if a node is marked >>>> as obsolete. It seems that it implicitly forces all child nodes to be >>>> obsolete as well regardless of which module they were defined in. >>> No I don't think this is correct. If module B augment X in module A, >>> and X is obsolete, it does NOT mean that the augmented nodes in B are >>> automatically obsolete. However, in an implementation that doesn't >>> implement X, the augmented nodes from B are obviously also not >>> implemented. >> I can get where you are coming from, but if you had a GUI viewer that >> was looking at the combined schema tree, I think that you would to see >> those descendant children nodes marked in some way to indicate that >> implementations may validly not return them. Reporting them as current >> when one of their parent nodes was obsolete would seem to be >> deceptive. >> >> Is it that you are trying to differentiate between being explicitly >> obsolete vs 'implicitly obsolete' through parentage? > I think that within a module, if a parent is obsolete, then all its > child should also be obsolete (*). But I do think that the status > should be explicitly stated. OK. I assume that this statement applies to deprecated as well. I don't feel particularly strongly on this point. If you mark something as obsolete/deprecated, then explicitly having to find and mark all references/children doesn't seem like a bad thing because it makes the full impact obvious (if pyang is enhanced to check for this). > > But marking definition as obsolete in one module cannot automatically > make definitions in *other* modules obsolete. I'm not so sure. It seems to me that in practice, they are directly equivalent as if they were marked as obsolete. I.e. clients cannot rely on them being available because the obsolete parent may not be implemented. If the augmenting module wants to keep those nodes, then their only choice seems to be to explicitly mark them as obsolete, and make a copy of the nodes augmenting somewhere else in the schema tree. > > (*) _maybe_ 7950 can be interpreted in this way when it says: > > If a definition is "current", it MUST NOT reference a "deprecated" or > "obsolete" definition within the same module > > If you're in a good mood, you could argue that a child always > "references" its parent. Would it not be better to add some sort of explicit statement as an errata to 7950 (once there is agreement on what it should say)? Or is this beyond the scope of what an errata is allowed to do? Rob > > > /martin > . > From nobody Thu Dec 22 06:23:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE3E1293E9; Thu, 22 Dec 2016 06:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BCZ6Yw93CxY; Thu, 22 Dec 2016 06:23:24 -0800 (PST) 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 D88771200A0; Thu, 22 Dec 2016 06:23:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3346; q=dns/txt; s=iport; t=1482416604; x=1483626204; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=azh0UclMBl+il73f2O1SFHhM6dH5r3puqQVAcnIpWd0=; b=je8goSHg1gqiQvrwUkJCfuBaAJeDuWDlLJMRsIR5nmv01H6avqRZaBRZ KisqwR3GkgxF8j26lPcVBf/HpDmKlmFpPJ6mZn+/gEzLd6Wg6XQ1prj8R MHR9U1SALkrtmLHOmDo7TSTbvFNjUfKzGIqaW8u88W5hpRkU9dRL+Unmh A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AAAZ4VtY/xbLJq1YBhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM1AQEBAQF7L1mNUXKVYJUVggkCHQuFLkoCgisUAQIBAQEBAQE?= =?us-ascii?q?BYiiEaAEBAQMBAQE2NgsQCxEEAQEBLicoCAYBDAYCAQGIYQgOqBcBg1SLBQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFMoYWggKCYYQdEQECBAiFbwWaeYlkh1aBdYU?= =?us-ascii?q?HgyeGL4pAg2aEDx83aB8WDS6FYT40hjuCLgEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,388,1477958400"; d="scan'208";a="690662421" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Dec 2016 14:23:21 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uBMENLLT011121; Thu, 22 Dec 2016 14:23:21 GMT To: Alex Campbell , Lou Berger , NetMod WG References: <1482278935303.24094@Aviatnet.com> From: Robert Wilton Message-ID: Date: Thu, 22 Dec 2016 14:23:21 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1482278935303.24094@Aviatnet.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: NetMod WG Chairs Subject: Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 14:23:25 -0000 Hi Alex, Thanks for the support and comments. Please see inline ... On 21/12/2016 00:08, Alex Campbell wrote: > Yes/support > > The main issue I have with this draft, that I would like to be addressed at some point, is the way it uses heavily restricted lists to model sequences of VLAN tags. > It seems to me that something like the following would be much simpler, without losing any expressive power, in most cases: > > container tags { > leaf s-vlan { > type dot1q:dot1q-vlan-id; > } > leaf c-vlan { > type dot1q:dot1q-vlan-id; > } > must "s-vlan or c-vlan"; > } > > where either or both tags can be specified, and only specified tags are matched (so if no c-vlan is specified then c-vlan is irrelevant for matching). The using a list structure was intended to serve a couple of purposes: (1) To easily allow the implementations to extend to more than 2 tags if required in the future. (2) Using lists also provides quite a clean way that the model could be augmented to classify on the CoS bits or DEI bit. Specifically it logically groups the data together. > > Alternatively, maybe the restrictions relating to tag type and order should be removed, so that if I *want* to have an unusual device configuration (such as pushing 3 consecutive c-vlan tags) then I am able to do so. The restrictions are in there to ensure good interoperability with IEEE 802.1Q compliant bridges. Part of the agreement with the IEEE 802.1Q WG to get consent from them to allow this draft to proceed was to ensure and emphasize good interoperability with IEEE technologies, particularly given that they own the 0x8100 and 0x88a8 Ethertypes. Of course, there is nothing preventing a vendor deviation to remove some of those restrictions. > > Also, ietf-if-l3-vlan contains a feature (l3-vlan-sub-interfaces) that gates everything in the module. This is pointless IMO. If a server doesn't support L3 vlan subinterfaces then it should not implement the module (whose entire purpose is to model L3 vlan subinterfaces). Yes, I agree that feature looks like it is redundant in this case and should be removed. Thanks, Rob > > > Alex > > ________________________________________ > From: netmod on behalf of Lou Berger > Sent: Tuesday, 13 December 2016 12:31 p.m. > To: NetMod WG > Cc: NetMod WG Chairs > Subject: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04 > > All, > > This is start of a two week* poll on making > draft-wilton-netmod-intf-vlan-yang-04 a NetMod working group > document. > > Please send email to the list indicating "yes/support" or "no/do not > support". If indicating no, please state your reservations with the > document. If yes, please also feel free to provide comments you'd like > to see addressed once the document is a WG document. > > * Given the holiday, the poll ends December 28. > > Thank you, > NetMod WG Chairs > > _______________________________________________ > 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 Dec 22 06:32:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27559129483 for ; Thu, 22 Dec 2016 06:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWuHbhb_Cw3y for ; Thu, 22 Dec 2016 06:32:28 -0800 (PST) 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 BBA75129512 for ; Thu, 22 Dec 2016 06:32:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3313; q=dns/txt; s=iport; t=1482417147; x=1483626747; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=NbEvUrikCpxf12UrnpIw+rS+t64SFRWPANqDfZGOyac=; b=Q7yrIV5XZovob8zwKcot8i8Uy8yWusgcUJZWSi5VVa0ggL2sGNGKJvS5 ECptCd1BqbW7CD6TIBqK2wMqt3FzxDhClf9CY0xNT1wV5Pr2OXJQ5DX/r AeEYqKTN6nhT925BqRtBlvAkF6S2xybo+e+SfaKy3Hacl+rvIIm6ndj2Y I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AABz41tY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzUBAQEBAYEqjipylWCVFYIJhiICgisUAQIBAQEBAQEBYiiEaAE?= =?us-ascii?q?BAQMBIw8BBVELGAICJgICVwYBDAgBAYhhCKlZgiiLBQEBAQEBAQEDAQEBAQEBA?= =?us-ascii?q?QEggQuFPYICgmGHT4JdBY8Ei3WROoojhi+KQINmhA8fN4EHFg0uhWE+iR0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,388,1477958400"; d="scan'208";a="650942165" 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; 22 Dec 2016 14:32:25 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uBMEWPdM012977; Thu, 22 Dec 2016 14:32:25 GMT To: Ladislav Lhotka , netmod@ietf.org References: From: Robert Wilton Message-ID: <33d0132e-750b-97ed-8bdb-0befeb1b81c3@cisco.com> Date: Thu, 22 Dec 2016 14:32:18 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] LL review of draft-ietf-netmod-intf-ext-yang-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 14:32:29 -0000 Hi Lada, Thanks for the review and comments. On 21/12/2016 13:08, Ladislav Lhotka wrote: > Hi, > > I think this is a very useful addition to ietf-interfaces. In general, > the document is clearly written and YANG modules nicely designed. Here > are my comments: > > *** Sec. 1 > - "This document defines two YANG RFC 7950 [RFC7950] modules …" > looks weird. I'd suggest "… YANG 1.1 [RFC7950] …" instead. OK. > *** Sec. 2 > - first line: s/of of/of/ > *** Sec. 3.1 > - If the "bandwidth" parameter is only used for tuning routing > algorithms and has nothing to do with real bandwidth on the > interface, I would suggest to use a different name > (metric?). Perhaps it may indeed be better to leave this to > routing protocol modules because they can also specify how > exactly such a parameter is used. Yes, possibility it would be better to define this as part of the routing models. The idea here is that the bandwidth would span across the routing protocols rather than be tied to a specific protocol. > *** Sec. 3.6 > - The "l3-mtu" parameter is probably the same as "mtu" defined in > ietf-ip. Again, I would suggest to leave the definition of MTU > to each L3 protocol because there may be specific aspects and > constraints. The MTU being defined here is an "l2-mtu" parameter. I.e. the maximum size of the L2 frames that can be sent/received. For some devices this value is independent of a protocol specific L3 MTU that only affects that particular protocol instance. > *** Sec. 3.8 > - I think that "transport-layer" is not a good name because in the > ISO OSI model it denotes a particular layer (L4). How about > "iso-osi-layer"? > - The type of "transport-layer" has three enums, namely > "layer-[123]". I would suggest to use descriptive names > ("physical-layer" etc.), include the remaining layers of the ISO > OSI model, and maybe also define it as a typedef - or does this > belong to ietf-inet-types? > - Is a leaf sufficient? I think some interfaces can be in multiple > layers at the same time (e.g. an ATM interface is L3 but can > also be L2 for Classical IP over ATM). Or is the idea that such > an interface will be split into two entries of the "interface" > list? This needs some further thought/work. The main idea here was to be able to label sub-interfaces as supporting only L2 services or L3 services, since on some platforms different types of interfaces get instantiated internally. > *** YANG modules > - Descriptions are not consistently formatted. I think that the > current BCP is to start description text on the same line as the > "description" keyword only if it all fits on one line. > - I don't have a strong opinion on this but it might increase > readability if the number of augments is reduced. Perhaps at > least augments that contain only one node could be made into one > (and the "feature" and "when" statements moved to the nodes' > definitions. Yes, I'll fix these, probably using Martin's suggested approach. Thanks again, Rob > > Lada > From nobody Thu Dec 22 06:43:24 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9017012968D for ; Thu, 22 Dec 2016 06:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 QI4JSf3By0PV for ; Thu, 22 Dec 2016 06:43:21 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A613E129684 for ; Thu, 22 Dec 2016 06:43:20 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:e444:89de:722a:8206] (unknown [IPv6:2001:718:1a02:1:e444:89de:722a:8206]) by mail.nic.cz (Postfix) with ESMTPSA id 5D527624CA; Thu, 22 Dec 2016 15:43:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1482417798; bh=vKEIBXKH/BG9ZJrp1Mn6v+IG1SfImESYjbzEfdtNxIo=; h=From:Date:To; b=O6QP+gWOdhzw/WlrTS87AjlwiwTXoot5Eyz7QVdb8ryjLTFtAVIfDpLolPymahPp9 lnal98CYdqymTt8vWDjx3j6hHhs9vEyq/2rdBO26MATySrs/Y6lTPXIF/ORAmyFkke SUWHviTP1WhDVtyB72P5JyRQYB1l6zyNoEqHaPMs= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <33d0132e-750b-97ed-8bdb-0befeb1b81c3@cisco.com> Date: Thu, 22 Dec 2016 15:43:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <064C29E6-0027-4033-AA9A-0B3E42551031@nic.cz> References: <33d0132e-750b-97ed-8bdb-0befeb1b81c3@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] LL review of draft-ietf-netmod-intf-ext-yang-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 14:43:22 -0000 > On 22 Dec 2016, at 15:32, Robert Wilton wrote: >=20 > Hi Lada, >=20 > Thanks for the review and comments. >=20 >=20 > On 21/12/2016 13:08, Ladislav Lhotka wrote: >> Hi, >>=20 >> I think this is a very useful addition to ietf-interfaces. In = general, >> the document is clearly written and YANG modules nicely designed. = Here >> are my comments: >>=20 >> *** Sec. 1 >> - "This document defines two YANG RFC 7950 [RFC7950] modules =E2=80= =A6" >> looks weird. I'd suggest "=E2=80=A6 YANG 1.1 [RFC7950] =E2=80=A6"= instead. > OK. >> *** Sec. 2 >> - first line: s/of of/of/ >> *** Sec. 3.1 >> - If the "bandwidth" parameter is only used for tuning routing >> algorithms and has nothing to do with real bandwidth on the >> interface, I would suggest to use a different name >> (metric?). Perhaps it may indeed be better to leave this to >> routing protocol modules because they can also specify how >> exactly such a parameter is used. > Yes, possibility it would be better to define this as part of the = routing models. The idea here is that the bandwidth would span across = the routing protocols rather than be tied to a specific protocol. We had a similar discussion regarding a route metric in ietf-routing: = whilst most protocols use some metric, its semantics, range etc. differ. = I wonder if it is the same here. >=20 >> *** Sec. 3.6 >> - The "l3-mtu" parameter is probably the same as "mtu" defined in >> ietf-ip. Again, I would suggest to leave the definition of MTU >> to each L3 protocol because there may be specific aspects and >> constraints. > The MTU being defined here is an "l2-mtu" parameter. I.e. the maximum = size of the L2 frames that can be sent/received. For some devices this = value is independent of a protocol specific L3 MTU that only affects = that particular protocol instance. Aha, you write about "l3-mtu" leaf in the text (also in Security = Considerations) but it's not present in the module. >=20 >> *** Sec. 3.8 >> - I think that "transport-layer" is not a good name because in = the >> ISO OSI model it denotes a particular layer (L4). How about >> "iso-osi-layer"? >> - The type of "transport-layer" has three enums, namely >> "layer-[123]". I would suggest to use descriptive names >> ("physical-layer" etc.), include the remaining layers of the = ISO >> OSI model, and maybe also define it as a typedef - or does this >> belong to ietf-inet-types? >> - Is a leaf sufficient? I think some interfaces can be in = multiple >> layers at the same time (e.g. an ATM interface is L3 but can >> also be L2 for Classical IP over ATM). Or is the idea that such >> an interface will be split into two entries of the "interface" >> list? > This needs some further thought/work. >=20 > The main idea here was to be able to label sub-interfaces as = supporting only L2 services or L3 services, since on some platforms = different types of interfaces get instantiated internally. OK. Thanks, Lada >=20 >> *** YANG modules >> - Descriptions are not consistently formatted. I think that the >> current BCP is to start description text on the same line as = the >> "description" keyword only if it all fits on one line. >> - I don't have a strong opinion on this but it might increase >> readability if the number of augments is reduced. Perhaps at >> least augments that contain only one node could be made into = one >> (and the "feature" and "when" statements moved to the nodes' >> definitions. > Yes, I'll fix these, probably using Martin's suggested approach. >=20 > Thanks again, > Rob >=20 >>=20 >> Lada >>=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Dec 22 12:39:25 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36764129585 for ; Thu, 22 Dec 2016 12:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SWVUOZWAt3Z for ; Thu, 22 Dec 2016 12:39:22 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFD9512957A for ; Thu, 22 Dec 2016 12:39:21 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id u25so115074808qki.2 for ; Thu, 22 Dec 2016 12:39:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c/smJo++pandqcoMV3FS8s5mxiACSo1bAqM9TkfoCyM=; b=XTKO0f5bNRJL8BQ7bR07jqUeKla8UvVSJ6QUCfUC6WNZStzeqfFldqyIAY+WLwlg1y TdnMTO0e6K9GZJli9mdabMRFR4hk7hYQ0Tl06VzFKcIv7YKwcWKzSIb/JyVvn7ass2u0 ZjfayoMjuWvgDSHZzJpdzABhl1rpKOavZJM8yTwUCEKWFCEi6DkhTiGficpCGsb5jrWl mOixHYv84eE//1zFryAOpAYKbsS0YKOn3ssAPmNfIZ2XhAFsNdVjcwXWle4hdMf1YMPq LCkKLNtYqU1mZ+67kmHVrH7xODVai8dIipPUm8BGnOUgtgifhdUAfnydwcZuWieCYmou 3aqw== 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=c/smJo++pandqcoMV3FS8s5mxiACSo1bAqM9TkfoCyM=; b=co1sItNtQmiDwOlx+05g8rNGm7NqzcunbfIfv0T5NKeAtdSfunzrh3rl9///o3ft38 yYXQD8t4ZNiAgYuc13YS4FtPZS4uO5ENa10Rs53hnlVpN61jWy0ckmeAKINce6OVm1GS PPgdgZV1m3a4GXgA1p5NFeK4goha6PWqMm2iX74cXdTkDfM3LBdgHns+QLCevfiHoGbL mHLomJRRNTNRun85ybrbI24FmdUykBIdEQjZ21I9G0VJNXwVKGbkSsuLWh9qAy8ROKhD Hg/UPA8MtiOHmtqrtwNoA1ANndev6ir/3ikREdZW9jR85X0TGB7rqD9crl+xXbk6MrnF 7gFQ== X-Gm-Message-State: AIkVDXI/UmX/kLlGZhRdP2YQ+11+XXq81ZEaK5u9+1MaW9pBs1kGsDOve1z/jV5qlmlsRIlETZ3Y0FytncJnIw== X-Received: by 10.55.76.197 with SMTP id z188mr11705094qka.184.1482439161028; Thu, 22 Dec 2016 12:39:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.113 with HTTP; Thu, 22 Dec 2016 12:39:20 -0800 (PST) In-Reply-To: <5ab58f5f-25d4-5cf9-f46c-c144da8e5597@cisco.com> References: <8ac64b13-469c-31fe-9d2b-ad0487204d69@cisco.com> <20161222.112242.1766522035191268644.mbj@tail-f.com> <8d2df0d5-b662-23a6-8339-1acf5086ae62@cisco.com> <20161222.114940.1495001277375813904.mbj@tail-f.com> <5ab58f5f-25d4-5cf9-f46c-c144da8e5597@cisco.com> From: Andy Bierman Date: Thu, 22 Dec 2016 12:39:20 -0800 Message-ID: To: Robert Wilton Content-Type: multipart/alternative; boundary=001a114a80629858bb0544454305 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 20:39:24 -0000 --001a114a80629858bb0544454305 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 22, 2016 at 3:24 AM, Robert Wilton wrote: > > > On 22/12/2016 10:49, Martin Bjorklund wrote: > >> Robert Wilton wrote: >> >>> >>> On 22/12/2016 10:22, Martin Bjorklund wrote: >>> >>>> Robert Wilton wrote: >>>> >>>>> On 22/12/2016 10:00, Andy Bierman wrote: >>>>> >>>>>> On Wed, Dec 21, 2016 at 11:49 PM, Ladislav Lhotka >>>>> > wrote: >>>>>> >>>>>> >>>>>> > On 22 Dec 2016, at 07:22, Randy Presuhn >>>>>> >>>>> > wrote: >>>>>> > >>>>>> > Hi - >>>>>> > >>>>>> > On 12/21/2016 3:55 PM, Andy Bierman wrote: >>>>>> >> >>>>>> >> >>>>>> >> On Wed, Dec 21, 2016 at 3:41 PM, Juergen Schoenwaelder >>>>>> >> >>>>> >>>>>> >> >>>>> >> wrote: >>>>>> > ... >>>>>> >> Perhaps I am blinded by the way @deprecate or >>>>>> __attribute__ >>>>>> >> ((deprecated)) or [[deprecated]] work in various >>>>>> programming >>>>>> >> languages. All these annotations do not deprecate my code, >>>>>> they just >>>>>> >> cause the generation of warnings so that I get aware of >>>>>> the >>>>>> issue and >>>>>> >> can do my homework. >>>>>> >> >>>>>> >> >>>>>> >> There are no protocols that let you manage orphaned data >>>>>> nodes >>>>>> >> without any parent. No way to represent it in XML or JSON >>>>>> either. >>>>>> >> No way to specify a RESTCONF target resource that leaves out >>>>>> >> some intermediate data nodes. >>>>>> > >>>>>> > Deprecating (or obsoleting) a definition does not orphan data >>>>>> nodes. >>>>>> > Perhaps I'm blinded by the way SNMP works, but it seems to me >>>>>> that >>>>>> > a robust client will need to be able to process data >>>>>> corresponding >>>>>> > to deprecated (or obsolete) definitions. Likewise, developers >>>>>> > of server-side software may find themselves in situations >>>>>> where >>>>>> > supporting obsolete definitions is a commercial necessity. >>>>>> Things >>>>>> > certainly played out that way in the SNMP world. I agree with >>>>>> Juergen >>>>>> > that tool-generated warnings seem to be the correct way to go. >>>>>> >>>>>> I agree that making a node deprecated or obsolete doesn't mean >>>>>> that its descendants are orphaned, it just means they cannot be >>>>>> current, and then "current" shouldn't be the default status for >>>>>> them - also because the descendants may come from other modules >>>>>> (via groupings and augments) that cannot be changed. >>>>>> >>>>>> Even if the default status is inherited, tools can still >>>>>> generate >>>>>> warnings. A data modeller can decide whether and where it makes >>>>>> sense to have the "status" statement explicitly, but isn't >>>>>> forced >>>>>> to do it everywhere. >>>>>> >>>>>> >>>>>> >>>>>> NETCONF and RESTCONF have no mechanisms for accessing data other than >>>>>> top-down from the top-level YANG data node to the target node. >>>>>> Removing an ancestor node from the server implementation effectively >>>>>> removes >>>>>> the entire subtree from the implementation. (The value of the YANG >>>>>> status-stmt >>>>>> of the descendant nodes has nothing to do with it) >>>>>> >>>>> I agree that this certainly seems to be the case if a node is marked >>>>> as obsolete. It seems that it implicitly forces all child nodes to be >>>>> obsolete as well regardless of which module they were defined in. >>>>> >>>> No I don't think this is correct. If module B augment X in module A, >>>> and X is obsolete, it does NOT mean that the augmented nodes in B are >>>> automatically obsolete. However, in an implementation that doesn't >>>> implement X, the augmented nodes from B are obviously also not >>>> implemented. >>>> >>> I can get where you are coming from, but if you had a GUI viewer that >>> was looking at the combined schema tree, I think that you would to see >>> those descendant children nodes marked in some way to indicate that >>> implementations may validly not return them. Reporting them as current >>> when one of their parent nodes was obsolete would seem to be >>> deceptive. >>> >>> Is it that you are trying to differentiate between being explicitly >>> obsolete vs 'implicitly obsolete' through parentage? >>> >> I think that within a module, if a parent is obsolete, then all its >> child should also be obsolete (*). But I do think that the status >> should be explicitly stated. >> > OK. I assume that this statement applies to deprecated as well. I don't > feel particularly strongly on this point. If you mark something as > obsolete/deprecated, then explicitly having to find and mark all > references/children doesn't seem like a bad thing because it makes the full > impact obvious (if pyang is enhanced to check for this). > > >> But marking definition as obsolete in one module cannot automatically >> make definitions in *other* modules obsolete. >> > I'm not so sure. > > It seems to me that in practice, they are directly equivalent as if they > were marked as obsolete. I.e. clients cannot rely on them being available > because the obsolete parent may not be implemented. > > If the augmenting module wants to keep those nodes, then their only choice > seems to be to explicitly mark them as obsolete, and make a copy of the > nodes augmenting somewhere else in the schema tree. > > > >> (*) _maybe_ 7950 can be interpreted in this way when it says: >> >> If a definition is "current", it MUST NOT reference a "deprecated" or >> "obsolete" definition within the same module >> >> If you're in a good mood, you could argue that a child always >> "references" its parent. >> > Would it not be better to add some sort of explicit statement as an errata > to 7950 (once there is agreement on what it should say)? Or is this beyond > the scope of what an errata is allowed to do? > > I think the current text is pretty bad. The term "references" is not very useful and it is not defined anywhere. IMO a child node implicitly references its parent. Any child node could be refactered as an augment: container X { status obsolete; leaf Y {} } equivalent to: augment /X { leaf Y {} } container X { status obsolete; } Does the augment reference X? I would say yes. Even more distressing to me is that the definition of 'obsolete' says SHOULD NOT implement. There is no guidence on when it is OK to ignore the SHOULD NOT. Also, a deviation-stmt is not allowed to alter the status-stmt. This seems wrong. There is no discovery mechanism for a client to reliably determine what the server implements. I would prefer that the server advertise a deviation stating explicity that the server is ignoring the status-stmt deviation /X { deviate replace { status deprecated; } } But this is not even permitted by the YANG language. > Rob > Andy > > >> >> /martin >> . >> >> > --001a114a80629858bb0544454305 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 22, 2016 at 3:24 AM, Robert Wilton <rwilton@cisco.com&= gt; wrote:


On 22/12/2016 10:49, Martin Bjorklund wrote:
Robert Wilton <rw= ilton@cisco.com> wrote:

On 22/12/2016 10:22, Martin Bjorklund wrote:
Robert Wilton <rw= ilton@cisco.com> wrote:
On 22/12/2016 10:00, Andy Bierman wrote:
On Wed, Dec 21, 2016 at 11:49 PM, Ladislav Lhotka <lhotka@nic.cz
<mailto:lhotka@nic.cz= >> wrote:


=C2=A0 =C2=A0 =C2=A0 > On 22 Dec 2016, at 07:22, Randy Presuhn
=C2=A0 =C2=A0 =C2=A0 <randy_presuhn@alumni.stanford.edu
=C2=A0 =C2=A0 =C2=A0 <mailto:randy_presuhn@alumni.stanford.edu>&= gt; wrote:
=C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 > Hi -
=C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 > On 12/21/2016 3:55 PM, Andy Bierman wrote:
=C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 >> On Wed, Dec 21, 2016 at 3:41 PM, Juergen Scho= enwaelder
=C2=A0 =C2=A0 =C2=A0 >> <j.schoenwaelder@jacobs-university.de<= /a>
=C2=A0 =C2=A0 =C2=A0 <mailto:j.schoenwaelder@jacobs-university.de>
=C2=A0 =C2=A0 =C2=A0 >> <mailto:j.schoenwaelder@jacobs-univers= ity.de
=C2=A0 =C2=A0 =C2=A0 <mailto:j.schoenwaelder@jacobs-university.de>>> wrote:
=C2=A0 =C2=A0 =C2=A0 > ...
=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 Perhaps I am blinded by the way = @deprecate or __attribute__
=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 ((deprecated)) or [[deprecated]]= work in various programming
=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 languages. All these annotations= do not deprecate my code,
=C2=A0 =C2=A0 =C2=A0 they just
=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 cause the generation of warnings= so that I get aware of the
=C2=A0 =C2=A0 =C2=A0 issue and
=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 can do my homework.
=C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 >> There are no protocols that let you manage or= phaned data nodes
=C2=A0 =C2=A0 =C2=A0 >> without any parent.=C2=A0 No way to represent= it in XML or JSON either.
=C2=A0 =C2=A0 =C2=A0 >> No way to specify a RESTCONF target resource = that leaves out
=C2=A0 =C2=A0 =C2=A0 >> some intermediate data nodes.
=C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 > Deprecating (or obsoleting) a definition does not= orphan data nodes.
=C2=A0 =C2=A0 =C2=A0 > Perhaps I'm blinded by the way SNMP works, bu= t it seems to me that
=C2=A0 =C2=A0 =C2=A0 > a robust client will need to be able to process d= ata corresponding
=C2=A0 =C2=A0 =C2=A0 > to deprecated (or obsolete) definitions.=C2=A0 Li= kewise, developers
=C2=A0 =C2=A0 =C2=A0 > of server-side software may find themselves in si= tuations where
=C2=A0 =C2=A0 =C2=A0 > supporting obsolete definitions is a commercial n= ecessity.=C2=A0 Things
=C2=A0 =C2=A0 =C2=A0 > certainly played out that way in the SNMP world.= =C2=A0 I agree with
=C2=A0 =C2=A0 =C2=A0 Juergen
=C2=A0 =C2=A0 =C2=A0 > that tool-generated warnings seem to be the corre= ct way to go.

=C2=A0 =C2=A0 =C2=A0 I agree that making a node deprecated or obsolete does= n't mean
=C2=A0 =C2=A0 =C2=A0 that its descendants are orphaned, it just means they = cannot be
=C2=A0 =C2=A0 =C2=A0 current, and then "current" shouldn't be= the default status for
=C2=A0 =C2=A0 =C2=A0 them - also because the descendants may come from othe= r modules
=C2=A0 =C2=A0 =C2=A0 (via groupings and augments) that cannot be changed.
=C2=A0 =C2=A0 =C2=A0 Even if the default status is inherited, tools can sti= ll generate
=C2=A0 =C2=A0 =C2=A0 warnings. A data modeller can decide whether and where= it makes
=C2=A0 =C2=A0 =C2=A0 sense to have the "status" statement explici= tly, but isn't forced
=C2=A0 =C2=A0 =C2=A0 to do it everywhere.



NETCONF and RESTCONF have no mechanisms for accessing data other than
top-down from the top-level YANG data node to the target node.
Removing an ancestor node from the server implementation effectively
removes
the entire subtree from the implementation.=C2=A0 (The value of the YANG status-stmt
of the descendant nodes has nothing to do with it)
I agree that this certainly seems to be the case if a node is marked
as obsolete.=C2=A0 It seems that it implicitly forces all child nodes to be=
obsolete as well regardless of which module they were defined in.
No I don't think this is correct.=C2=A0 If module B augment X in module= A,
and X is obsolete, it does NOT mean that the augmented nodes in B are
automatically obsolete.=C2=A0 However, in an implementation that doesn'= t
implement X, the augmented nodes from B are obviously also not
implemented.
I can get where you are coming from, but if you had a GUI viewer that
was looking at the combined schema tree, I think that you would to see
those descendant children nodes marked in some way to indicate that
implementations may validly not return them. Reporting them as current
when one of their parent nodes was obsolete would seem to be
deceptive.

Is it that you are trying to differentiate between being explicitly
obsolete vs 'implicitly obsolete' through parentage?
I think that within a module, if a parent is obsolete, then all its
child should also be obsolete (*).=C2=A0 But I do think that the status
should be explicitly stated.
OK.=C2=A0 I assume that this statement applies to deprecated as well.=C2=A0= I don't feel particularly strongly on this point.=C2=A0 If you mark so= mething as obsolete/deprecated, then explicitly having to find and mark all= references/children doesn't seem like a bad thing because it makes the= full impact obvious (if pyang is enhanced to check for this).


But marking definition as obsolete in one module cannot automatically
make definitions in *other* modules obsolete.
I'm not so sure.

It seems to me that in practice, they are directly equivalent as if they we= re marked as obsolete.=C2=A0 I.e. clients cannot rely on them being availab= le because the obsolete parent may not be implemented.

If the augmenting module wants to keep those nodes, then their only choice = seems to be to explicitly mark them as obsolete, and make a copy of the nod= es augmenting somewhere else in the schema tree.



(*) _maybe_ 7950 can be interpreted in this way when it says:

=C2=A0 =C2=A0 If a definition is "current", it MUST NOT reference= a "deprecated" or
=C2=A0 =C2=A0 "obsolete" definition within the same module

If you're in a good mood, you could argue that a child always
"references" its parent.
Would it not be better to add some sort of explicit statement as an errata = to 7950 (once there is agreement on what it should say)?=C2=A0 Or is this b= eyond the scope of what an errata is allowed to do?


--001a114a80629858bb0544454305-- From nobody Thu Dec 22 16:45:16 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B5012964B for ; Thu, 22 Dec 2016 16:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1] 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 NeelDmd0o-EE for ; Thu, 22 Dec 2016 16:45:13 -0800 (PST) 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 4C423129649 for ; Thu, 22 Dec 2016 16:45:13 -0800 (PST) Received: from [172.16.0.179] (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id CE4F3241A5B; Fri, 23 Dec 2016 01:45:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1482453909; bh=GMxQ+vQTa+jVWhHgm5ZMJdgeaZpobyFmwiPVAFshGaA=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=C3fZL5GijwBdr68UXXqEXfcNtwqhZAHdkuLujb+by4gPYMhC1bLBB8OmGnu6N8dqr krZBQedh/7njgcWuOP0Njqphbqw9D8pHeHHBxeCGEuw+nF3zwE+ZcA8Qo8SeFuCUdJ os3Una0uYaVLfll21mFY9i5HfVekvpcyjk6AfeAs= To: Ladislav Lhotka , Andy Bierman References: <20161221.103208.1910010141581780305.mbj@tail-f.com> <20161221.115438.163227970004322277.mbj@tail-f.com> <20161221223038.GB4526@elstar.local> <20161221234135.GA4630@elstar.local> <75ad1f98-c927-ba4b-ea35-7197c89c0759@alumni.stanford.edu> From: Robert Varga Message-ID: Date: Fri, 23 Dec 2016 01:45:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 00:45:15 -0000 On 22.12.2016 11:53, Ladislav Lhotka wrote: > Expected server/protocol behaviour for nodes of a given status is specified in sec. 7.21.2 and IMO it is a different issue. What may need to be clarified wrt YANG is how to figure out the status of each node from the data model. In particular, > > - what ancestor/descendant combinations of statuses are permitted > > - what is the default if "status" statement is omitted. I agree with Andy's view when a single module is concerned. In this sense "references" == "its ability to be accessed is granted by being a descendant of". I think we may have to have more complex rules taking into account enclosing statement and inter-module relationships: what harm is done by instantiating an obsolete grouping? Unfortunately we cannot legally prohibit 'status current' from appearing in an augmented (or refined) case from a different module, as not breaking downstream models seems to be obsolete's raison d'etre (based on 7950 section 11). Hence the effective status of any 'status current' nodes with an obsolete ancestor should be obsolete. I do not think it should be required to issue more than a warning. Regards, Robert From nobody Thu Dec 22 21:15:55 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF78012969D for ; Thu, 22 Dec 2016 21:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.321 X-Spam-Level: X-Spam-Status: No, score=-7.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, 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 lsjG_AnJXLsK for ; Thu, 22 Dec 2016 21:15:53 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60A16129694 for ; Thu, 22 Dec 2016 21:15:52 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DDC68457; Fri, 23 Dec 2016 05:15:49 +0000 (GMT) Received: from DGGEMA405-HUB.china.huawei.com (10.3.20.46) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 23 Dec 2016 05:15:48 +0000 Received: from DGGEMA502-MBX.china.huawei.com ([169.254.2.221]) by DGGEMA405-HUB.china.huawei.com ([10.3.20.46]) with mapi id 14.03.0301.000; Fri, 23 Dec 2016 13:15:33 +0800 From: Rohit R Ranade To: Martin Bjorklund Thread-Topic: [netmod] RFC 6022 Query Thread-Index: AdJbafmzui97K1h8RsGEGmV5TDm5HP//fzkA//yf0cA= Date: Fri, 23 Dec 2016 05:15:33 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6B011C87@DGGEMA502-MBX.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A6B01191A@DGGEMA502-MBX.china.huawei.com> <20161221.102852.1273087448152459126.mbj@tail-f.com> In-Reply-To: <20161221.102852.1273087448152459126.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.242.206] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.585CB306.02B4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.221, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 28e18623da0663900f6dadc0b7282d38 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] RFC 6022 Query X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 05:15:54 -0000 Ok Got it. 2.1.1. The /netconf-state/capabilities Subtree The /netconf-state/capabilities subtree contains the capabilities supported by the NETCONF server. The list MUST include all capabilities exchanged during session setup still applicable at the time of the request. Q1 : So "/netconf-state/capabilities" is specifically for client to periodi= cally check the capabilities and will be mainly used if the Server does not= support netconf-capability-change[RFC 6470] notification ? Q2 : Currently YANG module loading / unloading can add/delete capabilities= . Is there any other scenario where capabilities can be added/deleted/modif= ied ?=20 -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: 21 December, 2016 17:29 To: Rohit R Ranade Cc: netmod@ietf.org Subject: Re: [netmod] RFC 6022 Query Hi, Rohit R Ranade wrote: > Hi All, >=20 > /netconf-state/schemas =3D=3D> Will be used to retrieve the list of > schemas in the device. > will be used to get the actual schema file-content based > on the contents of the schema list. >=20 > Q1: Section 2.1.3 has the below statement for "version": >=20 > For YANG data models, version is the value of the most recent YANG > 'revision' statement in the module or submodule, or the empty > string if no 'revision' statement is present. >=20 > This clearly means that all the revisions of a YANG module will not be > listed. No. See the paragraph above the quoted one: Multiple versions MAY be supported simultaneously by a NETCONF server. Each version MUST be reported individually in the schema list, i.e., with same identifier, possibly different location, but different version. The text just means that for YANG module (in both formats 'yang' and 'yin') the version will contain the current revision for that version for the module. I hope this clarifies the rest of your questions below. > If a device has the YANG and YIN format for all the modules, > then the YIN format is shown with all the revisions, but the YANG > format will be shown with the highest revision only. > What is the logic behind this difference in behavior ? YANG is reader > friendly while YIN is operation(xml parsing) friendly. I feel it is a > valid scenario to have both these format in the device. >=20 > Q2: Since all the revisions are never shown for YANG in the schema > list, there is no mechanism to extract the lower revisions using > . The response from server also shows only the > highest revision. > One scenario for lower version usage : The import statement allows > import by revision. Consider ModuleA imports SubModuleB with a lower > revision. The user will never be able to get the lower revision file > of SubModule B ? If some content has been deleted / modified in the > latest revision of SubModule B it will cause confusion. >=20 > With Regards, > Rohit /martin From nobody Fri Dec 23 05:06:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3409B129452 for ; Fri, 23 Dec 2016 05:06:20 -0800 (PST) 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 rGRuwg2W0t2q for ; Fri, 23 Dec 2016 05:06:18 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 313CA1294B0 for ; Fri, 23 Dec 2016 05:06:15 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 92FDC1CC009F; Fri, 23 Dec 2016 14:06:14 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund , rwilton@cisco.com In-Reply-To: <20161222.114940.1495001277375813904.mbj@tail-f.com> References: <8ac64b13-469c-31fe-9d2b-ad0487204d69@cisco.com> <20161222.112242.1766522035191268644.mbj@tail-f.com> <8d2df0d5-b662-23a6-8339-1acf5086ae62@cisco.com> <20161222.114940.1495001277375813904.mbj@tail-f.com> Date: Fri, 23 Dec 2016 14:06:12 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 13:06:20 -0000 Martin Bjorklund writes: > Robert Wilton wrote: >> >> >> On 22/12/2016 10:22, Martin Bjorklund wrote: >> > Robert Wilton wrote: >> >> >> >> On 22/12/2016 10:00, Andy Bierman wrote: >> >>> >> >>> On Wed, Dec 21, 2016 at 11:49 PM, Ladislav Lhotka > >>> > wrote: >> >>> >> >>> >> >>> > On 22 Dec 2016, at 07:22, Randy Presuhn >> >>> > >>> > wrote: >> >>> > >> >>> > Hi - >> >>> > >> >>> > On 12/21/2016 3:55 PM, Andy Bierman wrote: >> >>> >> >> >>> >> >> >>> >> On Wed, Dec 21, 2016 at 3:41 PM, Juergen Schoenwaelder >> >>> >> > >>> >> >>> >> > >>> >> wrote: >> >>> > ... >> >>> >> Perhaps I am blinded by the way @deprecate or __attribute__ >> >>> >> ((deprecated)) or [[deprecated]] work in various programming >> >>> >> languages. All these annotations do not deprecate my code, >> >>> they just >> >>> >> cause the generation of warnings so that I get aware of the >> >>> issue and >> >>> >> can do my homework. >> >>> >> >> >>> >> >> >>> >> There are no protocols that let you manage orphaned data nodes >> >>> >> without any parent. No way to represent it in XML or JSON either. >> >>> >> No way to specify a RESTCONF target resource that leaves out >> >>> >> some intermediate data nodes. >> >>> > >> >>> > Deprecating (or obsoleting) a definition does not orphan data nodes. >> >>> > Perhaps I'm blinded by the way SNMP works, but it seems to me that >> >>> > a robust client will need to be able to process data corresponding >> >>> > to deprecated (or obsolete) definitions. Likewise, developers >> >>> > of server-side software may find themselves in situations where >> >>> > supporting obsolete definitions is a commercial necessity. Things >> >>> > certainly played out that way in the SNMP world. I agree with >> >>> Juergen >> >>> > that tool-generated warnings seem to be the correct way to go. >> >>> >> >>> I agree that making a node deprecated or obsolete doesn't mean >> >>> that its descendants are orphaned, it just means they cannot be >> >>> current, and then "current" shouldn't be the default status for >> >>> them - also because the descendants may come from other modules >> >>> (via groupings and augments) that cannot be changed. >> >>> >> >>> Even if the default status is inherited, tools can still generate >> >>> warnings. A data modeller can decide whether and where it makes >> >>> sense to have the "status" statement explicitly, but isn't forced >> >>> to do it everywhere. >> >>> >> >>> >> >>> >> >>> NETCONF and RESTCONF have no mechanisms for accessing data other than >> >>> top-down from the top-level YANG data node to the target node. >> >>> Removing an ancestor node from the server implementation effectively >> >>> removes >> >>> the entire subtree from the implementation. (The value of the YANG >> >>> status-stmt >> >>> of the descendant nodes has nothing to do with it) >> >> I agree that this certainly seems to be the case if a node is marked >> >> as obsolete. It seems that it implicitly forces all child nodes to be >> >> obsolete as well regardless of which module they were defined in. >> > No I don't think this is correct. If module B augment X in module A, >> > and X is obsolete, it does NOT mean that the augmented nodes in B are >> > automatically obsolete. However, in an implementation that doesn't >> > implement X, the augmented nodes from B are obviously also not >> > implemented. >> I can get where you are coming from, but if you had a GUI viewer that >> was looking at the combined schema tree, I think that you would to see >> those descendant children nodes marked in some way to indicate that >> implementations may validly not return them. Reporting them as current >> when one of their parent nodes was obsolete would seem to be >> deceptive. >> >> Is it that you are trying to differentiate between being explicitly >> obsolete vs 'implicitly obsolete' through parentage? > > I think that within a module, if a parent is obsolete, then all its > child should also be obsolete (*). But I do think that the status > should be explicitly stated. > > But marking definition as obsolete in one module cannot automatically > make definitions in *other* modules obsolete. OK, so what information is "current/deprecated/obsolete" supposed to convey? If we interpret it as likelihood that the node is implemented, then it is clear that no node is more likely to be implemented that any of its ancestors. If the target node of an augment isn't implemented because it is obsolete, then the augment cannot be applied, no matter how we classify its contents. > > (*) _maybe_ 7950 can be interpreted in this way when it says: > > If a definition is "current", it MUST NOT reference a "deprecated" or > "obsolete" definition within the same module > > If you're in a good mood, you could argue that a child always > "references" its parent. Whatever mood I am in, an augment certainly references its target node, so according to the above rule it cannot be current unless the target node is also current. Lada > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Dec 27 15:05:04 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E83F127735 for ; Tue, 27 Dec 2016 15:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MISoNRdGQ7A1 for ; Tue, 27 Dec 2016 15:05:01 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C12129735 for ; Tue, 27 Dec 2016 15:05:01 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id n21so226510550qka.3 for ; Tue, 27 Dec 2016 15:05:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GpVsPX5mBfEGzJoAUFyQLeuKuU/DB9c/ikOYie/m7WI=; b=y7P39f5U11GkbyhCp+4dcjVLx0WBUwcv/yT+GvqXBuIya3UnZniOir2rQc7oU/X2j+ m7Z3OOtM+K9lGrxDAADYL7JOX9dUSB+sq5QV5mB5uffTp3kVrAsnwX5ZtRIR5ais6y7N DehV/X2VUQ9+Svyqusd2BHD9YozvIMbmhGqwRDFaU8RoXX5RikR1wDeE/YUvtjPgRAbL PLu9HoUth9BCLOImeryty9Fe7ak2YOLyK3ymyHZZDumjDmCAhQavID5FJdHniYaJKIxy 81Ho9yKyv+yHDPMHB0g6Oi+5PkzSw1RcBQ7U9t1zGyNfiP9ubBMyB6G9w7uM/uemiTm5 1dJw== 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=GpVsPX5mBfEGzJoAUFyQLeuKuU/DB9c/ikOYie/m7WI=; b=DnIylVmdZSlvsBLJsp55MEiVC9hVwZ5DsGzvFWZ1j0siO97xOsAAKp4BcEKfyVIoyG JXoXgYX7DU4F8rTGdZ/q9HAPFk+NmDEzxKuUxSgd29KCyKEjnv/uMoWqOvMYKs58Ha11 gi4bNHzomaXDUwptsjhYPvFHMovMna3BZjvc3V7DoUDMjuE8hIl/Chpb+BPD2J6xeVXG YJBP7K/vA8lPJA8qx5y77Fs0W2gMsTGjr/DQ6XUTqj/+pXn5cXOI5BXY3rM7KhS3FM18 d07aVFxm7egtjxjtMAJf6DwvOaEs/iDY7AsLQwoZ9dgMPC2OwOf7ElcFcvO3/xwF8EN6 Jv2A== X-Gm-Message-State: AIkVDXIzX65lZL2PqVsOVvbEoS6icYgkvAYyM07iyCo7+S4550tvFHTsmmuc6xXWPxVoT7l1akEsNr2/CegzUA== X-Received: by 10.55.7.2 with SMTP id 2mr35623416qkh.228.1482879900240; Tue, 27 Dec 2016 15:05:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.113 with HTTP; Tue, 27 Dec 2016 15:04:59 -0800 (PST) In-Reply-To: <1481689016940.22442@Aviatnet.com> References: <19039254-973A-461A-8749-95F74C33DAD1@juniper.net> <1481689016940.22442@Aviatnet.com> From: Andy Bierman Date: Tue, 27 Dec 2016 15:04:59 -0800 Message-ID: To: Alex Campbell Content-Type: multipart/alternative; boundary=001a114c877cb2e75c0544abe1c3 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 23:05:03 -0000 --001a114c877cb2e75c0544abe1c3 Content-Type: text/plain; charset=UTF-8 Hi, I am also considering an implementation. I share the same concerns that Alex has brought up. Some detailed comments: 1) /syslog/actions: seems like everything is in this container. Why is it needed? Seems like it could be removed as it serves no purpose 2) 8 features: the granularity seems wrong. The main container for each section should have its own if-feature /console /buffer /file /remote 3) What is the 'buffer' container for? How is the internal memory accessed by the client? 4) selector-facility: Seems like no-facilities servers the same purpose as an empty facility-list. The choice is not needed; just use the facility-list 5) pattern-match: leaf pattern-match { if-feature select-match; type string; description "This leaf desribes a Posix 1003.2 regular expression string that can be used to select a syslog message for logging. The match is performed on the RFC 5424 SYSLOG-MSG field."; } The field SYSLOG-MSG is referenced but never defined or listed in the terminology section. 6) how are the syslog-facility identities mapped to SYSLOG messages? 6a) how to distinguish acme:foo-facility from example:foo-facility in a SYSLOG message? 7) source-interface: what if the server does not let a source interface be used and instead normal routing determines the source interface (this leaf is very router-centric) 8) signing-options: are these widely deployed on all routers and Linux hosts? 9) logrotate: there are several features related to log file cleanup allowing lots of server variability and forces the client to support all the options. Can't this be simplified and all the micro-behavior YANG features removed? 10) numeric limits: there is some odd usage of YANG types; some limits are uint64, some uint32, some uint16. Seems like uint32 is sufficient Andy On Tue, Dec 13, 2016 at 8:16 PM, Alex Campbell wrote: > I am considering to implement the data model in this draft. > > I have reviewed this draft and found the following issues. In > approximately decreasing order of severity: > > * In the "selector-facility" choice statement the cases have misleading > names - the case where no facility is matched is named "facility", and the > case where specific facilities are matched is named "name". I suggest > "no-facilities" and "specified-facilities", or similar. > > * I disagree with the premise of the "no-facilities" case, which is that > it can be used to disable a log action, according to the description: > > description > "This case specifies no facilities will match when > comparing the syslog message facility. This is a > method that can be used to effectively disable a > particular log-action (buffer, file, etc)."; > > If an administrator wants to disable a log action they should do it by > either removing it from the configuration, or by setting an "enabled" leaf > to false. > With that in mind, there is no reason for the "no-facilities" case to > exist. > > * What is the behaviour of a selector if neither "no-facilities" nor > "facility-list" is present? > * In the "selector" grouping it is not clear how the facility and pattern > conditions are combined to decide whether a message is selected. > Must they both match the message, or is it sufficient for either one to > match the message? > * Not all servers have a console; there should be a feature to indicate > whether logging to the console is supported. > * Likewise, not all servers may support logging to user sessions. > * Likewise, not all servers may support a user-accessible filesystem. > * RFC 5424 states that the severity and protocol values are not normative. > * It's not clear to me why this needs to be split into two modules. Is it > so that other modules can define logging parameters but still be usable on > a device without syslog? > * "log-severity" defines a severity filter, not a severity, so its name is > misleading. > * Perhaps the "severity" type and the facility identities should have > "reference" statements referring to RFC 5424, rather than referring to it > in the description. > * In section "8.2", "admisintrator" is a typo. > > I assume that the means of accessing the memory buffer and log files are > out of scope of this data model. > > Alex > > ________________________________________ > From: netmod on behalf of Kent Watsen < > kwatsen@juniper.net> > Sent: Wednesday, 14 December 2016 2:01 p.m. > To: netmod@ietf.org > Subject: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 > > This is a notice to start a two-week NETMOD WG last call for the document: > > A YANG Data Model for Syslog Configuration > https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-11 > > Please indicate your support or concerns by Tuesday, December 27, 2016. > > We are particularly interested in statements of the form: > * I have reviewed this draft and found no issues. > * I have reviewed this draft and found the following issues: ... > > As well as: > * I have implemented the data model in this draft. > * I am implementing the data model in this draft. > * I am considering to implement the data model in this draft. > * I am not considering to implement the data model in this draft. > > Thank you, > NETMOD WG Chairs > > > > _______________________________________________ > 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 > --001a114c877cb2e75c0544abe1c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am also considering an implementa= tion.
I share the same concerns that Alex has brought up.

Some detailed comments:

1) /sysl= og/actions: seems like everything is in this container.
=C2= =A0Why is it needed?=C2=A0 Seems like it could be removed as it serves no p= urpose

2) 8 features: the granularity seems wrong.= =C2=A0 The main container for each section
=C2=A0should have = its own if-feature
=C2=A0 =C2=A0 =C2=A0 /console
=C2=A0= =C2=A0 =C2=A0 /buffer
=C2=A0 =C2=A0 =C2=A0 /file
=C2= =A0 =C2=A0 =C2=A0 /remote

3) What is the 'buff= er' container for?
=C2=A0 How is the internal memory acce= ssed by the client?

4) selector-facility: Seems li= ke no-facilities servers the same purpose
=C2=A0 =C2=A0 as an emp= ty facility-list. The choice is not needed; just use the facility-list

5) pattern-match:=C2=A0

      leaf pattern-match {
        if-feature select-match;
        type string;
        description
          "This leaf desribes a Posix 1003.2 regular expression
           string that can be used to select a syslog message for
           logging. The match is performed on the RFC 5424
           SYSLOG-MSG field.";
      }

The field SYSLOG-MSG is referenced but never defined = or listed in
the terminology section.
6) how are the syslog-facility identitie= s mapped to SYSLOG messages?
6a) how to dis= tinguish acme:foo-facility from example:foo-facility in a SYSLOG message?

7) sour= ce-interface: what if the server does not let a source interface be used an= d instead
=C2=A0 =C2=A0 normal routing dete= rmines the source interface (this leaf is very router-centric)

8) signing-options= : are these widely deployed on all routers and Linux hosts?

9) logrotate: there a= re several features related to log file cleanup allowing lots of
=C2=A0 =C2=A0 server variability and forces the clien= t to support all the options.=C2=A0 Can't this be simplified
=C2=A0 =C2=A0and all the micro-behavior YANG features= removed?

10) numeric limits: there is some odd usage of YANG types; some limits = are uint64, some uint32,
some uint16.=C2=A0= Seems like uint32 is sufficient

=

Andy
<= div class=3D"gmail_extra">

On Tue, Dec 13, 2016 at 8:16 PM, Alex Campbell <Alex.Campbell@aviatnet.com> wrote:
I am= considering to implement the data model in this draft.

I have reviewed this draft and found the following issues. In approximately= decreasing order of severity:

* In the "selector-facility" choice statement the cases have misl= eading names - the case where no facility is matched is named "facilit= y", and the case where specific facilities are matched is named "= name". I suggest "no-facilities" and "specified-facilit= ies", or similar.

* I disagree with the premise of the "no-facilities" case, which = is that it can be used to disable a log action, according to the descriptio= n:

=C2=A0 =C2=A0 =C2=A0description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "This case specifies no faci= lities will match when
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0comparing the syslog messag= e facility. This is a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0method that can be used to = effectively disable a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0particular log-action (buff= er, file, etc).";

=C2=A0 If an administrator wants to disable a log action they should do it = by either removing it from the configuration, or by setting an "enable= d" leaf to false.
=C2=A0 With that in mind, there is no reason for the "no-facilities&qu= ot; case to exist.

* What is the behaviour of a selector if neither "no-facilities" = nor "facility-list" is present?
* In the "selector" grouping it is not clear how the facility and= pattern conditions are combined to decide whether a message is selected. =C2=A0 Must they both match the message, or is it sufficient for either one= to match the message?
* Not all servers have a console; there should be a feature to indicate whe= ther logging to the console is supported.
* Likewise, not all servers may support logging to user sessions.
* Likewise, not all servers may support a user-accessible filesystem.
* RFC 5424 states that the severity and protocol values are not normative.<= br> * It's not clear to me why this needs to be split into two modules. Is = it so that other modules can define logging parameters but still be usable = on a device without syslog?
* "log-severity" defines a severity filter, not a severity, so it= s name is misleading.
* Perhaps the "severity" type and the facility identities should = have "reference" statements referring to RFC 5424, rather than re= ferring to it in the description.
* In section "8.2", "admisintrator" is a typo.

I assume that the means of accessing the memory buffer and log files are ou= t of scope of this data model.

Alex

________________________________________
From: netmod <netmod-bounces@= ietf.org> on behalf of Kent Watsen <kwatsen@juniper.net>
Sent: Wednesday, 14 December 2016 2:01 p.m.
To: netmod@ietf.org
Subject: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
This is a notice to start a two-week NETMOD WG last call for the document:<= br>
=C2=A0 =C2=A0 A YANG Data Model for Syslog Configuration
=C2=A0 =C2=A0 https://tools.ietf.org/ht= ml/draft-ietf-netmod-syslog-model-11

Please indicate your support or concerns by Tuesday, December 27, 2016.

We are particularly interested in statements of the form:
=C2=A0 * I have reviewed this draft and found no issues.
=C2=A0 * I have reviewed this draft and found the following issues: ...

As well as:
=C2=A0 * I have implemented the data model in this draft.
=C2=A0 * I am implementing the data model in this draft.
=C2=A0 * I am considering to implement the data model in this draft.
=C2=A0 * I am not considering to implement the data model in this draft.
Thank you,
NETMOD WG Chairs



_______________________________________________
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

--001a114c877cb2e75c0544abe1c3-- From nobody Fri Dec 30 10:16:08 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5571294CF for ; Fri, 30 Dec 2016 10:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.022 X-Spam-Level: X-Spam-Status: No, score=-15.022 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, MANY_SPAN_IN_TEXT=2.599, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUjK55B3UnIg for ; Fri, 30 Dec 2016 10:16:03 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 585D01294C5 for ; Fri, 30 Dec 2016 10:16:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47874; q=dns/txt; s=iport; t=1483121763; x=1484331363; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=C5wOiMnDPBnycaXJUKV+o8IpdTqYskqFa3Qor59PLp0=; b=bmhmAn+k7hbGbkOvR2JSGBP/DfCJGy/KrOapgy0cX596pYhmNFa3lycc AGpmr1aenV4umjJ0FR3zaIQgeaHCLFvSKjvP9etS6pTxqrn7ntZoJQluE Zd982C8tA4rJEyh0WVbw9Y3gY7ZFo9G8VebSyOFiGlZU2PL8U9Q/jP0Uj Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAQBTo2ZY/5JdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnFGAQEBAQEfX4EMB41QlEWVG4IEAx8BCoUuSgIagUU/FAECAQE?= =?us-ascii?q?BAQEBAWIohGgBAQEEAQEbBksLEAIBCBEDAQEBIQEGAwICAiULFAkIAgQBDQWIc?= =?us-ascii?q?A6vD4IlK4oXAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGRYICCIJXhA4VDR0ZFoJ?= =?us-ascii?q?OLYIwBY8Gi3cBhlODEoMWhEKBdRiEcIlYji6EDgEfODF5Lg4Bg08CH4FecoZbD?= =?us-ascii?q?heBCoENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,432,1477958400"; d="scan'208,217";a="186562194" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Dec 2016 18:16:01 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id uBUIG147028279 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 30 Dec 2016 18:16:01 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 30 Dec 2016 12:16:01 -0600 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1210.000; Fri, 30 Dec 2016 12:16:01 -0600 From: "Clyde Wildes (cwildes)" To: Andy Bierman , Alex Campbell Thread-Topic: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 Thread-Index: AQHSVaWfIiJK4a4BSkqW0KAWiGRnmqEGzUbWgBYXToCAA+AjAA== Date: Fri, 30 Dec 2016 18:16:01 +0000 Message-ID: <3F4C49C9-1A6A-4644-97C6-F9CDC2E4EB4B@cisco.com> References: <19039254-973A-461A-8749-95F74C33DAD1@juniper.net> <1481689016940.22442@Aviatnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.27.7.182] Content-Type: multipart/alternative; boundary="_000_3F4C49C91A6A464497C6F9CDC2E4EB4Bciscocom_" MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 18:16:05 -0000 --_000_3F4C49C91A6A464497C6F9CDC2E4EB4Bciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KVGhhbmtzIGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gcmV2aWV3IHRoZSBtb2Rl bC4NCg0KTXkgY29tbWVudHMgYXJlIGlubGluZSBhcyBbY2x5ZGVd4oCmDQoNCkZyb206IG5ldG1v ZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBBbmR5IEJpZXJtYW4gPGFu ZHlAeXVtYXdvcmtzLmNvbT4NCkRhdGU6IFR1ZXNkYXksIERlY2VtYmVyIDI3LCAyMDE2IGF0IDM6 MDQgUE0NClRvOiBBbGV4IENhbXBiZWxsIDxBbGV4LkNhbXBiZWxsQEF2aWF0bmV0LmNvbT4NCkNj OiAibmV0bW9kQGlldGYub3JnIiA8bmV0bW9kQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtuZXRt b2RdIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsLTExDQoN CkhpLA0KDQpJIGFtIGFsc28gY29uc2lkZXJpbmcgYW4gaW1wbGVtZW50YXRpb24uDQpJIHNoYXJl IHRoZSBzYW1lIGNvbmNlcm5zIHRoYXQgQWxleCBoYXMgYnJvdWdodCB1cC4NCg0KU29tZSBkZXRh aWxlZCBjb21tZW50czoNCg0KMSkgL3N5c2xvZy9hY3Rpb25zOiBzZWVtcyBsaWtlIGV2ZXJ5dGhp bmcgaXMgaW4gdGhpcyBjb250YWluZXIuDQogV2h5IGlzIGl0IG5lZWRlZD8gIFNlZW1zIGxpa2Ug aXQgY291bGQgYmUgcmVtb3ZlZCBhcyBpdCBzZXJ2ZXMgbm8gcHVycG9zZQ0KDQpbY2x5ZGVdIEFs dGhvdWdoIHRoaXMgbW9kZWwgaXMgY3VycmVudGx5IGRlc2lnbmF0ZWQgYXMgY29uZmlnIG9ubHks IHdlIGNvdWxkIGFkZCBvcGVyYXRpb25hbCBkYXRhIGFuZCBycGMgbGVhdmVzIGluIHRoZSBmdXR1 cmUuIFRoZSBhY3Rpb25zIGNvbnRhaW5lciBpcyB0byBmdXR1cmUtcHJvb2YgdGhlIG1vZGVsLg0K DQoyKSA4IGZlYXR1cmVzOiB0aGUgZ3JhbnVsYXJpdHkgc2VlbXMgd3JvbmcuICBUaGUgbWFpbiBj b250YWluZXIgZm9yIGVhY2ggc2VjdGlvbg0KIHNob3VsZCBoYXZlIGl0cyBvd24gaWYtZmVhdHVy ZQ0KICAgICAgL2NvbnNvbGUNCiAgICAgIC9idWZmZXINCiAgICAgIC9maWxlDQogICAgICAvcmVt b3RlDQoNCltjbHlkZV0gV2UgaGF2ZSBnb25lIGJhY2sgYW5kIGZvcnRoIG9uIHRoaXPigKZzb21l IGhhdmUgY29tcGxhaW5lZCB0aGF0IHRoZXJlIGFyZSB0b28gbWFueSBmZWF0dXJlcy4gSSB3aWxs IGJlIGhhcHB5IHRvIGFkZCBhIGZlYXR1cmUgZm9yIGVhY2ggYWN0aW9uLiBOb3RlIHRoYXQgd2Ug c3R1ZGllZCB0aGUgaW1wbGVtZW50YXRpb24gb2YgZWFjaCBhY3Rpb24gYnkgc2l4IHZlbmRvcnMg aW5jbHVkaW5nIExpbnV4IGFuZCBvcHRlZCB0byBub3QgYWRkIGZlYXR1cmVzIGZvciBhY3Rpb25z IGltcGxlbWVudGVkIGJ5IGF0IGxlYXN0IDMgdmVuZG9ycy4gVmVuZG9ycyBub3QgaW1wbGVtZW50 aW5nIGFuIGFjdGlvbiBjb3VsZCBjcmVhdGUgYSBkZXZpYXRpb24uDQoNCjMpIFdoYXQgaXMgdGhl ICdidWZmZXInIGNvbnRhaW5lciBmb3I/DQogIEhvdyBpcyB0aGUgaW50ZXJuYWwgbWVtb3J5IGFj Y2Vzc2VkIGJ5IHRoZSBjbGllbnQ/DQoNCltjbHlkZV0gYnVmZmVyIGlzIGltcGxlbWVudGVkIGJ5 IHZlbmRvcnMgdHlwaWNhbGx5IGZvciByb3V0ZXJzIGNhcGFibGUgb2YgZ2VuZXJhdGluZyBtYW55 IHN5c2xvZyBtZXNzYWdlcyBpbiBldmVudC1zdG9ybSBidXJzdHMuIExvZ2dpbmcgdG8gbWVtb3J5 IChha2EgYnVmZmVyKSBhbGxvd3MgdGhlIHByZXNlcnZhdGlvbiBvZiBzeXNsb2cgbWVzc2FnZXMg d2hpY2ggbWlnaHQgb3RoZXJ3aXNlIGJlIGxvc3QuDQoNCkEg4oCcc2hvdyBsb2figJ0gY29tbWFu ZCBpcyB1c2VkIHRvIGFjY2VzcyB0aGUgYnVmZmVycy4gQXMgdGhpcyBtb2RlbCBpcyBjdXJyZW50 IGRlc2lnbmVkIGFzIGEgY29uZmlndXJhdGlvbiBvbmx5IG1vZGVsLCB0aGVyZSBpcyBubyBvcGVy YXRpb25hbCBsZWF2ZXMgZm9yIHNob3cgbG9nLCBvciBycGMgbGVhdmVzIGZvciBjbGVhciBsb2cu DQoNCjQpIHNlbGVjdG9yLWZhY2lsaXR5OiBTZWVtcyBsaWtlIG5vLWZhY2lsaXRpZXMgc2VydmVy cyB0aGUgc2FtZSBwdXJwb3NlDQogICAgYXMgYW4gZW1wdHkgZmFjaWxpdHktbGlzdC4gVGhlIGNo b2ljZSBpcyBub3QgbmVlZGVkOyBqdXN0IHVzZSB0aGUgZmFjaWxpdHktbGlzdA0KDQpbY2x5ZGVd IFRoaXMgd2FzIGNoYW5nZWQgYXMgYSByZXN1bHQgb2YgQWxleOKAmXMgZmVlZGJhY2sg4oCTIHBs ZWFzZSBzZWUgbXkgcmVzcG9uc2UgdG8gaGltLiBUaGUgbW9kZWwgd2lsbCBiZSBjaGFuZ2VkIHRv IHRoZSBmb2xsb3dpbmc6DQoNCg0KICAgIGNvbnRhaW5lciBzZWxlY3RvciB7DQoNCiAgICAgIGRl c2NyaXB0aW9uDQoNCiAgICAgICAgIlRoaXMgY29udGFpbmVyIGRlc2NyaWJlcyB0aGUgbG9nIHNl bGVjdG9yIHBhcmFtZXRlcnMNCg0KICAgICAgICAgZm9yIHN5c2xvZy4iOw0KDQogICAgICBsaXN0 IGZhY2lsaXR5LWxpc3Qgew0KDQogICAgICAgIGtleSBmYWNpbGl0eTsNCg0KICAgICAgICBkZXNj cmlwdGlvbg0KDQogICAgICAgICAgIlRoaXMgbGlzdCBkZXNjcmliZXMgYSBjb2xsZWN0aW9uIG9m IHN5c2xvZw0KDQogICAgICAgICAgIGZhY2lsaXRpZXMgYW5kIHNldmVyaXRpZXMuIjsNCg0KICAg ICAgICBsZWFmIGZhY2lsaXR5IHsNCg0KICAgICAgICAgIHR5cGUgdW5pb24gew0KDQogICAgICAg ICAgICB0eXBlIGlkZW50aXR5cmVmIHsNCg0KICAgICAgICAgICAgICBiYXNlIHN5c2xvZ3R5cGVz OnN5c2xvZy1mYWNpbGl0eTsNCg0KICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICB0eXBlIGVu dW1lcmF0aW9uIHsNCg0KICAgICAgICAgICAgICBlbnVtIGFsbCB7DQoNCiAgICAgICAgICAgICAg ICBkZXNjcmlwdGlvbg0KDQogICAgICAgICAgICAgICAgICAiVGhpcyBlbnVtIGRlc2NyaWJlcyB0 aGUgY2FzZSB3aGVyZSBhbGwNCg0KICAgICAgICAgICAgICAgICAgIGZhY2lsaXRpZXMgYXJlIHJl cXVlc3RlZC4iOw0KDQogICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgfQ0KDQogICAgICAg ICAgfQ0KDQogICAgICAgICAgZGVzY3JpcHRpb24NCg0KICAgICAgICAgICAgIlRoZSBsZWFmIHVu aXF1ZWx5IGlkZW50aWZpZXMgYSBzeXNsb2cgZmFjaWxpdHkuIjsNCg0KICAgICAgICB9DQoNCiAg ICAgICAgdXNlcyBsb2ctc2V2ZXJpdHk7DQoNCiAgICAgIH0NCg0KICAgICAgbGVhZiBwYXR0ZXJu LW1hdGNoIHsNCg0KICAgICAgICBpZi1mZWF0dXJlIHNlbGVjdC1tYXRjaDsNCg0KICAgICAgICB0 eXBlIHN0cmluZzsNCg0KICAgICAgICBkZXNjcmlwdGlvbg0KDQogICAgICAgICAgIlRoaXMgbGVh ZiBkZXNyaWJlcyBhIFBvc2l4IDEwMDMuMiByZWd1bGFyIGV4cHJlc3Npb24NCg0KICAgICAgICAg ICBzdHJpbmcgdGhhdCBjYW4gYmUgdXNlZCB0byBzZWxlY3QgYSBzeXNsb2cgbWVzc2FnZSBmb3IN Cg0KICAgICAgICAgICBsb2dnaW5nLiBUaGUgbWF0Y2ggaXMgcGVyZm9ybWVkIG9uIHRoZSBSRkMg NTQyNA0KDQogICAgICAgICAgIFNZU0xPRy1NU0cgZmllbGQuIjsNCg0KICAgICAgfQ0KDQoNCjUp IHBhdHRlcm4tbWF0Y2g6DQoNCg0KICAgICAgbGVhZiBwYXR0ZXJuLW1hdGNoIHsNCg0KICAgICAg ICBpZi1mZWF0dXJlIHNlbGVjdC1tYXRjaDsNCg0KICAgICAgICB0eXBlIHN0cmluZzsNCg0KICAg ICAgICBkZXNjcmlwdGlvbg0KDQogICAgICAgICAgIlRoaXMgbGVhZiBkZXNyaWJlcyBhIFBvc2l4 IDEwMDMuMiByZWd1bGFyIGV4cHJlc3Npb24NCg0KICAgICAgICAgICBzdHJpbmcgdGhhdCBjYW4g YmUgdXNlZCB0byBzZWxlY3QgYSBzeXNsb2cgbWVzc2FnZSBmb3INCg0KICAgICAgICAgICBsb2dn aW5nLiBUaGUgbWF0Y2ggaXMgcGVyZm9ybWVkIG9uIHRoZSBSRkMgNTQyNA0KDQogICAgICAgICAg IFNZU0xPRy1NU0cgZmllbGQuIjsNCg0KICAgICAgfQ0KDQoNClRoZSBmaWVsZCBTWVNMT0ctTVNH IGlzIHJlZmVyZW5jZWQgYnV0IG5ldmVyIGRlZmluZWQgb3IgbGlzdGVkIGluDQp0aGUgdGVybWlu b2xvZ3kgc2VjdGlvbi4NCg0KW2NseWRlXSBUaGlzIHdpbGwgYmUgZml4ZWQgaW4gdGhlIG5leHQg ZHJhZnQuDQoNCjYpIGhvdyBhcmUgdGhlIHN5c2xvZy1mYWNpbGl0eSBpZGVudGl0aWVzIG1hcHBl ZCB0byBTWVNMT0cgbWVzc2FnZXM/DQo2YSkgaG93IHRvIGRpc3Rpbmd1aXNoIGFjbWU6Zm9vLWZh Y2lsaXR5IGZyb20gZXhhbXBsZTpmb28tZmFjaWxpdHkgaW4gYSBTWVNMT0cgbWVzc2FnZT8NCg0K W2NseWRlXSBJIGRvIG5vdCB1bmRlcnN0YW5kIHlvdXIgcXVlc3Rpb24uIFRoZSBjdXJyZW50IGlt cGxlbWVudGF0aW9uIG9mIGZhY2lsaXRpZXMgd2FzIGRlc2lnbmVkIHdpdGggdGhlIGhlbHAgb2Yg c2V2ZXJhbCBZYW5nIERvY3RvcnMuIFRoZSByZXF1aXJlbWVudCBpcyB0byBzdXBwb3J0IHRoZSBm YWNpbGl0aWVzIGFzIGNhbGxlZCBvdXQgaW4gUkZDIDU0MjQgYXMgd2VsbCBhcyB2ZW5kb3Igc3Bl Y2lmaWMgZmFjaWxpdGllcyB0aGF0IGNhbiBiZSBhZGRlZCB0aHJvdWdoIGF1Z21lbnRhdGlvbi4g VmVuZG9yIHNwZWNpZmljIGZhY2lsaXRpZXMgYXJlIG5vdCBtZWFudCB0byBiZSB1c2VkIGFjcm9z cyBtdWx0aXBsZSB2ZW5kb3IgaW1wbGVtZW50YXRpb25zLg0KDQo3KSBzb3VyY2UtaW50ZXJmYWNl OiB3aGF0IGlmIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbGV0IGEgc291cmNlIGludGVyZmFjZSBiZSB1 c2VkIGFuZCBpbnN0ZWFkDQogICAgbm9ybWFsIHJvdXRpbmcgZGV0ZXJtaW5lcyB0aGUgc291cmNl IGludGVyZmFjZSAodGhpcyBsZWFmIGlzIHZlcnkgcm91dGVyLWNlbnRyaWMpDQoNCltjbHlkZV0g c291cmNlLWludGVyZmFjZSBpcyBvcHRpb25hbC4gSWYgbm90IHNwZWNpZmllZCBub3JtYWwgcm91 dGluZyBmbG93IHdvdWxkIGJlIHVzZWQuDQoNCjgpIHNpZ25pbmctb3B0aW9uczogYXJlIHRoZXNl IHdpZGVseSBkZXBsb3llZCBvbiBhbGwgcm91dGVycyBhbmQgTGludXggaG9zdHM/DQoNCltjbHlk ZV0gQWxleCBDbGVtbSBhc2tlZCB0aGF0IHdlIGluY2x1ZGUgc3lzbG9nIHNpZ25pbmctb3B0aW9u cy4gVGhpcyBpcyBpbXBsZW1lbnRlZCBieSBhdCBsZWFzdCBMaW51eCByc3lzbG9nLg0KDQo5KSBs b2dyb3RhdGU6IHRoZXJlIGFyZSBzZXZlcmFsIGZlYXR1cmVzIHJlbGF0ZWQgdG8gbG9nIGZpbGUg Y2xlYW51cCBhbGxvd2luZyBsb3RzIG9mDQogICAgc2VydmVyIHZhcmlhYmlsaXR5IGFuZCBmb3Jj ZXMgdGhlIGNsaWVudCB0byBzdXBwb3J0IGFsbCB0aGUgb3B0aW9ucy4gIENhbid0IHRoaXMgYmUg c2ltcGxpZmllZA0KICAgYW5kIGFsbCB0aGUgbWljcm8tYmVoYXZpb3IgWUFORyBmZWF0dXJlcyBy ZW1vdmVkPw0KDQpbY2x5ZGVdIFRoaXMgd2FzIGRlc2lnbmVkIGJ5IG1lcmdpbmcgdGhlIHJlcXVp cmVtZW50cyBmcm9tIHNldmVyYWwgdmVuZG9ycy4gQWxsIG9mIHRoZSB2YXJpYW50cyBzcGVjaWZp ZWQgYXJlIHdpdGggaWYtZmVhdHVyZSBzbyB0aGF0IHRoZSBjbGllbnQgZG9lcyBub3QgaGF2ZSB0 byBzdXBwb3J0IGFsbCBvcHRpb25zLg0KDQoxMCkgbnVtZXJpYyBsaW1pdHM6IHRoZXJlIGlzIHNv bWUgb2RkIHVzYWdlIG9mIFlBTkcgdHlwZXM7IHNvbWUgbGltaXRzIGFyZSB1aW50NjQsIHNvbWUg dWludDMyLA0Kc29tZSB1aW50MTYuICBTZWVtcyBsaWtlIHVpbnQzMiBpcyBzdWZmaWNpZW50DQoN CltjbHlkZV0gIFRoZSBzaWduaW5nLW9wdGlvbnMgY291bnRzIGFyZSBhcyBwZXIgdGhlIHN5c2xv Zy1zaWduIHNwZWMgKFJGQyA1ODQ4KSB3aGljaCBpcyB1aW50MTYuIEkgd2lsbCBtYWtlIGFsbCBv dGhlcnMgdWludDMyIGV4Y2VwdCBmb3IgdGhlIGJ1ZmZlciBzaXplIGxpbWl0IHdoaWNoIEkgd2ls bCBsZWF2ZSBhdCB1bml0NjQuDQoNClJlc3VsdDoNCjxzZXZlbiBzaWduaW5nLW9wdGlvbnMgY291 bnRlcnM+IHVpbnQxNg0KYnVmZmVyLWxpbWl0LWJ5dGVzIHVpbnQ2NA0KYnVmZmVyLWxpbWl0LW1l c3NhZ2VzIHVpbnQzMiAod2FzIGZvcm1hbGx5IHVpbnQ2NCkNCm51bWJlci1vZi1maWxlcyB1aW50 MzINCm1heC1maWxlLXNpemUgdWludDMyICh3YXMgZm9ybWFsbHkgdWludDY0KQ0Kcm9sbG92ZXIg dW5pdDMyDQpyZXRlbnRpb24gdW5pdDMyICh3YXMgZm9ybWFsbHkgdWludDE2KQ0KDQoNClRoYW5r cywNCg0KQ2x5ZGUNCg0KDQpBbmR5DQoNCg0KT24gVHVlLCBEZWMgMTMsIDIwMTYgYXQgODoxNiBQ TSwgQWxleCBDYW1wYmVsbCA8QWxleC5DYW1wYmVsbEBhdmlhdG5ldC5jb208bWFpbHRvOkFsZXgu Q2FtcGJlbGxAYXZpYXRuZXQuY29tPj4gd3JvdGU6DQpJIGFtIGNvbnNpZGVyaW5nIHRvIGltcGxl bWVudCB0aGUgZGF0YSBtb2RlbCBpbiB0aGlzIGRyYWZ0Lg0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhp cyBkcmFmdCBhbmQgZm91bmQgdGhlIGZvbGxvd2luZyBpc3N1ZXMuIEluIGFwcHJveGltYXRlbHkg ZGVjcmVhc2luZyBvcmRlciBvZiBzZXZlcml0eToNCg0KKiBJbiB0aGUgInNlbGVjdG9yLWZhY2ls aXR5IiBjaG9pY2Ugc3RhdGVtZW50IHRoZSBjYXNlcyBoYXZlIG1pc2xlYWRpbmcgbmFtZXMgLSB0 aGUgY2FzZSB3aGVyZSBubyBmYWNpbGl0eSBpcyBtYXRjaGVkIGlzIG5hbWVkICJmYWNpbGl0eSIs IGFuZCB0aGUgY2FzZSB3aGVyZSBzcGVjaWZpYyBmYWNpbGl0aWVzIGFyZSBtYXRjaGVkIGlzIG5h bWVkICJuYW1lIi4gSSBzdWdnZXN0ICJuby1mYWNpbGl0aWVzIiBhbmQgInNwZWNpZmllZC1mYWNp bGl0aWVzIiwgb3Igc2ltaWxhci4NCg0KKiBJIGRpc2FncmVlIHdpdGggdGhlIHByZW1pc2Ugb2Yg dGhlICJuby1mYWNpbGl0aWVzIiBjYXNlLCB3aGljaCBpcyB0aGF0IGl0IGNhbiBiZSB1c2VkIHRv IGRpc2FibGUgYSBsb2cgYWN0aW9uLCBhY2NvcmRpbmcgdG8gdGhlIGRlc2NyaXB0aW9uOg0KDQog ICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAiVGhpcyBjYXNlIHNwZWNpZmllcyBubyBmYWNp bGl0aWVzIHdpbGwgbWF0Y2ggd2hlbg0KICAgICAgICAgICAgIGNvbXBhcmluZyB0aGUgc3lzbG9n IG1lc3NhZ2UgZmFjaWxpdHkuIFRoaXMgaXMgYQ0KICAgICAgICAgICAgIG1ldGhvZCB0aGF0IGNh biBiZSB1c2VkIHRvIGVmZmVjdGl2ZWx5IGRpc2FibGUgYQ0KICAgICAgICAgICAgIHBhcnRpY3Vs YXIgbG9nLWFjdGlvbiAoYnVmZmVyLCBmaWxlLCBldGMpLiI7DQoNCiAgSWYgYW4gYWRtaW5pc3Ry YXRvciB3YW50cyB0byBkaXNhYmxlIGEgbG9nIGFjdGlvbiB0aGV5IHNob3VsZCBkbyBpdCBieSBl aXRoZXIgcmVtb3ZpbmcgaXQgZnJvbSB0aGUgY29uZmlndXJhdGlvbiwgb3IgYnkgc2V0dGluZyBh biAiZW5hYmxlZCIgbGVhZiB0byBmYWxzZS4NCiAgV2l0aCB0aGF0IGluIG1pbmQsIHRoZXJlIGlz IG5vIHJlYXNvbiBmb3IgdGhlICJuby1mYWNpbGl0aWVzIiBjYXNlIHRvIGV4aXN0Lg0KDQoqIFdo YXQgaXMgdGhlIGJlaGF2aW91ciBvZiBhIHNlbGVjdG9yIGlmIG5laXRoZXIgIm5vLWZhY2lsaXRp ZXMiIG5vciAiZmFjaWxpdHktbGlzdCIgaXMgcHJlc2VudD8NCiogSW4gdGhlICJzZWxlY3RvciIg Z3JvdXBpbmcgaXQgaXMgbm90IGNsZWFyIGhvdyB0aGUgZmFjaWxpdHkgYW5kIHBhdHRlcm4gY29u ZGl0aW9ucyBhcmUgY29tYmluZWQgdG8gZGVjaWRlIHdoZXRoZXIgYSBtZXNzYWdlIGlzIHNlbGVj dGVkLg0KICBNdXN0IHRoZXkgYm90aCBtYXRjaCB0aGUgbWVzc2FnZSwgb3IgaXMgaXQgc3VmZmlj aWVudCBmb3IgZWl0aGVyIG9uZSB0byBtYXRjaCB0aGUgbWVzc2FnZT8NCiogTm90IGFsbCBzZXJ2 ZXJzIGhhdmUgYSBjb25zb2xlOyB0aGVyZSBzaG91bGQgYmUgYSBmZWF0dXJlIHRvIGluZGljYXRl IHdoZXRoZXIgbG9nZ2luZyB0byB0aGUgY29uc29sZSBpcyBzdXBwb3J0ZWQuDQoqIExpa2V3aXNl LCBub3QgYWxsIHNlcnZlcnMgbWF5IHN1cHBvcnQgbG9nZ2luZyB0byB1c2VyIHNlc3Npb25zLg0K KiBMaWtld2lzZSwgbm90IGFsbCBzZXJ2ZXJzIG1heSBzdXBwb3J0IGEgdXNlci1hY2Nlc3NpYmxl IGZpbGVzeXN0ZW0uDQoqIFJGQyA1NDI0IHN0YXRlcyB0aGF0IHRoZSBzZXZlcml0eSBhbmQgcHJv dG9jb2wgdmFsdWVzIGFyZSBub3Qgbm9ybWF0aXZlLg0KKiBJdCdzIG5vdCBjbGVhciB0byBtZSB3 aHkgdGhpcyBuZWVkcyB0byBiZSBzcGxpdCBpbnRvIHR3byBtb2R1bGVzLiBJcyBpdCBzbyB0aGF0 IG90aGVyIG1vZHVsZXMgY2FuIGRlZmluZSBsb2dnaW5nIHBhcmFtZXRlcnMgYnV0IHN0aWxsIGJl IHVzYWJsZSBvbiBhIGRldmljZSB3aXRob3V0IHN5c2xvZz8NCiogImxvZy1zZXZlcml0eSIgZGVm aW5lcyBhIHNldmVyaXR5IGZpbHRlciwgbm90IGEgc2V2ZXJpdHksIHNvIGl0cyBuYW1lIGlzIG1p c2xlYWRpbmcuDQoqIFBlcmhhcHMgdGhlICJzZXZlcml0eSIgdHlwZSBhbmQgdGhlIGZhY2lsaXR5 IGlkZW50aXRpZXMgc2hvdWxkIGhhdmUgInJlZmVyZW5jZSIgc3RhdGVtZW50cyByZWZlcnJpbmcg dG8gUkZDIDU0MjQsIHJhdGhlciB0aGFuIHJlZmVycmluZyB0byBpdCBpbiB0aGUgZGVzY3JpcHRp b24uDQoqIEluIHNlY3Rpb24gIjguMiIsICJhZG1pc2ludHJhdG9yIiBpcyBhIHR5cG8uDQoNCkkg YXNzdW1lIHRoYXQgdGhlIG1lYW5zIG9mIGFjY2Vzc2luZyB0aGUgbWVtb3J5IGJ1ZmZlciBhbmQg bG9nIGZpbGVzIGFyZSBvdXQgb2Ygc2NvcGUgb2YgdGhpcyBkYXRhIG1vZGVsLg0KDQpBbGV4DQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IG5ldG1vZCA8 bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPj4g b24gYmVoYWxmIG9mIEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0PG1haWx0bzprd2F0 c2VuQGp1bmlwZXIubmV0Pj4NClNlbnQ6IFdlZG5lc2RheSwgMTQgRGVjZW1iZXIgMjAxNiAyOjAx IHAubS4NClRvOiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NClN1Ympl Y3Q6IFtuZXRtb2RdIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1v ZGVsLTExDQoNClRoaXMgaXMgYSBub3RpY2UgdG8gc3RhcnQgYSB0d28td2VlayBORVRNT0QgV0cg bGFzdCBjYWxsIGZvciB0aGUgZG9jdW1lbnQ6DQoNCiAgICBBIFlBTkcgRGF0YSBNb2RlbCBmb3Ig U3lzbG9nIENvbmZpZ3VyYXRpb24NCiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsLTExDQoNClBsZWFzZSBpbmRpY2F0ZSB5b3VyIHN1 cHBvcnQgb3IgY29uY2VybnMgYnkgVHVlc2RheSwgRGVjZW1iZXIgMjcsIDIwMTYuDQoNCldlIGFy ZSBwYXJ0aWN1bGFybHkgaW50ZXJlc3RlZCBpbiBzdGF0ZW1lbnRzIG9mIHRoZSBmb3JtOg0KICAq IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRyYWZ0IGFuZCBmb3VuZCBubyBpc3N1ZXMuDQogICogSSBo YXZlIHJldmlld2VkIHRoaXMgZHJhZnQgYW5kIGZvdW5kIHRoZSBmb2xsb3dpbmcgaXNzdWVzOiAu Li4NCg0KQXMgd2VsbCBhczoNCiAgKiBJIGhhdmUgaW1wbGVtZW50ZWQgdGhlIGRhdGEgbW9kZWwg aW4gdGhpcyBkcmFmdC4NCiAgKiBJIGFtIGltcGxlbWVudGluZyB0aGUgZGF0YSBtb2RlbCBpbiB0 aGlzIGRyYWZ0Lg0KICAqIEkgYW0gY29uc2lkZXJpbmcgdG8gaW1wbGVtZW50IHRoZSBkYXRhIG1v ZGVsIGluIHRoaXMgZHJhZnQuDQogICogSSBhbSBub3QgY29uc2lkZXJpbmcgdG8gaW1wbGVtZW50 IHRoZSBkYXRhIG1vZGVsIGluIHRoaXMgZHJhZnQuDQoNClRoYW5rIHlvdSwNCk5FVE1PRCBXRyBD aGFpcnMNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2Qg bWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg== --_000_3F4C49C91A6A464497C6F9CDC2E4EB4Bciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <87805C608DEDBF41A1088CA1816210BA@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpNb25hY287DQoJcGFub3NlLTE6MiAwIDUgMCAwIDAgMCAwIDAg MDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpD b3VyaWVyO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6d2luZG93dGV4dDsNCglm b250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0KcC5wMSwgbGkucDEsIGRp di5wMQ0KCXttc28tc3R5bGUtbmFtZTpwMTsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC41cHQ7DQoJZm9udC1mYW1pbHk6TW9uYWNvO30NCnAucDIs IGxpLnAyLCBkaXYucDINCgl7bXNvLXN0eWxlLW5hbWU6cDI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguNXB0Ow0KCWZvbnQtZmFtaWx5Ok1vbmFj bzsNCgljb2xvcjojOTMxQTY4O30NCnAucDMsIGxpLnAzLCBkaXYucDMNCgl7bXNvLXN0eWxlLW5h bWU6cDM7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjguNXB0Ow0KCWZvbnQtZmFtaWx5Ok1vbmFjbzsNCgljb2xvcjojMzkzM0ZGO30NCnNwYW4uczEN Cgl7bXNvLXN0eWxlLW5hbWU6czE7DQoJY29sb3I6IzkzMUE2ODt9DQpzcGFuLnMyDQoJe21zby1z dHlsZS1uYW1lOnMyOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNl DQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLm1zb0lucw0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkhpIEFuZHksPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGFua3MgZm9yIHRha2luZyB0 aGUgdGltZSB0byByZXZpZXcgdGhlIG1vZGVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TXkgY29tbWVudHMgYXJlIGlubGluZSBhcyBb Y2x5ZGVd4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD YWxpYnJpO2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPm5ldG1vZCAmbHQ7bmV0bW9kLWJvdW5jZXNAaWV0 Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBBbmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNv bSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgRGVjZW1iZXIgMjcsIDIwMTYgYXQgMzow NCBQTTxicj4NCjxiPlRvOiA8L2I+QWxleCBDYW1wYmVsbCAmbHQ7QWxleC5DYW1wYmVsbEBBdmlh dG5ldC5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtuZXRtb2RAaWV0Zi5vcmcmcXVvdDsg Jmx0O25ldG1vZEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtuZXRtb2Rd IFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsLTExPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I aSwgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIGFs c28gY29uc2lkZXJpbmcgYW4gaW1wbGVtZW50YXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHNoYXJlIHRoZSBzYW1lIGNvbmNlcm5zIHRo YXQgQWxleCBoYXMgYnJvdWdodCB1cC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U29tZSBkZXRhaWxlZCBjb21tZW50czo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MSkgL3N5c2xvZy9hY3Rp b25zOiBzZWVtcyBsaWtlIGV2ZXJ5dGhpbmcgaXMgaW4gdGhpcyBjb250YWluZXIuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtXaHkgaXMg aXQgbmVlZGVkPyZuYnNwOyBTZWVtcyBsaWtlIGl0IGNvdWxkIGJlIHJlbW92ZWQgYXMgaXQgc2Vy dmVzIG5vIHB1cnBvc2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W2NseWRlXSBBbHRob3VnaCB0 aGlzIG1vZGVsIGlzIGN1cnJlbnRseSBkZXNpZ25hdGVkIGFzIGNvbmZpZyBvbmx5LCB3ZSBjb3Vs ZCBhZGQgb3BlcmF0aW9uYWwgZGF0YSBhbmQgcnBjIGxlYXZlcyBpbiB0aGUgZnV0dXJlLiBUaGUg YWN0aW9ucyBjb250YWluZXIgaXMgdG8gZnV0dXJlLXByb29mIHRoZSBtb2RlbC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MikgOCBmZWF0dXJl czogdGhlIGdyYW51bGFyaXR5IHNlZW1zIHdyb25nLiZuYnNwOyBUaGUgbWFpbiBjb250YWluZXIg Zm9yIGVhY2ggc2VjdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7c2hvdWxkIGhhdmUgaXRzIG93biBpZi1mZWF0dXJlPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAvY29uc29sZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgL2J1ZmZlcjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg L2ZpbGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDsgJm5ic3A7IC9yZW1vdGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W2Ns eWRlXSBXZSBoYXZlIGdvbmUgYmFjayBhbmQgZm9ydGggb24gdGhpc+KApnNvbWUgaGF2ZSBjb21w bGFpbmVkIHRoYXQgdGhlcmUgYXJlIHRvbyBtYW55IGZlYXR1cmVzLiBJIHdpbGwgYmUgaGFwcHkg dG8gYWRkIGEgZmVhdHVyZSBmb3IgZWFjaCBhY3Rpb24uIE5vdGUgdGhhdCB3ZSBzdHVkaWVkIHRo ZSBpbXBsZW1lbnRhdGlvbiBvZiBlYWNoIGFjdGlvbiBieSBzaXggdmVuZG9ycyBpbmNsdWRpbmcg TGludXggYW5kDQogb3B0ZWQgdG8gbm90IGFkZCBmZWF0dXJlcyBmb3IgYWN0aW9ucyBpbXBsZW1l bnRlZCBieSBhdCBsZWFzdCAzIHZlbmRvcnMuIFZlbmRvcnMgbm90IGltcGxlbWVudGluZyBhbiBh Y3Rpb24gY291bGQgY3JlYXRlIGEgZGV2aWF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zKSBXaGF0IGlzIHRoZSAnYnVmZmVyJyBjb250 YWluZXIgZm9yPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7IEhvdyBpcyB0aGUgaW50ZXJuYWwgbWVtb3J5IGFjY2Vzc2VkIGJ5IHRoZSBj bGllbnQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltjbHlkZV0gYnVmZmVyIGlzIGltcGxlbWVu dGVkIGJ5IHZlbmRvcnMgdHlwaWNhbGx5IGZvciByb3V0ZXJzIGNhcGFibGUgb2YgZ2VuZXJhdGlu ZyBtYW55IHN5c2xvZyBtZXNzYWdlcyBpbiBldmVudC1zdG9ybSBidXJzdHMuIExvZ2dpbmcgdG8g bWVtb3J5IChha2EgYnVmZmVyKSBhbGxvd3MgdGhlIHByZXNlcnZhdGlvbiBvZiBzeXNsb2cgbWVz c2FnZXMgd2hpY2ggbWlnaHQgb3RoZXJ3aXNlIGJlIGxvc3QuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkEg4oCcc2hvdyBsb2figJ0gY29tbWFuZCBpcyB1c2VkIHRvIGFjY2VzcyB0aGUgYnVmZmVy cy4gQXMgdGhpcyBtb2RlbCBpcyBjdXJyZW50IGRlc2lnbmVkIGFzIGEgY29uZmlndXJhdGlvbiBv bmx5IG1vZGVsLCB0aGVyZSBpcyBubyBvcGVyYXRpb25hbCBsZWF2ZXMgZm9yIHNob3cgbG9nLCBv ciBycGMgbGVhdmVzIGZvciBjbGVhciBsb2cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjQpIHNlbGVjdG9yLWZhY2lsaXR5OiBTZWVtcyBsaWtl IG5vLWZhY2lsaXRpZXMgc2VydmVycyB0aGUgc2FtZSBwdXJwb3NlPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IGFzIGFuIGVt cHR5IGZhY2lsaXR5LWxpc3QuIFRoZSBjaG9pY2UgaXMgbm90IG5lZWRlZDsganVzdCB1c2UgdGhl IGZhY2lsaXR5LWxpc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W2NseWRlXSBUaGlzIHdhcyBj aGFuZ2VkIGFzIGEgcmVzdWx0IG9mIEFsZXjigJlzIGZlZWRiYWNrIOKAkyBwbGVhc2Ugc2VlIG15 IHJlc3BvbnNlIHRvIGhpbS4gVGhlIG1vZGVsIHdpbGwgYmUgY2hhbmdlZCB0byB0aGUgZm9sbG93 aW5nOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0icDEiPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOyAmbmJzcDsgPC9zcGFuPjxzcGFuIGNsYXNzPSJzMSI+Y29udGFpbmVyPC9zcGFuPiBz ZWxlY3RvciB7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0icDIiPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ZGVzY3JpcHRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJwMyI+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PHNwYW4gY2xhc3M9InMyIj4mcXVvdDs8L3NwYW4+VGhpcyBjb250YWluZXIgZGVzY3JpYmVzIHRo ZSBsb2cgc2VsZWN0b3IgcGFyYW1ldGVyczxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJwMyI+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IDwvc3Bhbj5mb3Igc3lzbG9nLjxzcGFuIGNsYXNzPSJzMiI+JnF1b3Q7Ozwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJwMSI+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgPC9zcGFuPjxzcGFuIGNsYXNzPSJzMSI+bGlzdDwv c3Bhbj4gZmFjaWxpdHktbGlzdCB7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0icDEiPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyA8L3NwYW4+PHNwYW4gY2xhc3M9InMxIj5rZXk8L3NwYW4+IGZhY2lsaXR5OzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9InAyIj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KPC9z cGFuPjwvc3Bhbj5kZXNjcmlwdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9InAzIj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PHNwYW4g Y2xhc3M9InMyIj4mcXVvdDs8L3NwYW4+VGhpcyBsaXN0IGRlc2NyaWJlcyBhIGNvbGxlY3Rpb24g b2Ygc3lzbG9nPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9InAzIj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvc3Bh bj5mYWNpbGl0aWVzIGFuZCBzZXZlcml0aWVzLjxzcGFuIGNsYXNzPSJzMiI+JnF1b3Q7Ozwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJwMSI+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvc3Bhbj48c3BhbiBjbGFz cz0iczEiPmxlYWY8L3NwYW4+IGZhY2lsaXR5IHs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJw MSI+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyA8L3NwYW4+PHNwYW4gY2xhc3M9InMxIj50eXBlPC9zcGFuPg0KPHNw YW4gY2xhc3M9InMxIj51bmlvbjwvc3Bhbj4gezxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9InAx Ij48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L3NwYW4+PHNwYW4gY2xhc3M9InMxIj50eXBlPC9zcGFu Pg0KPHNwYW4gY2xhc3M9InMxIj5pZGVudGl0eXJlZjwvc3Bhbj4gezxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9InAxIj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPC9zcGFuPjxzcGFuIGNs YXNzPSJzMSI+YmFzZTwvc3Bhbj4gc3lzbG9ndHlwZXM6c3lzbG9nLWZhY2lsaXR5OzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9InAxIj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L3NwYW4+fTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9InAxIj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L3NwYW4+PHNw YW4gY2xhc3M9InMxIj50eXBlPC9zcGFuPg0KPHNwYW4gY2xhc3M9InMxIj5lbnVtZXJhdGlvbjwv c3Bhbj4gezxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9InAxIj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgPC9zcGFuPjxzcGFuIGNsYXNzPSJzMSI+ZW51bTwvc3Bhbj4gYWxsIHs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJwMSI+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyA8L3NwYW4+PHNwYW4gY2xhc3M9InMxIj5kZXNjcmlwdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJwMyI+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0i czIiPiZxdW90Ozwvc3Bhbj5UaGlzIGVudW0gZGVzY3JpYmVzIHRoZSBjYXNlIHdoZXJlIGFsbDxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJwMyI+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgPC9zcGFuPmZhY2lsaXRpZXMgYXJlIHJlcXVlc3RlZC48c3BhbiBjbGFzcz0i czIiPiZxdW90Ozs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0icDEiPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyA8L3NwYW4+fTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9InAx Ij48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L3NwYW4+fTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 InAxIj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IDwvc3Bhbj59PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0icDIi PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KPC9zcGFuPjwvc3Bhbj5k ZXNjcmlwdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9InAzIj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQo8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNz PSJzMiI+JnF1b3Q7PC9zcGFuPlRoZSBsZWFmIHVuaXF1ZWx5IGlkZW50aWZpZXMgYSBzeXNsb2cg ZmFjaWxpdHkuPHNwYW4gY2xhc3M9InMyIj4mcXVvdDs7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9InAxIj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgPC9zcGFuPn08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJw MSI+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IDwvc3Bhbj48c3BhbiBjbGFzcz0iczEiPnVzZXM8L3NwYW4+IGxvZy1zZXZlcml0 eTs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJwMSI+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgPC9zcGFuPn08bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJwMSI+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgPC9zcGFuPjxzcGFuIGNsYXNzPSJzMSI+bGVhZjwvc3Bhbj4gcGF0dGVy bi1tYXRjaCB7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0icDEiPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L3NwYW4+PHNw YW4gY2xhc3M9InMxIj5pZi1mZWF0dXJlPC9zcGFuPiBzZWxlY3QtbWF0Y2g7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0icDEiPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L3NwYW4+PHNwYW4gY2xhc3M9InMxIj50eXBlPC9z cGFuPiBzdHJpbmc7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0icDIiPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQo8L3NwYW4+PC9zcGFuPmRlc2NyaXB0aW9uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0icDMiPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iczIiPiZxdW90Ozwvc3Bhbj5UaGlzIGxlYWYg ZGVzcmliZXMgYSBQb3NpeCAxMDAzLjIgcmVndWxhciBleHByZXNzaW9uPHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9InAzIj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvc3Bhbj5zdHJpbmcgdGhhdCBjYW4gYmUgdXNl ZCB0byBzZWxlY3QgYSBzeXNsb2cgbWVzc2FnZSBmb3I8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0icDMiPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgPC9zcGFuPmxvZ2dpbmcuIFRoZSBtYXRjaCBpcyBwZXJmb3JtZWQg b24gdGhlIFJGQyA1NDI0PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9InAzIj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDwvc3Bhbj5TWVNMT0ctTVNHIGZpZWxkLjxzcGFuIGNsYXNzPSJzMiI+JnF1b3Q7Ozwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJwMSI+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgPC9zcGFuPn08bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj41KSBwYXR0ZXJuLW1hdGNoOiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFr LXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgcGF0dGVybi1tYXRjaCB7PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlmLWZlYXR1cmUgc2VsZWN0LW1hdGNo OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBlIHN0cmluZzs8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRpb248bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7 VGhpcyBsZWFmIGRlc3JpYmVzIGEgUG9zaXggMTAwMy4yIHJlZ3VsYXIgZXhwcmVzc2lvbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBz dHJpbmcgdGhhdCBjYW4gYmUgdXNlZCB0byBzZWxlY3QgYSBzeXNsb2cgbWVzc2FnZSBmb3I8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg bG9nZ2luZy4gVGhlIG1hdGNoIGlzIHBlcmZvcm1lZCBvbiB0aGUgUkZDIDU0MjQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU1lTTE9H LU1TRyBmaWVsZC4mcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO3doaXRl LXNwYWNlOnByZS13cmFwIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGZpZWxkIFNZU0xPRy1N U0cgaXMgcmVmZXJlbmNlZCBidXQgbmV2ZXIgZGVmaW5lZCBvciBsaXN0ZWQgaW48YnI+DQp0aGUg dGVybWlub2xvZ3kgc2VjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W2NseWRlXSBUaGlz IHdpbGwgYmUgZml4ZWQgaW4gdGhlIG5leHQgZHJhZnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjYpIGhvdyBhcmUgdGhlIHN5c2xvZy1mYWNp bGl0eSBpZGVudGl0aWVzIG1hcHBlZCB0byBTWVNMT0cgbWVzc2FnZXM/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj42YSkgaG93IHRvIGRpc3Rpbmd1 aXNoIGFjbWU6Zm9vLWZhY2lsaXR5IGZyb20gZXhhbXBsZTpmb28tZmFjaWxpdHkgaW4gYSBTWVNM T0cgbWVzc2FnZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W2NseWRlXSBJIGRvIG5vdCB1bmRl cnN0YW5kIHlvdXIgcXVlc3Rpb24uIFRoZSBjdXJyZW50IGltcGxlbWVudGF0aW9uIG9mIGZhY2ls aXRpZXMgd2FzIGRlc2lnbmVkIHdpdGggdGhlIGhlbHAgb2Ygc2V2ZXJhbCBZYW5nIERvY3RvcnMu IFRoZSByZXF1aXJlbWVudCBpcyB0byBzdXBwb3J0IHRoZSBmYWNpbGl0aWVzIGFzIGNhbGxlZCBv dXQgaW4gUkZDIDU0MjQgYXMgd2VsbCBhcyB2ZW5kb3Igc3BlY2lmaWMgZmFjaWxpdGllcw0KIHRo YXQgY2FuIGJlIGFkZGVkIHRocm91Z2ggYXVnbWVudGF0aW9uLiBWZW5kb3Igc3BlY2lmaWMgZmFj aWxpdGllcyBhcmUgbm90IG1lYW50IHRvIGJlIHVzZWQgYWNyb3NzIG11bHRpcGxlIHZlbmRvciBp bXBsZW1lbnRhdGlvbnMuPGk+PG86cD48L286cD48L2k+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj43KSBzb3VyY2UtaW50ZXJmYWNlOiB3aGF0IGlmIHRoZSBzZXJ2 ZXIgZG9lcyBub3QgbGV0IGEgc291cmNlIGludGVyZmFjZSBiZSB1c2VkIGFuZCBpbnN0ZWFkPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg Jm5ic3A7IG5vcm1hbCByb3V0aW5nIGRldGVybWluZXMgdGhlIHNvdXJjZSBpbnRlcmZhY2UgKHRo aXMgbGVhZiBpcyB2ZXJ5IHJvdXRlci1jZW50cmljKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5b Y2x5ZGVdIHNvdXJjZS1pbnRlcmZhY2UgaXMgb3B0aW9uYWwuIElmIG5vdCBzcGVjaWZpZWQgbm9y bWFsIHJvdXRpbmcgZmxvdyB3b3VsZCBiZSB1c2VkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj44KSBzaWduaW5nLW9wdGlvbnM6IGFyZSB0aGVz ZSB3aWRlbHkgZGVwbG95ZWQgb24gYWxsIHJvdXRlcnMgYW5kIExpbnV4IGhvc3RzPzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5bY2x5ZGVdIEFsZXggQ2xlbW0gYXNrZWQgdGhhdCB3ZSBpbmNsdWRl IHN5c2xvZyBzaWduaW5nLW9wdGlvbnMuIFRoaXMgaXMgaW1wbGVtZW50ZWQgYnkgYXQgbGVhc3Qg TGludXggcnN5c2xvZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+OSkgbG9ncm90YXRlOiB0aGVyZSBhcmUgc2V2ZXJhbCBmZWF0dXJlcyByZWxh dGVkIHRvIGxvZyBmaWxlIGNsZWFudXAgYWxsb3dpbmcgbG90cyBvZjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBzZXJ2ZXIg dmFyaWFiaWxpdHkgYW5kIGZvcmNlcyB0aGUgY2xpZW50IHRvIHN1cHBvcnQgYWxsIHRoZSBvcHRp b25zLiZuYnNwOyBDYW4ndCB0aGlzIGJlIHNpbXBsaWZpZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDthbmQgYWxsIHRoZSBt aWNyby1iZWhhdmlvciBZQU5HIGZlYXR1cmVzIHJlbW92ZWQ/PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPltjbHlkZV0gVGhpcyB3YXMgZGVzaWduZWQgYnkgbWVyZ2luZyB0aGUgcmVxdWlyZW1lbnRz IGZyb20gc2V2ZXJhbCB2ZW5kb3JzLiBBbGwgb2YgdGhlIHZhcmlhbnRzIHNwZWNpZmllZCBhcmUg d2l0aCBpZi1mZWF0dXJlIHNvIHRoYXQgdGhlIGNsaWVudCBkb2VzIG5vdCBoYXZlIHRvIHN1cHBv cnQgYWxsIG9wdGlvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjEwKSBudW1lcmljIGxpbWl0czogdGhlcmUgaXMgc29tZSBvZGQgdXNhZ2Ug b2YgWUFORyB0eXBlczsgc29tZSBsaW1pdHMgYXJlIHVpbnQ2NCwgc29tZSB1aW50MzIsPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zb21lIHVpbnQx Ni4mbmJzcDsgU2VlbXMgbGlrZSB1aW50MzIgaXMgc3VmZmljaWVudDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5bY2x5ZGVdJm5ic3A7IFRoZSBzaWduaW5nLW9wdGlvbnMgY291bnRzIGFyZSBhcyBw ZXIgdGhlIHN5c2xvZy1zaWduIHNwZWMgKFJGQyA1ODQ4KSB3aGljaCBpcyB1aW50MTYuIEkgd2ls bCBtYWtlIGFsbCBvdGhlcnMgdWludDMyIGV4Y2VwdCBmb3IgdGhlIGJ1ZmZlciBzaXplIGxpbWl0 IHdoaWNoIEkgd2lsbCBsZWF2ZSBhdCB1bml0NjQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJl c3VsdDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtzZXZlbiBzaWdu aW5nLW9wdGlvbnMgY291bnRlcnMmZ3Q7IHVpbnQxNjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+YnVmZmVyLWxpbWl0LWJ5dGVzIHVpbnQ2NDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+YnVmZmVyLWxpbWl0LW1lc3NhZ2VzIHVpbnQzMiAod2FzIGZvcm1h bGx5IHVpbnQ2NCk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm51bWJlci1v Zi1maWxlcyB1aW50MzI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm1heC1m aWxlLXNpemUgdWludDMyICh3YXMgZm9ybWFsbHkgdWludDY0KTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+cm9sbG92ZXIgdW5pdDMyPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5yZXRlbnRpb24gdW5pdDMyICh3YXMgZm9ybWFsbHkgdWludDE2KTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2x5ZGU8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgRGVjIDEzLCAy MDE2IGF0IDg6MTYgUE0sIEFsZXggQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpBbGV4LkNh bXBiZWxsQGF2aWF0bmV0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFsZXguQ2FtcGJlbGxAYXZpYXRu ZXQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBhbSBjb25zaWRlcmluZyB0byBpbXBsZW1lbnQgdGhlIGRhdGEgbW9k ZWwgaW4gdGhpcyBkcmFmdC48YnI+DQo8YnI+DQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkcmFmdCBh bmQgZm91bmQgdGhlIGZvbGxvd2luZyBpc3N1ZXMuIEluIGFwcHJveGltYXRlbHkgZGVjcmVhc2lu ZyBvcmRlciBvZiBzZXZlcml0eTo8YnI+DQo8YnI+DQoqIEluIHRoZSAmcXVvdDtzZWxlY3Rvci1m YWNpbGl0eSZxdW90OyBjaG9pY2Ugc3RhdGVtZW50IHRoZSBjYXNlcyBoYXZlIG1pc2xlYWRpbmcg bmFtZXMgLSB0aGUgY2FzZSB3aGVyZSBubyBmYWNpbGl0eSBpcyBtYXRjaGVkIGlzIG5hbWVkICZx dW90O2ZhY2lsaXR5JnF1b3Q7LCBhbmQgdGhlIGNhc2Ugd2hlcmUgc3BlY2lmaWMgZmFjaWxpdGll cyBhcmUgbWF0Y2hlZCBpcyBuYW1lZCAmcXVvdDtuYW1lJnF1b3Q7LiBJIHN1Z2dlc3QgJnF1b3Q7 bm8tZmFjaWxpdGllcyZxdW90OyBhbmQgJnF1b3Q7c3BlY2lmaWVkLWZhY2lsaXRpZXMmcXVvdDss DQogb3Igc2ltaWxhci48YnI+DQo8YnI+DQoqIEkgZGlzYWdyZWUgd2l0aCB0aGUgcHJlbWlzZSBv ZiB0aGUgJnF1b3Q7bm8tZmFjaWxpdGllcyZxdW90OyBjYXNlLCB3aGljaCBpcyB0aGF0IGl0IGNh biBiZSB1c2VkIHRvIGRpc2FibGUgYSBsb2cgYWN0aW9uLCBhY2NvcmRpbmcgdG8gdGhlIGRlc2Ny aXB0aW9uOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ZGVzY3JpcHRpb248YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtUaGlzIGNhc2Ug c3BlY2lmaWVzIG5vIGZhY2lsaXRpZXMgd2lsbCBtYXRjaCB3aGVuPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29tcGFyaW5nIHRoZSBzeXNsb2cg bWVzc2FnZSBmYWNpbGl0eS4gVGhpcyBpcyBhPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bWV0aG9kIHRoYXQgY2FuIGJlIHVzZWQgdG8gZWZmZWN0 aXZlbHkgZGlzYWJsZSBhPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7cGFydGljdWxhciBsb2ctYWN0aW9uIChidWZmZXIsIGZpbGUsIGV0YykuJnF1 b3Q7Ozxicj4NCjxicj4NCiZuYnNwOyBJZiBhbiBhZG1pbmlzdHJhdG9yIHdhbnRzIHRvIGRpc2Fi bGUgYSBsb2cgYWN0aW9uIHRoZXkgc2hvdWxkIGRvIGl0IGJ5IGVpdGhlciByZW1vdmluZyBpdCBm cm9tIHRoZSBjb25maWd1cmF0aW9uLCBvciBieSBzZXR0aW5nIGFuICZxdW90O2VuYWJsZWQmcXVv dDsgbGVhZiB0byBmYWxzZS48YnI+DQombmJzcDsgV2l0aCB0aGF0IGluIG1pbmQsIHRoZXJlIGlz IG5vIHJlYXNvbiBmb3IgdGhlICZxdW90O25vLWZhY2lsaXRpZXMmcXVvdDsgY2FzZSB0byBleGlz dC48YnI+DQo8YnI+DQoqIFdoYXQgaXMgdGhlIGJlaGF2aW91ciBvZiBhIHNlbGVjdG9yIGlmIG5l aXRoZXIgJnF1b3Q7bm8tZmFjaWxpdGllcyZxdW90OyBub3IgJnF1b3Q7ZmFjaWxpdHktbGlzdCZx dW90OyBpcyBwcmVzZW50Pzxicj4NCiogSW4gdGhlICZxdW90O3NlbGVjdG9yJnF1b3Q7IGdyb3Vw aW5nIGl0IGlzIG5vdCBjbGVhciBob3cgdGhlIGZhY2lsaXR5IGFuZCBwYXR0ZXJuIGNvbmRpdGlv bnMgYXJlIGNvbWJpbmVkIHRvIGRlY2lkZSB3aGV0aGVyIGEgbWVzc2FnZSBpcyBzZWxlY3RlZC48 YnI+DQombmJzcDsgTXVzdCB0aGV5IGJvdGggbWF0Y2ggdGhlIG1lc3NhZ2UsIG9yIGlzIGl0IHN1 ZmZpY2llbnQgZm9yIGVpdGhlciBvbmUgdG8gbWF0Y2ggdGhlIG1lc3NhZ2U/PGJyPg0KKiBOb3Qg YWxsIHNlcnZlcnMgaGF2ZSBhIGNvbnNvbGU7IHRoZXJlIHNob3VsZCBiZSBhIGZlYXR1cmUgdG8g aW5kaWNhdGUgd2hldGhlciBsb2dnaW5nIHRvIHRoZSBjb25zb2xlIGlzIHN1cHBvcnRlZC48YnI+ DQoqIExpa2V3aXNlLCBub3QgYWxsIHNlcnZlcnMgbWF5IHN1cHBvcnQgbG9nZ2luZyB0byB1c2Vy IHNlc3Npb25zLjxicj4NCiogTGlrZXdpc2UsIG5vdCBhbGwgc2VydmVycyBtYXkgc3VwcG9ydCBh IHVzZXItYWNjZXNzaWJsZSBmaWxlc3lzdGVtLjxicj4NCiogUkZDIDU0MjQgc3RhdGVzIHRoYXQg dGhlIHNldmVyaXR5IGFuZCBwcm90b2NvbCB2YWx1ZXMgYXJlIG5vdCBub3JtYXRpdmUuPGJyPg0K KiBJdCdzIG5vdCBjbGVhciB0byBtZSB3aHkgdGhpcyBuZWVkcyB0byBiZSBzcGxpdCBpbnRvIHR3 byBtb2R1bGVzLiBJcyBpdCBzbyB0aGF0IG90aGVyIG1vZHVsZXMgY2FuIGRlZmluZSBsb2dnaW5n IHBhcmFtZXRlcnMgYnV0IHN0aWxsIGJlIHVzYWJsZSBvbiBhIGRldmljZSB3aXRob3V0IHN5c2xv Zz88YnI+DQoqICZxdW90O2xvZy1zZXZlcml0eSZxdW90OyBkZWZpbmVzIGEgc2V2ZXJpdHkgZmls dGVyLCBub3QgYSBzZXZlcml0eSwgc28gaXRzIG5hbWUgaXMgbWlzbGVhZGluZy48YnI+DQoqIFBl cmhhcHMgdGhlICZxdW90O3NldmVyaXR5JnF1b3Q7IHR5cGUgYW5kIHRoZSBmYWNpbGl0eSBpZGVu dGl0aWVzIHNob3VsZCBoYXZlICZxdW90O3JlZmVyZW5jZSZxdW90OyBzdGF0ZW1lbnRzIHJlZmVy cmluZyB0byBSRkMgNTQyNCwgcmF0aGVyIHRoYW4gcmVmZXJyaW5nIHRvIGl0IGluIHRoZSBkZXNj cmlwdGlvbi48YnI+DQoqIEluIHNlY3Rpb24gJnF1b3Q7OC4yJnF1b3Q7LCAmcXVvdDthZG1pc2lu dHJhdG9yJnF1b3Q7IGlzIGEgdHlwby48YnI+DQo8YnI+DQpJIGFzc3VtZSB0aGF0IHRoZSBtZWFu cyBvZiBhY2Nlc3NpbmcgdGhlIG1lbW9yeSBidWZmZXIgYW5kIGxvZyBmaWxlcyBhcmUgb3V0IG9m IHNjb3BlIG9mIHRoaXMgZGF0YSBtb2RlbC48YnI+DQo8YnI+DQpBbGV4PGJyPg0KPGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkZyb206IG5ldG1vZCAm bHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnIj5uZXRtb2QtYm91bmNl c0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBLZW50IFdhdHNlbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQiPmt3YXRzZW5AanVuaXBlci5uZXQ8L2E+Jmd0Ozxi cj4NClNlbnQ6IFdlZG5lc2RheSwgMTQgRGVjZW1iZXIgMjAxNiAyOjAxIHAubS48YnI+DQpUbzog PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4N ClN1YmplY3Q6IFtuZXRtb2RdIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1uZXRtb2Qtc3lz bG9nLW1vZGVsLTExPGJyPg0KPGJyPg0KVGhpcyBpcyBhIG5vdGljZSB0byBzdGFydCBhIHR3by13 ZWVrIE5FVE1PRCBXRyBsYXN0IGNhbGwgZm9yIHRoZSBkb2N1bWVudDo8YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7IEEgWUFORyBEYXRhIE1vZGVsIGZvciBTeXNsb2cgQ29uZmlndXJhdGlvbjxicj4N CiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbC0xMSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbC0xMTwvYT48 YnI+DQo8YnI+DQpQbGVhc2UgaW5kaWNhdGUgeW91ciBzdXBwb3J0IG9yIGNvbmNlcm5zIGJ5IFR1 ZXNkYXksIERlY2VtYmVyIDI3LCAyMDE2Ljxicj4NCjxicj4NCldlIGFyZSBwYXJ0aWN1bGFybHkg aW50ZXJlc3RlZCBpbiBzdGF0ZW1lbnRzIG9mIHRoZSBmb3JtOjxicj4NCiZuYnNwOyAqIEkgaGF2 ZSByZXZpZXdlZCB0aGlzIGRyYWZ0IGFuZCBmb3VuZCBubyBpc3N1ZXMuPGJyPg0KJm5ic3A7ICog SSBoYXZlIHJldmlld2VkIHRoaXMgZHJhZnQgYW5kIGZvdW5kIHRoZSBmb2xsb3dpbmcgaXNzdWVz OiAuLi48YnI+DQo8YnI+DQpBcyB3ZWxsIGFzOjxicj4NCiZuYnNwOyAqIEkgaGF2ZSBpbXBsZW1l bnRlZCB0aGUgZGF0YSBtb2RlbCBpbiB0aGlzIGRyYWZ0Ljxicj4NCiZuYnNwOyAqIEkgYW0gaW1w bGVtZW50aW5nIHRoZSBkYXRhIG1vZGVsIGluIHRoaXMgZHJhZnQuPGJyPg0KJm5ic3A7ICogSSBh bSBjb25zaWRlcmluZyB0byBpbXBsZW1lbnQgdGhlIGRhdGEgbW9kZWwgaW4gdGhpcyBkcmFmdC48 YnI+DQombmJzcDsgKiBJIGFtIG5vdCBjb25zaWRlcmluZyB0byBpbXBsZW1lbnQgdGhlIGRhdGEg bW9kZWwgaW4gdGhpcyBkcmFmdC48YnI+DQo8YnI+DQpUaGFuayB5b3UsPGJyPg0KTkVUTU9EIFdH IENoYWlyczxicj4NCjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9h Pjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpuZXRtb2RA aWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_3F4C49C91A6A464497C6F9CDC2E4EB4Bciscocom_-- From nobody Sat Dec 31 08:24:11 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4486B129446 for ; Sat, 31 Dec 2016 08:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=2.599, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 tynKs0cMi-II for ; Sat, 31 Dec 2016 08:24:06 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 A3188127076 for ; Sat, 31 Dec 2016 08:24:05 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id h201so180638357qke.1 for ; Sat, 31 Dec 2016 08:24:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tQy5YOogLMGha9kgJrrkSEVVwkM0lz8gCW6y4rqhFSM=; b=wGfk1c49cbcIYDHXvONcoms+ZrYLlRy0s7hIJoRHyO0QfneY+HxBNsvAe9lcoKUigd ZG4sqYjGirfosdKENg0b+KWQq6w9B2ZxxyU0xtJFjKzuTNw5XRG57a97ED2nDQwndO0w 0rwSoGVgewjNCllZabty3YN8SwZJJncaHRNt2BFOKy+srtmL/SVS+YUky3ursprZhflo 0Vd0zHnkF8GmSjHWSmKSEz0ksuO7Sea7CRe5GgNt/pXHZ6aZXSooOAmwyICEasyWYyyf 8aDfN4dZUdx5c72C4Gu4Dk7ykmrqSfNuvDk76nTP1J08n91MIWhIVbcrzcVQorYTVc2B UIdg== 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=tQy5YOogLMGha9kgJrrkSEVVwkM0lz8gCW6y4rqhFSM=; b=qpg3Ua8fSdYhy5fMMkQ+YWzGxqq8WWuh1rUC+S5bD99c6ETPmbyNIOl7DBjDx4/t8n trgqKSYZy6UJXvkR3pC3kt+PFLSAXTarNEWlqQAA2efaRiM8vdgsQyYocU0X1UcCmMD7 Zchqee9zBGM7eHg4yx1o2Bmcigu+brYePbeI/OfJAxM9VXrX0wXkg2P66LP/i6MUMkNi MrsFaBJ9L+cC23b7RDhW6JApXet22tqYea9h3u6DTpzHlIHA4kL6LXthBOT25lqTSvZE Ddpk+2JlK33EyvV1FGwa4w7wW85k5GGU4Nl2psGBpQXTVVZmwqRhVrHqVbuCXe9p8uPc I0Kg== X-Gm-Message-State: AIkVDXJE0A6Md9I50kpg+edh48zjB4xHzo2yGiGlljc8nAdSWEFjlJuLBEqyffrM6RwV07ayPVPMv+sQ1Zzmdg== X-Received: by 10.55.55.143 with SMTP id e137mr46958393qka.237.1483201444487; Sat, 31 Dec 2016 08:24:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.113 with HTTP; Sat, 31 Dec 2016 08:24:03 -0800 (PST) In-Reply-To: <3F4C49C9-1A6A-4644-97C6-F9CDC2E4EB4B@cisco.com> References: <19039254-973A-461A-8749-95F74C33DAD1@juniper.net> <1481689016940.22442@Aviatnet.com> <3F4C49C9-1A6A-4644-97C6-F9CDC2E4EB4B@cisco.com> From: Andy Bierman Date: Sat, 31 Dec 2016 08:24:03 -0800 Message-ID: To: "Clyde Wildes (cwildes)" Content-Type: multipart/alternative; boundary=001a114742d83ad4df0544f6bfc1 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2016 16:24:09 -0000 --001a114742d83ad4df0544f6bfc1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 30, 2016 at 10:16 AM, Clyde Wildes (cwildes) wrote: > Hi Andy, > > > > Thanks for taking the time to review the model. > > > > My comments are inline as [clyde]=E2=80=A6 > > > > *From: *netmod on behalf of Andy Bierman < > andy@yumaworks.com> > *Date: *Tuesday, December 27, 2016 at 3:04 PM > *To: *Alex Campbell > *Cc: *"netmod@ietf.org" > *Subject: *Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-1= 1 > > > > Hi, > > > > I am also considering an implementation. > > I share the same concerns that Alex has brought up. > > > > Some detailed comments: > > > > 1) /syslog/actions: seems like everything is in this container. > > Why is it needed? Seems like it could be removed as it serves no purpos= e > > > > [clyde] Although this model is currently designated as config only, we > could add operational data and rpc leaves in the future. The actions > container is to future-proof the model. > > > > 2) 8 features: the granularity seems wrong. The main container for each > section > > should have its own if-feature > > /console > > /buffer > > /file > > /remote > > > > [clyde] We have gone back and forth on this=E2=80=A6some have complained = that > there are too many features. I will be happy to add a feature for each > action. Note that we studied the implementation of each action by six > vendors including Linux and opted to not add features for actions > implemented by at least 3 vendors. Vendors not implementing an action cou= ld > create a deviation. > I prefer 1 mandatory-to-implement and a minimal number of additional options. /console /file /remote These are all mandatory-to-implement.. IMO only /file should be mandatory-to-implement. > > > 3) What is the 'buffer' container for? > > How is the internal memory accessed by the client? > > > > [clyde] buffer is implemented by vendors typically for routers capable of > generating many syslog messages in event-storm bursts. Logging to memory > (aka buffer) allows the preservation of syslog messages which might > otherwise be lost. > > > IMO it should be removed from the draft. We certainly have changed the IETF NM focus. In SNMP-land we routinely left the configuration out of scope and standardized the monitoring. Now we are standardizing the configuration and leaving the monitoring out of scope? I prefer complete standard solutions only. There is no standard way to access the /console either. Since the console provides "show log" I really do not see a need for /buffer at all. A =E2=80=9Cshow log=E2=80=9D command is used to access the buffers. As this= model is > current designed as a configuration only model, there is no operational > leaves for show log, or rpc leaves for clear log. > > > > 4) selector-facility: Seems like no-facilities servers the same purpose > > as an empty facility-list. The choice is not needed; just use the > facility-list > > > > [clyde] This was changed as a result of Alex=E2=80=99s feedback =E2=80=93= please see my > response to him. The model will be changed to the following: > > > > container selector { > > description > > "This container describes the log selector parameters > > for syslog."; > > list facility-list { > > key facility; > > description > > "This list describes a collection of syslog > > facilities and severities."; > > leaf facility { > > type union { > > type identityref { > > base syslogtypes:syslog-facility; > > } > > type enumeration { > > enum all { > > description > > "This enum describes the case where all > > facilities are requested."; > > } > > } > > } > > description > > "The leaf uniquely identifies a syslog facility."; > > } > > uses log-severity; > > } > > leaf pattern-match { > > if-feature select-match; > > type string; > > description > > "This leaf desribes a Posix 1003.2 regular expression > > string that can be used to select a syslog message for > > logging. The match is performed on the RFC 5424 > > SYSLOG-MSG field."; > > } > > > > > > 5) pattern-match: > > > > leaf pattern-match { > > if-feature select-match; > > type string; > > description > > "This leaf desribes a Posix 1003.2 regular expression > > string that can be used to select a syslog message for > > logging. The match is performed on the RFC 5424 > > SYSLOG-MSG field."; > > } > > > > The field SYSLOG-MSG is referenced but never defined or listed in > the terminology section. > > > > [clyde] This will be fixed in the next draft. > > > > 6) how are the syslog-facility identities mapped to SYSLOG messages? > > 6a) how to distinguish acme:foo-facility from example:foo-facility in a > SYSLOG message? > > > > [clyde] I do not understand your question. The current implementation of > facilities was designed with the help of several Yang Doctors. The > requirement is to support the facilities as called out in RFC 5424 as wel= l > as vendor specific facilities that can be added through augmentation. > Vendor specific facilities are not meant to be used across multiple vendo= r > implementations. > > > The filter is based on an identityref, which is a module-qualified name, e.g., acme:foo-facility and example:foo-facility are different entities. In the syslog message, only the string foo-facility will be present. The draft claims to provide extensible facilities,(see A.1) but it only seems to work if the identities do not contain any duplicates. > 7) source-interface: what if the server does not let a source interface b= e > used and instead > > normal routing determines the source interface (this leaf is very > router-centric) > > > > [clyde] source-interface is optional. If not specified normal routing flo= w > would be used. > > > > 8) signing-options: are these widely deployed on all routers and Linux > hosts? > > > > [clyde] Alex Clemm asked that we include syslog signing-options. This is > implemented by at least Linux rsyslog. > > > > 9) logrotate: there are several features related to log file cleanup > allowing lots of > > server variability and forces the client to support all the options. > Can't this be simplified > > and all the micro-behavior YANG features removed? > > > > [clyde] This was designed by merging the requirements from several > vendors. All of the variants specified are with if-feature so that the > client does not have to support all options. > > > There seems to be some procedures implied by these YANG objects, but it is not specified. The 4 different methods (each with its own feature), are in a container. Since container 'file-rotation' is in list 'log-file', the rotation variant can be different for every file. Is this really how implementations work? Also, the different parameters in this container can interact if the server supports more than 1 feature. The draft does not say anything about combining them. E.g.: leaf number-of-files { if-feature file-limit-size; type uint32; description "This leaf specifies the maximum number of log files retained. Specify 1 for implementations that only support one log file."; } How does the client know if the server only supports 1 file or not? This should really be revisions, since these files are per log-file list entry. If only 1 revision of the log-file is retained, then the meaning of the other leafs is unclear. If there is only 1 log-file revision, then what happens if the max-file-size # of megabytes, rollover # of minutes, or retention # of hours is reached? Does syslog monitoring stop for the log-file entry? How does the client access different revisions of the log file? Or even list them? How does the client know the current size of lifetime of the log-file They do not have names. Is it assumed they will be the log-file/name field appended with ".1", ".2", etc.? > 10) numeric limits: there is some odd usage of YANG types; some limits ar= e > uint64, some uint32, > > some uint16. Seems like uint32 is sufficient > > > > [clyde] The signing-options counts are as per the syslog-sign spec (RFC > 5848) which is uint16. I will make all others uint32 except for the buffe= r > size limit which I will leave at unit64. > > > > Result: > > uint16 > > buffer-limit-bytes uint64 > > buffer-limit-messages uint32 (was formally uint64) > > number-of-files uint32 > > max-file-size uint32 (was formally uint64) > > rollover unit32 > > retention unit32 (was formally uint16) > > > > > > Thanks, > > > > Clyde > > > > > Andy > Andy > > > > > > On Tue, Dec 13, 2016 at 8:16 PM, Alex Campbell > wrote: > > I am considering to implement the data model in this draft. > > I have reviewed this draft and found the following issues. In > approximately decreasing order of severity: > > * In the "selector-facility" choice statement the cases have misleading > names - the case where no facility is matched is named "facility", and th= e > case where specific facilities are matched is named "name". I suggest > "no-facilities" and "specified-facilities", or similar. > > * I disagree with the premise of the "no-facilities" case, which is that > it can be used to disable a log action, according to the description: > > description > "This case specifies no facilities will match when > comparing the syslog message facility. This is a > method that can be used to effectively disable a > particular log-action (buffer, file, etc)."; > > If an administrator wants to disable a log action they should do it by > either removing it from the configuration, or by setting an "enabled" lea= f > to false. > With that in mind, there is no reason for the "no-facilities" case to > exist. > > * What is the behaviour of a selector if neither "no-facilities" nor > "facility-list" is present? > * In the "selector" grouping it is not clear how the facility and pattern > conditions are combined to decide whether a message is selected. > Must they both match the message, or is it sufficient for either one to > match the message? > * Not all servers have a console; there should be a feature to indicate > whether logging to the console is supported. > * Likewise, not all servers may support logging to user sessions. > * Likewise, not all servers may support a user-accessible filesystem. > * RFC 5424 states that the severity and protocol values are not normative= . > * It's not clear to me why this needs to be split into two modules. Is it > so that other modules can define logging parameters but still be usable o= n > a device without syslog? > * "log-severity" defines a severity filter, not a severity, so its name i= s > misleading. > * Perhaps the "severity" type and the facility identities should have > "reference" statements referring to RFC 5424, rather than referring to it > in the description. > * In section "8.2", "admisintrator" is a typo. > > I assume that the means of accessing the memory buffer and log files are > out of scope of this data model. > > Alex > > ________________________________________ > From: netmod on behalf of Kent Watsen < > kwatsen@juniper.net> > Sent: Wednesday, 14 December 2016 2:01 p.m. > To: netmod@ietf.org > Subject: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 > > This is a notice to start a two-week NETMOD WG last call for the document= : > > A YANG Data Model for Syslog Configuration > https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-11 > > Please indicate your support or concerns by Tuesday, December 27, 2016. > > We are particularly interested in statements of the form: > * I have reviewed this draft and found no issues. > * I have reviewed this draft and found the following issues: ... > > As well as: > * I have implemented the data model in this draft. > * I am implementing the data model in this draft. > * I am considering to implement the data model in this draft. > * I am not considering to implement the data model in this draft. > > Thank you, > NETMOD WG Chairs > > > > _______________________________________________ > 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 > > > --001a114742d83ad4df0544f6bfc1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Dec 30, 2016 at 10:16 AM, Clyde Wildes (cwildes) <cwildes@cisc= o.com> wrote:

Hi Andy,

=C2=A0

Thanks for taking the time to review the model.<= /span>

=C2=A0

My comments are inline as [clyde]=E2=80=A6

=C2=A0

F= rom: netmod <netmod-bounces@ietf.org> on behalf of Andy Bierman <andy@yumaworks.com>
Date: Tuesday, December 27, 2016 at 3:04 PM
To: Alex Campbell <Alex.Campbell@Aviatnet.com>
Cc: "netmo= d@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

=C2=A0

Hi,

=C2=A0

I am also considering an implementation.

I share the same concerns that Alex has brought up.<= u>

=C2=A0

Some detailed comments:

=C2=A0

1) /syslog/actions: seems like everything is in this= container.

=C2=A0Why is it needed?=C2=A0 Seems like it could be= removed as it serves no purpose

=C2=A0

[clyde] Although this model is currently designated = as config only, we could add operational data and rpc leaves in the future.= The actions container is to future-proof the model.

=C2=A0

2) 8 features: the granularity seems wrong.=C2=A0 Th= e main container for each section

=C2=A0should have its own if-feature

=C2=A0 =C2=A0 =C2=A0 /console

=C2=A0 =C2=A0 =C2=A0 /buffer

=C2=A0 =C2=A0 =C2=A0 /file

=C2=A0 =C2=A0 =C2=A0 /remote

=C2=A0

[clyde] We have gone back and forth on this=E2=80=A6= some have complained that there are too many features. I will be happy to a= dd a feature for each action. Note that we studied the implementation of ea= ch action by six vendors including Linux and opted to not add features for actions implemented by at least 3 vendors. V= endors not implementing an action could create a deviation.

=


I prefer 1 mand= atory-to-implement and a minimal number of additional options.
=C2=A0 /console
=C2=A0 /file
=C2=A0 /remot= e

These are all mandatory-to-implement..
IMO only /file should be mandatory-to-implement.

=
=C2=A0

=C2=A0

3) What is the 'buffer' container for?

=C2=A0 How is the internal memory accessed by the cl= ient?

=C2=A0

[clyde] buffer is implemented by vendors typically f= or routers capable of generating many syslog messages in event-storm bursts= . Logging to memory (aka buffer) allows the preservation of syslog messages= which might otherwise be lost.

=C2=A0



IMO it should be removed from the draf= t.
We certainly have changed the IETF NM focus.
In SNMP= -land we routinely left the configuration out of scope
and standa= rdized the monitoring.=C2=A0 Now we are standardizing
the configu= ration and leaving the monitoring out of scope?
I prefer complete= standard solutions only.=C2=A0

There is no standa= rd way to access the /console either.
Since the console provides = "show log" I really do not see a need for
/buffer at al= l.


<= div>

A =E2=80=9Cshow log=E2=80=9D command is used to acce= ss the buffers. As this model is current designed as a configuration only m= odel, there is no operational leaves for show log, or rpc leaves for clear = log.

=C2=A0

4) selector-facility: Seems like no-facilities serve= rs the same purpose

=C2=A0 =C2=A0 as an empty facility-list. The choice = is not needed; just use the facility-list

=C2=A0

[clyde] This was changed as a result of Alex=E2=80= =99s feedback =E2=80=93 please see my response to him. The model will be ch= anged to the following:

=C2=A0

=C2=A0 =C2=A0 container selector {

=C2=A0 =C2= =A0 =C2=A0 description

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 "T= his container describes the log selector parameters=C2=A0

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 for syslog.";

=C2=A0 =C2=A0 =C2=A0 list facility-list {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 key facility;

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 description

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 "T= his list describes a collection of syslog=C2=A0

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= facilities and severities.";

=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf facility {<= /u>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type union {=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 type identityref {<= u>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 base syslogtypes:syslog-facility;

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 type enumeration {<= u>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 enum all {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 des= cription

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "T= his enum describes the case where all=C2=A0

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 facilities are requested.";

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

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

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

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 description

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "T= he leaf uniquely identifies a syslog facility.";

=C2=A0 =C2=A0 =C2=A0 =C2=A0 }<= /u>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 uses log-severity;<= u>

=C2=A0 =C2=A0 =C2=A0 }<= /u>

=C2=A0 =C2=A0 =C2=A0 leaf pattern-match {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 if-feature select-match;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 type string;=

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 description

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 "T= his leaf desribes a Posix 1003.2 regular expression=C2=A0

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= string that can be used to select a syslog message for=C2=A0=

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= logging. The match is performed on the RFC 5424=C2=A0

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= SYSLOG-MSG field.&qu= ot;;

=C2=A0 =C2=A0 =C2=A0 }<= /u>

=C2=A0

=C2=A0

5) pattern-match:=C2=A0

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf pattern-match {=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 if-feature select-match;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 type string;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 description
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 "This leaf desribes a Posix 1003.2 regular expression<=
/u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 string that can be used to select a syslog message for
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 logging. The match is performed on the RFC 5424
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 SYSLOG-MSG field.";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }=

=C2=A0

The field SYSLOG-MSG is referenced but never defined= or listed in
the terminology section.

=C2=A0

[clyde] This will be fixed in the next draft.=

=C2=A0

6) how are the syslog-facility identities mapped to = SYSLOG messages?

6a) how to distinguish acme:foo-facility from exampl= e:foo-facility in a SYSLOG message?

=C2=A0

[clyde] I do not understand your question. The curre= nt implementation of facilities was designed with the help of several Yang = Doctors. The requirement is to support the facilities as called out in RFC = 5424 as well as vendor specific facilities that can be added through augmentation. Vendor specific facilities are not= meant to be used across multiple vendor implementations.<= /i>

=C2=A0



The filter is based on an identi= tyref, which is a module-qualified name,
e.g., acme:foo-facility = and example:foo-facility are different entities.
In the syslog me= ssage, only the string foo-facility will be present.
The draft cl= aims to provide extensible facilities,(see A.1) =C2=A0but it only
seems to work if the identities do not contain any duplicates.
<= br>


=C2=A0
=

7) source-interface: what if the server does not let= a source interface be used and instead

=C2=A0 =C2=A0 normal routing determines the source i= nterface (this leaf is very router-centric)

=C2=A0

[clyde] source-interface is optional. If not specifi= ed normal routing flow would be used.

=C2=A0

8) signing-options: are these widely deployed on all= routers and Linux hosts?

=C2=A0

[clyde] Alex Clemm asked that we include syslog sign= ing-options. This is implemented by at least Linux rsyslog.

=C2=A0

9) logrotate: there are several features related to = log file cleanup allowing lots of

=C2=A0 =C2=A0 server variability and forces the clie= nt to support all the options.=C2=A0 Can't this be simplified=

=C2=A0 =C2=A0and all the micro-behavior YANG feature= s removed?

=C2=A0

[clyde] This was designed by merging the requirement= s from several vendors. All of the variants specified are with if-feature s= o that the client does not have to support all options.

=C2=A0


There seems to be some procedures implied by th= ese YANG objects,
but it is not specified.

The 4 different methods (each with its own feature), are in a container.=
Since container 'file-rotation' is in list 'log-file= ', the rotation variant
can be different for every file.=C2= =A0 Is this really how implementations work?

Also,= the different parameters in this container can interact if the server
supports more than 1 feature.=C2=A0 The draft does not say anything a= bout
combining them.

E.g.:
    =
       leaf number-of-files {
              if-feature file-limit-size;
              type uint32;
              description
                "This leaf specifies the maximum number of log
                 files retained. Specify 1 for implementations
                 that only support one log file.";
            }

How does the client know if the server only supports 1 file or not?<= /div>
This should really be revisions, since these files are=C2=A0per l= og-file list entry.

If only 1 revision of the log-= file is retained, then the meaning of the other
leafs is unclear.= If there is only 1 log-file revision, then what happens
if the m= ax-file-size # of megabytes, rollover # of minutes, or retention # of hours=
is reached?=C2=A0 Does syslog monitoring stop for the log-file e= ntry?

How does the client access different revisio= ns of the log file? Or even list them?
How does the client know t= he current size of lifetime of the log-file
They do not have name= s. Is it assumed they will be the log-file/name field
appended wi= th ".1", ".2", etc.?

=C2=A0

10) numeric limits: there is some odd usage of YANG = types; some limits are uint64, some uint32,

some uint16.=C2=A0 Seems like uint32 is sufficient

=C2=A0

[clyde]=C2=A0 The signing-options counts are as per = the syslog-sign spec (RFC 5848) which is uint16. I will make all others uin= t32 except for the buffer size limit which I will leave at unit64.

=C2=A0

Result:

<seven signing-options counters> uint16=

buffer-limit-bytes uint64

buffer-limit-messages uint32 (was formally uint64)

number-of-files uint32

max-file-size uint32 (was formally uint64)=

rollover unit32

retention unit32 (was formally uint16)=

=C2=A0

=C2=A0

Thanks,

=C2=A0

Clyde

=C2=A0

=C2=A0




Andy
=C2=A0

Andy

=C2=A0

=C2=A0

On Tue, Dec 13, 2016 at 8:16 PM, Alex Campbell <<= a href=3D"mailto:Alex.Campbell@aviatnet.com" target=3D"_blank">Alex.Campbel= l@aviatnet.com> wrote:

I am considering to implement the data model in this= draft.

I have reviewed this draft and found the following issues. In approximately= decreasing order of severity:

* In the "selector-facility" choice statement the cases have misl= eading names - the case where no facility is matched is named "facilit= y", and the case where specific facilities are matched is named "= name". I suggest "no-facilities" and "specified-facilit= ies", or similar.

* I disagree with the premise of the "no-facilities" case, which = is that it can be used to disable a log action, according to the descriptio= n:

=C2=A0 =C2=A0 =C2=A0description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "This case specifies no faci= lities will match when
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0comparing the syslog messag= e facility. This is a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0method that can be used to = effectively disable a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0particular log-action (buff= er, file, etc).";

=C2=A0 If an administrator wants to disable a log action they should do it = by either removing it from the configuration, or by setting an "enable= d" leaf to false.
=C2=A0 With that in mind, there is no reason for the "no-facilities&qu= ot; case to exist.

* What is the behaviour of a selector if neither "no-facilities" = nor "facility-list" is present?
* In the "selector" grouping it is not clear how the facility and= pattern conditions are combined to decide whether a message is selected. =C2=A0 Must they both match the message, or is it sufficient for either one= to match the message?
* Not all servers have a console; there should be a feature to indicate whe= ther logging to the console is supported.
* Likewise, not all servers may support logging to user sessions.
* Likewise, not all servers may support a user-accessible filesystem.
* RFC 5424 states that the severity and protocol values are not normative.<= br> * It's not clear to me why this needs to be split into two modules. Is = it so that other modules can define logging parameters but still be usable = on a device without syslog?
* "log-severity" defines a severity filter, not a severity, so it= s name is misleading.
* Perhaps the "severity" type and the facility identities should = have "reference" statements referring to RFC 5424, rather than re= ferring to it in the description.
* In section "8.2", "admisintrator" is a typo.

I assume that the means of accessing the memory buffer and log files are ou= t of scope of this data model.

Alex

________________________________________
From: netmod <netmod-bounces@ietf.org> on behalf of Kent Watsen <kwatsen@juniper.net> Sent: Wednesday, 14 December 2016 2:01 p.m.
To: netmod@ietf.org
Subject: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
This is a notice to start a two-week NETMOD WG last call for the document:<= br>
=C2=A0 =C2=A0 A YANG Data Model for Syslog Configuration
=C2=A0 =C2=A0 https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-11=

Please indicate your support or concerns by Tuesday, December 27, 2016.

We are particularly interested in statements of the form:
=C2=A0 * I have reviewed this draft and found no issues.
=C2=A0 * I have reviewed this draft and found the following issues: ...

As well as:
=C2=A0 * I have implemented the data model in this draft.
=C2=A0 * I am implementing the data model in this draft.
=C2=A0 * I am considering to implement the data model in this draft.
=C2=A0 * I am not considering to implement the data model in this draft.
Thank you,
NETMOD WG Chairs



_______________________________________________
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

=C2=A0


--001a114742d83ad4df0544f6bfc1--


On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue <mersue@gmail.com>= wrote:

Hi Andy,

=C2=A0

> This architectural change needs to be impl= emented in various protocols.

> I am not sure a 6241bis is the best approach because= it is not clear which

> servers really need to implement the revised datastores.=C2= =A0

= =C2=A0

I agree fu= lly. This is the reason why I wrote in my mail:

=C2=A0

>> - a new protocol- and language-inde= pendent standard document (RFC XYZ) defining the generic datastore concept = and framework and describing its use (based on and following the DT solutio= n draft),

&g= t;> - a RFC6241bis draft removing the current datasore concept specifica= tion, and getting rid of well-known issues e.g. with the <get> operat= ion,


I do no= t agree with the text you wrote.
I do not want to remove candidat= e, running, and startup from RFC 6241.
IMO the new datastores can= be defined in a new document that does not redefine the existing datastore= s.

I also do not want to get rid of <get>, = =C2=A0It works as intended.
It is not a problem on small devices.= =C2=A0 It is not a problem on large devices if
sufficient filteri= ng is used.=C2=A0 It does not differentiate between intended and applied co= nfig
or understand different types of config=3Dfalse nodes.=C2=A0= Use a new operation to
add these features.

<= div>


=C2=A0

Mehme= t



And= y

=C2=A0

=C2=A0

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Dienstag, 13. Dezember 2016 18= :38
To: Eric Voit (evoit) <evoit@cisco.com>
Cc: Ladislav Lhotka <= ;lhotka@nic.cz>; = MehmetErsue <mersu= e@gmail.com>; NetMod WG Chairs <netmod-chairs@ietf.org>; NetConf WG Chair= s <netconf-= chairs@ietf.org>; NetMod WG <netmod@ietf.org>; Netconf <netconf@ietf.org>
Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-= datastores-00

=C2=A0<= u>

=C2=A0

=C2=A0

On Tue, = Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) <evoit@cisco.com> wrote:

I support adoption, and like Mehmet's thin= king as well.

Also worth focusing on is transport protocol independe= nt yang filtering.=C2=A0 So along with how to frame get operations against = one of the datastores, how do you know which subtrees/nodes should be inclu= ded/excluded.

= =C2=A0

=C2=A0=

This architectural change needs to be= implemented in various protocols.

I am not sure a 6241bis is the best approach because it is not c= lear which

servers reall= y need to implement the revised datastores.=C2=A0 Since RD is purely option= al

to implement, it shou= ld not obsolete 6241 in any way.=C2=A0 It should be possible<= /p>

to add new operations and/or new param= eters to existing operations without

needing to redefine what is already there.

=

=C2=A0

The new protocol features need to explain how to include/e= xclude subtrees.

IMO we = should only support YANG defined data.=C2=A0 This allows the solutions

to be generalized and reusab= le across protocols (e.g., using YANG extensions).

<= div>

=C2=A0

=C2=A0

Eric

=

=C2=A0

=C2=A0

Andy

=C2=A0

<= /div>


> From: Netconf, December 9, 2016 7:49 AM
>
> Hi Me= hmet,
>
> I think I could just sign your text at the bottom.>
> Lada
>
> > On 9 Dec 2016, at 13:25, MehmetErsu= e <mersue@gmail.co= m> wrote:
> >
> > Hi All,
> >
> >= ; I think the adoption of the DT draft is fine. We agreed in IETF 97 to ado= pt and
> finalize the DT draft in NETMOD WG, which I still support.> >
> > I believe the bigger issue is to agree on a plan c= oncerning the related work
> and the re-organization of existing stan= dards. As a matter of fact this plan will
> lead to updating the char= ter of two WGs and the work we are going to start.
> >
> >= ; I see the DT document as a datastore solution proposal. There are differe= nt
> gaps and issues which still need to be addressed and the solutio= n proposal
> needs yet to be discussed and finalized. The document is= providing information
> on the history, explaining the need for a ge= neric solution as well as is discussing
> different scenarios. As suc= h I believe the datastore solution proposal from the
> DT should be p= ublished with the intended status Informational RFC.
> >
> &= gt; Based on the finalized and agreed datastore solution we should do diffe= rent
> updates to existing documents in NETCONF and NETMOD WGs. With = this
> action we can also fix well-known issues.
> >
>= > Concerning the NETCONF WG I would see it as valuable if we develop:> > - a RFC6241bis draft removing the current datasore concept
&= gt; > specification, and getting rid of well-known issues e.g. with the<= br>> > <get> operation,
> > - a new protocol- and lang= uage-independent standard document (RFC XYZ)
> > defining the gene= ric datastore concept and framework and describing
> > its use (ba= sed on and following the DT solution draft),
> > - adding potentia= l extensions to RFC6241bis (following the DT draft
> > and with a = normative reference to RFC XYZ),
> > - adding potential extensions= to a RESTCONF-bis RFC (following the DT
> > draft and with a norm= ative reference to RFC XYZ),
> >
> > Concerning the NETMO= D WG I would see it as valuable if we develop:
> > - RFC7950bis de= leting protocol-dependent details and specifying the
> > datastore= usage with YANG on a generic level (with a normative
> > referenc= e to RFC XYZ),
> > - adding potential extensions to RFC7950bis, e.= g. concerning the
> > proposed <notification> element,
&g= t; > - possibly an RFC 6244bis to describe architectural aspects. Howeve= r RFC6244
> is Informational and a RFC6244bis would be still Informat= ional. I'm not sure
> whether this is really necessary. The DT pr= oposal does already describe such a
> solution and can be seen as an = update to RFC 6244.
> > - RFC6087bis giving guidelines on how to u= se YANG with the new datastore
> concept.
> >
> > R= eferring to Lada's proposal concerning the spin off document from
&g= t; > RFC7950 ("Adapting NETCONF for use with YANG"), I think t= his can be
> provided in the corresponding protocol RFCs, i.e.
>= ; > for NETCONF a section on "Using NETCONF with YANG" in RFC6= 241bis and
> for RESTCONF "Using RESTCONF with YANG" in RES= TCONF-bis RFC.
> >
> > Hope this helps as a starting poin= t on the way to a good plan.
> >
> > PS: As Benoit sugges= ted some time ago we might also consider to rename
> NETCONF WG as it= is not only on NETCONF protocol anymore.
> >
> > Regards= ,
> > Mehmet
> >
> > On Mon, Dec 5, 2016 at 6:19= PM Andy Bierman <andy@yumaworks.com>
> wrote:
> > On Mon, Dec 5, 201= 6 at 4:02 AM, Juergen Schoenwaelder
> <j.schoenwaelder@jacobs-= university.de> wrote:
> > On Mon, Dec 05, 2016 at 11:36:11A= M +0100, Ladislav Lhotka wrote:
> > >
> > > >> > > > I disagree that the datastore model is a protocol spec= ific aspect.
> > > > I consider datastores an architectural = component binding data
> > > > models and protocols together= . In fact, the 'traditional'
> > > > datastore model=
> > >
> > > I would agree with this if datastores = were a general concept in YANG, but
> the revised-datastores draft ex= plicitly introduces the "intended" and "applied"
>= ; datastores that may be irrelevant to other protocols using YANG, and even=
> needn't be used in all NETCONF implementations. I wouldn't= call this "an
> architectural component" of YANG.
> = > >
> >
> > An architectural component of this new = management framework (that does
> > not have a name). The fact tha= t not all protocols may expose all
> > datastores is IMHO not a re= ason that the datastore model is not an
> > architectural framewor= k.
> >
> > > If you are saying that it will have nontr= ivial impact on YANG, I would like to
> see it explained in sec. 6.3.= Without this information I am quite reluctant to
> agree with the ad= option.
> >
> > An operational state datastore has implic= ations how one writes data
> > models. It may not directly affect = YANG itself but surely the usage of
> > YANG.
> >
>= > > See above - architectural aspects need to be relevant to all pro= tocols.
> >
> > Yes, but relevant to all protocols does n= ot mean every protocol needs
> > to expose say all datastores. But= every protocol should be clear about
> > how what it exposes rela= tes to the architectural framework.
> >
> >
> ><= br>> > There is a "current solution" consisting of hard-wir= ed object
> > semantics (e.g., ifAdminStatus and ifOperStatus).=C2= =A0 This solution does
> > not require special protocols or datast= ores, but it is being replaced by a
> generic solution.
> ><= br>> > If the "generic" solution requires special procedure= s which differ on
> > each protocol, then it might end up be worse= than the hard-wired solution
> that works on every protocol.
>= > So I agree with Juergen that this is primarily an architectural issue= .
> >
> >
> > /js
> >
> > Andy=
> >
> >
> >
> > --
> > Juerge= n Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs University B= remen gGmbH
> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Campus Ring 1 | 28759 Bremen | Germany
> > Fax:=C2=A0 =C2= =A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-univers= ity.de/>
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> &= gt; https://www.ietf.org/mailman/listinfo/netmod
> > --> > Cheers,
> > Mehmet
>
> --
> Ladislav= Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>>
> _______________________________________________
>= Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/li= stinfo/netconf

____________________________________________= ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/n= etmod

=C2=A0