From scheng2@cisco.com Sun Mar 2 10:23:41 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03361A09BF for ; Sun, 2 Mar 2014 10:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZGMjfT-Coje for ; Sun, 2 Mar 2014 10:23:40 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id C474C1A09BD for ; Sun, 2 Mar 2014 10:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9322; q=dns/txt; s=iport; t=1393784617; x=1394994217; h=from:to:cc:subject:date:message-id:mime-version; bh=CY04fSVAX+hYIFd3Z/Sn5d8au9bdnJgQ0XaJIEphMFY=; b=lI585ZyhXid4y43gZTYuOItQjLY0wuqOynxCdzE5teftskpX4HChrQzA LUXOk+/cos6mEU6zul7Ichql9+mUnyBJw2lenzElk6ztI2T0sTtzkB/+h o6vqLZsedqHrq31/XWk5WVeVPbY9g5YIu7a3uUN/3viG+Dbkd5L4acrsF c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAPp2E1OtJV2Y/2dsb2JhbABagkJEO1fBIYEUFnSCJwEELUwSASpWJgEEDg2HccthF44FIzGDK4EUBKpngy2CKg X-IronPort-AV: E=Sophos; i="4.97,573,1389744000"; d="scan'208,217"; a="24325880" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP; 02 Mar 2014 18:23:28 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s22INSvO021612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 2 Mar 2014 18:23:28 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.8]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Sun, 2 Mar 2014 12:23:27 -0600 From: "Steve Cheng (scheng2)" To: "netmod@ietf.org" Thread-Topic: [netmod] draft-huang-netmod-acl (Stateless Packet Filter Configuration) Thread-Index: Ac82RH943Y2UpcCSR8WU0DmNpMyXKw== Date: Sun, 2 Mar 2014 18:23:27 +0000 Message-ID: <450CD1FAE82EE649B25FF237DDB5BD4004F1706A@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.64.43] Content-Type: multipart/alternative; boundary="_000_450CD1FAE82EE649B25FF237DDB5BD4004F1706Axmbalnx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_wOsl0Ub2DXmIr_5WAGQfjnns-c X-Mailman-Approved-At: Mon, 03 Mar 2014 01:38:56 -0800 Cc: "Steve Cheng \(scheng2\)" Subject: [netmod] draft-huang-netmod-acl (Stateless Packet Filter Configuration) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 09:37:13 -0000 --_000_450CD1FAE82EE649B25FF237DDB5BD4004F1706Axmbalnx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Team, I went through the draft with some colleagues and we do have quite some que= stions about this draft. I'm in IETF London meeting so if you are intereste= d in this topic, we can talk in person. I'd like to list all questions abou= t checking with a few folks first. Anyway, one dummy question to get started. Why do we name it "SPF" instead = of "ACL". Taking a look at major vendors (Haihua/Cisco/ALU/Juniper), none o= f them call this SPF. * Cisco/Haihua call it "ACL", ALU calls it "Filter", and Juniper ca= lls it stateless firewall filter. ACL has been around for a long time with huge customer base. Not sure why r= enaming it to SPF. I heard this was discussed before but I simply don't qui= te understand the reason. Thanks, Steve Cheng --_000_450CD1FAE82EE649B25FF237DDB5BD4004F1706Axmbalnx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Team,

 

I went through the draft with some colleagues and we= do have quite some questions about this draft. I’m in IETF London me= eting so if you are interested in this topic, we can talk in person. I̵= 7;d like to list all questions about checking with a few folks first.

 

Anyway, one dummy question to get started. Why do we= name it “SPF” instead of “ACL”. Taking a look at m= ajor vendors (Haihua/Cisco/ALU/Juniper), none of them call this SPF.

 

·         Cisco/Haihua call it “ACL”, ALU = calls it “Filter”, and Juniper calls it stateless firewall filt= er.

 

ACL has been around for a long time with huge custom= er base. Not sure why renaming it to SPF. I heard this was discussed before= but I simply don’t quite understand the reason.

 

Thanks,

 

Steve Cheng

 

 

 

 

--_000_450CD1FAE82EE649B25FF237DDB5BD4004F1706Axmbalnx08ciscoc_-- From nobody Mon Mar 3 01:45:35 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48F51A0D97 for ; Mon, 3 Mar 2014 01:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6beRPPsUy625 for ; Mon, 3 Mar 2014 01:45:26 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id D45C31A0D5D for ; Mon, 3 Mar 2014 01:45:20 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7D653167A; Mon, 3 Mar 2014 10:45:17 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id cndzunPEsmCd; Mon, 3 Mar 2014 10:45:16 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Mon, 3 Mar 2014 10:45:16 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id EB0612002F; Mon, 3 Mar 2014 10:45:15 +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 hsp-eSIYA15W; Mon, 3 Mar 2014 10:45: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 6843220017; Mon, 3 Mar 2014 10:45:14 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2B8802B8F2D7; Mon, 3 Mar 2014 10:45:11 +0100 (CET) Date: Mon, 3 Mar 2014 10:45:10 +0100 From: Juergen Schoenwaelder To: "Steve Cheng (scheng2)" Message-ID: <20140303094510.GB21301@elstar.local> Mail-Followup-To: "Steve Cheng (scheng2)" , "netmod@ietf.org" References: <450CD1FAE82EE649B25FF237DDB5BD4004F1706A@xmb-aln-x08.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450CD1FAE82EE649B25FF237DDB5BD4004F1706A@xmb-aln-x08.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/r65fMYQx8BiJUL_PbKdgkoqgOvU Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-huang-netmod-acl (Stateless Packet Filter Configuration) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 03 Mar 2014 09:45:34 -0000 On Sun, Mar 02, 2014 at 06:23:27PM +0000, Steve Cheng (scheng2) wrote: > > Anyway, one dummy question to get started. Why do we name it "SPF" instead of "ACL". Taking a look at major vendors (Haihua/Cisco/ALU/Juniper), none of them call this SPF. > > > * Cisco/Haihua call it "ACL", ALU calls it "Filter", and Juniper calls it stateless firewall filter. > > ACL has been around for a long time with huge customer base. Not sure why renaming it to SPF. I heard this was discussed before but I simply don't quite understand the reason. > I guess it is called stateless packet filter because that is what it really is that you are modeling. /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 Mar 3 02:10:48 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896B41A0C0B for ; Mon, 3 Mar 2014 02:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68o5BOLCqmwo for ; Mon, 3 Mar 2014 02:10:38 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 894D31A0DFA for ; Mon, 3 Mar 2014 02:10:31 -0800 (PST) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:7554:d18d:4a07:5607]) by mail.nic.cz (Postfix) with ESMTPSA id 85453140A0D; Mon, 3 Mar 2014 11:10:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1393841428; bh=JmUIVQ7AANJm6U7ea2rJDOx9ox1AE2klA4BwYp1JcoI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QY23K9QkQjUb0pthHTG9jvNsIHi2dSIdDKs+wJ1i6/hPeaA5ut76Rig+r52Fxds3w p071esQJYmPNv4vcB6ayD2Q5/HCQMKuCA8lUOg/KzXt+rU6H1JsFdINaRzHmWF95KR +YRx8kwUc75SQkhgD5HTaXS5Z65axEXnkomFoQI0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140303094510.GB21301@elstar.local> Date: Mon, 3 Mar 2014 10:10:27 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <450CD1FAE82EE649B25FF237DDB5BD4004F1706A@xmb-aln-x08.cisco.com> <20140303094510.GB21301@elstar.local> To: =?iso-8859-1?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_PoYUrQTjcHK3cEc8drSYlPWgqI Cc: "Steve Cheng \(scheng2\)" , "netmod@ietf.org" Subject: Re: [netmod] draft-huang-netmod-acl (Stateless Packet Filter Configuration) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 10:10:40 -0000 On 03 Mar 2014, at 09:45, Juergen Schoenwaelder = wrote: > On Sun, Mar 02, 2014 at 06:23:27PM +0000, Steve Cheng (scheng2) wrote: >>=20 >> Anyway, one dummy question to get started. Why do we name it "SPF" = instead of "ACL". Taking a look at major vendors = (Haihua/Cisco/ALU/Juniper), none of them call this SPF. >>=20 >>=20 >> * Cisco/Haihua call it "ACL", ALU calls it "Filter", and = Juniper calls it stateless firewall filter. >>=20 >> ACL has been around for a long time with huge customer base. Not sure = why renaming it to SPF. I heard this was discussed before but I simply = don't quite understand the reason. >>=20 >=20 > I guess it is called stateless packet filter because that is what it > really is that you are modeling. +1. It neither controls access nor filters firewalls. :-) 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 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 3 02:26:39 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BAB1A0C3B for ; Mon, 3 Mar 2014 02:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdnpwmeYt8J5 for ; Mon, 3 Mar 2014 02:26:28 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5411A0C4E for ; Mon, 3 Mar 2014 02:26:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1284; q=dns/txt; s=iport; t=1393842385; x=1395051985; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KRd7EYuFpAA4e6VbqRCk5R6f6YZwNyqi6h2MGclXupc=; b=YhcLdmymeW/3oSpvgNpZN22+MybgEeGV6TA+dyFWFTYy0zQQusrVgmft EWKeyI8Qf9Ebel4YtzBa2OWCYMf/u9SL0RhrCZV9S8nJrgA3aWytvPdhS N1esIOoWh7LrsK8+vGNttJYJh/buHcrrFJ6/KOQFgx8iAl/3y6vosM0YE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAMBXFFOtJV2Z/2dsb2JhbABXA4MGO1fAToEfFnSCJQEBAQQ6PwwCAgIBCA4CAQQBAQEKFAkHGxcUCQgCBA4FCIdxzD4XBI4kIRAHBguDE4EUBKpngy2CKg X-IronPort-AV: E=Sophos;i="4.97,577,1389744000"; d="scan'208";a="307440747" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 03 Mar 2014 10:26:25 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s23AQPun010051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Mar 2014 10:26:25 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.8]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 04:26:25 -0600 From: "Steve Cheng (scheng2)" To: Juergen Schoenwaelder Thread-Topic: [netmod] draft-huang-netmod-acl (Stateless Packet Filter Configuration) Thread-Index: AQHPNsVK/GVCjClnf0+AVK/z7qUyq5rPJ1kg Date: Mon, 3 Mar 2014 10:26:24 +0000 Message-ID: <450CD1FAE82EE649B25FF237DDB5BD4004F18481@xmb-aln-x08.cisco.com> References: <450CD1FAE82EE649B25FF237DDB5BD4004F1706A@xmb-aln-x08.cisco.com> <20140303094510.GB21301@elstar.local> In-Reply-To: <20140303094510.GB21301@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.217.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/0qc79ap4PiZ_07l5lL568i-gOu8 Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-huang-netmod-acl (Stateless Packet Filter Configuration) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 10:26:36 -0000 Well, we are modeling something already exists for 15+ years which is known= as ACL... -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, March 03, 2014 1:45 AM To: Steve Cheng (scheng2) Cc: netmod@ietf.org Subject: Re: [netmod] draft-huang-netmod-acl (Stateless Packet Filter Confi= guration) On Sun, Mar 02, 2014 at 06:23:27PM +0000, Steve Cheng (scheng2) wrote: >=20 > Anyway, one dummy question to get started. Why do we name it "SPF" instea= d of "ACL". Taking a look at major vendors (Haihua/Cisco/ALU/Juniper), none= of them call this SPF. >=20 >=20 > * Cisco/Haihua call it "ACL", ALU calls it "Filter", and Juniper = calls it stateless firewall filter. >=20 > ACL has been around for a long time with huge customer base. Not sure why= renaming it to SPF. I heard this was discussed before but I simply don't q= uite understand the reason. >=20 I guess it is called stateless packet filter because that is what it really= is that you are modeling. /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 Mon Mar 3 06:01:04 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212A41A012C; Mon, 3 Mar 2014 06:01:01 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAr6CTk2iBbW; Mon, 3 Mar 2014 06:00:59 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) by ietfa.amsl.com (Postfix) with ESMTP id C62061A0114; Mon, 3 Mar 2014 06:00:56 -0800 (PST) Received: from [2001:8d8:81:5c2::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1WKTQL-0001vz-32; Mon, 03 Mar 2014 15:00:53 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80.1) (envelope-from ) id 1WKTQ8-000QDh-Ac; Mon, 03 Mar 2014 15:00:42 +0100 Date: Mon, 3 Mar 2014 15:00:40 +0100 From: David Lamparter To: netconf@ietf.org Message-ID: <20140303140039.GZ856433@jupiter.n2.diac24.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/FBmp0nsUAChZgOM_BbRY7qs56eI Cc: netmod@ietf.org Subject: [netmod] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 14:01:01 -0000 Hi, (this is the mail version of the somewhat garbled comment on the mic) The original question was, how the configured device chooses a "VPN" for either incoming or outgoing connections. This referred to VRF instances. In particular, for the very simplest case where this matters, there are devices that have out of band management ports and treat those as a VRF. So, both for listening and for connecting, the device needs to choose between "VR-Default" and "VR-Mgmt" (actual names, guess the vendor.) It could even listen in both VRFs, to be manageable inband (normal ops maybe?) and out of band (network in flames?). Even though this was raised on the server config model, this is a rather generic problem. E.g. specifying a NTP or Syslog server has the same issue. (Cc' from netconf to netmod due to this.) NB: I haven't followed this topic, there might be some simple answer that I'm not aware of. -David (Sorry for the garbled jump to the mic, this wasn't on my radar, I was only able to parse the meaning of "VPN".) From nobody Tue Mar 4 04:39:25 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC3B1A0122 for ; Tue, 4 Mar 2014 04:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6M83W9jS650f for ; Tue, 4 Mar 2014 04:39:13 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id EF7431A0086 for ; Tue, 4 Mar 2014 04:39:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=546; q=dns/txt; s=iport; t=1393936750; x=1395146350; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8HFVxmIVBaaWS15gPATXz9pLLQ77G81VXM1WEY/jBqE=; b=SDADelbK87P7GOcPO948TEq/X/ciEAiGK++PwlUF3TsdJUGzIA8/e6ja C8iho29sFiNCT8VyGaFVgMKOm6SpsTNCzQiYhelpJCo2pe1Dhu10B58up vxxSC0hsL1RUuJgq4N1wCQGfNH5ioydSRhxy+kkNrIcVAdIW+EPj9GTnR Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAL3IFVOtJXG9/2dsb2JhbABRCYMGgRLAbYEgFnSCJgEBBDo/EAIBPhAyJQIEDod+zFEXjXZbB4Q4AQOYPJIrgy2CKg X-IronPort-AV: E=Sophos;i="4.97,584,1389744000"; d="scan'208";a="24777035" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-8.cisco.com with ESMTP; 04 Mar 2014 12:39:09 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s24Cd9NB019136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Mar 2014 12:39:09 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.147]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Tue, 4 Mar 2014 06:39:09 -0600 From: "Derek Man-Kit Yeung (myeung)" To: Ladislav Lhotka Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt Thread-Index: AQHPN6a8TcSsF5Wm80Ok259R/K6NOQ== Date: Tue, 4 Mar 2014 12:39:08 +0000 Message-ID: References: <20140111.133634.462426147.mbj@tail-f.com> <12A63CCF-69CE-4D43-A3EC-F420635B5237@nic.cz> <20140220134130.GA19665@elstar.local> <20140220.145129.73716044088019744.mbj@tail-f.com> <657A1870-B234-4489-8F0E-A85559843C16@nic.cz> In-Reply-To: <657A1870-B234-4489-8F0E-A85559843C16@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.92.66] Content-Type: text/plain; charset="us-ascii" Content-ID: <76CDF3DF5D44E240B01C5DAA66E01640@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5K1klj5x0fUdwHrvL4EQVtkRyXg Cc: "netmod@ietf.org" Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 12:39:18 -0000 Hi Ladislav, Have a few of questions for the draft. 1) I saw an ipv4-unicast identity defined. Is there a ipv4-multicast for reference to the RIB which store ipv4 unicast route for RPF lookup? 2) How would topology as used in RFC5120 be supported? 3) Given routing-protocol has only name as the key list routing-protocol { key "name"; Would it prevent different protocols from using the same name? Like "router ospf 101" and "router rip 101" at the same time using IOS syntax? Thanks, - Derek From nobody Tue Mar 4 05:44:20 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787351A01BF for ; Tue, 4 Mar 2014 05:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDXcKtVfJo2H for ; Tue, 4 Mar 2014 05:44:09 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2461A01F9 for ; Tue, 4 Mar 2014 05:43:59 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6127A11A5 for ; Tue, 4 Mar 2014 14:43:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id akgQdmbT31F8 for ; Tue, 4 Mar 2014 14:43:53 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP for ; Tue, 4 Mar 2014 14:43:53 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC1822002F for ; Tue, 4 Mar 2014 14:43:53 +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 dcpcVoSLYikZ; Tue, 4 Mar 2014 14:43:51 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 391C52002C; Tue, 4 Mar 2014 14:43:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2E6AF2B92790; Tue, 4 Mar 2014 14:43:48 +0100 (CET) Date: Tue, 4 Mar 2014 14:43:48 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140304134348.GA27138@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/a60KgzVDXyP4eqqU4mOUx-q285U Subject: [netmod] netmod charter revision (version 2014-03-04) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 04 Mar 2014 13:44:13 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, here is another charter text proposal based on the feedback received on the mailing list and during hallway discussions at the IETF in London. Please read and comment. We plan to resolve the charter revision discussion tomorrow at the WG meeting. But please, if you have issues with the new proposal, please raise them as soon as possible (it is good to be aware of any issues before the meeting). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="netmod-charter-2014-03-04.txt" The NETMOD working group has defined the data modeling language YANG, which can be used to specify network management data models that are manipulated by the NETCONF protocol. The NETMOD working group also defined a number of core data models as basic building blocks. The purpose of the NETMOD working group is to support the ongoing deployment of YANG by maintaining and evolving the core YANG specifications based on usage experience and developing data models that are considered core building blocks and that do not fall into charters of other active IETF working groups (for example a data model for stateless packet filters). The NETMOD Working Group will produce a maintenance release of the core YANG specification called YANG 1.1, that is a revision of RFC 6020. The changes to RFC 6020 are restricted in the following ways: - All compliant YANG 1.0 modules must be accepted as compliant YANG 1.1 modules. - All known ambiguities of YANG 1.0 and all reported defects and errata will be addressed. - YANG 1.1 is not adding new data modeling concepts to the language. - The changes of the specification will be kept to the minimum necessary to achieve the previously stated goals. The NETMOD Working Group will also revise the Guidelines for Authors and Reviewers of YANG Data Models (RFC 6087) in order to fix any ambiguities and to incorporate the lessons learned by producing YANG data models. The NETMOD Working Group will produce a specification how YANG-defined data trees can be represented in JSON. The NETMOD Working Group will not serve as a review team for YANG modules developed by other working groups. All data models must be fully interoperable with implementations of NETCONF and YANG. The WG will consult with the NETCONF working group to ensure that NETMOD's decision do not conflict with planned work in NETCONF. Goals and Milestones: Apr 2014 - Submit first working group draft of the stateless packet filter data model Apr 2014 - Submit first working group draft of a mapping to JSON May 2014 - Compiled issue list to be considered for YANG 1.1 Jul 2014 - Submit first working group draft of YANG 1.1 Oct 2014 - Submit stateless packet filter data model to the IESG Oct 2014 - Submit custom a mapping to JSON to the IESG Mar 2015 - Submit YANG 1.1 to the IESG --7JfCtLOvnd9MIVvH-- From nobody Tue Mar 4 06:50:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67AE1A0159 for ; Tue, 4 Mar 2014 06:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRvwCe7QenvV for ; Tue, 4 Mar 2014 06:50:30 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id EA2A61A01FB for ; Tue, 4 Mar 2014 06:50:25 -0800 (PST) Received: from [172.16.0.55] (80-46-118-65.static.dsl.as9105.com [80.46.118.65]) by mail.nic.cz (Postfix) with ESMTPSA id 246BC13F7D8; Tue, 4 Mar 2014 15:50:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1393944622; bh=xRCFeYZ7INAuAXGObu692laahQqWGCqwHTVEXmjf4Vg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Qh9K1jdH/ngCC9+fNvS2i/Bx+L6aOtFiTS14bGDxFhFoQ62d4zE5cLx5Tt2m9Y2qy 4BxDRsNlJkneRBbZKGaqP38SHlBagnhh9vSmiKWqSEVhpEvqzhV/eKxHKaD+Ng74vs CYfydu3Sj8cKwQdYNrfCtWRuIZifXq4iAQ3fsIbg= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 4 Mar 2014 14:50:19 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7AC19724-68FC-4A06-B491-8DA29BD2A1B7@nic.cz> References: <20140111.133634.462426147.mbj@tail-f.com> <12A63CCF-69CE-4D43-A3EC-F420635B5237@nic.cz> <20140220134130.GA19665@elstar.local> <20140220.145129.73716044088019744.mbj@tail-f.com> <657A1870-B234-4489-8F0E-A85559843C16@nic.cz> To: "Derek Man-Kit Yeung (myeung)" X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/MF8orMMkKb5yW32Twzq-Skcyw60 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 14:50:31 -0000 Hi Derek, thanks for reading the draft. On 04 Mar 2014, at 12:39, Derek Man-Kit Yeung (myeung) = wrote: > Hi Ladislav, >=20 >=20 > Have a few of questions for the draft. > 1) I saw an ipv4-unicast identity defined. > Is there a ipv4-multicast for reference to the RIB which store ipv4 > unicast route for RPF lookup? Identities are extensible by design, so the =93ipv4-multicast=94 = identity can (and will) be defined in another module - it will be = derived from the =93rt:ipv4=94 identity. > 2) How would topology as used in RFC5120 be supported? I am not an expert on IS-IS, so I don=92t have a quick answer to this. = Do you have any specific concerns that it might NOT work? > 3) Given routing-protocol has only name as the key > list routing-protocol { > key "name"; > Would it prevent different protocols from using the same name? Like > "router ospf 101" and "router rip 101" at the same time using IOS = syntax? List keys have to be unique, so in this case you would need to use e.g. = =93ospf-101=94 and =93rip-101=94 as the keys. Lada >=20 >=20 > Thanks, > - Derek >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 5 03:15:44 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A170B1A04B8 for ; Wed, 5 Mar 2014 03:15:40 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LuJOwdpn1Mw for ; Wed, 5 Mar 2014 03:15:38 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEC81A0250 for ; Wed, 5 Mar 2014 03:15:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id D1E3F540690; Wed, 5 Mar 2014 11:07:52 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Bf+R80fzWux; Wed, 5 Mar 2014 11:07:47 +0100 (CET) Received: from localhost (dhcp-a653.meeting.ietf.org [31.133.166.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 948435401BA; Wed, 5 Mar 2014 11:07:46 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder , netmod@ietf.org In-Reply-To: <20140304134348.GA27138@elstar.local> References: <20140304134348.GA27138@elstar.local> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Wed, 05 Mar 2014 10:07:39 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/eC4uWB76RJNFqXtZm-ZlOvtUbdc Subject: Re: [netmod] netmod charter revision (version 2014-03-04) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 11:15:40 -0000 Juergen Schoenwaelder writes: > > All data models must be fully interoperable with implementations > of NETCONF and YANG. > What is the purpose of this statement? In my view, data models that are valid YANG should satisfy this by definition. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 5 03:28:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782D21A0458 for ; Wed, 5 Mar 2014 03:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccJd0WmoO2Xu for ; Wed, 5 Mar 2014 03:28:26 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 298D31A0549 for ; Wed, 5 Mar 2014 03:28:25 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 12C791338; Wed, 5 Mar 2014 12:28:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ydyu-Qa2P_ft; Wed, 5 Mar 2014 12:28:19 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Wed, 5 Mar 2014 12:28:19 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9D7B22002F; Wed, 5 Mar 2014 12:28: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 djOIZJRLLn7L; Wed, 5 Mar 2014 12:28:18 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6E5B320033; Wed, 5 Mar 2014 12:28:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6CAF02B950C7; Wed, 5 Mar 2014 12:28:16 +0100 (CET) Date: Wed, 5 Mar 2014 12:28:15 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140305112815.GA30423@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20140304134348.GA27138@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZpbRX33kj4V1WvWoiJSFFhTMfuI Cc: netmod@ietf.org Subject: Re: [netmod] netmod charter revision (version 2014-03-04) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 05 Mar 2014 11:28:28 -0000 On Wed, Mar 05, 2014 at 10:07:39AM +0000, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > > All data models must be fully interoperable with implementations > > of NETCONF and YANG. > > > > What is the purpose of this statement? In my view, data models that are valid YANG should satisfy this by definition. > I tend to agree. This sentence was copied from the current charter... Perhaps we can say explicitely in the second paragraph that data models are written in YANG and then this sentence can be removed, that is: s/developing data models/developing data models written in YANG/ /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 Mar 5 03:29:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAC01A049C for ; Wed, 5 Mar 2014 03:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] autolearn=no Received: 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_DakasnhJNJ for ; Wed, 5 Mar 2014 03:29:28 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 621EA1A0458 for ; Wed, 5 Mar 2014 03:29:28 -0800 (PST) Received: from [IPv6:2001:67c:370:160:4c1:eada:44ca:1ba7] (unknown [IPv6:2001:67c:370:160:4c1:eada:44ca:1ba7]) by mail.nic.cz (Postfix) with ESMTPSA id 1510614014F; Wed, 5 Mar 2014 12:29:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394018964; bh=z/CeCH/CHZFdBPiY5tf3+QgMGGcguiLEN3iMHw9ljlk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=uJ/6o8OtONkv9XVDF6IyKMJ2EL9imsAtgOADfFjEtPB8CV8gZ1T5jjRphiwXunldx 0sLI+lc19huzW46FSE/LxOdVj5LbMKemTwRcdBt5zgX1dfIxYNoE0V6sgzJev+dQJE ziTXMnmCk6ecV+cNOSiNBAJBOpPhPgAgxGj0TjB0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140305112815.GA30423@elstar.local> Date: Wed, 5 Mar 2014 11:29:21 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140304134348.GA27138@elstar.local> <20140305112815.GA30423@elstar.local> To: =?iso-8859-1?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/FG_Xbb7tuh1_Rx1vAyarrHUEmwM Cc: netmod@ietf.org Subject: Re: [netmod] netmod charter revision (version 2014-03-04) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 11:29:30 -0000 On 05 Mar 2014, at 11:28, Juergen Schoenwaelder = wrote: > On Wed, Mar 05, 2014 at 10:07:39AM +0000, Ladislav Lhotka wrote: >> Juergen Schoenwaelder writes: >>>=20 >>> All data models must be fully interoperable with implementations >>> of NETCONF and YANG. >>>=20 >>=20 >> What is the purpose of this statement? In my view, data models that = are valid YANG should satisfy this by definition. >>=20 >=20 > I tend to agree. This sentence was copied from the current charter... >=20 > Perhaps we can say explicitely in the second paragraph that data = models > are written in YANG and then this sentence can be removed, that is: >=20 > s/developing data models/developing data models written in YANG/ +1 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 Wed Mar 5 07:25:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6D11A00C2 for ; Wed, 5 Mar 2014 07:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UU7MY25wXrfp for ; Wed, 5 Mar 2014 07:25:44 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 773EF1A0122 for ; Wed, 5 Mar 2014 07:25:44 -0800 (PST) Received: from dhcp-a653.meeting.ietf.org (dhcp-a653.meeting.ietf.org [31.133.166.83]) by mail.nic.cz (Postfix) with ESMTPSA id 546E414014F for ; Wed, 5 Mar 2014 16:25:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394033140; bh=8xNENn9KAOK0uqGT7CRqms1FnraG/ASJ/oahuGIOCrA=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id: Date:To:Mime-Version; b=v9EPH+SbAouxQaHwAc7grztbvTI2mS0EP9gNZLgypeF5EekX8Oq18jFxytdstSLzq 3AUSiO8zfj4ZEnutEtbacup8qeXfS2tsmYRv/rd9kuotQllVnXMYwo09FTGqz3IURv biSu+34mlQGbbzlVrDpkU3/84WgZMqSTQ7SULBPg= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3D792068-D432-4011-B402-809638F07E43@nic.cz> Date: Wed, 5 Mar 2014 15:25:39 +0000 To: netmod@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/uabMHOH52Dvi_nd9gBtU7caW_ik Subject: [netmod] identities - multiple inheritance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 15:25:46 -0000 Hi, here is a simple example why an identity deriving from multiple bases = can be useful: identity ethernet { base if:interface-type; } identity ieee802.11 { base if:interface-type; } Then, a WiFi interface whose type is derived from both identities can = include in its configuration and state data both general Ethernet = parameters (as in ifconfig) as well as the radio parameters (as in = iwconfig). Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 5 07:44:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F6C1A00AF for ; Wed, 5 Mar 2014 07:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9G5o7uR-9A1 for ; Wed, 5 Mar 2014 07:44:42 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D3EF31A0732 for ; Wed, 5 Mar 2014 07:44:41 -0800 (PST) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:81f5:2b14:607f:7f9c]) by mail.nic.cz (Postfix) with ESMTPSA id 7B9FD14014F; Wed, 5 Mar 2014 16:44:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394034277; bh=B0ZeszqEvUaD4isQrmhTPXE1hYEm45jZIsL9abE4Tvw=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-Id:Cc:To:Mime-Version; b=xGtUUMpX3q0ij9fmOyseGO7utmuawLxo6Fwkl/7YbiiVTWZ8Yk995PNYYDu1MXxWW q5q3bolE0jgMs7d9T25mlNkPFqwa2Se07nTTX7nf0DwnnSVdrpca0EG+PlkxTo/kaJ imSnFKF3jcjedQIYKtY2eGctk6zX9uRvqTXUWlj0= From: Ladislav Lhotka Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Mar 2014 15:44:36 +0000 Message-Id: To: "Derek Man-Kit Yeung (myeung)" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LlQSv3pWUTD-ykg3Pi_2oFPg3ZE Cc: netmod@ietf.org Subject: [netmod] OSPF interfaces X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 15:44:43 -0000 Hi Derek, one comment to your OSPF module: in the configuration of interfaces = (inside an area), you should not use the type "if:interface-ref" for the = =93interface=94 leaf because you have to make sure that only interfaces = belonging to the same routing instance are used. So the definition = should be something like leaf interface { type leafref { path =93../=85/../rt:interfaces/rt:interface/rt:name=94; } } (I am too lazy to count how many double-dots are actually needed;-). The leaf =93te-rid=94 is the same case. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 5 08:32:02 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0AB21A01BF; Wed, 5 Mar 2014 08:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oxznD2I3Lf4; Wed, 5 Mar 2014 08:31:59 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id C4CAB1A01A7; Wed, 5 Mar 2014 08:31:58 -0800 (PST) Received: from localhost (dhcp-83db.meeting.ietf.org [31.133.131.219]) by mail.tail-f.com (Postfix) with ESMTPSA id A442C37C2BC; Wed, 5 Mar 2014 17:31:54 +0100 (CET) Date: Wed, 05 Mar 2014 16:31:54 +0000 (GMT) Message-Id: <20140305.163154.391777655.mbj@tail-f.com> To: equinox@diac24.net From: Martin Bjorklund In-Reply-To: <20140303140039.GZ856433@jupiter.n2.diac24.net> References: <20140303140039.GZ856433@jupiter.n2.diac24.net> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/CrUulRrry-Y31SKQSVabubMYHi8 Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 16:32:01 -0000 Hi, David Lamparter wrote: > Hi, > > > (this is the mail version of the somewhat garbled comment on the mic) > > The original question was, how the configured device chooses a "VPN" > for > either incoming or outgoing connections. This referred to VRF > instances. In particular, for the very simplest case where this > matters, there are devices that have out of band management ports and > treat those as a VRF. So, both for listening and for connecting, the > device needs to choose between "VR-Default" and "VR-Mgmt" (actual > names, > guess the vendor.) It could even listen in both VRFs, to be > manageable > inband (normal ops maybe?) and out of band (network in flames?). > > Even though this was raised on the server config model, this is a > rather > generic problem. E.g. specifying a NTP or Syslog server has the same > issue. (Cc' from netconf to netmod due to this.) If I understand this correctly, the proposal is to include a reference to a routing-instance (rt:routing-instance-ref) in all cases where we currently have an ip-address (or host) and a port, since the combination of ip-adress and port is not guaranteed to be unique, on systems with multiple routing instances. leaf address { type inet:ip-address; } leaf port { type inet:port-number; } leaf routing-instance { type rt:routing-instance-ref; } The existsing data models (specifically ietf-system) are designed in a way that vendors can augment there own definition of routing-instance or vrf. (However, I noticed that ietf-snmp is not). The question is if the IETF models should include a standardized way to handle this. I can see three alternatives: 1) Do nothing. I.e., assume ip/port is unique. 2) In all our data models, always make sure we add an (optional) reference to a routing-instance, whenever we have a ip/port for inbound/outbound traffic. 3) Do not add the routing-instance references, but design our data models so that vendors can augment with this if they have to. /martin From nobody Wed Mar 5 08:47:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740CB1A0759; Wed, 5 Mar 2014 08:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6FvChnfPk6S; Wed, 5 Mar 2014 08:46:57 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id AEEA61A071A; Wed, 5 Mar 2014 08:46: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 C2DFF18E8; Wed, 5 Mar 2014 17:46:53 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id EHWlYIzE9CTx; Wed, 5 Mar 2014 17:46:53 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Wed, 5 Mar 2014 17:46:53 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5BEBC2002C; Wed, 5 Mar 2014 17:46:53 +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 SpXYenMFT8Q8; Wed, 5 Mar 2014 17:46:52 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F5C42002F; Wed, 5 Mar 2014 17:46:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8845B2B95E23; Wed, 5 Mar 2014 17:46:50 +0100 (CET) Date: Wed, 5 Mar 2014 17:46:49 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140305164648.GC31132@elstar.local> Mail-Followup-To: Martin Bjorklund , equinox@diac24.net, netconf@ietf.org, netmod@ietf.org References: <20140303140039.GZ856433@jupiter.n2.diac24.net> <20140305.163154.391777655.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140305.163154.391777655.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ho2G-omc0Gms8sFtlEP043WEMI0 Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 05 Mar 2014 16:47:02 -0000 On Wed, Mar 05, 2014 at 04:31:54PM +0000, Martin Bjorklund wrote: > Hi, > > The question is if the IETF models should include a standardized way > to handle this. I can see three alternatives: > > 1) Do nothing. I.e., assume ip/port is unique. > > 2) In all our data models, always make sure we add an (optional) > reference to a routing-instance, whenever we have a ip/port for > inbound/outbound traffic. > > 3) Do not add the routing-instance references, but design our data > models so that vendors can augment with this if they have to. > My preference is 3) unless there is documented IETF agreement that addressing needs to include a routing instance (e.g., a standards-track RFC). My understanding is that 3) also allows IETF augmentations, not only vendor augmentations. /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 Mar 5 08:51:20 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAF61A0784; Wed, 5 Mar 2014 08:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] autolearn=no Received: 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_EoYQ67Bbgw; Wed, 5 Mar 2014 08:51:14 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 813E31A078C; Wed, 5 Mar 2014 08:51:14 -0800 (PST) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:81f5:2b14:607f:7f9c]) by mail.nic.cz (Postfix) with ESMTPSA id 178E613F94C; Wed, 5 Mar 2014 17:51:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394038270; bh=eRyNDXhPrtbyG7sNqC2dKGt3mRBYRnh+FKZzyIf7KBQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=kUWN5XYPbuK8/EaAJOk9BYuRWAt/CJMQ4kClBUQau9pqfadilC8yPOcrGGi7T4cXl 49B+7qk9XXq46/slznHylvf6Mg6kHdCzRdLZ2u00dFXBy5N9E5Lt6F84CGSedsn3ii D7tF9HBHICPu8QsxPX4PT55K2aZBLlknwB0pXfhA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140305.163154.391777655.mbj@tail-f.com> Date: Wed, 5 Mar 2014 16:51:08 +0000 Content-Transfer-Encoding: 7bit Message-Id: <9DA17C69-64BB-4F07-A5F8-91AF1ACB8796@nic.cz> References: <20140303140039.GZ856433@jupiter.n2.diac24.net> <20140305.163154.391777655.mbj@tail-f.com> To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/L1Z1KU-Xlb_nmRBN8l3euGk5rS0 Cc: Netconf , netmod@ietf.org Subject: Re: [netmod] [Netconf] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 16:51:16 -0000 On 05 Mar 2014, at 16:31, Martin Bjorklund wrote: > Hi, > > David Lamparter wrote: >> Hi, >> >> >> (this is the mail version of the somewhat garbled comment on the mic) >> >> The original question was, how the configured device chooses a "VPN" >> for >> either incoming or outgoing connections. This referred to VRF >> instances. In particular, for the very simplest case where this >> matters, there are devices that have out of band management ports and >> treat those as a VRF. So, both for listening and for connecting, the >> device needs to choose between "VR-Default" and "VR-Mgmt" (actual >> names, >> guess the vendor.) It could even listen in both VRFs, to be >> manageable >> inband (normal ops maybe?) and out of band (network in flames?). >> >> Even though this was raised on the server config model, this is a >> rather >> generic problem. E.g. specifying a NTP or Syslog server has the same >> issue. (Cc' from netconf to netmod due to this.) > > If I understand this correctly, the proposal is to include a reference > to a routing-instance (rt:routing-instance-ref) in all cases where we > currently have an ip-address (or host) and a port, since the > combination of ip-adress and port is not guaranteed to be unique, on > systems with multiple routing instances. > > leaf address { type inet:ip-address; } > leaf port { type inet:port-number; } > leaf routing-instance { type rt:routing-instance-ref; } > > > The existsing data models (specifically ietf-system) are designed in a > way that vendors can augment there own definition of routing-instance > or vrf. (However, I noticed that ietf-snmp is not). > > The question is if the IETF models should include a standardized way > to handle this. I can see three alternatives: > > 1) Do nothing. I.e., assume ip/port is unique. > > 2) In all our data models, always make sure we add an (optional) > reference to a routing-instance, whenever we have a ip/port for > inbound/outbound traffic. > > 3) Do not add the routing-instance references, but design our data > models so that vendors can augment with this if they have to. My preference is #3. Lada > > > /martin > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 5 09:01:30 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714FE1A0140; Wed, 5 Mar 2014 09:01:25 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_378kv9R7yM; Wed, 5 Mar 2014 09:01:22 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDA11A012A; Wed, 5 Mar 2014 09:01:22 -0800 (PST) Received: from [2001:8d8:81:5c2::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1WLFC1-0002M0-Pz; Wed, 05 Mar 2014 18:01:17 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80.1) (envelope-from ) id 1WLFBn-003IgT-Os; Wed, 05 Mar 2014 18:01:07 +0100 Date: Wed, 5 Mar 2014 18:01:03 +0100 From: David Lamparter To: Martin Bjorklund Message-ID: <20140305170103.GQ104882@jupiter.n2.diac24.net> References: <20140303140039.GZ856433@jupiter.n2.diac24.net> <20140305.163154.391777655.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140305.163154.391777655.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/YWldsXJN4Zuqj43oaCLVcTz4oC0 Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 17:01:25 -0000 (comments below) On Wed, Mar 05, 2014 at 04:31:54PM +0000, Martin Bjorklund wrote: > David Lamparter wrote: > > The original question was, how the configured device chooses a "VPN" > > for > > either incoming or outgoing connections. This referred to VRF > > instances. In particular, for the very simplest case where this > > matters, there are devices that have out of band management ports and > > treat those as a VRF. So, both for listening and for connecting, the > > device needs to choose between "VR-Default" and "VR-Mgmt" (actual > > names, > > guess the vendor.) It could even listen in both VRFs, to be > > manageable > > inband (normal ops maybe?) and out of band (network in flames?). > > > > Even though this was raised on the server config model, this is a > > rather > > generic problem. E.g. specifying a NTP or Syslog server has the same > > issue. (Cc' from netconf to netmod due to this.) > > If I understand this correctly, the proposal is to include a reference > to a routing-instance (rt:routing-instance-ref) in all cases where we > currently have an ip-address (or host) and a port, since the > combination of ip-adress and port is not guaranteed to be unique, on > systems with multiple routing instances. Indeed, with the caveat that this also applies to listening ports (which are specified just the same, just noting it so this doesn't get lost.) > leaf address { type inet:ip-address; } > leaf port { type inet:port-number; } > leaf routing-instance { type rt:routing-instance-ref; } > > > The existsing data models (specifically ietf-system) are designed in a > way that vendors can augment there own definition of routing-instance > or vrf. (However, I noticed that ietf-snmp is not). > > The question is if the IETF models should include a standardized way > to handle this. I can see three alternatives: > > 1) Do nothing. I.e., assume ip/port is unique. > > 2) In all our data models, always make sure we add an (optional) > reference to a routing-instance, whenever we have a ip/port for > inbound/outbound traffic. > > 3) Do not add the routing-instance references, but design our data > models so that vendors can augment with this if they have to. It seems that 1) would imply a mixture of not having support for this and case 3) in places where we already allow extensions, and I'd claim that this inconsistency is undesirable. I would however argue for option 2), based on the fact that routing-cfg does have routing instances in a standardised way, and I don't see the point in each vendor defining a distinct extension to add this reference. Essentially, I would say that if there's a problem with 2) here, there's also a problem with routing instances in routing-cfg, which in turn means we fix that or we're headed for neverland on the express train. Cheers, -David From nobody Wed Mar 5 09:15:36 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3095D1A03BC; Wed, 5 Mar 2014 09:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSnWNXYJmxCl; Wed, 5 Mar 2014 09:15:29 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A9A411A01A7; Wed, 5 Mar 2014 09:15:28 -0800 (PST) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:81f5:2b14:607f:7f9c]) by mail.nic.cz (Postfix) with ESMTPSA id 3415913F94C; Wed, 5 Mar 2014 18:15:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394039724; bh=Zpw55qUaW7mexjOk/4UtM0PvhZZUDYCKgr5mKMju+vk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=VmqpiLrfd1TVOlGZJEqcZlBDMy8HFBU7LesZT52FGJvtDfuEZABghHAlLimvooDCe DN/ABkFeBg+Xh8WrT9sNTxoXk/VIcjHvdzMoTHLSnVZy94VW+w1p1IggpH2l1PBa16 lHxa5rPKWrX+zFSHvBMTV0fcZvG5i3oi+gVIvi8E= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140305170103.GQ104882@jupiter.n2.diac24.net> Date: Wed, 5 Mar 2014 17:15:23 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140303140039.GZ856433@jupiter.n2.diac24.net> <20140305.163154.391777655.mbj@tail-f.com> <20140305170103.GQ104882@jupiter.n2.diac24.net> To: David Lamparter X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/eN992sc_yRp-QXA2bQBnoCbCAGw Cc: Netconf , netmod@ietf.org Subject: Re: [netmod] [Netconf] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 17:15:32 -0000 On 05 Mar 2014, at 17:01, David Lamparter wrote: > (comments below) >=20 > On Wed, Mar 05, 2014 at 04:31:54PM +0000, Martin Bjorklund wrote: >> David Lamparter wrote: >>> The original question was, how the configured device chooses a "VPN" >>> for >>> either incoming or outgoing connections. This referred to VRF >>> instances. In particular, for the very simplest case where this >>> matters, there are devices that have out of band management ports = and >>> treat those as a VRF. So, both for listening and for connecting, = the >>> device needs to choose between "VR-Default" and "VR-Mgmt" (actual >>> names, >>> guess the vendor.) It could even listen in both VRFs, to be >>> manageable >>> inband (normal ops maybe?) and out of band (network in flames?). >>>=20 >>> Even though this was raised on the server config model, this is a >>> rather >>> generic problem. E.g. specifying a NTP or Syslog server has the = same >>> issue. (Cc' from netconf to netmod due to this.) >>=20 >> If I understand this correctly, the proposal is to include a = reference >> to a routing-instance (rt:routing-instance-ref) in all cases where we >> currently have an ip-address (or host) and a port, since the >> combination of ip-adress and port is not guaranteed to be unique, on >> systems with multiple routing instances. >=20 > Indeed, with the caveat that this also applies to listening ports = (which > are specified just the same, just noting it so this doesn't get lost.) >=20 >> leaf address { type inet:ip-address; } >> leaf port { type inet:port-number; } >> leaf routing-instance { type rt:routing-instance-ref; } >>=20 >>=20 >> The existsing data models (specifically ietf-system) are designed in = a >> way that vendors can augment there own definition of routing-instance >> or vrf. (However, I noticed that ietf-snmp is not). >>=20 >> The question is if the IETF models should include a standardized way >> to handle this. I can see three alternatives: >>=20 >> 1) Do nothing. I.e., assume ip/port is unique. >>=20 >> 2) In all our data models, always make sure we add an (optional) >> reference to a routing-instance, whenever we have a ip/port for >> inbound/outbound traffic. >>=20 >> 3) Do not add the routing-instance references, but design our data >> models so that vendors can augment with this if they have to. >=20 > It seems that 1) would imply a mixture of not having support for this > and case 3) in places where we already allow extensions, and I'd claim > that this inconsistency is undesirable. >=20 > I would however argue for option 2), based on the fact that = routing-cfg > does have routing instances in a standardised way, and I don't see the > point in each vendor defining a distinct extension to add this > reference. Essentially, I would say that if there's a problem with 2) As Juergen already pointed out in his reply, a standard model can be = written for this purpose, too. Lada > here, there's also a problem with routing instances in routing-cfg, > which in turn means we fix that or we're headed for neverland on the > express train. >=20 >=20 > Cheers, >=20 >=20 > -David >=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 Wed Mar 5 09:15:44 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E951A029D; Wed, 5 Mar 2014 09:15:37 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnNFQkX7QxKT; Wed, 5 Mar 2014 09:15:31 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2761A0183; Wed, 5 Mar 2014 09:15:31 -0800 (PST) Received: from [2001:8d8:81:5c2::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1WLFPi-00035B-V0; Wed, 05 Mar 2014 18:15:27 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80.1) (envelope-from ) id 1WLFPV-003JVS-Sp; Wed, 05 Mar 2014 18:15:16 +0100 Date: Wed, 5 Mar 2014 18:15:13 +0100 From: David Lamparter To: Martin Bjorklund , equinox@diac24.net, netconf@ietf.org, netmod@ietf.org Message-ID: <20140305171513.GR104882@jupiter.n2.diac24.net> References: <20140303140039.GZ856433@jupiter.n2.diac24.net> <20140305.163154.391777655.mbj@tail-f.com> <20140305164648.GC31132@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20140305164648.GC31132@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/x5DmrrGfMOSIyB-uV2-MPR9oAHM Subject: Re: [netmod] [Netconf] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 17:15:38 -0000 On Wed, Mar 05, 2014 at 05:46:49PM +0100, Juergen Schoenwaelder wrote: > On Wed, Mar 05, 2014 at 04:31:54PM +0000, Martin Bjorklund wrote: > > Hi, > > > > The question is if the IETF models should include a standardized way > > to handle this. I can see three alternatives: > > > > 1) Do nothing. I.e., assume ip/port is unique. > > > > 2) In all our data models, always make sure we add an (optional) > > reference to a routing-instance, whenever we have a ip/port for > > inbound/outbound traffic. > > > > 3) Do not add the routing-instance references, but design our data > > models so that vendors can augment with this if they have to. > > > > My preference is 3) unless there is documented IETF agreement > that addressing needs to include a routing instance (e.g., a > standards-track RFC). My understanding is that 3) also allows > IETF augmentations, not only vendor augmentations. I've made this as an assumption in my previous answer, but didn't explicitly mention it: I believe having support for routing instances in routing-cfg and having a reference in addressing share the same reasoning: there are configurable systems that contain more than one VRF / IP stack / routing domain / whatever you call it. And as such, just like you can't add a static route without saying which of these instances you want to insert it in, it's underspecified from where you want to establish your syslog connection if you don't specify the IP stack instance to be used. Yes, there might be a default instance for management. But I believe the rather widespread case of a box with in-band + out-of-band management rectifies always having this reference. We're not talking about enterprise routers here, this is 400€ small-business COTS switches. Are there reasons for modeling routing instances in routing-cfg that don't apply here? NB: it might be an acceptable solution to fix this in a separate draft for existing extensible cases, so we don't need to reroll things. However, for future models, I don't think we want to create a VRF-for-this VRF-for-that extra spec each single time? -David From nobody Wed Mar 5 09:27:43 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C856D1A00F5 for ; Wed, 5 Mar 2014 09:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjKzrnzCSLdo for ; Wed, 5 Mar 2014 09:27:40 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id B232C1A011E for ; Wed, 5 Mar 2014 09:27: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 C0E7F1445 for ; Wed, 5 Mar 2014 18:27:36 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id o2gIO2EIT_yj for ; Wed, 5 Mar 2014 18:27:35 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP for ; Wed, 5 Mar 2014 18:27:35 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94B4320033 for ; Wed, 5 Mar 2014 18:27:35 +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 eDlnObAqfNFY; Wed, 5 Mar 2014 18:27:34 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C5BF2002C; Wed, 5 Mar 2014 18:27:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9AB252B9614C; Wed, 5 Mar 2014 18:27:30 +0100 (CET) Date: Wed, 5 Mar 2014 18:27:30 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140305172730.GA31399@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20140304134348.GA27138@elstar.local> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: <20140304134348.GA27138@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/GOIfl4ISd2GllKh17yN0P8seDjE Subject: Re: [netmod] netmod charter revision (version 2014-03-04) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 05 Mar 2014 17:27:43 -0000 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Mar 04, 2014 at 02:43:48PM +0100, Juergen Schoenwaelder wrote: > Hi, > > here is another charter text proposal based on the feedback received > on the mailing list and during hallway discussions at the IETF in > London. Please read and comment. We plan to resolve the charter > revision discussion tomorrow at the WG meeting. But please, if you > have issues with the new proposal, please raise them as soon as > possible (it is good to be aware of any issues before the meeting). > I have udpated the charter text based on the feedback received so far. In particular, I have - applied the fix posted previously to address Lada's comment - fixed the wording in the milestones list - added a pointer to YANG doctors so people know where to go - checked the usage of NETCONF (and as part of that changed 'planned work in NETCONF' to 'work in NETCONF') - changed 'new data modeling concepts' to 'fundamentally new data modeling concepts' in the hope that this makes the intention a bit clearer Benoit, you may want to upload this to the tracker so people can easily see the diff. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="netmod-charter-2014-03-05.txt" The NETMOD working group has defined the data modeling language YANG, which can be used to specify network management data models that are manipulated by the NETCONF protocol. The NETMOD working group also defined a number of core data models as basic building blocks. The purpose of the NETMOD working group is to support the ongoing deployment of YANG by maintaining and evolving the core YANG specifications based on usage experience and developing data models written in YANG that are considered core building blocks and that do not fall into charters of other active IETF working groups (for example a data model for stateless packet filters). The NETMOD Working Group will produce a maintenance release of the core YANG specification called YANG 1.1, that is a revision of RFC 6020. The changes to RFC 6020 are restricted in the following ways: - All compliant YANG 1.0 modules must be accepted as compliant YANG 1.1 modules. - All known ambiguities of YANG 1.0 and all reported defects and errata will be addressed. - YANG 1.1 is not adding fundamentally new data modeling concepts to the language. - The changes of the specification will be kept to the minimum necessary to achieve the previously stated goals. The NETMOD Working Group will also revise the Guidelines for Authors and Reviewers of YANG Data Models (RFC 6087) in order to fix any ambiguities and to incorporate the lessons learned by producing YANG data models. The NETMOD Working Group will produce a specification how YANG-defined data trees can be represented in JSON. The NETMOD Working Group will not serve as a review team for YANG modules developed by other working groups. The YANG doctors, organized by the OPS area director responsible for network management, can act as advisors for other working groups and they provide YANG reviews for the OPS area directors [1]. The WG will consult with the NETCONF working group to ensure that NETMOD's decision do not conflict with work in NETCONF. [1] http://www.ietf.org/iesg/directorate/yang-doctors.html Goals and Milestones: Apr 2014 - Submit first working group draft of the stateless packet filter data model Apr 2014 - Submit first working group draft of a mapping to JSON May 2014 - Compiled issue list to be considered for YANG 1.1 Jul 2014 - Submit first working group draft of YANG 1.1 Oct 2014 - Submit stateless packet filter data model to the IESG Oct 2014 - Submit the mapping to JSON to the IESG Mar 2015 - Submit YANG 1.1 to the IESG --2fHTh5uZTiUOsy+g-- From nobody Wed Mar 5 09:32:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BAA1A01F4; Wed, 5 Mar 2014 09:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 928MQyVd_8_z; Wed, 5 Mar 2014 09:31:54 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DC6EE1A01E2; Wed, 5 Mar 2014 09:31:53 -0800 (PST) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:81f5:2b14:607f:7f9c]) by mail.nic.cz (Postfix) with ESMTPSA id E951714014F; Wed, 5 Mar 2014 18:31:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394040709; bh=LhG10vUa1qMUMcrUgRV3J/PbFa/Jo9w6NsCiD00280A=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=oxW4LGM/sdzP6c0/efnhO9WgNppafb8cgYzQW8fpMlUqqLy6IFNFTE3+i1iwXZXOb jDqUieX5R++q/JtPV2chpoMW1rRlRJPnHypXrvvvsCH81FV2H+jSfuXvgbOf85aiWd vfCdez1JKfQiuihhLI3xHleiZjPCxtOASnTJATi8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140305171513.GR104882@jupiter.n2.diac24.net> Date: Wed, 5 Mar 2014 17:31:47 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6161D244-5AE2-4C0A-9EAF-67160E456AE7@nic.cz> References: <20140303140039.GZ856433@jupiter.n2.diac24.net> <20140305.163154.391777655.mbj@tail-f.com> <20140305164648.GC31132@elstar.local> <20140305171513.GR104882@jupiter.n2.diac24.net> To: David Lamparter X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/DOLmpVLJiZ-ZUNj8erSQAi-tfnw Cc: Netconf , netmod@ietf.org Subject: Re: [netmod] [Netconf] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 17:31:56 -0000 On 05 Mar 2014, at 17:15, David Lamparter wrote: > On Wed, Mar 05, 2014 at 05:46:49PM +0100, Juergen Schoenwaelder wrote: >> On Wed, Mar 05, 2014 at 04:31:54PM +0000, Martin Bjorklund wrote: >>> Hi, >>>=20 >>> The question is if the IETF models should include a standardized way >>> to handle this. I can see three alternatives: >>>=20 >>> 1) Do nothing. I.e., assume ip/port is unique. >>>=20 >>> 2) In all our data models, always make sure we add an (optional) >>> reference to a routing-instance, whenever we have a ip/port for >>> inbound/outbound traffic. >>>=20 >>> 3) Do not add the routing-instance references, but design our data >>> models so that vendors can augment with this if they have to. >>>=20 >>=20 >> My preference is 3) unless there is documented IETF agreement >> that addressing needs to include a routing instance (e.g., a >> standards-track RFC). My understanding is that 3) also allows >> IETF augmentations, not only vendor augmentations. >=20 > I've made this as an assumption in my previous answer, but didn't > explicitly mention it: I believe having support for routing instances > in routing-cfg and having a reference in addressing share the same > reasoning: there are configurable systems that contain more than one > VRF / IP stack / routing domain / whatever you call it. And as such, > just like you can't add a static route without saying which of these > instances you want to insert it in, it's underspecified from where you > want to establish your syslog connection if you don't specify the IP > stack instance to be used. >=20 > Yes, there might be a default instance for management. But I believe > the rather widespread case of a box with in-band + out-of-band > management rectifies always having this reference. We're not talking > about enterprise routers here, this is 400=80 small-business COTS > switches. >=20 > Are there reasons for modeling routing instances in routing-cfg that > don't apply here? It should probably be spelled out somewhere, but in many cases there = will only be a single routing instance, so it is bound to be the default = to be used for all routing. =20 >=20 >=20 > NB: it might be an acceptable solution to fix this in a separate draft > for existing extensible cases, so we don't need to reroll things. > However, for future models, I don't think we want to create a > VRF-for-this VRF-for-that extra spec each single time? I see your point, a separate draft can only define augments for the = existing cases. Then #2 might be indeed better, perhaps using a feature = like =93multiple-routing-instances=94. Lada >=20 >=20 > -David >=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 Thu Mar 6 00:31:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384EF1A0121 for ; Thu, 6 Mar 2014 00:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9PqrzmEvaZr for ; Thu, 6 Mar 2014 00:31:02 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0CF1A0020 for ; Thu, 6 Mar 2014 00:31:02 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1BB5C1C79 for ; Thu, 6 Mar 2014 09:30:58 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id O4Zb9lp4Fgh6 for ; Thu, 6 Mar 2014 09:30:56 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP for ; Thu, 6 Mar 2014 09:30:56 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 716932002F for ; Thu, 6 Mar 2014 09:30:56 +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 A-Iuf4c-J745; Thu, 6 Mar 2014 09:30: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 A446B20031; Thu, 6 Mar 2014 09:30:55 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 83E1B2B96F90; Thu, 6 Mar 2014 09:30:54 +0100 (CET) Date: Thu, 6 Mar 2014 09:30:54 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140306083054.GA32986@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZjW67xQYMc3BJUg6RO8A2quWLs0 Subject: [netmod] ietf 89 wg meeting summary X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 06 Mar 2014 08:31:05 -0000 Hi, below is a high-level summary of yesterday's WG meeting that I just submitted to the OPS ADs and that will be also part of the minutes. The NETMOD meeting in London was attended by about 70 people. All currently charter work items are either in the RFC editor queue, on the IESG agenda, or they passed WG last call and are on the way to the area director. The discussion of a proposed new WG charter resulted in some minor modifications. The active contributors indicated support for the new charter and there were no objections. The revised charter text including the modifications has been circulated on the mailing list right after the meeting. After the charter discussion, the WG started to go through a list of issues that may be addressed in a YANG maintenance release in order to determine which issues are in scope, out of scope, or need more discussion. The status of the stateless packet filter data model and a revision of the guidelines document has been reported. /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 Mar 6 01:12:53 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930B31A0194; Thu, 6 Mar 2014 01:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWQGgQa_qvX1; Thu, 6 Mar 2014 01:12:48 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6310F1A0170; Thu, 6 Mar 2014 01:12:48 -0800 (PST) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:6da5:2533:a87:3733]) by mail.nic.cz (Postfix) with ESMTPSA id 7915013F94C; Thu, 6 Mar 2014 10:12:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394097164; bh=Ewx+nNvdueux7BWm2ByqPT7pz9yI6xBdsUPtd4U0xdM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=FmDbnb8yoF9gL4Bd6Qh+WHQkEfkzX8HhyreKqVR3EIHWmxr3VQnS7Z9FBEvkXpfJs I6b9W/Zd4SpPczoKy6TNCD2i1hmaKNwdHaVSkM7ujw99VgTp8zS9L0vnDSZprFJ1Ih UIcUHmdWJ98uTjR+/tis/LJE9PUd0We61x67U4is= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140305.163154.391777655.mbj@tail-f.com> Date: Thu, 6 Mar 2014 09:12:41 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <48B5B401-32B6-4928-B917-1D32421B4244@nic.cz> References: <20140303140039.GZ856433@jupiter.n2.diac24.net> <20140305.163154.391777655.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hs8NPQO1y044eiRAafH6WwT8-14 Cc: Netconf , netmod@ietf.org Subject: Re: [netmod] [Netconf] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 09:12:50 -0000 On 05 Mar 2014, at 16:31, Martin Bjorklund wrote: > Hi, >=20 > David Lamparter wrote: >> Hi, >>=20 >>=20 >> (this is the mail version of the somewhat garbled comment on the mic) >>=20 >> The original question was, how the configured device chooses a "VPN" >> for >> either incoming or outgoing connections. This referred to VRF >> instances. In particular, for the very simplest case where this >> matters, there are devices that have out of band management ports and >> treat those as a VRF. So, both for listening and for connecting, the >> device needs to choose between "VR-Default" and "VR-Mgmt" (actual >> names, >> guess the vendor.) It could even listen in both VRFs, to be >> manageable >> inband (normal ops maybe?) and out of band (network in flames?). >>=20 >> Even though this was raised on the server config model, this is a >> rather >> generic problem. E.g. specifying a NTP or Syslog server has the same >> issue. (Cc' from netconf to netmod due to this.) >=20 > If I understand this correctly, the proposal is to include a reference > to a routing-instance (rt:routing-instance-ref) in all cases where we Hmm, it is actually not that simple. It is possible to have different = types of routing instances distinguished by the =93rt:type=94 child. So = it is not true that routing-instance =3D=3D VRF instance. Therefore, the correct approach is IMO this: 1. A module will be written defining the VRF type of routing instances = and specifying the semantics of this kind of virtualization. 2. Where necessary, vrf-id leafs will be added to the existing module = via augments. Before this is done, alternative #3 in Martin=92s list (i.e. enabling = step 2 above) seems to be the best option after all. Lada > currently have an ip-address (or host) and a port, since the > combination of ip-adress and port is not guaranteed to be unique, on > systems with multiple routing instances. >=20 > leaf address { type inet:ip-address; } > leaf port { type inet:port-number; } > leaf routing-instance { type rt:routing-instance-ref; } >=20 >=20 > The existsing data models (specifically ietf-system) are designed in a > way that vendors can augment there own definition of routing-instance > or vrf. (However, I noticed that ietf-snmp is not). >=20 > The question is if the IETF models should include a standardized way > to handle this. I can see three alternatives: >=20 > 1) Do nothing. I.e., assume ip/port is unique. >=20 > 2) In all our data models, always make sure we add an (optional) > reference to a routing-instance, whenever we have a ip/port for > inbound/outbound traffic. >=20 > 3) Do not add the routing-instance references, but design our data > models so that vendors can augment with this if they have to. >=20 >=20 > /martin >=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 Thu Mar 6 01:50:59 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2411A019A for ; Thu, 6 Mar 2014 01:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOEtoHUs8n9D for ; Thu, 6 Mar 2014 01:50:54 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id A6CCE1A0194 for ; Thu, 6 Mar 2014 01:50:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3184; q=dns/txt; s=iport; t=1394099451; x=1395309051; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dMYmkVjjMvYIpIsV9NHqjwfLjaDyHAcqRViW5fzu57Q=; b=Gbix3noN2UoJ/WHHCepnIlyT86k5+AffYVZsmQb+h8XTnY7LMuXfzmhE 8jt1PuvH/VxyUJEPipBJ37l7GTJ7ccyxeMkQ7RlwZgnboxvd81O2x1mB3 Vo2dyArPccfOdaR4IRziEgWlijHJNgvaMewZv7CAWOVMqhJ34LUboy1il Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAHFDGFOtJV2Z/2dsb2JhbABRCYMGgRLBHYEbFnSCJQEBAQMBaw4QAgEIRjIlAgQOBRuHVgjPGheNdigzB4Q4BIkTjyqSK4Mtgio X-IronPort-AV: E=Sophos;i="4.97,598,1389744000"; d="scan'208";a="25342130" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP; 06 Mar 2014 09:50:50 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s269ooeh024418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Mar 2014 09:50:50 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.3]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Thu, 6 Mar 2014 03:50:50 -0600 From: "Derek Man-Kit Yeung (myeung)" To: Ladislav Lhotka Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt Thread-Index: AQHPN6a8TcSsF5Wm80Ok259R/K6NOZrRZ2eAgAJK3AA= Date: Thu, 6 Mar 2014 09:50:50 +0000 Message-ID: References: <20140111.133634.462426147.mbj@tail-f.com> <12A63CCF-69CE-4D43-A3EC-F420635B5237@nic.cz> <20140220134130.GA19665@elstar.local> <20140220.145129.73716044088019744.mbj@tail-f.com> <657A1870-B234-4489-8F0E-A85559843C16@nic.cz> <7AC19724-68FC-4A06-B491-8DA29BD2A1B7@nic.cz> In-Reply-To: <7AC19724-68FC-4A06-B491-8DA29BD2A1B7@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.92.66] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Xg2Vq4z98JDzUDf7QMNejHDTlY8 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 09:50:56 -0000 On 3/4/14 6:50 AM, "Ladislav Lhotka" wrote: >Hi Derek, > >thanks for reading the draft. > >On 04 Mar 2014, at 12:39, Derek Man-Kit Yeung (myeung) >wrote: > >> Hi Ladislav, >>=20 >>=20 >> Have a few of questions for the draft. >> 1) I saw an ipv4-unicast identity defined. >> Is there a ipv4-multicast for reference to the RIB which store ipv4 >> unicast route for RPF lookup? > >Identities are extensible by design, so the =B3ipv4-multicast=B2 identity = can >(and will) be defined in another module - it will be derived from the >=B3rt:ipv4=B2 identity. DY> Defer reply on this one. I have some questions on how identity is used. Will reply once I got that clarified. > >> 2) How would topology as used in RFC5120 be supported? > >I am not an expert on IS-IS, so I don=B9t have a quick answer to this. Do >you have any specific concerns that it might NOT work? DY> See reply in 3). > >> 3) Given routing-protocol has only name as the key >> list routing-protocol { >> key "name"; >> Would it prevent different protocols from using the same name? Like >> "router ospf 101" and "router rip 101" at the same time using IOS >>syntax? > >List keys have to be unique, so in this case you would need to use e.g. >=B3ospf-101=B2 and =B3rip-101=B2 as the keys. DY> One the router, the routing protocol is identified by the type and a tag. DY> Example is type OSPF and tag 101. For display purpose, you may see "ospf 101", "Protocol: OSPF, Tag: 101" or "ospf-101" depending on implementation. DY> When I read your draft, I took that name mean tag and hence the uniqueness question. DY> If name equate a string like "ospf-101", then the string cannot be just arbitrary as the draft said. DY> It has to have some forward like so the network device can extract the tag from it. DY> My preference is to treat the name as and include type a part of the key.=20 DY> Even if name mean just the tag, still need some kind of pattern as not all character is allowed. DY> Is this a way in YANG to augment the name with pattern which suit the implementation that it talk to? DY> For topology, it is just a RIB. DY> Before topology, a RIB is identified by (Name, AFI, SAFI) like ("Customer1", IPv4, UNICAST). DY> Topology add an extract topology name so the identifier become (VRF name, AFI, SAFI, Topo name). DY> Example are ("Customer1", IPv4, UNICAST, "Gold"), ("Customer1", IPv4, UNICAST, "Sliver"), ("Customer1", IPv4, UNICAST, "Bronze") DY> It is like providing multiple data in the under the same VRF, AFI and SAFI. DY> It is similar to the routing protocol name discussion. DY> Either an topology name is added (Could it be through augmentation as not all vendors support topology), DY> or the RIB name is made to have certain format like or :. DY> It will need more discussion to agree on solution. Thanks, - Derek > >Lada > >>=20 >>=20 >> Thanks, >> - Derek >>=20 >>=20 > >-- >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: E74E8C0C > > > > From nobody Thu Mar 6 02:44:14 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86EEB1A025C for ; Thu, 6 Mar 2014 02:44: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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0Q0e-0LhzbP for ; Thu, 6 Mar 2014 02:44:11 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id AE3EC1A01C8 for ; Thu, 6 Mar 2014 02:44:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id AB4BA54067F; Thu, 6 Mar 2014 11:44:05 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeStv8wBo8EV; Thu, 6 Mar 2014 11:43:59 +0100 (CET) Received: from localhost (dhcp-a653.meeting.ietf.org [31.133.166.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 686185401F0; Thu, 6 Mar 2014 11:43:58 +0100 (CET) From: Ladislav Lhotka To: "Derek Man-Kit Yeung \(myeung\)" In-Reply-To: References: <20140111.133634.462426147.mbj@tail-f.com> <12A63CCF-69CE-4D43-A3EC-F420635B5237@nic.cz> <20140220134130.GA19665@elstar.local> <20140220.145129.73716044088019744.mbj@tail-f.com> <657A1870-B234-4489-8F0E-A85559843C16@nic.cz> <7AC19724-68FC-4A06-B491-8DA29BD2A1B7@nic.cz> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Thu, 06 Mar 2014 10:43:54 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Ska-2jinvRsxi41-31Qj0TE18Ok Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 10:44:13 -0000 "Derek Man-Kit Yeung (myeung)" writes: ... >>> 3) Given routing-protocol has only name as the key >>> list routing-protocol { >>> key "name"; >>> Would it prevent different protocols from using the same name? Like >>> "router ospf 101" and "router rip 101" at the same time using IOS >>>syntax? >> >>List keys have to be unique, so in this case you would need to use e.g. >>=C2=B3ospf-101=C2=B2 and =C2=B3rip-101=C2=B2 as the keys. > > > DY> One the router, the routing protocol is identified by the type and a > tag. > DY> Example is type OSPF and tag 101. For display purpose, you may see > "ospf 101", "Protocol: OSPF, Tag: 101" or "ospf-101" depending on > implementation. > DY> When I read your draft, I took that name mean tag and hence the > uniqueness question. As this is a vendor-neutral module, we tried to avoid assigning semantics t= o the names of objects because that would hardly work for different vendors= . An implementation may use random strings as list keys provided they are u= nique. > DY> If name equate a string like "ospf-101", then the string cannot be > just arbitrary as the draft said. "ospf-101" is just an example how the name can be disambiguated in a way th= at is "friendly" to a particular platform.=20 > DY> It has to have some forward like Str> so the network device can extract the tag from it. I don't know what you mean by a "forward". How is this tag supposed to be u= sed? > DY> My preference is to treat the name as and include type a part of > the key.=20 > DY> Even if name mean just the tag, still need some kind of pattern as not > all character is allowed. > DY> Is this a way in YANG to augment the name with pattern which suit the > implementation that it talk to? Yes, it is. Some protocols add a tag as a new route attribute - see the exa= mple RIP implementation in Appendix C. If a vendor then wants to use a tag or anything else in an implementation-s= pecific way, it can do so by writing a proprietary module that augments the= standard module where necessary. This is IMO much better than encode seman= tics into routing protocol names. > > DY> For topology, it is just a RIB. > DY> Before topology, a RIB is identified by (Name, AFI, SAFI) like > ("Customer1", IPv4, UNICAST). > DY> Topology add an extract topology name so the identifier become (VRF > name, AFI, SAFI, Topo name). > DY> Example are ("Customer1", IPv4, UNICAST, "Gold"), ("Customer1", IPv4, > UNICAST, "Sliver"), ("Customer1", IPv4, UNICAST, "Bronze") > DY> It is like providing multiple data in the under the same VRF, AFI and > SAFI. > DY> It is similar to the routing protocol name discussion. > DY> Either an topology name is added (Could it be through augmentation as > not all vendors support topology), I believe this topology object has to do with link-state protocols, so in m= y view a future implementation of OSPF or IS-IS has to design new configura= tion and/or state data representing topologies, and augment "rt:routing-pro= tocol" (or "rt:interface") with it.=20=20 > DY> or the RIB name is made to have certain format like or Name>:. A discussion of VRFs is now going on in the NETCONF mailing list and I alre= ady expressed my opinion there: http://www.ietf.org/mail-archive/web/netconf/current/msg08755.html In short, I think the VRF concept should be defined as a special type of ro= uting-instance. Thanks, Lada > DY> It will need more discussion to agree on solution. > > Thanks, > - Derek > >> >>Lada >> >>>=20 >>>=20 >>> Thanks, >>> - Derek >>>=20 >>>=20 >> >>-- >>Ladislav Lhotka, CZ.NIC Labs >>PGP Key ID: E74E8C0C >> >> >> >> > --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Mar 6 03:49:52 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EC51A026A for ; Thu, 6 Mar 2014 03:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jf6c-J7RY_EZ for ; Thu, 6 Mar 2014 03:49:42 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id B53851A02C0 for ; Thu, 6 Mar 2014 03:49:42 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 65B3A9C; Thu, 6 Mar 2014 12:49:37 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5AEE39A; Thu, 6 Mar 2014 12:49:37 +0100 (CET) Date: Thu, 6 Mar 2014 12:49:37 +0100 (CET) From: Mikael Abrahamsson To: Juergen Schoenwaelder In-Reply-To: <20140306083054.GA32986@elstar.local> Message-ID: References: <20140306083054.GA32986@elstar.local> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/0RDyYjPfZoRXsO2vo3HLlbwi6Iw Cc: netmod@ietf.org Subject: Re: [netmod] ietf 89 wg meeting summary X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 11:49:45 -0000 On Thu, 6 Mar 2014, Juergen Schoenwaelder wrote: > Hi, > > below is a high-level summary of yesterday's WG meeting that I just > submitted to the OPS ADs and that will be also part of the minutes. I note that there is absolutely no mention of the discussion I started that took a substantial part of the meeting. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Mar 6 05:12:44 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00AF1A01F2 for ; Thu, 6 Mar 2014 05:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38fJAQv5IRj4 for ; Thu, 6 Mar 2014 05:12:40 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5858C1A017A for ; Thu, 6 Mar 2014 05:12: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 239E31DFF; Thu, 6 Mar 2014 14:12:36 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id lccXzC5dO9dd; Thu, 6 Mar 2014 14:12:35 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Thu, 6 Mar 2014 14:12:35 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 44A122002C; Thu, 6 Mar 2014 14:12:35 +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 zc-Vo2buTixP; Thu, 6 Mar 2014 14:12:34 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 920F620017; Thu, 6 Mar 2014 14:12:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D5CEF2B97AA7; Thu, 6 Mar 2014 14:12:31 +0100 (CET) Date: Thu, 6 Mar 2014 14:12:31 +0100 From: Juergen Schoenwaelder To: Mikael Abrahamsson Message-ID: <20140306131231.GB33713@elstar.local> Mail-Followup-To: Mikael Abrahamsson , netmod@ietf.org References: <20140306083054.GA32986@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fX4gfJl7VY54Jc0TBF0B78ZDDog Cc: netmod@ietf.org Subject: Re: [netmod] ietf 89 wg meeting summary X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 06 Mar 2014 13:12:42 -0000 On Thu, Mar 06, 2014 at 12:49:37PM +0100, Mikael Abrahamsson wrote: > On Thu, 6 Mar 2014, Juergen Schoenwaelder wrote: > > >Hi, > > > >below is a high-level summary of yesterday's WG meeting that I just > >submitted to the OPS ADs and that will be also part of the minutes. > > I note that there is absolutely no mention of the discussion I > started that took a substantial part of the meeting. Perhaps you can be more concrete and spell out what you find missing. Note that the summary is written primarily for the ADs and thus there is a slight focus on chartered items and the charter; the summary does not attempt to replace the minutes. /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 Mar 6 06:16:48 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDD31A0384 for ; Thu, 6 Mar 2014 06:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fw77QONCYiFr for ; Thu, 6 Mar 2014 06:16:44 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2E61A02DB for ; Thu, 6 Mar 2014 06:16:44 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2B03A9C; Thu, 6 Mar 2014 15:16:40 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 21B5F9A; Thu, 6 Mar 2014 15:16:40 +0100 (CET) Date: Thu, 6 Mar 2014 15:16:40 +0100 (CET) From: Mikael Abrahamsson To: Juergen Schoenwaelder In-Reply-To: <20140306131231.GB33713@elstar.local> Message-ID: References: <20140306083054.GA32986@elstar.local> <20140306131231.GB33713@elstar.local> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LWuGqbT3EPR_dd0VesZGXws44Ss Cc: netmod@ietf.org Subject: Re: [netmod] ietf 89 wg meeting summary X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:16:46 -0000 On Thu, 6 Mar 2014, Juergen Schoenwaelder wrote: > On Thu, Mar 06, 2014 at 12:49:37PM +0100, Mikael Abrahamsson wrote: >> On Thu, 6 Mar 2014, Juergen Schoenwaelder wrote: >> >>> Hi, >>> >>> below is a high-level summary of yesterday's WG meeting that I just >>> submitted to the OPS ADs and that will be also part of the minutes. >> >> I note that there is absolutely no mention of the discussion I >> started that took a substantial part of the meeting. > > Perhaps you can be more concrete and spell out what you find missing. > > Note that the summary is written primarily for the ADs and thus there > is a slight focus on chartered items and the charter; the summary does > not attempt to replace the minutes. "There was a request from a participant for guidance from the netmod group regarding tools and ways of collaborating when developing YANG models, and regarding the current process of developing YANG standards by means of publishing them as RFCs instead of a more light-weight process. This was discussed but no consensus was reached on how to proceed." -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Mar 6 07:03:59 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC591A0083 for ; Thu, 6 Mar 2014 07:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfpT6v5ZJ3SD for ; Thu, 6 Mar 2014 07:03:56 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id AD1FA1A0063 for ; Thu, 6 Mar 2014 07:03:56 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8D7AD1E63; Thu, 6 Mar 2014 16:03:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id M_o89DiCRmLi; Thu, 6 Mar 2014 16:03:51 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Thu, 6 Mar 2014 16:03:51 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8FFA22002C; Thu, 6 Mar 2014 16:03:51 +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 tP9XNC-ddGWG; Thu, 6 Mar 2014 16:03: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 15F6B20017; Thu, 6 Mar 2014 16:03:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 035452B985D0; Thu, 6 Mar 2014 16:03:48 +0100 (CET) Date: Thu, 6 Mar 2014 16:03:48 +0100 From: Juergen Schoenwaelder To: Mikael Abrahamsson Message-ID: <20140306150348.GA34364@elstar.local> Mail-Followup-To: Mikael Abrahamsson , netmod@ietf.org References: <20140306083054.GA32986@elstar.local> <20140306131231.GB33713@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/TD78mS-fTYhtHiHvZQOQakjZt1A Cc: netmod@ietf.org Subject: Re: [netmod] ietf 89 wg meeting summary X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 06 Mar 2014 15:03:58 -0000 On Thu, Mar 06, 2014 at 03:16:40PM +0100, Mikael Abrahamsson wrote: > On Thu, 6 Mar 2014, Juergen Schoenwaelder wrote: > > >On Thu, Mar 06, 2014 at 12:49:37PM +0100, Mikael Abrahamsson wrote: > >>On Thu, 6 Mar 2014, Juergen Schoenwaelder wrote: > >> > >>>Hi, > >>> > >>>below is a high-level summary of yesterday's WG meeting that I just > >>>submitted to the OPS ADs and that will be also part of the minutes. > >> > >>I note that there is absolutely no mention of the discussion I > >>started that took a substantial part of the meeting. > > > >Perhaps you can be more concrete and spell out what you find missing. > > > >Note that the summary is written primarily for the ADs and thus there > >is a slight focus on chartered items and the charter; the summary does > >not attempt to replace the minutes. > > "There was a request from a participant for guidance from the netmod > group regarding tools and ways of collaborating when developing YANG > models, and regarding the current process of developing YANG > standards by means of publishing them as RFCs instead of a more > light-weight process. This was discussed but no consensus was > reached on how to proceed." > I have updated the text to read as follows: The NETMOD meeting in London was attended by about 70 people. All currently charter work items are either in the RFC editor queue, on the IESG agenda, or they passed WG last call and are on the way to the area director. The discussion of a proposed new WG charter resulted in some minor modifications. The WG also discussed the ecosystem around YANG data model development and support and how it could be improved to better support and accelerate implementations of YANG modules. The active contributors indicated support for the new charter and there were no objections. The revised charter text including the modifications has been circulated on the mailing list right after the meeting. After the charter discussion, the WG started to go through a list of issues that may be addressed in a YANG maintenance release in order to determine which issues are in scope, out of scope, or need more discussion. The status of the stateless packet filter data model and a revision of the guidelines document has been reported. /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 Mar 6 12:14:39 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66711A017D; Thu, 6 Mar 2014 12:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shiK3nLBc_UZ; Thu, 6 Mar 2014 12:14:32 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id F1C3F1A0084; Thu, 6 Mar 2014 12:14:31 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 50AEC4775C7; Thu, 6 Mar 2014 21:14:26 +0100 (CET) Date: Thu, 06 Mar 2014 21:14:25 +0100 (CET) Message-Id: <20140306.211425.344710042.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <48B5B401-32B6-4928-B917-1D32421B4244@nic.cz> References: <20140303140039.GZ856433@jupiter.n2.diac24.net> <20140305.163154.391777655.mbj@tail-f.com> <48B5B401-32B6-4928-B917-1D32421B4244@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6dwvdqmBd8yOZgMJQJltwKsv13c Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 20:14:34 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+IE9uIDA1IE1hciAy MDE0LCBhdCAxNjozMSwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+IHdyb3RlOg0K PiANCj4gPiBIaSwNCj4gPiANCj4gPiBEYXZpZCBMYW1wYXJ0ZXIgPGVxdWlub3hAZGlhYzI0Lm5l dD4gd3JvdGU6DQo+ID4+IEhpLA0KPiA+PiANCj4gPj4gDQo+ID4+ICh0aGlzIGlzIHRoZSBtYWls IHZlcnNpb24gb2YgdGhlIHNvbWV3aGF0IGdhcmJsZWQgY29tbWVudCBvbiB0aGUgbWljKQ0KPiA+ PiANCj4gPj4gVGhlIG9yaWdpbmFsIHF1ZXN0aW9uIHdhcywgaG93IHRoZSBjb25maWd1cmVkIGRl dmljZSBjaG9vc2VzIGEgIlZQTiINCj4gPj4gZm9yDQo+ID4+IGVpdGhlciBpbmNvbWluZyBvciBv dXRnb2luZyBjb25uZWN0aW9ucy4gIFRoaXMgcmVmZXJyZWQgdG8gVlJGDQo+ID4+IGluc3RhbmNl cy4gIEluIHBhcnRpY3VsYXIsIGZvciB0aGUgdmVyeSBzaW1wbGVzdCBjYXNlIHdoZXJlIHRoaXMN Cj4gPj4gbWF0dGVycywgdGhlcmUgYXJlIGRldmljZXMgdGhhdCBoYXZlIG91dCBvZiBiYW5kIG1h bmFnZW1lbnQgcG9ydHMgYW5kDQo+ID4+IHRyZWF0IHRob3NlIGFzIGEgVlJGLiAgU28sIGJvdGgg Zm9yIGxpc3RlbmluZyBhbmQgZm9yIGNvbm5lY3RpbmcsIHRoZQ0KPiA+PiBkZXZpY2UgbmVlZHMg dG8gY2hvb3NlIGJldHdlZW4gIlZSLURlZmF1bHQiIGFuZCAiVlItTWdtdCIgKGFjdHVhbA0KPiA+ PiBuYW1lcywNCj4gPj4gZ3Vlc3MgdGhlIHZlbmRvci4pICBJdCBjb3VsZCBldmVuIGxpc3RlbiBp biBib3RoIFZSRnMsIHRvIGJlDQo+ID4+IG1hbmFnZWFibGUNCj4gPj4gaW5iYW5kIChub3JtYWwg b3BzIG1heWJlPykgYW5kIG91dCBvZiBiYW5kIChuZXR3b3JrIGluIGZsYW1lcz8pLg0KPiA+PiAN Cj4gPj4gRXZlbiB0aG91Z2ggdGhpcyB3YXMgcmFpc2VkIG9uIHRoZSBzZXJ2ZXIgY29uZmlnIG1v ZGVsLCB0aGlzIGlzIGENCj4gPj4gcmF0aGVyDQo+ID4+IGdlbmVyaWMgcHJvYmxlbS4gIEUuZy4g c3BlY2lmeWluZyBhIE5UUCBvciBTeXNsb2cgc2VydmVyIGhhcyB0aGUgc2FtZQ0KPiA+PiBpc3N1 ZS4gIChDYycgZnJvbSBuZXRjb25mIHRvIG5ldG1vZCBkdWUgdG8gdGhpcy4pDQo+ID4gDQo+ID4g SWYgSSB1bmRlcnN0YW5kIHRoaXMgY29ycmVjdGx5LCB0aGUgcHJvcG9zYWwgaXMgdG8gaW5jbHVk ZSBhIHJlZmVyZW5jZQ0KPiA+IHRvIGEgcm91dGluZy1pbnN0YW5jZSAocnQ6cm91dGluZy1pbnN0 YW5jZS1yZWYpIGluIGFsbCBjYXNlcyB3aGVyZSB3ZQ0KPiANCj4gSG1tLCBpdCBpcyBhY3R1YWxs eSBub3QgdGhhdCBzaW1wbGUuIEl0IGlzIHBvc3NpYmxlIHRvIGhhdmUgZGlmZmVyZW50IHR5cGVz IG9mDQo+IHJvdXRpbmcgaW5zdGFuY2VzIGRpc3Rpbmd1aXNoZWQgYnkgdGhlIOKAnHJ0OnR5cGXi gJ0gY2hpbGQuIFNvIGl0IGlzIG5vdCB0cnVlIHRoYXQNCj4gcm91dGluZy1pbnN0YW5jZSA9PSBW UkYgaW5zdGFuY2UuDQo+IA0KPiBUaGVyZWZvcmUsIHRoZSBjb3JyZWN0IGFwcHJvYWNoIGlzIElN TyB0aGlzOg0KPiANCj4gMS4gQSBtb2R1bGUgd2lsbCBiZSB3cml0dGVuIGRlZmluaW5nIHRoZSBW UkYgdHlwZSBvZiByb3V0aW5nIGluc3RhbmNlcyBhbmQNCj4gc3BlY2lmeWluZyB0aGUgc2VtYW50 aWNzIG9mIHRoaXMga2luZCBvZiB2aXJ0dWFsaXphdGlvbi4NCj4gDQo+IDIuIFdoZXJlIG5lY2Vz c2FyeSwgdnJmLWlkIGxlYWZzIHdpbGwgYmUgYWRkZWQgdG8gdGhlIGV4aXN0aW5nIG1vZHVsZSB2 aWENCj4gYXVnbWVudHMuDQo+IA0KPiBCZWZvcmUgdGhpcyBpcyBkb25lLCBhbHRlcm5hdGl2ZSAj MyBpbiBNYXJ0aW7igJlzIGxpc3QgKGkuZS4gZW5hYmxpbmcgc3RlcCAyDQo+IGFib3ZlKSBzZWVt cyB0byBiZSB0aGUgYmVzdCBvcHRpb24gYWZ0ZXIgYWxsLg0KDQpJIGZ1bGx5IGFncmVlIHdpdGgg dGhpcy4gIERlcGVuZGluZyBvbiB0aW1pbmcsIDIgYWJvdmUgY2FuIGJlIGRvbmUNCndpdGggYXVn bWVudGF0aW9uIG9yIGJ5IHJldmlzaW5nIHRoZSBleGlzdGluZyBtb2R1bGVzLg0KDQouLi4gYnV0 IHlvdSB3cml0ZSAiYSBtb2R1bGUgd2lsbCBiZSB3cml0dGVuIi4gIEl0IHdvbid0IHdyaXRlIGl0 c2VsZi4NCkhhcyBhbnlvbmUgdm9sdW50ZWVyZWQgdG8gd29yayBvbiB0aGlzPw0KDQoNCi9tYXJ0 aW4NCg== From nobody Thu Mar 6 15:03:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C5A1A01AF; Thu, 6 Mar 2014 15:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPQzvn0e8vIC; Thu, 6 Mar 2014 15:03:22 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3E81A00F1; Thu, 6 Mar 2014 15:03:21 -0800 (PST) Received: from [172.16.0.55] (80-46-118-65.static.dsl.as9105.com [80.46.118.65]) by mail.nic.cz (Postfix) with ESMTPSA id 0442E13F94C; Fri, 7 Mar 2014 00:03:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394146996; bh=0S6pIjYTgMfGBSnW3OMc2trG/7iiSsGb1SC4Ay33LDo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=niRC0v9w16Qfgl+ZBsDGb+pkWW6lq0Qru1ujIYltsSoTBNW1fVuSCtgfxwayBH4lF pKjw3XssN7Pr9eZdPH6qYllKmmYSnMfgJElDX8qbezo6U+vkeqOFBgmmCcHKr4/GIy ec/htl1ZBcECeDv0yuvhXa3rbQqUTrE177mU1WXU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140306.211425.344710042.mbj@tail-f.com> Date: Thu, 6 Mar 2014 23:03:04 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140303140039.GZ856433@jupiter.n2.diac24.net> <20140305.163154.391777655.mbj@tail-f.com> <48B5B401-32B6-4928-B917-1D32421B4244@nic.cz> <20140306.211425.344710042.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/r64wMw4W4K1Awt77fLbBY3W4eT4 Cc: Netconf , netmod@ietf.org Subject: Re: [netmod] [Netconf] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 23:03:26 -0000 On 06 Mar 2014, at 20:14, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On 05 Mar 2014, at 16:31, Martin Bjorklund wrote: >>=20 >>> Hi, >>>=20 >>> David Lamparter wrote: >>>> Hi, >>>>=20 >>>>=20 >>>> (this is the mail version of the somewhat garbled comment on the = mic) >>>>=20 >>>> The original question was, how the configured device chooses a = "VPN" >>>> for >>>> either incoming or outgoing connections. This referred to VRF >>>> instances. In particular, for the very simplest case where this >>>> matters, there are devices that have out of band management ports = and >>>> treat those as a VRF. So, both for listening and for connecting, = the >>>> device needs to choose between "VR-Default" and "VR-Mgmt" (actual >>>> names, >>>> guess the vendor.) It could even listen in both VRFs, to be >>>> manageable >>>> inband (normal ops maybe?) and out of band (network in flames?). >>>>=20 >>>> Even though this was raised on the server config model, this is a >>>> rather >>>> generic problem. E.g. specifying a NTP or Syslog server has the = same >>>> issue. (Cc' from netconf to netmod due to this.) >>>=20 >>> If I understand this correctly, the proposal is to include a = reference >>> to a routing-instance (rt:routing-instance-ref) in all cases where = we >>=20 >> Hmm, it is actually not that simple. It is possible to have different = types of >> routing instances distinguished by the =93rt:type=94 child. So it is = not true that >> routing-instance =3D=3D VRF instance. >>=20 >> Therefore, the correct approach is IMO this: >>=20 >> 1. A module will be written defining the VRF type of routing = instances and >> specifying the semantics of this kind of virtualization. >>=20 >> 2. Where necessary, vrf-id leafs will be added to the existing module = via >> augments. >>=20 >> Before this is done, alternative #3 in Martin=92s list (i.e. enabling = step 2 >> above) seems to be the best option after all. >=20 > I fully agree with this. Depending on timing, 2 above can be done > with augmentation or by revising the existing modules. >=20 > ... but you write "a module will be written". It won't write itself. > Has anyone volunteered to work on this? It should be a knowledgeable person who is interested in having the VRF = stuff implemented. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Mar 7 09:39:57 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCF51A00AA; Fri, 7 Mar 2014 09:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmcIVxTETTZc; Fri, 7 Mar 2014 09:39:54 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 69EE61A0083; Fri, 7 Mar 2014 09:39:54 -0800 (PST) Received: from mail60-ch1-R.bigfish.com (10.43.68.235) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.22; Fri, 7 Mar 2014 17:39:50 +0000 Received: from mail60-ch1 (localhost [127.0.0.1]) by mail60-ch1-R.bigfish.com (Postfix) with ESMTP id DDF4F407E1; Fri, 7 Mar 2014 17:39:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(z579ehzda00hdc73hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzzz2fh109h2a8h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h1155h) Received-SPF: pass (mail60-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(46102001)(53806001)(77096001)(49866001)(81542001)(47736001)(36756003)(81342001)(47976001)(50986001)(4396001)(95416001)(93136001)(86362001)(94316002)(83072002)(93516002)(92566001)(558084003)(51856001)(74502001)(74662001)(76482001)(87266001)(65816001)(76796001)(56776001)(66066001)(47446002)(54316002)(54356001)(80022001)(59766001)(94946001)(79102001)(31966008)(85306002)(76786001)(2656002)(77982001)(63696002)(90146001)(56816005)(74706001)(95666003)(69226001)(83322001)(97336001)(85852003)(74366001)(80976001)(81686001)(92726001)(97186001)(81816001)(74876001)(87936001)(83506001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB776; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.10; FPR:DEEDC14C.63067EF.A8DDA3C1.C6EC907D.20090; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail60-ch1 (localhost.localdomain [127.0.0.1]) by mail60-ch1 (MessageSwitch) id 139421398820375_28862; Fri, 7 Mar 2014 17:39:48 +0000 (UTC) Received: from CH1EHSMHS008.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247]) by mail60-ch1.bigfish.com (Postfix) with ESMTP id EA9D12400FD; Fri, 7 Mar 2014 17:39:47 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS008.bigfish.com (10.43.70.8) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 7 Mar 2014 17:39:47 +0000 Received: from BY2PR05MB776.namprd05.prod.outlook.com (10.141.224.154) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.423.0; Fri, 7 Mar 2014 17:39:45 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BY2PR05MB776.namprd05.prod.outlook.com (10.141.224.154) with Microsoft SMTP Server (TLS) id 15.0.893.10; Fri, 7 Mar 2014 17:39:43 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.210]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.210]) with mapi id 15.00.0893.001; Fri, 7 Mar 2014 17:39:43 +0000 From: Kent Watsen To: Ladislav Lhotka , =?iso-8859-1?Q?Martin_Bj=F6rklund?= Thread-Topic: [netmod] [Netconf] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections Thread-Index: AQHPOXi6TH1xB35f9UekZNtIqP0q55rUrYMAgAE3/AA= Date: Fri, 7 Mar 2014 17:39:42 +0000 Message-ID: References: <20140303140039.GZ856433@jupiter.n2.diac24.net> <20140305.163154.391777655.mbj@tail-f.com> <48B5B401-32B6-4928-B917-1D32421B4244@nic.cz> <20140306.211425.344710042.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/14.3.9.131030 x-originating-ip: [66.129.241.10] x-forefront-prvs: 014304E855 Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xvqMPwEv-QTcp4BquO1O3gwTZXk Cc: Netconf , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 17:39:56 -0000 > It should be a knowledgeable person who is interested in having the VRF >stuff implemented. Not me, but I did verify with other routing experts that being able to do this is necessary... Any volunteers? K. From nobody Fri Mar 7 13:52:27 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9AC1A0150; Fri, 7 Mar 2014 13:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sngFPtagI3qd; Fri, 7 Mar 2014 13:52:23 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B30161A0114; Fri, 7 Mar 2014 13:52:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2117; q=dns/txt; s=iport; t=1394229139; x=1395438739; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BWJgFnbsg15uexnOjKyFRGYqGytbPRHZhNKlQr2oGPc=; b=Z9FdsAJeOznOAOLSPuWzTVFSFsnNNtJLk5EE/az+0pEmZII9v0ChFFZS MGe3qtS9JGOX4n72KWUxiY1inilsRZKZNSE+ZgiuuYDfJpuOucLOCxltq bjExoHmv+YALvVJv2sRn8miu7jpHisazEmtjUYCAuihIu7nnTONNb/WWf Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMFAAU/GlOtJXG+/2dsb2JhbABagwY7UQbAYE+BGBZ0giYBAQQBAQE3NAsQAgEINhAnCyUCBAENBQmHcAgF0A4XjlsHhDgEmEOBMpB5gy2CKw X-IronPort-AV: E=Sophos;i="4.97,610,1389744000"; d="scan'208";a="308635011" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 07 Mar 2014 21:52:19 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s27LqJ24006012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Mar 2014 21:52:19 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.219]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Fri, 7 Mar 2014 15:52:18 -0600 From: "Yi Yang (yiya)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt Thread-Index: AQHPDgglsV7ZhSMgp02l6cqKlZJTf5rW54cA Date: Fri, 7 Mar 2014 21:52:17 +0000 Message-ID: References: <20140110133016.24678.42711.idtracker@ietfa.amsl.com> In-Reply-To: <20140110133016.24678.42711.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.82.240.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <7A0D820A1216C44391E810DAFD78CC88@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Fy5ABJbWqq8PZWNZt0wWl6SGy8A Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 21:52:25 -0000 One thing is missing from the data model is association with vrf. Another concern I have is about address family. To facilitate a query based on AFI only, or SAFI only, it seems more convenient to use two leafs (AFI and SAFI) instead of one (AFI-SAFI). Yi On 1/10/14 8:30 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the NETCONF Data Modeling Language Working >Group of the IETF. > > Title : A YANG Data Model for Routing Management > Author : Ladislav Lhotka > Filename : draft-ietf-netmod-routing-cfg-13.txt > Pages : 95 > Date : 2014-01-10 > >Abstract: > This document contains a specification of three YANG modules. > Together they form the core routing data model which serves as a > framework for configuring and managing a routing subsystem. It is > expected that these modules will be augmented by additional YANG > modules defining data models for individual routing protocols and > other related functions. The core routing data model provides common > building blocks for such extensions - routing instances, routes, > routing information bases (RIB), routing protocols and route filters. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg-13 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Mar 7 13:58:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9359F1A0270; Fri, 7 Mar 2014 13:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyTRykkggOnf; Fri, 7 Mar 2014 13:58:10 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 2E60E1A01EE; Fri, 7 Mar 2014 13:58:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1543; q=dns/txt; s=iport; t=1394229486; x=1395439086; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HoZjOYaWl5ZCkRUkbAE/9TexoWk9q4PbONFpdSrOfGw=; b=lYaFgvUVVzigxa3TJfxtubrAA8UYWeAHr662rnq72Dd3rDiEmJaQqKbc T/TrQX+v9tSK9I5rXdFKZseigUYY13uIPTOhrFEBJcQXDCO7y9OuxaMim Y7nYW56idYEj9txdWmMaQIx+DSLDXxs4/cjD76L24AHZzFBKSbSh5vIxQ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMFAKpAGlOtJV2a/2dsb2JhbABagwY7UQbAYE+BGBZ0giYBAQQBAQE3NAsQAgEINhAnCyUCBAENBQmHcAgF0A8XjlsHhDgEmEOBMpB5gy2CKw X-IronPort-AV: E=Sophos;i="4.97,610,1389744000"; d="scan'208";a="25797592" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP; 07 Mar 2014 21:58:05 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s27Lw517002616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Mar 2014 21:58:05 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.219]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Fri, 7 Mar 2014 15:58:05 -0600 From: "Yi Yang (yiya)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-13.txt Thread-Index: AQHPKOonM1qjeVH+6Ea3YIfD39khT5rWs2EA Date: Fri, 7 Mar 2014 21:58:04 +0000 Message-ID: References: <20140213183325.16175.99400.idtracker@ietfa.amsl.com> In-Reply-To: <20140213183325.16175.99400.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.82.240.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <0A9C6880158B8F47A185577775A52217@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/DyGaJZo5y4KZdqy_jVSh86Ir4Dk Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 21:58:11 -0000 In the context of IP, each interface is associated with one and only one VRF -- which is not reflected in the current data model. Yi On 2/13/14 1:33 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the NETCONF Data Modeling Language Working >Group of the IETF. > > Title : A YANG Data Model for IP Management > Author : Martin Bjorklund > Filename : draft-ietf-netmod-ip-cfg-13.txt > Pages : 32 > Date : 2014-02-13 > >Abstract: > This document defines a YANG data model for management of IP > implementations. The data model includes configuration data and > state data. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-13 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-ip-cfg-13 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Mar 7 14:12:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714701A012A for ; Fri, 7 Mar 2014 14:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 314W3ST6dP44 for ; Fri, 7 Mar 2014 14:11:58 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id E5FA71A0110 for ; Fri, 7 Mar 2014 14:11:57 -0800 (PST) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id B7C963943EA; Fri, 7 Mar 2014 23:11:52 +0100 (CET) Date: Fri, 07 Mar 2014 23:11:52 +0100 (CET) Message-Id: <20140307.231152.435558401.mbj@tail-f.com> To: yiya@cisco.com From: Martin Bjorklund In-Reply-To: References: <20140213183325.16175.99400.idtracker@ietfa.amsl.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LykcyU73VLtt5JUUFOSXmP3mlb0 Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 22:11:59 -0000 "Yi Yang (yiya)" wrote: > In the context of IP, each interface is associated with one and only one > VRF -- which is not reflected in the current data model. A VRF can be represented as a routing-instance, as defined in the routing draft. Such a routing-instance will have interfaces associated to it. See also the thread http://www.ietf.org/mail-archive/web/netmod/current/msg09253.html /martin > > Yi > > On 2/13/14 1:33 PM, "internet-drafts@ietf.org" > wrote: > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > This draft is a work item of the NETCONF Data Modeling Language Working > >Group of the IETF. > > > > Title : A YANG Data Model for IP Management > > Author : Martin Bjorklund > > Filename : draft-ietf-netmod-ip-cfg-13.txt > > Pages : 32 > > Date : 2014-02-13 > > > >Abstract: > > This document defines a YANG data model for management of IP > > implementations. The data model includes configuration data and > > state data. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/ > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-13 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-ip-cfg-13 > > > > > >Please note that it may take a couple of minutes from the time of > >submission > >until the htmlized version and diff are available at tools.ietf.org. > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >netmod mailing list > >netmod@ietf.org > >https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Mar 7 14:18:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFE91A0128 for ; Fri, 7 Mar 2014 14:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsrQv1Q3t8js for ; Fri, 7 Mar 2014 14:18:02 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 5083D1A011C for ; Fri, 7 Mar 2014 14:18:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2631; q=dns/txt; s=iport; t=1394230678; x=1395440278; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Gk50jYm9bJmKNxbvXP5H9N4i3TluHI49TP0uIblP3tI=; b=lmBaz2ogND/GerhRa2cjUJcvPbgsrof4tYK/DX6tTetwmlvt0aZq0C6X k8xdkYykNzx0TR0hr1RFFIBF3cfafIEyzYrlRJfbsZ7yZpA8+reQNfhot l7MUhaZSbbk7PjUx/euJiDZeb/wY1bjmEE/wQTLs5unNplsj7uZF6Urgd s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMFAGNFGlOtJXG9/2dsb2JhbABagwY7UQbAYE+BGBZ0giUBAQEEAQEBNzQLEAIBCA4KHhAnCyUCBA4FCYdwCAXQFReOCgEBTwIFhDgEmEOBMpB5gy2Bcjk X-IronPort-AV: E=Sophos;i="4.97,610,1389744000"; d="scan'208";a="25801862" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-1.cisco.com with ESMTP; 07 Mar 2014 22:17:44 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s27MHiiL003773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Mar 2014 22:17:44 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.219]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Fri, 7 Mar 2014 16:17:43 -0600 From: "Yi Yang (yiya)" To: Martin Bjorklund Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-13.txt Thread-Index: AQHPKOonM1qjeVH+6Ea3YIfD39khT5rWs2EAgAAD3ACAAAGhAA== Date: Fri, 7 Mar 2014 22:17:43 +0000 Message-ID: References: <20140213183325.16175.99400.idtracker@ietfa.amsl.com> <20140307.231152.435558401.mbj@tail-f.com> In-Reply-To: <20140307.231152.435558401.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.82.240.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <6899CB852D9192489E4CC85901324110@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/YDhzukPI9hOzBVKFajWwBQi3egU Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 22:18:04 -0000 Hi Martin, Yes, a routing instance is associated with a VRF, but routing table and interface should also be associated with VRF as well. This is like address family, which should be referred in multiple data models. Actually, I'd think the VRF/address family are just like glue, which help build the association between routing tables, routing instances, and interfaces and etc. Yi On 3/7/14 10:11 PM, "Martin Bjorklund" wrote: >"Yi Yang (yiya)" wrote: >> In the context of IP, each interface is associated with one and only one >> VRF -- which is not reflected in the current data model. > >A VRF can be represented as a routing-instance, as defined in the >routing draft. Such a routing-instance will have interfaces >associated to it. > >See also the thread >http://www.ietf.org/mail-archive/web/netmod/current/msg09253.html > > >/martin > > >>=20 >> Yi >>=20 >> On 2/13/14 1:33 PM, "internet-drafts@ietf.org" >> >> wrote: >>=20 >> > >> >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 >>Working >> >Group of the IETF. >> > >> > Title : A YANG Data Model for IP Management >> > Author : Martin Bjorklund >> > Filename : draft-ietf-netmod-ip-cfg-13.txt >> > Pages : 32 >> > Date : 2014-02-13 >> > >> >Abstract: >> > This document defines a YANG data model for management of IP >> > implementations. The data model includes configuration data and >> > state data. >> > >> > >> >The IETF datatracker status page for this draft is: >> >https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/ >> > >> >There's also a htmlized version available at: >> >http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-13 >> > >> >A diff from the previous version is available at: >> >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-ip-cfg-13 >> > >> > >> >Please note that it may take a couple of minutes from the time of >> >submission >> >until the htmlized version and diff are available at tools.ietf.org. >> > >> >Internet-Drafts are also available by anonymous FTP at: >> >ftp://ftp.ietf.org/internet-drafts/ >> > >> >_______________________________________________ >> >netmod mailing list >> >netmod@ietf.org >> >https://www.ietf.org/mailman/listinfo/netmod >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 From nobody Fri Mar 7 14:29:24 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A881A02DD for ; Fri, 7 Mar 2014 14:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szr8CjD-Hohs for ; Fri, 7 Mar 2014 14:29:19 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBBE1A011C for ; Fri, 7 Mar 2014 14:29:19 -0800 (PST) Received: from ip-94-113-93-133.net.upcbroadband.cz (ip-94-113-93-133.net.upcbroadband.cz [94.113.93.133]) by mail.nic.cz (Postfix) with ESMTPSA id 1F88D13F960; Fri, 7 Mar 2014 23:29:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394231354; bh=lDkSMUnUfzJujkCVP90ov1lJNbyXgUGta49Txk5uFZs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=I1ZTs1rtfry5YqvnSy9Wk1WQQeThT9u86NQrZGNXHV5uTDgseh84mVhorCrx5Zcry JpzZRmbFmRZw14zFKxr+WOCuJlwtEfUFJtLT1A3Yd4x3GWJqGVIDqYiZE3bVVJjv9g fFlFKjMnHSlOCMFIP9CG7y2mDsoYabYkisIX1Af4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 7 Mar 2014 23:29:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9C81158E-5B4C-4479-AEA5-23CBCC020ADD@nic.cz> References: <20140110133016.24678.42711.idtracker@ietfa.amsl.com> To: "Yi Yang (yiya)" X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fp-IIaYTs41RzOpB2rSXLZrKKgw Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 22:29:22 -0000 On 07 Mar 2014, at 22:52, Yi Yang (yiya) wrote: > One thing is missing from the data model is association with vrf. I agree with what Martin wrote in a parallel thread. I believe the = routing module (and YANG augment statement) provide sufficient hooks for = implementing VRF as a specific type of routing-instance. I think though that other work extending the routing module is much more = needed, namely vendor-neutral data models for routing protocols. The consensus of the NETMOD WG was that these new modules should be = developed by experts in the Routing Area (VRF in the MPLS WG?). The = NETMOD WG and YANG Doctors will certainly help but the bulk of this work = should be done by domain experts. Lada >=20 > Another concern I have is about address family. To facilitate a query > based on AFI only, or SAFI only, it seems more convenient to use two = leafs > (AFI and SAFI) instead of one (AFI-SAFI). >=20 > Yi >=20 >=20 >=20 >=20 > On 1/10/14 8:30 AM, "internet-drafts@ietf.org" = > wrote: >=20 >>=20 >> 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 = Working >> Group of the IETF. >>=20 >> Title : A YANG Data Model for Routing Management >> Author : Ladislav Lhotka >> Filename : draft-ietf-netmod-routing-cfg-13.txt >> Pages : 95 >> Date : 2014-01-10 >>=20 >> Abstract: >> This document contains a specification of three YANG modules. >> Together they form the core routing data model which serves as a >> framework for configuring and managing a routing subsystem. It is >> expected that these modules will be augmented by additional YANG >> modules defining data models for individual routing protocols and >> other related functions. The core routing data model provides = common >> building blocks for such extensions - routing instances, routes, >> routing information bases (RIB), routing protocols and route = filters. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg-13 >>=20 >>=20 >> 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. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=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 Mar 7 14:31:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBF41A012A for ; Fri, 7 Mar 2014 14:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIk4WGu0gxUC for ; Fri, 7 Mar 2014 14:31:28 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id C64DF1A0110 for ; Fri, 7 Mar 2014 14:31:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1767; q=dns/txt; s=iport; t=1394231483; x=1395441083; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/AWWyoJjTGxfezMOmNFXCDbBYN+dbO9lPwQP6KndvM8=; b=Pn9p54Q5d9uzBHgSiXcdpgwNp7Bw0l72rZcMeJ7hboWGsx7+06DQ9Tnm /6ZXR7TXGo62YSnutrMhKnY+rSqk+SFyOKnhuOftwApbII/k7D9Xz5UdV xBQFeNFTkhVnxw7HbeHe0WdkX6pYuCkoI2QwB4kZSF29ngslBhxMhwKmZ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAP5HGlOtJV2c/2dsb2JhbABXA4MGO1fAYE+BFxZ0giYBAQQBAQE3NBkCAgEIDgImEBsMCyUCBAESh3kN0BQXBI4DRBcRhCcElFeDbJIrgy2CKw X-IronPort-AV: E=Sophos;i="4.97,610,1389744000"; d="scan'208";a="25804294" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP; 07 Mar 2014 22:31:23 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s27MVN1n009590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Mar 2014 22:31:23 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.219]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Fri, 7 Mar 2014 16:31:23 -0600 From: "Yi Yang (yiya)" To: Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] ietf 89 wg meeting summary Thread-Index: AQHPORZsBHW++HT0JUe5KmmBwG5rSprWnFcA Date: Fri, 7 Mar 2014 22:31:22 +0000 Message-ID: References: <20140306083054.GA32986@elstar.local> In-Reply-To: <20140306083054.GA32986@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.82.240.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <207586EC9E26634C88A051214994F76D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/meXpjRmN2HC_qUShs3wvI61QrIY Subject: Re: [netmod] ietf 89 wg meeting summary X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 22:31:29 -0000 For the YANG maintenance release, one feature may be useful is to support constraints for union type. For example, a server can be defined as union of domain-name/ip-addresss. However, domain-name should only be allowed when a dns-server exists. Yi=20 On 3/6/14 8:30 AM, "Juergen Schoenwaelder" wrote: >Hi, > >below is a high-level summary of yesterday's WG meeting that I just >submitted to the OPS ADs and that will be also part of the minutes. > > The NETMOD meeting in London was attended by about 70 people. All > currently charter work items are either in the RFC editor queue, on > the IESG agenda, or they passed WG last call and are on the way to the > area director. The discussion of a proposed new WG charter resulted in > some minor modifications. The active contributors indicated support > for the new charter and there were no objections. The revised charter > text including the modifications has been circulated on the mailing > list right after the meeting. After the charter discussion, the WG > started to go through a list of issues that may be addressed in a YANG > maintenance release in order to determine which issues are in scope, > out of scope, or need more discussion. The status of the stateless > packet filter data model and a revision of the guidelines document has > been reported. > >/js > >--=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 Mar 7 14:40:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1AE01A016E for ; Fri, 7 Mar 2014 14:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5Y5yJbnuRwD for ; Fri, 7 Mar 2014 14:40:31 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 46EA21A00BE for ; Fri, 7 Mar 2014 14:40:31 -0800 (PST) Received: from ip-94-113-93-133.net.upcbroadband.cz (ip-94-113-93-133.net.upcbroadband.cz [94.113.93.133]) by mail.nic.cz (Postfix) with ESMTPSA id E0D4613F960; Fri, 7 Mar 2014 23:40:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394232025; bh=E6328yOZVNgL2B4FzD+rI4u60Ph6QAbodXfNAPERHig=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=iQ6YyZfCRd49g3kczkmpVl7ndDpAzW6XtO05Kx3sR4pV8xxlmdzgnyOP/BG5JNWuB GVOdm3lGBVslsEHKNuYM/LXoTcO5LdlAymcLh7ZWRYq1PPxE8KyNWpSQKYzVeQ0Zym x/irr1hQyciq9J7gocj03dX7Ci6NvSWPCL2oxq18= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 7 Mar 2014 23:40:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140213183325.16175.99400.idtracker@ietfa.amsl.com> <20140307.231152.435558401.mbj@tail-f.com> To: "Yi Yang (yiya)" X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BzJu_13zQPSEU8Kn8SGqzPVVJEA Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 22:40:32 -0000 On 07 Mar 2014, at 23:17, Yi Yang (yiya) wrote: > Hi Martin, >=20 > Yes, a routing instance is associated with a VRF, but routing table = and > interface should also be associated with VRF as well. This is like = address Each routing-instance has its own list of interfaces, and RIBs can be = also made specific for a routing-instance. The draft explicitly = envisions such restrictions: RIBs are global, which means that a RIB may be used by any or all routing instances. However, an implementation MAY specify rules and restrictions for sharing RIBs among routing instances. > family, which should be referred in multiple data models. Actually, = I'd > think the VRF/address family are just like glue, which help build the > association between routing tables, routing instances, and interfaces = and > etc. I don=92t think though that VRFs are so ubiquitous to warrant their = direct inclusion in the core routing data model. A separate module seems = more appropriate. Lada >=20 > Yi >=20 >=20 > On 3/7/14 10:11 PM, "Martin Bjorklund" wrote: >=20 >> "Yi Yang (yiya)" wrote: >>> In the context of IP, each interface is associated with one and only = one >>> VRF -- which is not reflected in the current data model. >>=20 >> A VRF can be represented as a routing-instance, as defined in the >> routing draft. Such a routing-instance will have interfaces >> associated to it. >>=20 >> See also the thread >> http://www.ietf.org/mail-archive/web/netmod/current/msg09253.html >>=20 >>=20 >> /martin >>=20 >>=20 >>>=20 >>> Yi >>>=20 >>> On 2/13/14 1:33 PM, "internet-drafts@ietf.org" >>> >>> wrote: >>>=20 >>>>=20 >>>> 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 >>> Working >>>> Group of the IETF. >>>>=20 >>>> Title : A YANG Data Model for IP Management >>>> Author : Martin Bjorklund >>>> Filename : draft-ietf-netmod-ip-cfg-13.txt >>>> Pages : 32 >>>> Date : 2014-02-13 >>>>=20 >>>> Abstract: >>>> This document defines a YANG data model for management of IP >>>> implementations. The data model includes configuration data and >>>> state data. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/ >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-13 >>>>=20 >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-ip-cfg-13 >>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>>=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 Mar 7 14:50:15 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DD21A0165 for ; Fri, 7 Mar 2014 14:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiW4BYVfVEIh for ; Fri, 7 Mar 2014 14:50:12 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1681A016E for ; Fri, 7 Mar 2014 14:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4131; q=dns/txt; s=iport; t=1394232608; x=1395442208; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=C6QOX7eXeoJ2SkyqzjnSS65PRRkOiTh5HqFjWZiJe2k=; b=YWshGez4xq7KGxheJcEXf8SrGcW/Dnqo0h8cLV3OeRfbOmfXo6YgN8z8 f+tWiDygkR8RB7ODIWR3u863sBX0E6aZpCSyBcs+ENgLmOurLTm5bLz0g 0k8vxUfICyrKeFCxbKLfVjFEyrsnZ7sylBZDxf2LvG76589oX6WrzJTBd Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMFAPxLGlOtJXHB/2dsb2JhbABagwY7UQbAYE+BFxZ0giUBAQEDAQEBAWsLBQsCAQgYLicLJQIEDgUJh2gICAXQCReOCgEBTwIFhDgEiRiPK4EykHmDLYFyOQ X-IronPort-AV: E=Sophos;i="4.97,610,1389744000"; d="scan'208";a="308837042" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 07 Mar 2014 22:50:06 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s27Mo5YM031275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Mar 2014 22:50:05 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.219]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Fri, 7 Mar 2014 16:50:05 -0600 From: "Yi Yang (yiya)" To: Ladislav Lhotka Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-13.txt Thread-Index: AQHPKOonM1qjeVH+6Ea3YIfD39khT5rWs2EAgAAD3ACAAAGhAIAABlGAgAACugA= Date: Fri, 7 Mar 2014 22:50:04 +0000 Message-ID: References: <20140213183325.16175.99400.idtracker@ietfa.amsl.com> <20140307.231152.435558401.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/14.3.9.131030 x-originating-ip: [10.82.240.92] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ibD1wsd9q-9FFHIBoSohPiZYCFI Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 22:50:14 -0000 Hi Ladislav, On 3/7/14 10:40 PM, "Ladislav Lhotka" wrote: > >On 07 Mar 2014, at 23:17, Yi Yang (yiya) wrote: > >> Hi Martin, >>=20 >> Yes, a routing instance is associated with a VRF, but routing table and >> interface should also be associated with VRF as well. This is like >>address > >Each routing-instance has its own list of interfaces, and RIBs can be >also made specific for a routing-instance. The draft explicitly envisions >such restrictions: > > RIBs are global, which means that a RIB may be used by any or all > routing instances. [yi]: A routing table can be associated with multiple routing instances, but should be associated with only one VRF. > However, an implementation MAY specify rules and > restrictions for sharing RIBs among routing instances. > > >> family, which should be referred in multiple data models. Actually, I'd >> think the VRF/address family are just like glue, which help build the >> association between routing tables, routing instances, and interfaces >>and >> etc. > >I don=B9t think though that VRFs are so ubiquitous to warrant their direct >inclusion in the core routing data model. A separate module seems more >appropriate. [yi]: A vrf can be associated with multiple routing tables, so yes, a separated data model for vrf is required. But in the DM for routing table, we need a reference to the vrf. Yi > >Lada > >>=20 >> Yi >>=20 >>=20 >> On 3/7/14 10:11 PM, "Martin Bjorklund" wrote: >>=20 >>> "Yi Yang (yiya)" wrote: >>>> In the context of IP, each interface is associated with one and only >>>>one >>>> VRF -- which is not reflected in the current data model. >>>=20 >>> A VRF can be represented as a routing-instance, as defined in the >>> routing draft. Such a routing-instance will have interfaces >>> associated to it. >>>=20 >>> See also the thread >>> http://www.ietf.org/mail-archive/web/netmod/current/msg09253.html >>>=20 >>>=20 >>> /martin >>>=20 >>>=20 >>>>=20 >>>> Yi >>>>=20 >>>> On 2/13/14 1:33 PM, "internet-drafts@ietf.org" >>>> >>>> wrote: >>>>=20 >>>>>=20 >>>>> 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 >>>> Working >>>>> Group of the IETF. >>>>>=20 >>>>> Title : A YANG Data Model for IP Management >>>>> Author : Martin Bjorklund >>>>> Filename : draft-ietf-netmod-ip-cfg-13.txt >>>>> Pages : 32 >>>>> Date : 2014-02-13 >>>>>=20 >>>>> Abstract: >>>>> This document defines a YANG data model for management of IP >>>>> implementations. The data model includes configuration data and >>>>> state data. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/ >>>>>=20 >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-13 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-ip-cfg-13 >>>>>=20 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>>=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 Mar 7 23:52:08 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E671A0225 for ; Fri, 7 Mar 2014 23:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0vHoQALvBVu for ; Fri, 7 Mar 2014 23:52:05 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C1F311A021A for ; Fri, 7 Mar 2014 23:52:04 -0800 (PST) Received: from [192.168.42.206] (37-48-34-84.tmcz.cz [37.48.34.84]) by mail.nic.cz (Postfix) with ESMTPSA id CFCDB13F9F4; Sat, 8 Mar 2014 08:51:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394265118; bh=5QtHgU+rr1BqKlRf7OoIgY9kinaXhHkF4mP8LCTH/Kg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=oFFyL66+zhB1VB8so9+Eq2G4f2YXERYJCaxuTkqyFLl9fTeGcKLnziFaG1vbvEUz2 LCSoquHQ2cMjv5HTd8r5+UUy2YKvA5/3WO9TgRkSd2e4MtjnLCXk/NNBpn+UO5Vvuk 2O6x4uLrZlmWYolitQKdPwmjLck5U4Ow/59MgOzA= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Sat, 8 Mar 2014 08:51:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140213183325.16175.99400.idtracker@ietfa.amsl.com> <20140307.231152.435558401.mbj@tail-f.com> To: "Yi Yang (yiya)" X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/loVzJK_RGYByUj7UawjuZ3BvO4g Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 07:52:06 -0000 On 07 Mar 2014, at 23:50, Yi Yang (yiya) wrote: > Hi Ladislav, >=20 > On 3/7/14 10:40 PM, "Ladislav Lhotka" wrote: >=20 >>=20 >> On 07 Mar 2014, at 23:17, Yi Yang (yiya) wrote: >>=20 >>> Hi Martin, >>>=20 >>> Yes, a routing instance is associated with a VRF, but routing table = and >>> interface should also be associated with VRF as well. This is like >>> address >>=20 >> Each routing-instance has its own list of interfaces, and RIBs can be >> also made specific for a routing-instance. The draft explicitly = envisions >> such restrictions: >>=20 >> RIBs are global, which means that a RIB may be used by any or all >> routing instances. >=20 > [yi]: A routing table can be associated with multiple routing = instances, > but should be associated with only one VRF. Then you should define precise semantics of the routing instance and VRF = (instance). I assume both concepts can be modelled as different types of = =93routing-instance=94 in the existing data model. I actually suspect the semantics are vendor-specific. >=20 >> However, an implementation MAY specify rules and >> restrictions for sharing RIBs among routing instances. >>=20 >>=20 >>> family, which should be referred in multiple data models. Actually, = I'd >>> think the VRF/address family are just like glue, which help build = the >>> association between routing tables, routing instances, and = interfaces >>> and >>> etc. >>=20 >> I don=B9t think though that VRFs are so ubiquitous to warrant their = direct >> inclusion in the core routing data model. A separate module seems = more >> appropriate. >=20 > [yi]: A vrf can be associated with multiple routing tables, so yes, a > separated data model for vrf is required. But in the DM for routing = table, > we need a reference to the vrf. Right, so the VRF module is free to augment =93rib" with a new parameter = (or more of them) that establishes this relationship. The advantage of = this approach is that implementations not supporting the VRF module = won=92t have the new parameter in their data model. Lada >=20 >=20 > Yi >=20 >>=20 >> Lada >>=20 >>>=20 >>> Yi >>>=20 >>>=20 >>> On 3/7/14 10:11 PM, "Martin Bjorklund" wrote: >>>=20 >>>> "Yi Yang (yiya)" wrote: >>>>> In the context of IP, each interface is associated with one and = only >>>>> one >>>>> VRF -- which is not reflected in the current data model. >>>>=20 >>>> A VRF can be represented as a routing-instance, as defined in the >>>> routing draft. Such a routing-instance will have interfaces >>>> associated to it. >>>>=20 >>>> See also the thread >>>> http://www.ietf.org/mail-archive/web/netmod/current/msg09253.html >>>>=20 >>>>=20 >>>> /martin >>>>=20 >>>>=20 >>>>>=20 >>>>> Yi >>>>>=20 >>>>> On 2/13/14 1:33 PM, "internet-drafts@ietf.org" >>>>> >>>>> wrote: >>>>>=20 >>>>>>=20 >>>>>> 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 >>>>> Working >>>>>> Group of the IETF. >>>>>>=20 >>>>>> Title : A YANG Data Model for IP Management >>>>>> Author : Martin Bjorklund >>>>>> Filename : draft-ietf-netmod-ip-cfg-13.txt >>>>>> Pages : 32 >>>>>> Date : 2014-02-13 >>>>>>=20 >>>>>> Abstract: >>>>>> This document defines a YANG data model for management of IP >>>>>> implementations. The data model includes configuration data and >>>>>> state data. >>>>>>=20 >>>>>>=20 >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/ >>>>>>=20 >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-13 >>>>>>=20 >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-ip-cfg-13 >>>>>>=20 >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>=20 >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> netmod@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>=20 >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Mar 7 23:57:27 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8521A027F; Fri, 7 Mar 2014 23:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0TIHyV7zyrR; Fri, 7 Mar 2014 23:57:22 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF641A0225; Fri, 7 Mar 2014 23:57:22 -0800 (PST) Received: from [192.168.42.206] (37-48-34-84.tmcz.cz [37.48.34.84]) by mail.nic.cz (Postfix) with ESMTPSA id E4A7B13F9F4; Sat, 8 Mar 2014 08:57:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394265437; bh=FTgw98P59pyc8hHP46jVwc6rONgcGDaVrgNd7gcYIaU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=beX2Jn51AYPNIXzqQW6+1HIXY6LsG8HraJNceJZdvcvi3JbIT47SRqgzKjDDbLYKD +WYM+baw9wLDk/PxOOkFyH2DNa4Ie7SPumHa1CiJc6+3+ur4NX5/w0Z8zyC+6dn3Ra AC5U43M3bO6d+p8ZKkPmRt8ydE7Y5a9bHPTC0ibU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Sat, 8 Mar 2014 08:57:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140303140039.GZ856433@jupiter.n2.diac24.net> <20140305.163154.391777655.mbj@tail-f.com> <48B5B401-32B6-4928-B917-1D32421B4244@nic.cz> <20140306.211425.344710042.mbj@tail-f.com> To: Kent Watsen X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/QkH-diW9B3pWFyeZCrLQOmPR-KQ Cc: Netconf , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 07:57:23 -0000 On 07 Mar 2014, at 18:39, Kent Watsen wrote: >=20 >> It should be a knowledgeable person who is interested in having the = VRF >> stuff implemented. >=20 > Not me, but I did verify with other routing experts that being able to = do > this is necessary=85 >=20 > Any volunteers? I am prepared to help them integrate this work into the core routing = model. Lada >=20 >=20 > K. >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Mar 7 23:59:56 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DD31A02C5 for ; Fri, 7 Mar 2014 23:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsllZ9vuYfT2 for ; Fri, 7 Mar 2014 23:59:51 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6B21A0225 for ; Fri, 7 Mar 2014 23:59:50 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4E6CDFC2; Sat, 8 Mar 2014 08:59:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id wcgiuQnGgf74; Sat, 8 Mar 2014 08:59:44 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Sat, 8 Mar 2014 08:59:44 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 63C542002C; Sat, 8 Mar 2014 08:59:44 +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 GLIgGQfFvB3R; Sat, 8 Mar 2014 08:59:42 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 91C0F20017; Sat, 8 Mar 2014 08:59:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E41322BAC3C4; Sat, 8 Mar 2014 08:59:40 +0100 (CET) Date: Sat, 8 Mar 2014 08:59:40 +0100 From: Juergen Schoenwaelder To: "Yi Yang (yiya)" Message-ID: <20140308075940.GA71516@elstar.local> Mail-Followup-To: "Yi Yang (yiya)" , "netmod@ietf.org" References: <20140306083054.GA32986@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wnOjYh46tKDtKytJiDoXhZNz4DA Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf 89 wg meeting summary X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 08 Mar 2014 07:59:54 -0000 Hi, we will soon start a structured list of issues (Martin is working on it based on the list used during the WG meeting) and then contributors can submit any issues they want to get fixed. But to make things easy to track, please use appropriate email threads. /js On Fri, Mar 07, 2014 at 10:31:22PM +0000, Yi Yang (yiya) wrote: > For the YANG maintenance release, one feature may be useful is to support > constraints for union type. For example, a server can be defined as union > of domain-name/ip-addresss. However, domain-name should only be allowed > when a dns-server exists. > > Yi > > > On 3/6/14 8:30 AM, "Juergen Schoenwaelder" > wrote: > > >Hi, > > > >below is a high-level summary of yesterday's WG meeting that I just > >submitted to the OPS ADs and that will be also part of the minutes. > > > > The NETMOD meeting in London was attended by about 70 people. All > > currently charter work items are either in the RFC editor queue, on > > the IESG agenda, or they passed WG last call and are on the way to the > > area director. The discussion of a proposed new WG charter resulted in > > some minor modifications. The active contributors indicated support > > for the new charter and there were no objections. The revised charter > > text including the modifications has been circulated on the mailing > > list right after the meeting. After the charter discussion, the WG > > started to go through a list of issues that may be addressed in a YANG > > maintenance release in order to determine which issues are in scope, > > out of scope, or need more discussion. The status of the stateless > > packet filter data model and a revision of the guidelines document has > > been reported. > > > >/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 > -- 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 Mar 8 00:09:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22921A0234 for ; Sat, 8 Mar 2014 00:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BUDxhWStwFK for ; Sat, 8 Mar 2014 00:09:15 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 56DF91A01D3 for ; Sat, 8 Mar 2014 00:09:15 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 93E95FC2; Sat, 8 Mar 2014 09:09:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id J4sYOlb6Y7h4; Sat, 8 Mar 2014 09:09:10 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Sat, 8 Mar 2014 09:09:10 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A5D02002C; Sat, 8 Mar 2014 09:09: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 vIGnqIItGpou; Sat, 8 Mar 2014 09:09:09 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 23EA220017; Sat, 8 Mar 2014 09:09:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 211CB2BAC4FC; Sat, 8 Mar 2014 09:09:08 +0100 (CET) Date: Sat, 8 Mar 2014 09:09:08 +0100 From: Juergen Schoenwaelder To: "Yi Yang (yiya)" Message-ID: <20140308080908.GB71516@elstar.local> Mail-Followup-To: "Yi Yang (yiya)" , Ladislav Lhotka , "netmod@ietf.org" References: <20140213183325.16175.99400.idtracker@ietfa.amsl.com> <20140307.231152.435558401.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.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/MmwVMizdeqe1kqd9w09jtfgaiVo Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 08 Mar 2014 08:09:28 -0000 On Fri, Mar 07, 2014 at 10:50:04PM +0000, Yi Yang (yiya) wrote: > > [yi]: A vrf can be associated with multiple routing tables, so yes, a > separated data model for vrf is required. But in the DM for routing table, > we need a reference to the vrf. > Can you make a concrete proposal what you think is missing? Note that the routing model passed WG last call and unless there is a major bug I prefer to move this document forward as is. So please come up with a concrete detailed proposal so that we can decide whether we have a bug or not. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sat Mar 8 07:26:04 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CC81A028B for ; Sat, 8 Mar 2014 07:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQOc76tdEd1S for ; Sat, 8 Mar 2014 07:25:59 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 877561A0277 for ; Sat, 8 Mar 2014 07:25:59 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id i8so6115001qcq.3 for ; Sat, 08 Mar 2014 07:25:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=AqnGn7nee3AdxlI3PG3PsWwYauwANUwECFyQm47BblU=; b=BW0srkQDTxe5wn/HIopcz3YcB2wcRORn6CjxUEIIZ1BiitaN7qYTXG9sObesX8eBPQ I+yVTUBBC0At+N6jRF29bg0VapuSbJokLCT4KpmIU7vLb7NzivnbO0mksRpcmaG+nIS5 qegO1e4JNc7Qfns4vm8Zn7l4bSWrit/5I7WL7pCwoTNHMsegfPXXAriMwrHjCei2Q4Qh N9vDsX0elELzEFCuc45k6qhqmTk0rkvx4zlZP01vlmCyu0+MjD+D/3liVLn4So0kFci0 yzWgSKnLV8xs3fZUVhrjYHPwhJahtu8HnnjpKKfhsoKEX/ZGQIrOSqaw8RaaVAYwLwdA YqsQ== X-Gm-Message-State: ALoCoQlPKJ/Xo0GGlsYT39KPDcvP8C6RTEIqQokjn1X53mAWI9NSw7ayBiyGfTUS34P3X9J6HdE2 MIME-Version: 1.0 X-Received: by 10.140.36.77 with SMTP id o71mr27514845qgo.25.1394292354682; Sat, 08 Mar 2014 07:25:54 -0800 (PST) Received: by 10.140.104.194 with HTTP; Sat, 8 Mar 2014 07:25:54 -0800 (PST) Date: Sat, 8 Mar 2014 07:25:54 -0800 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c15fa683c3af04f419fc1f Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/YFB_JQiDDVsby6ri-kP_QI5RylA Subject: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 15:26:02 -0000 --001a11c15fa683c3af04f419fc1f Content-Type: text/plain; charset=ISO-8859-1 Hi, I have been thinking about the integrated feature set for YANG 1.1. I have not figured out how a YANG 1.0 client connecting to a YANG 1.1 server is going to continue to work. I want to support YANG 1.0 and 1.1 clients with the same server. The only way I know to do that is have the server delay its to check the client for the 'capability-id' URI, as specified in the NETCONF-EX draft. This is non-trivial to implement, and probably doesn't work in some situations (Martin does not like it). A YANG 1.0 client will look for the "module=foo" parameters in the server and not find any URIs, and not load any modules (ietf-netconf-monitoring is optional to implement). I think the capabilities defined in the NETCONF-EX draft needs to be part of the charter to support RESTCONF and YANG 1.1. Andy --001a11c15fa683c3af04f419fc1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I have been thinking about the inte= grated feature set for YANG 1.1.
I have not figured out how a YAN= G 1.0 client connecting
to a YANG 1.1 server is going to continue= to work.
I want to support YANG 1.0 and 1.1 clients with the same server.
=

The only way I know to do that is have the server delay=
its <hello> to check the client <hello> for the '= ;capability-id'
URI, as specified in the NETCONF-EX draft.
This is non-trivi= al to implement, and probably doesn't work in
some situations= (Martin does not like it).

A YANG 1.0 client will= look for the "module=3Dfoo" parameters
in the server <hello> and not find any URIs, and not load
<= div>any modules (ietf-netconf-monitoring is optional to implement).

I think the capabilities defined in the NETCONF-EX draft = needs
to be part of the charter to support RESTCONF and YANG 1.1.
=


Andy

=

--001a11c15fa683c3af04f419fc1f-- From nobody Sat Mar 8 08:19:18 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAD31A02B3 for ; Sat, 8 Mar 2014 08:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0MLiIL9Qpfs for ; Sat, 8 Mar 2014 08:19:14 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 01CA41A029C for ; Sat, 8 Mar 2014 08:19:13 -0800 (PST) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 06AB537C2C6; Sat, 8 Mar 2014 17:19:08 +0100 (CET) Date: Sat, 08 Mar 2014 17:19:07 +0100 (CET) Message-Id: <20140308.171907.224328665.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/YyPtaDNUfGXu-zeW1TeCK7qWDw8 Cc: netmod@ietf.org Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 16:19:16 -0000 Hi, Even if the server advertises 1.1 modules like today (directly in the hello), the YANG 1.0 client will not be able to load these modules. I think the server has to advertise any YANG 1.0 modules it implements just like today. But 1.1 modules can be advertised using the new caching mechanism. This means that there are cases where a 1.0 client would have continued to work if the 1.1 modules were advertised as before (if it didn't try to download the new revision of the module, but just used its old revision); but with the new caching mechanism it will not work. I think this is a price we have to pay. However, operationally, it should be possible to configure the server to run in "1.0" mode and advertise modules as before. When the operator knows that all his clients have been upgraded, "1.0" legacy mode can be turned off. /martin Andy Bierman wrote: > Hi, > > I have been thinking about the integrated feature set for YANG 1.1. > I have not figured out how a YANG 1.0 client connecting > to a YANG 1.1 server is going to continue to work. > I want to support YANG 1.0 and 1.1 clients with the same server. > > The only way I know to do that is have the server delay > its to check the client for the 'capability-id' > URI, as specified in the NETCONF-EX draft. > This is non-trivial to implement, and probably doesn't work in > some situations (Martin does not like it). > > A YANG 1.0 client will look for the "module=foo" parameters > in the server and not find any URIs, and not load > any modules (ietf-netconf-monitoring is optional to implement). > > I think the capabilities defined in the NETCONF-EX draft needs > to be part of the charter to support RESTCONF and YANG 1.1. > > > > Andy From nobody Sat Mar 8 08:27:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8DA1A02C2 for ; Sat, 8 Mar 2014 08:27:47 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7Ij6hostIYi for ; Sat, 8 Mar 2014 08:27:44 -0800 (PST) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 731111A02B2 for ; Sat, 8 Mar 2014 08:27:44 -0800 (PST) Received: by mail-yh0-f43.google.com with SMTP id b6so5572551yha.30 for ; Sat, 08 Mar 2014 08:27:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s4vRKU3n5QFQHI7KQ5QDnYsoTMds2l8slUrbcf30f5w=; b=cg0ssvgTiyjTRImGQ3AScnNnNZ2zcMoo2kdgOpBn53xY5SaC9V7KSjJYfnYYz8216Q 7NsPz68uoysso4XZtp0MbceD/v4oITKskr73RfY/2YH4aq8DCSokFz+dm1wgvxUa8jeZ g3OuZ7KginAk9nGjc/N2sFXQD/TTVCuivtHlaHPC89k8umbap81U2rdoFl70A+Dgg7vg xkHDhavnnGCn90HSntMRsCstVVGlFlmZ38D9r+Dw3JzI0ci0ke63gvp9Ywro2wFXlU2N +cfXT0wnxWr/JegxG0HYidbWAs1Q4/sLuUAHquagPOMg80Vex6a0kO79OtuDM+vqIG3y 3fuQ== MIME-Version: 1.0 X-Received: by 10.236.108.202 with SMTP id q50mr382581yhg.146.1394296059518; Sat, 08 Mar 2014 08:27:39 -0800 (PST) Received: by 10.170.194.69 with HTTP; Sat, 8 Mar 2014 08:27:39 -0800 (PST) In-Reply-To: <9C81158E-5B4C-4479-AEA5-23CBCC020ADD@nic.cz> References: <20140110133016.24678.42711.idtracker@ietfa.amsl.com> <9C81158E-5B4C-4479-AEA5-23CBCC020ADD@nic.cz> Date: Sat, 8 Mar 2014 11:27:39 -0500 Message-ID: From: Alia Atlas To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=20cf303b433d56e41e04f41ad9d3 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/F9VQIkrUjPqYNGMc41Zj0w5CQLc Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 16:27:47 -0000 --20cf303b433d56e41e04f41ad9d3 Content-Type: text/plain; charset=ISO-8859-1 VRF would fit better in L3VPN. I strongly agree that we need to start doing therouting-related YANG models in the routing working groups. I do think that some hand-holding is necessary. Personally, despite having read the YANG RFC several times and reading YANG models and thinking about information models, I am still hesitant about trying to write a YANG model that has the necessary considerations & trade-offs. Alia On Fri, Mar 7, 2014 at 5:29 PM, Ladislav Lhotka wrote: > > On 07 Mar 2014, at 22:52, Yi Yang (yiya) wrote: > > > One thing is missing from the data model is association with vrf. > > I agree with what Martin wrote in a parallel thread. I believe the routing > module (and YANG augment statement) provide sufficient hooks for > implementing VRF as a specific type of routing-instance. > > I think though that other work extending the routing module is much more > needed, namely vendor-neutral data models for routing protocols. > > The consensus of the NETMOD WG was that these new modules should be > developed by experts in the Routing Area (VRF in the MPLS WG?). The NETMOD > WG and YANG Doctors will certainly help but the bulk of this work should be > done by domain experts. > > Lada > > > > > Another concern I have is about address family. To facilitate a query > > based on AFI only, or SAFI only, it seems more convenient to use two > leafs > > (AFI and SAFI) instead of one (AFI-SAFI). > > > > Yi > > > > > > > > > > On 1/10/14 8:30 AM, "internet-drafts@ietf.org" > > > wrote: > > > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> This draft is a work item of the NETCONF Data Modeling Language Working > >> Group of the IETF. > >> > >> Title : A YANG Data Model for Routing Management > >> Author : Ladislav Lhotka > >> Filename : draft-ietf-netmod-routing-cfg-13.txt > >> Pages : 95 > >> Date : 2014-01-10 > >> > >> Abstract: > >> This document contains a specification of three YANG modules. > >> Together they form the core routing data model which serves as a > >> framework for configuring and managing a routing subsystem. It is > >> expected that these modules will be augmented by additional YANG > >> modules defining data models for individual routing protocols and > >> other related functions. The core routing data model provides common > >> building blocks for such extensions - routing instances, routes, > >> routing information bases (RIB), routing protocols and route filters. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ > >> > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13 > >> > >> A diff from the previous version is available at: > >> http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-routing-cfg-13 > >> > >> > >> Please note that it may take a couple of minutes from the time of > >> submission > >> until the htmlized version and diff are available at tools.ietf.org. > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > 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 > --20cf303b433d56e41e04f41ad9d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
VRF would fit better in L3VPN. =A0I strongly agree that we= need to start doing therouting-related =A0YANG models in the routing worki= ng groups. =A0I do think that some hand-holding is necessary. =A0Personally= , despite having read the YANG RFC several times and reading YANG models an= d thinking about information models, I am still hesitant about trying to wr= ite a YANG model that has the necessary considerations & trade-offs.
Alia


On Fri, Mar 7, 2014 at 5:29 PM, Ladislav Lhotka <lhotka@nic.= cz> wrote:

On 07 Mar 2014, at 22:52, Yi Yang (yiya) <yiya@cisco.com> wrote:

> One thing is missing from the data model is association with vrf.

I agree with what Martin wrote in a parallel thread. I believe the ro= uting module (and YANG augment statement) provide sufficient hooks for impl= ementing VRF as a specific type of routing-instance.

I think though that other work extending the routing module is much more ne= eded, namely vendor-neutral data models for routing protocols.

The consensus of the NETMOD WG was that these new modules should be develop= ed by experts in the Routing Area (VRF in the MPLS WG?). The NETMOD WG and = YANG Doctors will certainly help but the bulk of this work should be done b= y domain experts.

Lada

>
> Another concern I have is about address family. To facilitate a query<= br> > based on AFI only, or SAFI only, it seems more convenient to use two l= eafs
> (AFI and SAFI) instead of one (AFI-SAFI).
>
> Yi
>
>
>
>
> On 1/10/14 8:30 AM, "= internet-drafts@ietf.org" <internet-drafts@ietf.org>
> wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts=
>> directories.
>> This draft is a work item of the NETCONF Data Modeling Language Wo= rking
>> Group of the IETF.
>>
>> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : A YANG Data Model for Rout= ing Management
>> =A0 =A0 =A0 Author =A0 =A0 =A0 =A0 =A0: Ladislav Lhotka
>> =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-netmod-routing-cfg= -13.txt
>> =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 95
>> =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-01-10
>>
>> Abstract:
>> =A0This document contains a specification of three YANG modules. >> =A0Together they form the core routing data model which serves as = a
>> =A0framework for configuring and managing a routing subsystem. =A0= It is
>> =A0expected that these modules will be augmented by additional YAN= G
>> =A0modules defining data models for individual routing protocols a= nd
>> =A0other related functions. =A0The core routing data model provide= s common
>> =A0building blocks for such extensions - routing instances, routes= ,
>> =A0routing information bases (RIB), routing protocols and route fi= lters.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-net= mod-routing-cfg/
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-netmod-routin= g-cfg-13
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-netmod-routing-cfg-13
>>
>>
>> Please note that it may take a couple of minutes from the time of<= br> >> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> = ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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




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

--20cf303b433d56e41e04f41ad9d3-- From nobody Sat Mar 8 09:15:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A949D1A0164 for ; Sat, 8 Mar 2014 09:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kT_IBc9vF1Zr for ; Sat, 8 Mar 2014 09:15:34 -0800 (PST) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id BC5771A02C2 for ; Sat, 8 Mar 2014 09:15:34 -0800 (PST) Received: by mail-qc0-f169.google.com with SMTP id i17so6154097qcy.28 for ; Sat, 08 Mar 2014 09:15:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kUixzmXyXgLnfVnmrO5m+a5CAyw1+QgkHdHti8IDY0o=; b=RqdNxMaVfnZGZ9cEFIvJZMM7LeWMmpBzkRIJGlv3jo/P4crr5UCwE3Fi8782blJSCV vsXbzCc7EJO2ZVj7PJipbkw1/p3kt5hu81QkCdveCIb4jZH7rHwwNrg8tdCGsvv5WYj4 tIf71eBvOylSkvpV5wzHQc5Jhf5pPhvSCg8YbFBKkX/I0S808gE1PYRYlJuFSYLRworQ Md8rvsyIkeWi4AlTNr+C6pl+fWdgEpvByxewPHSjndFRZ382cRrWcNX6rElcBRsVkIKk 3hHzv/UKIm0/srQ29Itey7l8+VXVrZNwlLWfaEPiNQWCHIzEIWMaMbQgBcvAZv6cq5gs 4bsQ== X-Gm-Message-State: ALoCoQl6G+JO7fhz2k9/jOqH3Puax6rw6gafB6c1uNe7oR81RDUybVBv6sn1DyNtIJ1fAs3pzqJ8 MIME-Version: 1.0 X-Received: by 10.224.46.130 with SMTP id j2mr29662614qaf.7.1394298929924; Sat, 08 Mar 2014 09:15:29 -0800 (PST) Received: by 10.140.104.194 with HTTP; Sat, 8 Mar 2014 09:15:29 -0800 (PST) In-Reply-To: <20140308.171907.224328665.mbj@tail-f.com> References: <20140308.171907.224328665.mbj@tail-f.com> Date: Sat, 8 Mar 2014 09:15:29 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c2a9ca6e312404f41b847f Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1288Fl3FJDfHwwK__bGqh2NFfmA Cc: "netmod@ietf.org" Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 17:15:37 -0000 --001a11c2a9ca6e312404f41b847f Content-Type: text/plain; charset=ISO-8859-1 On Sat, Mar 8, 2014 at 8:19 AM, Martin Bjorklund wrote: > Hi, > > Even if the server advertises 1.1 modules like today (directly in the > hello), the YANG 1.0 client will not be able to load these modules. > > I think the server has to advertise any YANG 1.0 modules it implements > just like today. But 1.1 modules can be advertised using the new > caching mechanism. > > This means that there are cases where a 1.0 client would have > continued to work if the 1.1 modules were advertised as before (if it > didn't try to download the new revision of the module, but just used > its old revision); but with the new caching mechanism it will not > work. > > I think this is a price we have to pay. However, operationally, it > should be possible to configure the server to run in "1.0" mode and > advertise modules as before. When the operator knows that all his > clients have been upgraded, "1.0" legacy mode can be turned off. > > This means implementation of even 1 YANG 1.1 module breaks these YANG 1.0 clients, even though they do not even use those modules. So they cannot use this feature. So how does a server know if a YANG 1.0 or 1.1 client is going to connect without seeing its message? The server can never send the abbreviated if it wants to continue supporting existing YANG 1.0 applications. Not OK. In our code, the thin client that is called by OpenSSH is triggered because the client sent a message, so there is no delay. It may not be hard to deliver the client hello in the initial connect message. So no delay or timeout is needed, just some code changes. Are there server implementations that send the hello as soon as the TCP or SSH session is started? A YANG 1.0 client should be able to continue working with the server because it was written to only use YANG 1.0 modules, so it is not importing any YANG 1.1 modules. > /martin > > > Andy > > > Andy Bierman wrote: > > Hi, > > > > I have been thinking about the integrated feature set for YANG 1.1. > > I have not figured out how a YANG 1.0 client connecting > > to a YANG 1.1 server is going to continue to work. > > I want to support YANG 1.0 and 1.1 clients with the same server. > > > > The only way I know to do that is have the server delay > > its to check the client for the 'capability-id' > > URI, as specified in the NETCONF-EX draft. > > This is non-trivial to implement, and probably doesn't work in > > some situations (Martin does not like it). > > > > A YANG 1.0 client will look for the "module=foo" parameters > > in the server and not find any URIs, and not load > > any modules (ietf-netconf-monitoring is optional to implement). > > > > I think the capabilities defined in the NETCONF-EX draft needs > > to be part of the charter to support RESTCONF and YANG 1.1. > > > > > > > > Andy --001a11c2a9ca6e312404f41b847f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Mar 8, 2014 at 8:19 AM, Martin Bjorklund = <mbj@tail-f.com&= gt; wrote:
Hi,

Even if the server advertises 1.1 modules like today (directly in the
hello), the YANG 1.0 client will not be able to load these modules.

I think the server has to advertise any YANG 1.0 modules it implements
just like today. =A0But 1.1 modules can be advertised using the new
caching mechanism.

This means that there are cases where a 1.0 client would have
continued to work if the 1.1 modules were advertised as before (if it
didn't try to download the new revision of the module, but just used its old revision); but with the new caching mechanism it will not
work.

I think this is a price we have to pay. =A0However, operationally, it
should be possible to configure the server to run in "1.0" mode a= nd
advertise modules as before. =A0When the operator knows that all his
clients have been upgraded, "1.0" legacy mode can be turned off.<= br>

This means implementation of even 1 YA= NG 1.1 module breaks
these YANG 1.0 clients, even though they do = not even use
those modules. So they cannot use this feature.

So how does a server know if a YANG 1.0 or 1.1 client i= s going
to connect without seeing its <hello> message? =A0T= he server
can never send the abbreviated <hello> if it want= s to continue
supporting existing YANG 1.0 applications. Not OK.

In our code, the thin client that is called by OpenSSH
is t= riggered because the client sent a <hello> message,
so ther= e is no delay. =A0It may not be hard to deliver
the client hello in the initial connect message.
So no delay= or timeout is needed, just some code changes.

Are= there server implementations that send the hello
as soon as the = TCP or SSH session is started?

A YANG 1.0 client should be able to continue working
with the server because it was written to only use
YANG 1= .0 modules, so it is not importing any YANG 1.1 modules.





/martin



Andy

=A0


Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
>
> I have been thinking about the integrated feature set for YANG 1.1. > I have not figured out how a YANG 1.0 client connecting
> to a YANG 1.1 server is going to continue to work.
> I want to support YANG 1.0 and 1.1 clients with the same server.
>
> The only way I know to do that is have the server delay
> its <hello> to check the client <hello> for the 'capab= ility-id'
> URI, as specified in the NETCONF-EX draft.
> This is non-trivial to implement, and probably doesn't work in
> some situations (Martin does not like it).
>
> A YANG 1.0 client will look for the "module=3Dfoo" parameter= s
> in the server <hello> and not find any URIs, and not load
> any modules (ietf-netconf-monitoring is optional to implement).
>
> I think the capabilities defined in the NETCONF-EX draft needs
> to be part of the charter to support RESTCONF and YANG 1.1.
>
>
>
> Andy
--001a11c2a9ca6e312404f41b847f-- From nobody Sat Mar 8 09:40:08 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C021A0205 for ; Sat, 8 Mar 2014 09:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UuIKhKeBs_1 for ; Sat, 8 Mar 2014 09:40:02 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8845D1A02D9 for ; Sat, 8 Mar 2014 09:40:02 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 31BC6FCB; Sat, 8 Mar 2014 18:39:57 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Q6rrgfB1D0tN; Sat, 8 Mar 2014 18:39:56 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 8 Mar 2014 18:39:56 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2BED02002C; Sat, 8 Mar 2014 18:39:56 +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 ETrxGEnBobDA; Sat, 8 Mar 2014 18:39: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 F03A320017; Sat, 8 Mar 2014 18:39:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0A0092BACC5E; Sat, 8 Mar 2014 18:39:52 +0100 (CET) Date: Sat, 8 Mar 2014 18:39:52 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140308173950.GB72376@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <20140308.171907.224328665.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.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2v3PHHF_ArgmhVIDNZmZluPACtk Cc: "netmod@ietf.org" Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 08 Mar 2014 17:40:05 -0000 On Sat, Mar 08, 2014 at 09:15:29AM -0800, Andy Bierman wrote: > So how does a server know if a YANG 1.0 or 1.1 client is going > to connect without seeing its message? The server > can never send the abbreviated if it wants to continue > supporting existing YANG 1.0 applications. Not OK. In London, I suggested to do translation of 1.1 to 1.0 and hence a server could announce 1.0 versions of 1.1 modules to clients that do not grok 1.1 format. I got told this is not a good idea... > In our code, the thin client that is called by OpenSSH > is triggered because the client sent a message, > so there is no delay. It may not be hard to deliver > the client hello in the initial connect message. > So no delay or timeout is needed, just some code changes. > > Are there server implementations that send the hello > as soon as the TCP or SSH session is started? Relying on hello timing is brittle. In hindsight, we should not have announced the yang modules during the and instead mandated implementation of the monitoring data model or a separate get-yang-modules RPC. The should really have only been used for protocol capabilities, not for announcing data models. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sat Mar 8 10:44:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0701A0142 for ; Sat, 8 Mar 2014 10:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgUBG-BtZlTB for ; Sat, 8 Mar 2014 10:44:34 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id C09481A026F for ; Sat, 8 Mar 2014 10:44:33 -0800 (PST) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 74B3737C2C6; Sat, 8 Mar 2014 19:44:27 +0100 (CET) Date: Sat, 08 Mar 2014 19:44:26 +0100 (CET) Message-Id: <20140308.194426.31476886.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140308.171907.224328665.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hx6tPB-qnCkbFKikxbZWQ6XkbS0 Cc: netmod@ietf.org Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 18:44:36 -0000 Andy Bierman wrote: > On Sat, Mar 8, 2014 at 8:19 AM, Martin Bjorklund wrote: > > > Hi, > > > > Even if the server advertises 1.1 modules like today (directly in the > > hello), the YANG 1.0 client will not be able to load these modules. > > > > I think the server has to advertise any YANG 1.0 modules it implements > > just like today. But 1.1 modules can be advertised using the new > > caching mechanism. > > > > This means that there are cases where a 1.0 client would have > > continued to work if the 1.1 modules were advertised as before (if it > > didn't try to download the new revision of the module, but just used > > its old revision); but with the new caching mechanism it will not > > work. > > > > I think this is a price we have to pay. However, operationally, it > > should be possible to configure the server to run in "1.0" mode and > > advertise modules as before. When the operator knows that all his > > clients have been upgraded, "1.0" legacy mode can be turned off. > > > > > This means implementation of even 1 YANG 1.1 module breaks > these YANG 1.0 clients, even though they do not even use > those modules. So they cannot use this feature. No, if the server implements module A in YANG 1.0 and B in 1.1, it would advertise A as usual, and then the new cache-thing for B only. So the 1.0 client that knows about A still works. > So how does a server know if a YANG 1.0 or 1.1 client is going > to connect without seeing its message? It will have to be configured to advertise all modules, b/c the operator knows that there are (or might be) 1.0 clients in his network. > The server > can never send the abbreviated if it wants to continue > supporting existing YANG 1.0 applications. Not OK. Over time, old clients get upgraded, and all servers can advertise just the new stuff. I think the benefit of cached module capabilities is worth this. At least it allows the optimization over time. I would say that a 1.1 server MUST either advertise all modules like before, or advertise the new cache thing (or both). A 1.1 client MUST be prepared for old-style module advertisement, and the new style. > In our code, the thin client that is called by OpenSSH > is triggered because the client sent a message, > so there is no delay. It may not be hard to deliver > the client hello in the initial connect message. > So no delay or timeout is needed, just some code changes. > > Are there server implementations that send the hello > as soon as the TCP or SSH session is started? Yes, since this is the REQUIRED behavior according to 6241 (and 4741). I know at least two other implementations (in addition to ours) than does this. /martin > A YANG 1.0 client should be able to continue working > with the server because it was written to only use > YANG 1.0 modules, so it is not importing any YANG 1.1 modules. > > > > > > > /martin > > > > > > > Andy > > > > > > > > > Andy Bierman wrote: > > > Hi, > > > > > > I have been thinking about the integrated feature set for YANG 1.1. > > > I have not figured out how a YANG 1.0 client connecting > > > to a YANG 1.1 server is going to continue to work. > > > I want to support YANG 1.0 and 1.1 clients with the same server. > > > > > > The only way I know to do that is have the server delay > > > its to check the client for the 'capability-id' > > > URI, as specified in the NETCONF-EX draft. > > > This is non-trivial to implement, and probably doesn't work in > > > some situations (Martin does not like it). > > > > > > A YANG 1.0 client will look for the "module=foo" parameters > > > in the server and not find any URIs, and not load > > > any modules (ietf-netconf-monitoring is optional to implement). > > > > > > I think the capabilities defined in the NETCONF-EX draft needs > > > to be part of the charter to support RESTCONF and YANG 1.1. > > > > > > > > > > > > Andy From nobody Sat Mar 8 10:47:48 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946451A00AA for ; Sat, 8 Mar 2014 10:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: 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-uFBXgVsgu6 for ; Sat, 8 Mar 2014 10:47:46 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 222B71A0030 for ; Sat, 8 Mar 2014 10:47:46 -0800 (PST) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 17EE637C2C6; Sat, 8 Mar 2014 19:47:41 +0100 (CET) Date: Sat, 08 Mar 2014 19:47:40 +0100 (CET) Message-Id: <20140308.194740.485430438.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140308173950.GB72376@elstar.local> References: <20140308.171907.224328665.mbj@tail-f.com> <20140308173950.GB72376@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/MAWY5caRfXmYwjpdPD2vUNz5kKY Cc: netmod@ietf.org Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 18:47:47 -0000 Juergen Schoenwaelder wrote: > On Sat, Mar 08, 2014 at 09:15:29AM -0800, Andy Bierman wrote: > > > So how does a server know if a YANG 1.0 or 1.1 client is going > > to connect without seeing its message? The server > > can never send the abbreviated if it wants to continue > > supporting existing YANG 1.0 applications. Not OK. > > In London, I suggested to do translation of 1.1 to 1.0 and hence a > server could announce 1.0 versions of 1.1 modules to clients that do > not grok 1.1 format. I got told this is not a good idea... It doesn't work b/c the server doesn't know if the client is 1.0, as you also stated. Also, a translation of 1.1 to 1.0 would not be correct, and maybe not even possible (e.g., if we allow multiple base statements in an identity). > > In our code, the thin client that is called by OpenSSH > > is triggered because the client sent a message, > > so there is no delay. It may not be hard to deliver > > the client hello in the initial connect message. > > So no delay or timeout is needed, just some code changes. > > > > Are there server implementations that send the hello > > as soon as the TCP or SSH session is started? > > Relying on hello timing is brittle. > > In hindsight, we should not have announced the yang modules during the > and instead mandated implementation of the monitoring data > model or a separate get-yang-modules RPC. The should really > have only been used for protocol capabilities, not for announcing data > models. Yes. This is what we want to do now in 1.1. /martin From nobody Sat Mar 8 11:19:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0E01A026F for ; Sat, 8 Mar 2014 11:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sduLpss3Inku for ; Sat, 8 Mar 2014 11:19:03 -0800 (PST) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEC41A0143 for ; Sat, 8 Mar 2014 11:19:03 -0800 (PST) Received: by mail-qa0-f41.google.com with SMTP id j5so5517542qaq.14 for ; Sat, 08 Mar 2014 11:18:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=33UFvsewXy3sFlO4nps+X6mG8g0k3uXvE/CDLTw5cII=; b=VISkC99yfoqc2oMKPdBuxDInxl5qWfh1NKpEw7AnHBNlbsr3PZPdxySbrGmouzgPwb wUfpp1k2PntrA1tXGYCavof4eG730hBKm71qXmFvCGuSU0bm0L7NYVKsu+RGhCVBop8L bLMZe/fPzOesQ7O1dlp6UXnxmKVDgeqhCUwD4MkIDiv26Jt1UOR0/DLlXg0f/FGF9Z+m 7+BtBqO8kRAsL9kVUAlys8OSewC4og6OaAhSMvNmCxWAsr/XC47fg7EN2oxK6go1TlF5 p1gjBYxez9IXKZVuIldeJSJGbqLD64JYrq6omYGUurId1h8V95BW0kOrs/N2gmNnfDj0 jW9w== X-Gm-Message-State: ALoCoQmmee5zm2FkP9sRwOicupWYOOO8txYyfmAv1QcOODwNowxvBtRdNqgyQRKFL6Md3NbHwftm MIME-Version: 1.0 X-Received: by 10.224.112.6 with SMTP id u6mr30237073qap.78.1394306338471; Sat, 08 Mar 2014 11:18:58 -0800 (PST) Received: by 10.140.104.194 with HTTP; Sat, 8 Mar 2014 11:18:58 -0800 (PST) In-Reply-To: <20140308.194426.31476886.mbj@tail-f.com> References: <20140308.171907.224328665.mbj@tail-f.com> <20140308.194426.31476886.mbj@tail-f.com> Date: Sat, 8 Mar 2014 11:18:58 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c2e84803731704f41d3ebb Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6sKqzQKt154FJjbdSxFDWY8bp0M Cc: "netmod@ietf.org" Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 19:19:07 -0000 --001a11c2e84803731704f41d3ebb Content-Type: text/plain; charset=ISO-8859-1 On Sat, Mar 8, 2014 at 10:44 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Sat, Mar 8, 2014 at 8:19 AM, Martin Bjorklund wrote: > > > > > Hi, > > > > > > Even if the server advertises 1.1 modules like today (directly in the > > > hello), the YANG 1.0 client will not be able to load these modules. > > > > > > I think the server has to advertise any YANG 1.0 modules it implements > > > just like today. But 1.1 modules can be advertised using the new > > > caching mechanism. > > > > > > This means that there are cases where a 1.0 client would have > > > continued to work if the 1.1 modules were advertised as before (if it > > > didn't try to download the new revision of the module, but just used > > > its old revision); but with the new caching mechanism it will not > > > work. > > > > > > I think this is a price we have to pay. However, operationally, it > > > should be possible to configure the server to run in "1.0" mode and > > > advertise modules as before. When the operator knows that all his > > > clients have been upgraded, "1.0" legacy mode can be turned off. > > > > > > > > This means implementation of even 1 YANG 1.1 module breaks > > these YANG 1.0 clients, even though they do not even use > > those modules. So they cannot use this feature. > > No, if the server implements module A in YANG 1.0 and B in 1.1, it > would advertise A as usual, and then the new cache-thing for B only. > So the 1.0 client that knows about A still works. > A YANG 1.1 module can import 1.0, but not the other way around. If this happens, there will be a mix of versions advertised in the module URIs. > > > So how does a server know if a YANG 1.0 or 1.1 client is going > > to connect without seeing its message? > > It will have to be configured to advertise all modules, b/c the > operator knows that there are (or might be) 1.0 clients in his > network. > This is very brittle because just 1 old client will probably disable caching for every application. This can be left as an implementation detail. If a server knows how to get the client hello and send its hello to match, then it will be completely transparent to the client. So we will implement it anyway. > > > The server > > can never send the abbreviated if it wants to continue > > supporting existing YANG 1.0 applications. Not OK. > > Over time, old clients get upgraded, and all servers can advertise > just the new stuff. I think the benefit of cached module capabilities > is worth this. At least it allows the optimization over time. > > I would say that a 1.1 server MUST either advertise all modules like > before, or advertise the new cache thing (or both). A 1.1 client MUST > be prepared for old-style module advertisement, and the new style. > > > In our code, the thin client that is called by OpenSSH > > is triggered because the client sent a message, > > so there is no delay. It may not be hard to deliver > > the client hello in the initial connect message. > > So no delay or timeout is needed, just some code changes. > > > > Are there server implementations that send the hello > > as soon as the TCP or SSH session is started? > > Yes, since this is the REQUIRED behavior according to 6241 (and > 4741). I know at least two other implementations (in addition to > ours) than does this. > > It is not required. There is no text that says that any incoming packet has to invoke a response within a certain time interval. > /martin > > Andy > > > A YANG 1.0 client should be able to continue working > > with the server because it was written to only use > > YANG 1.0 modules, so it is not importing any YANG 1.1 modules. > > > > > > > > > > > > > /martin > > > > > > > > > > > Andy > > > > > > > > > > > > > > > Andy Bierman wrote: > > > > Hi, > > > > > > > > I have been thinking about the integrated feature set for YANG 1.1. > > > > I have not figured out how a YANG 1.0 client connecting > > > > to a YANG 1.1 server is going to continue to work. > > > > I want to support YANG 1.0 and 1.1 clients with the same server. > > > > > > > > The only way I know to do that is have the server delay > > > > its to check the client for the 'capability-id' > > > > URI, as specified in the NETCONF-EX draft. > > > > This is non-trivial to implement, and probably doesn't work in > > > > some situations (Martin does not like it). > > > > > > > > A YANG 1.0 client will look for the "module=foo" parameters > > > > in the server and not find any URIs, and not load > > > > any modules (ietf-netconf-monitoring is optional to implement). > > > > > > > > I think the capabilities defined in the NETCONF-EX draft needs > > > > to be part of the charter to support RESTCONF and YANG 1.1. > > > > > > > > > > > > > > > > Andy > --001a11c2e84803731704f41d3ebb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Mar 8, 2014 at 10:44 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Sat, Mar 8, 2014 at 8:19 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Hi,
> >
> > Even if the server advertises 1.1 modules like today (directly in= the
> > hello), the YANG 1.0 client will not be able to load these module= s.
> >
> > I think the server has to advertise any YANG 1.0 modules it imple= ments
> > just like today. =A0But 1.1 modules can be advertised using the n= ew
> > caching mechanism.
> >
> > This means that there are cases where a 1.0 client would have
> > continued to work if the 1.1 modules were advertised as before (i= f it
> > didn't try to download the new revision of the module, but ju= st used
> > its old revision); but with the new caching mechanism it will not=
> > work.
> >
> > I think this is a price we have to pay. =A0However, operationally= , it
> > should be possible to configure the server to run in "1.0&qu= ot; mode and
> > advertise modules as before. =A0When the operator knows that all = his
> > clients have been upgraded, "1.0" legacy mode can be tu= rned off.
> >
> >
> This means implementation of even 1 YANG 1.1 module breaks
> these YANG 1.0 clients, even though they do not even use
> those modules. So they cannot use this feature.

No, if the server implements module A in YANG 1.0 and B in 1.1, it
would advertise A as usual, and then the new cache-thing for B only.
So the 1.0 client that knows about A still works.

=

A YANG 1.1 module can import 1.0, but not the oth= er way around.
If this happens, there will be a mix of versions a= dvertised in the
module URIs.

=A0

> So how does a server know if a YANG 1.0 or 1.1 client is going
> to connect without seeing its <hello> message?

It will have to be configured to advertise all modules, b/c the
operator knows that there are (or might be) 1.0 clients in his
network.


This is very br= ittle because just 1 old client will probably
disable caching for= every application.

This can be left as an impleme= ntation detail.
If a server knows how to get the client hello
and send its h= ello to match, then it will be completely
transparent to the clie= nt. =A0So we will implement it anyway.


=A0

> The server
> can never send the abbreviated <hello> if it wants to continue > supporting existing YANG 1.0 applications. Not OK.

Over time, old clients get upgraded, and all servers can advertise
just the new stuff. =A0I think the benefit of cached module capabilities is worth this. =A0At least it allows the optimization over time.

I would say that a 1.1 server MUST either advertise all modules like
before, or advertise the new cache thing (or both). =A0A 1.1 client MUST be prepared for old-style module advertisement, and the new style.

> In our code, the thin client that is called by OpenSSH
> is triggered because the client sent a <hello> message,
> so there is no delay. =A0It may not be hard to deliver
> the client hello in the initial connect message.
> So no delay or timeout is needed, just some code changes.
>
> Are there server implementations that send the hello
> as soon as the TCP or SSH session is started?

Yes, since this is the REQUIRED behavior according to 6241 (and
4741). =A0I know at least two other implementations (in addition to
ours) than does this.


It is not required.
There is= no text that says that any incoming packet has
to invoke a respo= nse within a certain time interval.



/martin



Andy

=A0

> A YANG 1.0 client should be able to continue working
> with the server because it was written to only use
> YANG 1.0 modules, so it is not importing any YANG 1.1 modules.
>
>
>
>
>
> > /martin
> >
> >
> >
> Andy
>
>
>
> >
> >
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > Hi,
> > >
> > > I have been thinking about the integrated feature set for YA= NG 1.1.
> > > I have not figured out how a YANG 1.0 client connecting
> > > to a YANG 1.1 server is going to continue to work.
> > > I want to support YANG 1.0 and 1.1 clients with the same ser= ver.
> > >
> > > The only way I know to do that is have the server delay
> > > its <hello> to check the client <hello> for the = 'capability-id'
> > > URI, as specified in the NETCONF-EX draft.
> > > This is non-trivial to implement, and probably doesn't w= ork in
> > > some situations (Martin does not like it).
> > >
> > > A YANG 1.0 client will look for the "module=3Dfoo"= parameters
> > > in the server <hello> and not find any URIs, and not l= oad
> > > any modules (ietf-netconf-monitoring is optional to implemen= t).
> > >
> > > I think the capabilities defined in the NETCONF-EX draft nee= ds
> > > to be part of the charter to support RESTCONF and YANG 1.1.<= br> > > >
> > >
> > >
> > > Andy

--001a11c2e84803731704f41d3ebb-- From nobody Sat Mar 8 11:25:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDFA1A02B0 for ; Sat, 8 Mar 2014 11:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSn4WNu2EZxx for ; Sat, 8 Mar 2014 11:25:49 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id A8E221A02A9 for ; Sat, 8 Mar 2014 11:25:48 -0800 (PST) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 7ED1437C2C6; Sat, 8 Mar 2014 20:25:43 +0100 (CET) Date: Sat, 08 Mar 2014 20:25:43 +0100 (CET) Message-Id: <20140308.202543.115008719.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140308.194426.31476886.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/veTE2ROWHPg_D8fT9BUqdDBvjXY Cc: netmod@ietf.org Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 19:25:52 -0000 Andy Bierman wrote: > On Sat, Mar 8, 2014 at 10:44 AM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > On Sat, Mar 8, 2014 at 8:19 AM, Martin Bjorklund wrote: > > > > > > > Hi, > > > > > > > > Even if the server advertises 1.1 modules like today (directly in the > > > > hello), the YANG 1.0 client will not be able to load these modules. > > > > > > > > I think the server has to advertise any YANG 1.0 modules it implements > > > > just like today. But 1.1 modules can be advertised using the new > > > > caching mechanism. > > > > > > > > This means that there are cases where a 1.0 client would have > > > > continued to work if the 1.1 modules were advertised as before (if it > > > > didn't try to download the new revision of the module, but just used > > > > its old revision); but with the new caching mechanism it will not > > > > work. > > > > > > > > I think this is a price we have to pay. However, operationally, it > > > > should be possible to configure the server to run in "1.0" mode and > > > > advertise modules as before. When the operator knows that all his > > > > clients have been upgraded, "1.0" legacy mode can be turned off. > > > > > > > > > > > This means implementation of even 1 YANG 1.1 module breaks > > > these YANG 1.0 clients, even though they do not even use > > > those modules. So they cannot use this feature. > > > > No, if the server implements module A in YANG 1.0 and B in 1.1, it > > would advertise A as usual, and then the new cache-thing for B only. > > So the 1.0 client that knows about A still works. > > > > > A YANG 1.1 module can import 1.0, but not the other way around. > If this happens, there will be a mix of versions advertised in the > module URIs. Yes. But does it matter? > > > So how does a server know if a YANG 1.0 or 1.1 client is going > > > to connect without seeing its message? > > > > It will have to be configured to advertise all modules, b/c the > > operator knows that there are (or might be) 1.0 clients in his > > network. > > > > > This is very brittle because just 1 old client will probably > disable caching for every application. Correct. But the alternative is that we keep the old behavior and never get caching, even if all our clients are 1.1. > This can be left as an implementation detail. No, b/c it won't be interoperable. > If a server knows how to get the client hello > and send its hello to match, then it will be completely > transparent to the client. So we will implement it anyway. > > > > > > > > > The server > > > can never send the abbreviated if it wants to continue > > > supporting existing YANG 1.0 applications. Not OK. > > > > Over time, old clients get upgraded, and all servers can advertise > > just the new stuff. I think the benefit of cached module capabilities > > is worth this. At least it allows the optimization over time. > > > > I would say that a 1.1 server MUST either advertise all modules like > > before, or advertise the new cache thing (or both). A 1.1 client MUST > > be prepared for old-style module advertisement, and the new style. > > > > > In our code, the thin client that is called by OpenSSH > > > is triggered because the client sent a message, > > > so there is no delay. It may not be hard to deliver > > > the client hello in the initial connect message. > > > So no delay or timeout is needed, just some code changes. > > > > > > Are there server implementations that send the hello > > > as soon as the TCP or SSH session is started? > > > > Yes, since this is the REQUIRED behavior according to 6241 (and > > 4741). I know at least two other implementations (in addition to > > ours) than does this. > > > > > It is not required. > There is no text that says that any incoming packet has > to invoke a response within a certain time interval. Section 8.1 of 6241: A peer MUST NOT wait to receive the capability set from the other side before sending its own set. /martin From nobody Sat Mar 8 14:18:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4411A02EA for ; Sat, 8 Mar 2014 14:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YN1oloDDe2xW for ; Sat, 8 Mar 2014 14:18:25 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBBA1A02BE for ; Sat, 8 Mar 2014 14:18:25 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id f11so5462080qae.17 for ; Sat, 08 Mar 2014 14:18:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HbGFOcnfJCE4slhEu18kkBbOJwQosnB6Nqojmf4utEo=; b=k/8RMRrcjnEtW1uYiDrtcJqg4qPZR5sVwFpD/6EIycoaVpXwUGDFYqgyvkFcAhSQD+ v6Pbxh1PamoUTTY1KW1sxbxVUhS7zDtyXWOALMVxh7BFO/ShbBIZtUGuVmTc3UHvNLwv qlKHrcckhz3+GfJMGh8pl8EDwWk4dHKESiFfH87+QxH90eGn00zwouzuZY/d/O9r5Qit A0pYQo2w8EbemL1zCQUFmV6seRmJSBOAiWbeNiG/RofAdDNZnxIK6efUFG/rCrQ+HYPK oNpjflAN+iOsYL2hkl+O6dTtUYJpKv4b1Xo8MP8gBdvs1CjwDHNgytM0AyOmqZ+/8Svz /jwA== X-Gm-Message-State: ALoCoQlQPShZ/+uPfvQyYukca6GSXcTw7WK9OOynRs0arXLWM+78Xv9Mk1q88kvRAY6kb6TXrHWE MIME-Version: 1.0 X-Received: by 10.224.43.200 with SMTP id x8mr23520515qae.43.1394317100599; Sat, 08 Mar 2014 14:18:20 -0800 (PST) Received: by 10.140.104.194 with HTTP; Sat, 8 Mar 2014 14:18:20 -0800 (PST) In-Reply-To: <20140308.202543.115008719.mbj@tail-f.com> References: <20140308.194426.31476886.mbj@tail-f.com> <20140308.202543.115008719.mbj@tail-f.com> Date: Sat, 8 Mar 2014 14:18:20 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7bf0ec227c932b04f41fbff4 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZGsEGEOwVkYtX4iLS9yfAu4_LR0 Cc: "netmod@ietf.org" Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 22:18:28 -0000 --047d7bf0ec227c932b04f41fbff4 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Mar 8, 2014 at 11:25 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Sat, Mar 8, 2014 at 10:44 AM, Martin Bjorklund > wrote: > > > > > Andy Bierman wrote: > > > > On Sat, Mar 8, 2014 at 8:19 AM, Martin Bjorklund > wrote: > > > > > > > > > Hi, > > > > > > > > > > Even if the server advertises 1.1 modules like today (directly in > the > > > > > hello), the YANG 1.0 client will not be able to load these modules. > > > > > > > > > > I think the server has to advertise any YANG 1.0 modules it > implements > > > > > just like today. But 1.1 modules can be advertised using the new > > > > > caching mechanism. > > > > > > > > > > This means that there are cases where a 1.0 client would have > > > > > continued to work if the 1.1 modules were advertised as before (if > it > > > > > didn't try to download the new revision of the module, but just > used > > > > > its old revision); but with the new caching mechanism it will not > > > > > work. > > > > > > > > > > I think this is a price we have to pay. However, operationally, it > > > > > should be possible to configure the server to run in "1.0" mode and > > > > > advertise modules as before. When the operator knows that all his > > > > > clients have been upgraded, "1.0" legacy mode can be turned off. > > > > > > > > > > > > > > This means implementation of even 1 YANG 1.1 module breaks > > > > these YANG 1.0 clients, even though they do not even use > > > > those modules. So they cannot use this feature. > > > > > > No, if the server implements module A in YANG 1.0 and B in 1.1, it > > > would advertise A as usual, and then the new cache-thing for B only. > > > So the 1.0 client that knows about A still works. > > > > > > > > > A YANG 1.1 module can import 1.0, but not the other way around. > > If this happens, there will be a mix of versions advertised in the > > module URIs. > > Yes. But does it matter? > > > > > So how does a server know if a YANG 1.0 or 1.1 client is going > > > > to connect without seeing its message? > > > > > > It will have to be configured to advertise all modules, b/c the > > > operator knows that there are (or might be) 1.0 clients in his > > > network. > > > > > > > > > This is very brittle because just 1 old client will probably > > disable caching for every application. > > Correct. But the alternative is that we keep the old behavior and > never get caching, even if all our clients are 1.1. > > > This can be left as an implementation detail. > > No, b/c it won't be interoperable. > Yes it is -- servers only talk to clients, not other servers. It is completely transparent to the client. > > > If a server knows how to get the client hello > > and send its hello to match, then it will be completely > > transparent to the client. So we will implement it anyway. > > > > > > > > > > > > > > > The server > > > > can never send the abbreviated if it wants to continue > > > > supporting existing YANG 1.0 applications. Not OK. > > > > > > Over time, old clients get upgraded, and all servers can advertise > > > just the new stuff. I think the benefit of cached module capabilities > > > is worth this. At least it allows the optimization over time. > > > > > > I would say that a 1.1 server MUST either advertise all modules like > > > before, or advertise the new cache thing (or both). A 1.1 client MUST > > > be prepared for old-style module advertisement, and the new style. > > > > > > > In our code, the thin client that is called by OpenSSH > > > > is triggered because the client sent a message, > > > > so there is no delay. It may not be hard to deliver > > > > the client hello in the initial connect message. > > > > So no delay or timeout is needed, just some code changes. > > > > > > > > Are there server implementations that send the hello > > > > as soon as the TCP or SSH session is started? > > > > > > Yes, since this is the REQUIRED behavior according to 6241 (and > > > 4741). I know at least two other implementations (in addition to > > > ours) than does this. > > > > > > > > It is not required. > > There is no text that says that any incoming packet has > > to invoke a response within a certain time interval. > > Section 8.1 of 6241: > > A peer MUST NOT wait to receive the capability > > set from the other side before sending its own set. Right -- we follow this -- the NETCONF client peer sends a and the server responds right away. This text refers to the NETCONF layer. > /martin > Andy --047d7bf0ec227c932b04f41fbff4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Mar 8, 2014 at 11:25 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Sat, Mar 8, 2014 at 10:44 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > On Sat, Mar 8, 2014 at 8:19 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > Even if the server advertises 1.1 modules like today (d= irectly in the
> > > > hello), the YANG 1.0 client will not be able to load th= ese modules.
> > > >
> > > > I think the server has to advertise any YANG 1.0 module= s it implements
> > > > just like today. =A0But 1.1 modules can be advertised u= sing the new
> > > > caching mechanism.
> > > >
> > > > This means that there are cases where a 1.0 client woul= d have
> > > > continued to work if the 1.1 modules were advertised as= before (if it
> > > > didn't try to download the new revision of the modu= le, but just used
> > > > its old revision); but with the new caching mechanism i= t will not
> > > > work.
> > > >
> > > > I think this is a price we have to pay. =A0However, ope= rationally, it
> > > > should be possible to configure the server to run in &q= uot;1.0" mode and
> > > > advertise modules as before. =A0When the operator knows= that all his
> > > > clients have been upgraded, "1.0" legacy mode= can be turned off.
> > > >
> > > >
> > > This means implementation of even 1 YANG 1.1 module breaks > > > these YANG 1.0 clients, even though they do not even use
> > > those modules. So they cannot use this feature.
> >
> > No, if the server implements module A in YANG 1.0 and B in 1.1, i= t
> > would advertise A as usual, and then the new cache-thing for B on= ly.
> > So the 1.0 client that knows about A still works.
> >
>
>
> A YANG 1.1 module can import 1.0, but not the other way around.
> If this happens, there will be a mix of versions advertised in the
> module URIs.

Yes. =A0But does it matter?

> > > So how does a server know if a YANG 1.0 or 1.1 client is goi= ng
> > > to connect without seeing its <hello> message?
> >
> > It will have to be configured to advertise all modules, b/c the > > operator knows that there are (or might be) 1.0 clients in his > > network.
> >
>
>
> This is very brittle because just 1 old client will probably
> disable caching for every application.

Correct. =A0But the alternative is that we keep the old behavior and
never get caching, even if all our clients are 1.1.

> This can be left as an implementation detail.

No, b/c it won't be interoperable.
=A0
<= br>
Yes it is -- servers only talk to clients, not other servers.=
It is completely transparent to the client.



=A0

> If a server knows how to get the client hello
> and send its hello to match, then it will be completely
> transparent to the client. =A0So we will implement it anyway.
>
>
>
>
> >
> > > The server
> > > can never send the abbreviated <hello> if it wants to = continue
> > > supporting existing YANG 1.0 applications. Not OK.
> >
> > Over time, old clients get upgraded, and all servers can advertis= e
> > just the new stuff. =A0I think the benefit of cached module capab= ilities
> > is worth this. =A0At least it allows the optimization over time.<= br> > >
> > I would say that a 1.1 server MUST either advertise all modules l= ike
> > before, or advertise the new cache thing (or both). =A0A 1.1 clie= nt MUST
> > be prepared for old-style module advertisement, and the new style= .
> >
> > > In our code, the thin client that is called by OpenSSH
> > > is triggered because the client sent a <hello> message= ,
> > > so there is no delay. =A0It may not be hard to deliver
> > > the client hello in the initial connect message.
> > > So no delay or timeout is needed, just some code changes. > > >
> > > Are there server implementations that send the hello
> > > as soon as the TCP or SSH session is started?
> >
> > Yes, since this is the REQUIRED behavior according to 6241 (and > > 4741). =A0I know at least two other implementations (in addition = to
> > ours) than does this.
> >
> >
> It is not required.
> There is no text that says that any incoming packet has
> to invoke a response within a certain time interval.

Section 8.1 of 6241:

=A0 =A0A peer MUST NOT wait to receive the capability

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> =A0 =A0set from the other side before sending its own set.
Right -- we follow this -- the NETCONF client peer sends a = <hello>
and the server responds right away. =A0This text re= fers to the NETCONF
layer.




/martin


<= /div>
Andy


--047d7bf0ec227c932b04f41fbff4-- From nobody Sat Mar 8 18:11:48 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9481A01A7 for ; Sat, 8 Mar 2014 18:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UJ2JWa2dQC1 for ; Sat, 8 Mar 2014 18:11:41 -0800 (PST) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id E99731A019C for ; Sat, 8 Mar 2014 18:11:40 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id m5so5639044qaj.11 for ; Sat, 08 Mar 2014 18:11:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SW+xmYO73gj7LFIWrE9MWqBP25DoIU3uw5fz32rWPMo=; b=mqvuO5sLmFENEehh7biXsPBR26ZxJEHkYxTNGi7K5wGgQNdXWDVFCRdLkYg7cdrIPG Wy4cyf+O+4yFST64yNVoVHvGVlwrseAnaDPYWPsqgRJoWOqLCPBHKeKoUMG9WzMYlwm5 wd+SQNrj90wSKpf6CQm4uTy1yJM5h3rgO5xWUEzMnvSvlC6qonwO7PUJ3TQGkZIGBLCF uCDgD/lzi6QGB2leIYgB4yMLO9Y0EL+a6YULm45Aj0VtM0p05peUvwLVqR+PpUBw0y3q JIfqp/QE3CtcDdXZXkD7ZvRc4EyOWOsp8mWgHSPLGAiyGlpZRGzdVJPVdcpoFhlwmo8N VxxQ== X-Gm-Message-State: ALoCoQmBIotBL2B97MrU5nhoaFAq1WAAY/nB+shhc+ulbBZosVYF9IBGEszELQ78ZOnIdrLkXvW2 MIME-Version: 1.0 X-Received: by 10.224.114.130 with SMTP id e2mr28087809qaq.53.1394331095832; Sat, 08 Mar 2014 18:11:35 -0800 (PST) Received: by 10.140.104.194 with HTTP; Sat, 8 Mar 2014 18:11:35 -0800 (PST) In-Reply-To: <20140308.202543.115008719.mbj@tail-f.com> References: <20140308.194426.31476886.mbj@tail-f.com> <20140308.202543.115008719.mbj@tail-f.com> Date: Sat, 8 Mar 2014 18:11:35 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7bea44ccaaae2f04f423014b Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_YGF2abNbmQT92ttAFsmQ-kqFPs Cc: "netmod@ietf.org" Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 02:11:45 -0000 --047d7bea44ccaaae2f04f423014b Content-Type: text/plain; charset=ISO-8859-1 On Sat, Mar 8, 2014 at 11:25 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Sat, Mar 8, 2014 at 10:44 AM, Martin Bjorklund > wrote: > > > > > Andy Bierman wrote: > > > > On Sat, Mar 8, 2014 at 8:19 AM, Martin Bjorklund > wrote: > > > > > > > > > Hi, > > > > > > > > > > Even if the server advertises 1.1 modules like today (directly in > the > > > > > hello), the YANG 1.0 client will not be able to load these modules. > > > > > > > > > > I think the server has to advertise any YANG 1.0 modules it > implements > > > > > just like today. But 1.1 modules can be advertised using the new > > > > > caching mechanism. > > > > > > > > > > This means that there are cases where a 1.0 client would have > > > > > continued to work if the 1.1 modules were advertised as before (if > it > > > > > didn't try to download the new revision of the module, but just > used > > > > > its old revision); but with the new caching mechanism it will not > > > > > work. > > > > > > > > > > I think this is a price we have to pay. However, operationally, it > > > > > should be possible to configure the server to run in "1.0" mode and > > > > > advertise modules as before. When the operator knows that all his > > > > > clients have been upgraded, "1.0" legacy mode can be turned off. > > > > > > > > > > > > > > This means implementation of even 1 YANG 1.1 module breaks > > > > these YANG 1.0 clients, even though they do not even use > > > > those modules. So they cannot use this feature. > > > > > > No, if the server implements module A in YANG 1.0 and B in 1.1, it > > > would advertise A as usual, and then the new cache-thing for B only. > > > So the 1.0 client that knows about A still works. > > > > > > > > > A YANG 1.1 module can import 1.0, but not the other way around. > > If this happens, there will be a mix of versions advertised in the > > module URIs. > > Yes. But does it matter? > > > > > So how does a server know if a YANG 1.0 or 1.1 client is going > > > > to connect without seeing its message? > > > > > > It will have to be configured to advertise all modules, b/c the > > > operator knows that there are (or might be) 1.0 clients in his > > > network. > > > > > > > > > This is very brittle because just 1 old client will probably > > disable caching for every application. > > Correct. But the alternative is that we keep the old behavior and > never get caching, even if all our clients are 1.1. > > > This can be left as an implementation detail. > > No, b/c it won't be interoperable. > > > If a server knows how to get the client hello > > and send its hello to match, then it will be completely > > transparent to the client. So we will implement it anyway. > > > > > > > > > > > > > > > The server > > > > can never send the abbreviated if it wants to continue > > > > supporting existing YANG 1.0 applications. Not OK. > > > > > > Over time, old clients get upgraded, and all servers can advertise > > > just the new stuff. I think the benefit of cached module capabilities > > > is worth this. At least it allows the optimization over time. > > > > > > I would say that a 1.1 server MUST either advertise all modules like > > > before, or advertise the new cache thing (or both). A 1.1 client MUST > > > be prepared for old-style module advertisement, and the new style. > > > > > > > In our code, the thin client that is called by OpenSSH > > > > is triggered because the client sent a message, > > > > so there is no delay. It may not be hard to deliver > > > > the client hello in the initial connect message. > > > > So no delay or timeout is needed, just some code changes. > > > > > > > > Are there server implementations that send the hello > > > > as soon as the TCP or SSH session is started? > > > > > > Yes, since this is the REQUIRED behavior according to 6241 (and > > > 4741). I know at least two other implementations (in addition to > > > ours) than does this. > > > > > > > > It is not required. > > There is no text that says that any incoming packet has > > to invoke a response within a certain time interval. > > Section 8.1 of 6241: > > A peer MUST NOT wait to receive the capability > set from the other side before sending its own set. > > OK -- so we are back to square 1: 1) The client should decide which type of advertisement to make, if possible. 2) A new client should indicate its version before sending the 3) A new server must not need to have the client before deciding What about a new SSH subsystem? What if we followed to rules you suggest for sub-system "netconf" and use the cache version rules (1.1) for sub-system "netconf-ex"? Applications can either learn or be configured to use 1 or the other in many cases. An old client keeps doing the same thing and keeps working. A new client does a new thing and the new advertisement works. It does not help to mandate behavior after the if the point is to send a shorter to only new clients. > /martin > Andy --047d7bea44ccaaae2f04f423014b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Mar 8, 2014 at 11:25 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Sat, Mar 8, 2014 at 10:44 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > On Sat, Mar 8, 2014 at 8:19 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > Even if the server advertises 1.1 modules like today (d= irectly in the
> > > > hello), the YANG 1.0 client will not be able to load th= ese modules.
> > > >
> > > > I think the server has to advertise any YANG 1.0 module= s it implements
> > > > just like today. =A0But 1.1 modules can be advertised u= sing the new
> > > > caching mechanism.
> > > >
> > > > This means that there are cases where a 1.0 client woul= d have
> > > > continued to work if the 1.1 modules were advertised as= before (if it
> > > > didn't try to download the new revision of the modu= le, but just used
> > > > its old revision); but with the new caching mechanism i= t will not
> > > > work.
> > > >
> > > > I think this is a price we have to pay. =A0However, ope= rationally, it
> > > > should be possible to configure the server to run in &q= uot;1.0" mode and
> > > > advertise modules as before. =A0When the operator knows= that all his
> > > > clients have been upgraded, "1.0" legacy mode= can be turned off.
> > > >
> > > >
> > > This means implementation of even 1 YANG 1.1 module breaks > > > these YANG 1.0 clients, even though they do not even use
> > > those modules. So they cannot use this feature.
> >
> > No, if the server implements module A in YANG 1.0 and B in 1.1, i= t
> > would advertise A as usual, and then the new cache-thing for B on= ly.
> > So the 1.0 client that knows about A still works.
> >
>
>
> A YANG 1.1 module can import 1.0, but not the other way around.
> If this happens, there will be a mix of versions advertised in the
> module URIs.

Yes. =A0But does it matter?

> > > So how does a server know if a YANG 1.0 or 1.1 client is goi= ng
> > > to connect without seeing its <hello> message?
> >
> > It will have to be configured to advertise all modules, b/c the > > operator knows that there are (or might be) 1.0 clients in his > > network.
> >
>
>
> This is very brittle because just 1 old client will probably
> disable caching for every application.

Correct. =A0But the alternative is that we keep the old behavior and
never get caching, even if all our clients are 1.1.

> This can be left as an implementation detail.

No, b/c it won't be interoperable.

> If a server knows how to get the client hello
> and send its hello to match, then it will be completely
> transparent to the client. =A0So we will implement it anyway.
>
>
>
>
> >
> > > The server
> > > can never send the abbreviated <hello> if it wants to = continue
> > > supporting existing YANG 1.0 applications. Not OK.
> >
> > Over time, old clients get upgraded, and all servers can advertis= e
> > just the new stuff. =A0I think the benefit of cached module capab= ilities
> > is worth this. =A0At least it allows the optimization over time.<= br> > >
> > I would say that a 1.1 server MUST either advertise all modules l= ike
> > before, or advertise the new cache thing (or both). =A0A 1.1 clie= nt MUST
> > be prepared for old-style module advertisement, and the new style= .
> >
> > > In our code, the thin client that is called by OpenSSH
> > > is triggered because the client sent a <hello> message= ,
> > > so there is no delay. =A0It may not be hard to deliver
> > > the client hello in the initial connect message.
> > > So no delay or timeout is needed, just some code changes. > > >
> > > Are there server implementations that send the hello
> > > as soon as the TCP or SSH session is started?
> >
> > Yes, since this is the REQUIRED behavior according to 6241 (and > > 4741). =A0I know at least two other implementations (in addition = to
> > ours) than does this.
> >
> >
> It is not required.
> There is no text that says that any incoming packet has
> to invoke a response within a certain time interval.

Section 8.1 of 6241:

=A0 =A0A peer MUST NOT wait to receive the capability
=A0 =A0set from the other side before sending its own set.



OK -- so we are back to square 1:

=A01) The client should decide which type of advertis= ement to make, if possible.
=A02) A new client should indicate its version before sending the <= hello>
=A03) A new server must not need to have the client= <hello> before deciding

What about a new SS= H subsystem?
What if we followed to rules you suggest for sub-system "netconf&= quot;
and use the cache version rules (1.1) for sub-system "= netconf-ex"?
Applications can either learn or be configured = to use 1 or the other
in many cases.

An old client keeps doing the = same thing and keeps working.
A new client does a new thing and t= he new advertisement works.
It does not help to mandate behavior = after the <hello> if the point
is to send a shorter <hello> to only new clients.

=

=
/martin


<= /div>
Andy

--047d7bea44ccaaae2f04f423014b-- From nobody Sun Mar 9 00:36:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0151A0208 for ; Sun, 9 Mar 2014 00:36: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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZLVWMZqFWBY for ; Sun, 9 Mar 2014 00:36:03 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id A2C0A1A0240 for ; Sun, 9 Mar 2014 00:36:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 69ABC54067E; Sun, 9 Mar 2014 09:35:54 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bm1ws9AKZ6+Q; Sun, 9 Mar 2014 09:35:48 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id C61D5540472; Sun, 9 Mar 2014 09:35:47 +0100 (CET) From: Ladislav Lhotka To: "Yi Yang \(yiya\)" In-Reply-To: References: <20140110133016.24678.42711.idtracker@ietfa.amsl.com> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Sun, 09 Mar 2014 09:35:47 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/NgBYUXiOVmlBGottgbBdp_zPE2I Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 08:36:06 -0000 Hi Yi, sorry, I forgot to address your second concern, so here is my reply: "Yi Yang (yiya)" writes: > > Another concern I have is about address family. To facilitate a query > based on AFI only, or SAFI only, it seems more convenient to use two leafs > (AFI and SAFI) instead of one (AFI-SAFI). Due to the properties of YANG identities (derivation), it will be possible to make queries based on either AFI or SAFI, or both. However, this requires two additions that are currently being proposed for YANG 1.1: 1. XPath function derived-from() - see draft-bjorklund-netmod-yang-xpath-extensions-00 2. Multiple inheritance of identities (it is actually a good use case for this feature). For example, the "ipv4-unicast" identity would be defined like so: identity ipv4-unicast { base ipv4; base unicast; } I think identities are much more elegant compared to the two enumeration leafs "afn" and "safi" that we had in older revisions, even though it might currently need some workarounds. Lada > > Yi > > > > > On 1/10/14 8:30 AM, "internet-drafts@ietf.org" > wrote: > >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the NETCONF Data Modeling Language Working >>Group of the IETF. >> >> Title : A YANG Data Model for Routing Management >> Author : Ladislav Lhotka >> Filename : draft-ietf-netmod-routing-cfg-13.txt >> Pages : 95 >> Date : 2014-01-10 >> >>Abstract: >> This document contains a specification of three YANG modules. >> Together they form the core routing data model which serves as a >> framework for configuring and managing a routing subsystem. It is >> expected that these modules will be augmented by additional YANG >> modules defining data models for individual routing protocols and >> other related functions. The core routing data model provides common >> building blocks for such extensions - routing instances, routes, >> routing information bases (RIB), routing protocols and route filters. >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13 >> >>A diff from the previous version is available at: >>http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-routing-cfg-13 >> >> >>Please note that it may take a couple of minutes from the time of >>submission >>until the htmlized version and diff are available at tools.ietf.org. >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>netmod mailing list >>netmod@ietf.org >>https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Mar 9 00:46:48 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C861A0160 for ; Sun, 9 Mar 2014 00:46:47 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWPcnT85zzsT for ; Sun, 9 Mar 2014 00:46:45 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id D82371A011D for ; Sun, 9 Mar 2014 00:46:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 8727654067E; Sun, 9 Mar 2014 09:46:39 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgENNZwZl8pa; Sun, 9 Mar 2014 09:46:34 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id B1DF7540472; Sun, 9 Mar 2014 09:46:34 +0100 (CET) From: Ladislav Lhotka To: Alia Atlas In-Reply-To: References: <20140110133016.24678.42711.idtracker@ietfa.amsl.com> <9C81158E-5B4C-4479-AEA5-23CBCC020ADD@nic.cz> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Sun, 09 Mar 2014 09:46:34 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kzGOmoY2Dji17-AiWzpnuCDF8ZY Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 08:46:47 -0000 Alia Atlas writes: > VRF would fit better in L3VPN. I strongly agree that we need to start > doing therouting-related YANG models in the routing working groups. I do > think that some hand-holding is necessary. Personally, despite having read > the YANG RFC several times and reading YANG models and thinking about > information models, I am still hesitant about trying to write a YANG model > that has the necessary considerations & trade-offs. Absolutely. This issue was discussed at some length during the meeting of YANG Doctors in London, and the conclusion was that a tutorial session held at one of the forthcoming IETF meetings would be useful. Lada > > Alia > > > On Fri, Mar 7, 2014 at 5:29 PM, Ladislav Lhotka wrote: > >> >> On 07 Mar 2014, at 22:52, Yi Yang (yiya) wrote: >> >> > One thing is missing from the data model is association with vrf. >> >> I agree with what Martin wrote in a parallel thread. I believe the routing >> module (and YANG augment statement) provide sufficient hooks for >> implementing VRF as a specific type of routing-instance. >> >> I think though that other work extending the routing module is much more >> needed, namely vendor-neutral data models for routing protocols. >> >> The consensus of the NETMOD WG was that these new modules should be >> developed by experts in the Routing Area (VRF in the MPLS WG?). The NETMOD >> WG and YANG Doctors will certainly help but the bulk of this work should be >> done by domain experts. >> >> Lada >> >> > >> > Another concern I have is about address family. To facilitate a query >> > based on AFI only, or SAFI only, it seems more convenient to use two >> leafs >> > (AFI and SAFI) instead of one (AFI-SAFI). >> > >> > Yi >> > >> > >> > >> > >> > On 1/10/14 8:30 AM, "internet-drafts@ietf.org" > > >> > wrote: >> > >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> >> directories. >> >> This draft is a work item of the NETCONF Data Modeling Language Working >> >> Group of the IETF. >> >> >> >> Title : A YANG Data Model for Routing Management >> >> Author : Ladislav Lhotka >> >> Filename : draft-ietf-netmod-routing-cfg-13.txt >> >> Pages : 95 >> >> Date : 2014-01-10 >> >> >> >> Abstract: >> >> This document contains a specification of three YANG modules. >> >> Together they form the core routing data model which serves as a >> >> framework for configuring and managing a routing subsystem. It is >> >> expected that these modules will be augmented by additional YANG >> >> modules defining data models for individual routing protocols and >> >> other related functions. The core routing data model provides common >> >> building blocks for such extensions - routing instances, routes, >> >> routing information bases (RIB), routing protocols and route filters. >> >> >> >> >> >> The IETF datatracker status page for this draft is: >> >> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ >> >> >> >> There's also a htmlized version available at: >> >> http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13 >> >> >> >> A diff from the previous version is available at: >> >> http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-routing-cfg-13 >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> >> submission >> >> until the htmlized version and diff are available at tools.ietf.org. >> >> >> >> Internet-Drafts are also available by anonymous FTP at: >> >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> >> _______________________________________________ >> >> netmod mailing list >> >> netmod@ietf.org >> >> https://www.ietf.org/mailman/listinfo/netmod >> > >> > _______________________________________________ >> > 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 >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Mar 9 01:48:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875971A0331 for ; Sun, 9 Mar 2014 01:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJgGuqszF0fR for ; Sun, 9 Mar 2014 01:48:43 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 504741A021A for ; Sun, 9 Mar 2014 01:48:43 -0800 (PST) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 50B6337C2C6; Sun, 9 Mar 2014 10:48:37 +0100 (CET) Date: Sun, 09 Mar 2014 10:48:36 +0100 (CET) Message-Id: <20140309.104836.277008943.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140308.202543.115008719.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Jeh_ED-eSFJ3cen37Vksc7O98N0 Cc: netmod@ietf.org Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 09:48:44 -0000 Andy Bierman wrote: > OK -- so we are back to square 1: > > 1) The client should decide which type of advertisement to make, if > possible. > 2) A new client should indicate its version before sending the > 3) A new server must not need to have the client before deciding > > What about a new SSH subsystem? Unfortunatley, this would be a protocol change, and only work for the SSH transport. I still think the solution where the server MAY advertise an "etag" is ok. View this is an optimization that we allow depolyments to enable if all clients speak 1.1. It still might make sense for 1.1 servers that advertise just a small set of modules to do that in the hello, in order to save one round-trip, and avoid keeping state on the client side. /martin From nobody Sun Mar 9 03:35:27 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588531A0359 for ; Sun, 9 Mar 2014 03:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sO_6I_vY-EhS for ; Sun, 9 Mar 2014 03:35:21 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id BAE0C1A0240 for ; Sun, 9 Mar 2014 03:35:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 4708954067E; Sun, 9 Mar 2014 11:35:16 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tY8Q9hp1GcMO; Sun, 9 Mar 2014 11:35:11 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 3DDB4540472; Sun, 9 Mar 2014 11:35:10 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de In-Reply-To: <20140308.194740.485430438.mbj@tail-f.com> References: <20140308.171907.224328665.mbj@tail-f.com> <20140308173950.GB72376@elstar.local> <20140308.194740.485430438.mbj@tail-f.com> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Sun, 09 Mar 2014 11:35:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/J6UfxeU_GVjFWKJ0-k_d4rsTTKA Cc: netmod@ietf.org Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 10:35:24 -0000 Martin Bjorklund writes: > Juergen Schoenwaelder wrote: >> On Sat, Mar 08, 2014 at 09:15:29AM -0800, Andy Bierman wrote: >> >> > So how does a server know if a YANG 1.0 or 1.1 client is going >> > to connect without seeing its message? The server >> > can never send the abbreviated if it wants to continue >> > supporting existing YANG 1.0 applications. Not OK. >> >> In London, I suggested to do translation of 1.1 to 1.0 and hence a >> server could announce 1.0 versions of 1.1 modules to clients that do >> not grok 1.1 format. I got told this is not a good idea... > > It doesn't work b/c the server doesn't know if the client is 1.0, as > you also stated. Also, a translation of 1.1 to 1.0 would not be > correct, and maybe not even possible (e.g., if we allow multiple base > statements in an identity). Yes, I also think the server(s) will have to stick to 1.0 if there is any need for using 1.0 clients. On the other hand, due to the backward compatibility requirements, data models could be a mix of YANG 1.0 and 1.1 modules. BTW, can a YANG 1.1 module be a new revision of a YANG 1.0 module? Lada > >> > In our code, the thin client that is called by OpenSSH >> > is triggered because the client sent a message, >> > so there is no delay. It may not be hard to deliver >> > the client hello in the initial connect message. >> > So no delay or timeout is needed, just some code changes. >> > >> > Are there server implementations that send the hello >> > as soon as the TCP or SSH session is started? >> >> Relying on hello timing is brittle. >> >> In hindsight, we should not have announced the yang modules during the >> and instead mandated implementation of the monitoring data >> model or a separate get-yang-modules RPC. The should really >> have only been used for protocol capabilities, not for announcing data >> models. > > Yes. This is what we want to do now in 1.1. > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Mar 9 04:16:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD5A1A01F9 for ; Sun, 9 Mar 2014 04:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Jre5vIc9e_I for ; Sun, 9 Mar 2014 04:16:02 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD091A01CC for ; Sun, 9 Mar 2014 04:16:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 96D9054067E; Sun, 9 Mar 2014 12:15:56 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O41lsZ2ntEsd; Sun, 9 Mar 2014 12:15:52 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 25525540472; Sun, 9 Mar 2014 12:15:49 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund , andy@yumaworks.com In-Reply-To: <20140308.194426.31476886.mbj@tail-f.com> References: <20140308.171907.224328665.mbj@tail-f.com> <20140308.194426.31476886.mbj@tail-f.com> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Sun, 09 Mar 2014 12:15:50 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_yeNf4QtWLkVS_uP7IYG2DsGojQ Cc: netmod@ietf.org Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 11:16:05 -0000 Martin Bjorklund writes: > Andy Bierman wrote: >> On Sat, Mar 8, 2014 at 8:19 AM, Martin Bjorklund wrote: >> >> > Hi, >> > >> > Even if the server advertises 1.1 modules like today (directly in the >> > hello), the YANG 1.0 client will not be able to load these modules. >> > >> > I think the server has to advertise any YANG 1.0 modules it implements >> > just like today. But 1.1 modules can be advertised using the new >> > caching mechanism. >> > >> > This means that there are cases where a 1.0 client would have >> > continued to work if the 1.1 modules were advertised as before (if it >> > didn't try to download the new revision of the module, but just used >> > its old revision); but with the new caching mechanism it will not >> > work. >> > >> > I think this is a price we have to pay. However, operationally, it >> > should be possible to configure the server to run in "1.0" mode and >> > advertise modules as before. When the operator knows that all his >> > clients have been upgraded, "1.0" legacy mode can be turned off. >> > >> > >> This means implementation of even 1 YANG 1.1 module breaks >> these YANG 1.0 clients, even though they do not even use >> those modules. So they cannot use this feature. > > No, if the server implements module A in YANG 1.0 and B in 1.1, it > would advertise A as usual, and then the new cache-thing for B only. > So the 1.0 client that knows about A still works. Hmm, can this really work? Since module B may augment A, the client would have to be prepared to accept unknown stuff anywhere in a get/get-config reply, RPC reply, or a notification. Or consider this: module A { ... container things-to-do { presence "do something"; leaf watch-birds { type boolean; } } } module B { ... augment "/A:things-to-do" { leaf launch-missiles { type boolean; default true; } } } Then the server would also launch missiles upon receiving edit-config with true I believe both parties must agree upon the complete data model (contract) before proceeding. Lada > >> So how does a server know if a YANG 1.0 or 1.1 client is going >> to connect without seeing its message? > > It will have to be configured to advertise all modules, b/c the > operator knows that there are (or might be) 1.0 clients in his > network. > >> The server >> can never send the abbreviated if it wants to continue >> supporting existing YANG 1.0 applications. Not OK. > > Over time, old clients get upgraded, and all servers can advertise > just the new stuff. I think the benefit of cached module capabilities > is worth this. At least it allows the optimization over time. > > I would say that a 1.1 server MUST either advertise all modules like > before, or advertise the new cache thing (or both). A 1.1 client MUST > be prepared for old-style module advertisement, and the new style. > >> In our code, the thin client that is called by OpenSSH >> is triggered because the client sent a message, >> so there is no delay. It may not be hard to deliver >> the client hello in the initial connect message. >> So no delay or timeout is needed, just some code changes. >> >> Are there server implementations that send the hello >> as soon as the TCP or SSH session is started? > > Yes, since this is the REQUIRED behavior according to 6241 (and > 4741). I know at least two other implementations (in addition to > ours) than does this. > > > /martin > > >> A YANG 1.0 client should be able to continue working >> with the server because it was written to only use >> YANG 1.0 modules, so it is not importing any YANG 1.1 modules. >> >> >> >> >> >> > /martin >> > >> > >> > >> Andy >> >> >> >> > >> > >> > Andy Bierman wrote: >> > > Hi, >> > > >> > > I have been thinking about the integrated feature set for YANG 1.1. >> > > I have not figured out how a YANG 1.0 client connecting >> > > to a YANG 1.1 server is going to continue to work. >> > > I want to support YANG 1.0 and 1.1 clients with the same server. >> > > >> > > The only way I know to do that is have the server delay >> > > its to check the client for the 'capability-id' >> > > URI, as specified in the NETCONF-EX draft. >> > > This is non-trivial to implement, and probably doesn't work in >> > > some situations (Martin does not like it). >> > > >> > > A YANG 1.0 client will look for the "module=foo" parameters >> > > in the server and not find any URIs, and not load >> > > any modules (ietf-netconf-monitoring is optional to implement). >> > > >> > > I think the capabilities defined in the NETCONF-EX draft needs >> > > to be part of the charter to support RESTCONF and YANG 1.1. >> > > >> > > >> > > >> > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Mar 9 05:32:14 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33851A035F for ; Sun, 9 Mar 2014 05:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id re9cOwJFQfu3 for ; Sun, 9 Mar 2014 05:32:08 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id D42771A035B for ; Sun, 9 Mar 2014 05:32:07 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 5432537C2C6; Sun, 9 Mar 2014 13:32:01 +0100 (CET) Date: Sun, 09 Mar 2014 13:32:00 +0100 (CET) Message-Id: <20140309.133200.467983579.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20140308.194426.31476886.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/QnBFC9FOCe4FUqYFA96rVn1n_yg Cc: netmod@ietf.org Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 12:32:10 -0000 Ladislav Lhotka wrote: > Martin Bjorklund writes: > > > Andy Bierman wrote: > >> On Sat, Mar 8, 2014 at 8:19 AM, Martin Bjorklund wrote: > >> > >> > Hi, > >> > > >> > Even if the server advertises 1.1 modules like today (directly in the > >> > hello), the YANG 1.0 client will not be able to load these modules. > >> > > >> > I think the server has to advertise any YANG 1.0 modules it implements > >> > just like today. But 1.1 modules can be advertised using the new > >> > caching mechanism. > >> > > >> > This means that there are cases where a 1.0 client would have > >> > continued to work if the 1.1 modules were advertised as before (if it > >> > didn't try to download the new revision of the module, but just used > >> > its old revision); but with the new caching mechanism it will not > >> > work. > >> > > >> > I think this is a price we have to pay. However, operationally, it > >> > should be possible to configure the server to run in "1.0" mode and > >> > advertise modules as before. When the operator knows that all his > >> > clients have been upgraded, "1.0" legacy mode can be turned off. > >> > > >> > > >> This means implementation of even 1 YANG 1.1 module breaks > >> these YANG 1.0 clients, even though they do not even use > >> those modules. So they cannot use this feature. > > > > No, if the server implements module A in YANG 1.0 and B in 1.1, it > > would advertise A as usual, and then the new cache-thing for B only. > > So the 1.0 client that knows about A still works. > > Hmm, can this really work? Since module B may augment A, the client would have > to be prepared to accept unknown stuff anywhere in a get/get-config reply, RPC > reply, or a notification. > > Or consider this: > > module A { > ... > container things-to-do { > presence "do something"; > leaf watch-birds { > type boolean; > } > } > } > > module B { > ... > augment "/A:things-to-do" { > leaf launch-missiles { > type boolean; > default true; > } > } > } > > Then the server would also launch missiles upon receiving edit-config with > > > true > I'm glad you brought up this real-world example ;) > I believe both parties must agree upon the complete data model (contract) > before proceeding. This is an orthognal issue from YANG 1.0 vs 1.1. It would imply that unless the client understands the semantics of *exact* versions of *all* data models, it would not proceed. I don't think is a workable model. /martin From nobody Sun Mar 9 06:37:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707731A0343 for ; Sun, 9 Mar 2014 06:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMPf4hSEjwAM for ; Sun, 9 Mar 2014 06:37:30 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 572531A011D for ; Sun, 9 Mar 2014 06:37:30 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 5C45E13F7D8; Sun, 9 Mar 2014 14:37:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394372243; bh=9JHkccnhyYQPZ7tPkHTtBi1c82Tkq2KRTw3Gk3CHKpk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Ya3PglCBal7VfjlcmtCvU6EpjDf6+62vw7QIZdDusPROj70gzAeB1rHidOANGaJ1a mg5hFDqRSaec9x2JYn7BNKjNwoDOzkMP6ui1KywL/8MSjq8+ERjI219grf4zd3CR3Q jnnIBCA/ehq7DWaTCG1Rl/ychNkdRnZQ0De8u2Oc= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140309.133200.467983579.mbj@tail-f.com> Date: Sun, 9 Mar 2014 14:37:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3EC30BF5-E7A0-408C-9CB6-41E41970EB15@nic.cz> References: <20140308.194426.31476886.mbj@tail-f.com> <20140309.133200.467983579.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/3kERlr1Kepwkk_-Z6RoPxvYE1Vo Cc: netmod@ietf.org Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 13:37:32 -0000 On 09 Mar 2014, at 13:32, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Martin Bjorklund writes: >>=20 >>> Andy Bierman wrote: >>>> On Sat, Mar 8, 2014 at 8:19 AM, Martin Bjorklund = wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> Even if the server advertises 1.1 modules like today (directly in = the >>>>> hello), the YANG 1.0 client will not be able to load these = modules. >>>>>=20 >>>>> I think the server has to advertise any YANG 1.0 modules it = implements >>>>> just like today. But 1.1 modules can be advertised using the new >>>>> caching mechanism. >>>>>=20 >>>>> This means that there are cases where a 1.0 client would have >>>>> continued to work if the 1.1 modules were advertised as before (if = it >>>>> didn't try to download the new revision of the module, but just = used >>>>> its old revision); but with the new caching mechanism it will not >>>>> work. >>>>>=20 >>>>> I think this is a price we have to pay. However, operationally, = it >>>>> should be possible to configure the server to run in "1.0" mode = and >>>>> advertise modules as before. When the operator knows that all his >>>>> clients have been upgraded, "1.0" legacy mode can be turned off. >>>>>=20 >>>>>=20 >>>> This means implementation of even 1 YANG 1.1 module breaks >>>> these YANG 1.0 clients, even though they do not even use >>>> those modules. So they cannot use this feature. >>>=20 >>> No, if the server implements module A in YANG 1.0 and B in 1.1, it >>> would advertise A as usual, and then the new cache-thing for B only. >>> So the 1.0 client that knows about A still works. >>=20 >> Hmm, can this really work? Since module B may augment A, the client = would have >> to be prepared to accept unknown stuff anywhere in a get/get-config = reply, RPC >> reply, or a notification. >>=20 >> Or consider this: >>=20 >> module A { >> ... >> container things-to-do { >> presence "do something"; >> leaf watch-birds { >> type boolean; >> } >> } >> } >>=20 >> module B { >> ... >> augment "/A:things-to-do" { >> leaf launch-missiles { >> type boolean; >> default true; >> } >> } >> } >>=20 >> Then the server would also launch missiles upon receiving edit-config = with >>=20 >> >> true >> >=20 > I'm glad you brought up this real-world example ;) >=20 >> I believe both parties must agree upon the complete data model = (contract) >> before proceeding. >=20 > This is an orthognal issue from YANG 1.0 vs 1.1. Do you mean that the idea of a client cherry-picking modules is already = in YANG? Where in RFC 6020 is this stated? Actually, sec. 5.6.1 says: The model defines a contract between the NETCONF client and server, which allows both parties to have faith the other knows the syntax and semantics behind the modeled data. The strength of YANG lies in the strength of this contract. My example shows that this would be an illusion if cherry-picking was = allowed (and I can give more examples). It is true that the cherry-picking idea was used as the rationale behind = the CLR that augments must not define mandatory nodes, but I=92ve been = arguing against this several times already.=20 =20 >=20 > It would imply that unless the client understands the semantics of > *exact* versions of *all* data models, it would not proceed. I don't > think is a workable model. But what is a workable model then? The augment statement and XPath are = extremely powerful but this power and flexibility also means that = different modules are not necessarily isolated from each other. Maybe in the beginning we underestimated (I did for sure) the role that = augments and XPath would play in the data models. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Mar 9 06:47:04 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DC31A032A for ; Sun, 9 Mar 2014 06:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53ZPxqOlFCl3 for ; Sun, 9 Mar 2014 06:47:02 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 452501A0207 for ; Sun, 9 Mar 2014 06:47:02 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 2323C37C2C6; Sun, 9 Mar 2014 14:46:56 +0100 (CET) Date: Sun, 09 Mar 2014 14:46:55 +0100 (CET) Message-Id: <20140309.144655.457263402.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <3EC30BF5-E7A0-408C-9CB6-41E41970EB15@nic.cz> References: <20140309.133200.467983579.mbj@tail-f.com> <3EC30BF5-E7A0-408C-9CB6-41E41970EB15@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/pZBFGaMhpBWtYPih1HBcPlzIy2A Cc: netmod@ietf.org Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 13:47:04 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gRG8geW91IG1lYW4gdGhh dCB0aGUgaWRlYSBvZiBhIGNsaWVudCBjaGVycnktcGlja2luZyBtb2R1bGVzIGlzIGFscmVhZHkg aW4NCj4gWUFORz8NCg0KU3VyZS4gIFN1cHBvc2UgSSB3cml0ZSBhIGNsaWVudCB0aGF0IGlzIHVz ZWQgdG8gY29uZmlndXJlIHRoZSBnZW5lcmljDQpwYXJ0cyBvZiBhbiBpbnRlcmZhY2U7IGlldGYt aW50ZXJmYWNlcy55YW5nLiAgVGhpcyBjbGllbnQgZG9lc24ndCBrbm93DQphbnl0aGluZyBlbHNl LiAgQnV0IHRoZSBzZXJ2ZXIgYWR2ZXJ0aXNlcyBhY21lLWV0aGVybmV0LCB3aGljaA0KYXVnbWVu dHMgaWV0Zi1pbnRlcmZhY2VzLiAgVGhlIGNsaWVudCBjb250aW51ZXMgdG8gd29yay4NCg0KPiBX aGVyZSBpbiBSRkMgNjAyMCBpcyB0aGlzIHN0YXRlZD8gQWN0dWFsbHksIHNlYy4gNS42LjEgc2F5 czoNCj4gDQo+ICAgIFRoZSBtb2RlbCBkZWZpbmVzIGEgY29udHJhY3QgYmV0d2VlbiB0aGUgTkVU Q09ORiBjbGllbnQgYW5kIHNlcnZlciwNCj4gICAgd2hpY2ggYWxsb3dzIGJvdGggcGFydGllcyB0 byBoYXZlIGZhaXRoIHRoZSBvdGhlciBrbm93cyB0aGUgc3ludGF4DQo+ICAgIGFuZCBzZW1hbnRp Y3MgYmVoaW5kIHRoZSBtb2RlbGVkIGRhdGEuICBUaGUgc3RyZW5ndGggb2YgWUFORyBsaWVzIGlu DQo+ICAgIHRoZSBzdHJlbmd0aCBvZiB0aGlzIGNvbnRyYWN0Lg0KPiANCj4gTXkgZXhhbXBsZSBz aG93cyB0aGF0IHRoaXMgd291bGQgYmUgYW4gaWxsdXNpb24gaWYgY2hlcnJ5LXBpY2tpbmcgd2Fz IGFsbG93ZWQNCj4gKGFuZCBJIGNhbiBnaXZlIG1vcmUgZXhhbXBsZXMpLg0KPiANCj4gSXQgaXMg dHJ1ZSB0aGF0IHRoZSBjaGVycnktcGlja2luZyBpZGVhIHdhcyB1c2VkIGFzIHRoZSByYXRpb25h bGUgYmVoaW5kIHRoZQ0KPiBDTFIgdGhhdCBhdWdtZW50cyBtdXN0IG5vdCBkZWZpbmUgbWFuZGF0 b3J5IG5vZGVzLCBidXQgSeKAmXZlIGJlZW4gYXJndWluZw0KPiBhZ2FpbnN0IHRoaXMgc2V2ZXJh bCB0aW1lcyBhbHJlYWR5Lg0KDQpJdCBqdXN0IG1lYW5zIHRoYXQgdGhlIGRlc2lnbiBvZiBhbiBh dWdtZW50aW5nIG1vZHVsZSBtdXN0IGJlIGRvbmUNCmNhcmVmdWxseS4gIEZpcnN0LCBmb2xsb3cg dGhlIG1lY2hhbmljYWwgcnVsZXMgKG5vdCBhbGxvd2VkIHRvDQphdWdtZW50KS4gIFRoZW4gbWFr ZSBzdXJlIHRoYXQgbm8gbWlzc2lsZXMgYXJlIGxhdW5jaGVkIGJ5IG1pc3Rha2UgZHVlDQp0byB0 aGUgZGVzaWduIG9mIHRoZSBtb2RlbCA6KQ0KDQoNCi9tYXJ0aW4NCg0KDQoNCj4gIA0KPiA+IA0K PiA+IEl0IHdvdWxkIGltcGx5IHRoYXQgdW5sZXNzIHRoZSBjbGllbnQgdW5kZXJzdGFuZHMgdGhl IHNlbWFudGljcyBvZg0KPiA+ICpleGFjdCogdmVyc2lvbnMgb2YgKmFsbCogZGF0YSBtb2RlbHMs IGl0IHdvdWxkIG5vdCBwcm9jZWVkLiAgSSBkb24ndA0KPiA+IHRoaW5rIGlzIGEgd29ya2FibGUg bW9kZWwuDQo+IA0KPiBCdXQgd2hhdCBpcyBhIHdvcmthYmxlIG1vZGVsIHRoZW4/IFRoZSBhdWdt ZW50IHN0YXRlbWVudCBhbmQgWFBhdGggYXJlDQo+IGV4dHJlbWVseSBwb3dlcmZ1bCBidXQgdGhp cyBwb3dlciBhbmQgZmxleGliaWxpdHkgYWxzbyBtZWFucyB0aGF0IGRpZmZlcmVudA0KPiBtb2R1 bGVzIGFyZSBub3QgbmVjZXNzYXJpbHkgaXNvbGF0ZWQgZnJvbSBlYWNoIG90aGVyLg0KPiANCj4g TWF5YmUgaW4gdGhlIGJlZ2lubmluZyB3ZSB1bmRlcmVzdGltYXRlZCAoSSBkaWQgZm9yIHN1cmUp IHRoZSByb2xlIHRoYXQNCj4gYXVnbWVudHMgYW5kIFhQYXRoIHdvdWxkIHBsYXkgaW4gdGhlIGRh dGEgbW9kZWxzLg0KPiANCj4gTGFkYQ0KPiANCj4gPiANCj4gPiANCj4gPiAvbWFydGluDQo+IA0K PiAtLQ0KPiBMYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+IFBHUCBLZXkgSUQ6IEU3NEU4 QzBDDQo+IA0KPiANCj4gDQo+IA0K From nobody Sun Mar 9 07:02:02 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F101A0207 for ; Sun, 9 Mar 2014 07:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BYbfwphBAEQ for ; Sun, 9 Mar 2014 07:01:59 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1830D1A0204 for ; Sun, 9 Mar 2014 07:01:58 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C73EA13F7D8; Sun, 9 Mar 2014 15:01:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394373712; bh=LStWIDvJNg0wO+vt1pRPc+k/1EPk/OnZwGVj7yViIn4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Zc5lTmbZHfzyOXyQu2VbetVVyASrGw1Z/I3WkLrfs7oVeb2FNpOy0Yg0LDUx14yJ2 6e3fUHRggzKtkBrDXZ9Lte2j8/6DI7O2rz+geG05QCdHFoHi0GhSL8jN/eKp8lGXjI kBqLf8QK1Az8vLTdZyMNtoruvq7+QzH9bSNIeHHo= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140309.144655.457263402.mbj@tail-f.com> Date: Sun, 9 Mar 2014 15:01:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <527CF187-0AE2-4328-A79F-BE1C7DD7E4E5@nic.cz> References: <20140309.133200.467983579.mbj@tail-f.com> <3EC30BF5-E7A0-408C-9CB6-41E41970EB15@nic.cz> <20140309.144655.457263402.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/UqsysvexhcPG2zZ5q7rasubhK_Q Cc: netmod@ietf.org Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 14:02:00 -0000 On 09 Mar 2014, at 14:46, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Do you mean that the idea of a client cherry-picking modules is = already in >> YANG? >=20 > Sure. Suppose I write a client that is used to configure the generic > parts of an interface; ietf-interfaces.yang. This client doesn't know > anything else. But the server advertises acme-ethernet, which > augments ietf-interfaces. The client continues to work. Or maybe not, see my example. The CLR about mandatory stuff in augments = is terribly insufficient. I don=92t see any statement in 6020 saying that the client is free to = ignore parts of the data model as advertised in server=92s hello. >=20 >> Where in RFC 6020 is this stated? Actually, sec. 5.6.1 says: >>=20 >> The model defines a contract between the NETCONF client and server, >> which allows both parties to have faith the other knows the syntax >> and semantics behind the modeled data. The strength of YANG lies = in >> the strength of this contract. >>=20 >> My example shows that this would be an illusion if cherry-picking was = allowed >> (and I can give more examples). >>=20 >> It is true that the cherry-picking idea was used as the rationale = behind the >> CLR that augments must not define mandatory nodes, but I=92ve been = arguing >> against this several times already. >=20 > It just means that the design of an augmenting module must be done > carefully. First, follow the mechanical rules (not allowed to > augment). Then make sure that no missiles are launched by mistake due > to the design of the model :) You can take care about this if you are developing a data model for a = particular customer. However, if we envision many modules being = developed by independent parties, we must make sure that different = contributions play together well. Of course, my example is an extreme = case, there can be other, more subtle, side effects. Lada >=20 >=20 > /martin >=20 >=20 >=20 >>=20 >>>=20 >>> It would imply that unless the client understands the semantics of >>> *exact* versions of *all* data models, it would not proceed. I = don't >>> think is a workable model. >>=20 >> But what is a workable model then? The augment statement and XPath = are >> extremely powerful but this power and flexibility also means that = different >> modules are not necessarily isolated from each other. >>=20 >> Maybe in the beginning we underestimated (I did for sure) the role = that >> augments and XPath would play in the data models. >>=20 >> Lada >>=20 >>>=20 >>>=20 >>> /martin >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Mar 9 07:52:41 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081FA1A0361 for ; Sun, 9 Mar 2014 07:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZ7MwAf6dSHp for ; Sun, 9 Mar 2014 07:52:38 -0700 (PDT) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3990B1A01AD for ; Sun, 9 Mar 2014 07:52:38 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id j5so6021605qaq.0 for ; Sun, 09 Mar 2014 07:52:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jOwAFb2to66P8ic5Vf8ul9G9iAoXRD9vlJy1k/Y151w=; b=UkygDdl1AdpbpDq0l80YJP9YaRYeI+UkAC9V7TM8ROefvqQyQ89bg4KsaBXDMehiUg PA38P9liE7hvbXezz63iMMf7SvkpbdLSZHIaCqCRFgOEQKIdr5a8R4wQ3Qa1F6WqrfG2 kSSNMnQES7Rk5/7+XoZD554QDghNtLChbkO0tdZa5ABwZ6KkGZxbGVckkPMzMOB1uldv GNeKi3kIqnv4KpqnLlCaBURC2njVwmEoOHJzq/OiJiHngydeuu0R7INczb+I//VXkokp HboaSYCnm6strx1fRC2i6Rm5Kw76Lt4D1Og2LRyeelUglgS+IInOzt2ZDJlmDvkjUua3 HxIg== X-Gm-Message-State: ALoCoQlUyXHRNf5CBGPBRCLHUJej3R6lap0gghobBC2B1NkCIBKJMchFOONjcmtdSnOF7+K3w/lf MIME-Version: 1.0 X-Received: by 10.224.36.129 with SMTP id t1mr1969041qad.88.1394376752862; Sun, 09 Mar 2014 07:52:32 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Sun, 9 Mar 2014 07:52:32 -0700 (PDT) In-Reply-To: <20140309.104836.277008943.mbj@tail-f.com> References: <20140308.202543.115008719.mbj@tail-f.com> <20140309.104836.277008943.mbj@tail-f.com> Date: Sun, 9 Mar 2014 07:52:32 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=089e0158a9e409e29904f42da3f2 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qgkQUgR3QORM1hWME2hZyEz25yg Cc: "netmod@ietf.org" Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 14:52:40 -0000 --089e0158a9e409e29904f42da3f2 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 9, 2014 at 1:48 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > OK -- so we are back to square 1: > > > > 1) The client should decide which type of advertisement to make, if > > possible. > > 2) A new client should indicate its version before sending the > > 3) A new server must not need to have the client before deciding > > > > What about a new SSH subsystem? > > Unfortunatley, this would be a protocol change, and only work for the > SSH transport. > > I still think the solution where the server MAY advertise an "etag" is > ok. View this is an optimization that we allow depolyments to enable > if all clients speak 1.1. > > It still might make sense for 1.1 servers that advertise just a small > set of modules to do that in the hello, in order to save one > round-trip, and avoid keeping state on the client side. > > Hi, I do not think this is a workable plan. Too many requirements and too little gain. This feature should be left out of YANG 1.1. The old advertisement scheme should be used without any changes at all. > > /martin > Andy --089e0158a9e409e29904f42da3f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Mar 9, 2014 at 1:48 AM, Martin Bjorklund = <mbj@tail-f.com&= gt; wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> OK -- so we are back to square 1:
>
> =A01) The client should decide which type of advertisement to make, if=
> possible.
> =A02) A new client should indicate its version before sending the <= hello>
> =A03) A new server must not need to have the client <hello> befo= re deciding
>
> What about a new SSH subsystem?

Unfortunatley, this would be a protocol change, and only work for the
SSH transport.

I still think the solution where the server MAY advertise an "etag&quo= t; is
ok. =A0View this is an optimization that we allow depolyments to enable
if all clients speak 1.1.

It still might make sense for 1.1 servers that advertise just a small
set of modules to do that in the hello, in order to save one
round-trip, and avoid keeping state on the client side.


Hi,

I do not think this is = a workable plan.
Too many requirements and too little gain.
This feature should be left out of YANG 1.1.
The old adverti= sement scheme should be used
without any changes at all.

=A0

/martin

Andy<= /div>

--089e0158a9e409e29904f42da3f2-- From nobody Sun Mar 9 08:11:30 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893FF1A0264 for ; Sun, 9 Mar 2014 08:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paIZJ1gSRbra for ; Sun, 9 Mar 2014 08:11:23 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id E7EAF1A0268 for ; Sun, 9 Mar 2014 08:11:22 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id A7C6C37C2C6; Sun, 9 Mar 2014 16:11:16 +0100 (CET) Date: Sun, 09 Mar 2014 16:11:15 +0100 (CET) Message-Id: <20140309.161115.323245671.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <527CF187-0AE2-4328-A79F-BE1C7DD7E4E5@nic.cz> References: <3EC30BF5-E7A0-408C-9CB6-41E41970EB15@nic.cz> <20140309.144655.457263402.mbj@tail-f.com> <527CF187-0AE2-4328-A79F-BE1C7DD7E4E5@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Qw01EwnNxuRg8I1MwzvYCPL5xEk Cc: netmod@ietf.org Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 15:11:28 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gSSBkb27igJl0IHNlZSBh bnkgc3RhdGVtZW50IGluIDYwMjAgc2F5aW5nIHRoYXQgdGhlIGNsaWVudCBpcyBmcmVlIHRvIGln bm9yZQ0KPiBwYXJ0cyBvZiB0aGUgZGF0YSBtb2RlbCBhcyBhZHZlcnRpc2VkIGluIHNlcnZlcuKA mXMgaGVsbG8uDQoNClRoZSBzZXJ2ZXIgdGVsbHMgdGhlIGNsaWVudCB3aGF0IGl0IGltcGxlbWVu dHMsIHRoZSBjbGllbnQgZG9lcw0Kd2hhdGV2ZXIgaXQgd2FudHMgd2l0aCB0aGlzIGluZm9ybWF0 aW9uLg0KDQpIb3cgZXhhY3RseSB3b3VsZCBzdWNoIGEgcmVxdWlyZW1lbnQgYmUgcGhyYXNlZD8g IEhvdyB3b3VsZCBpdCBiZQ0KZW5mb3JjZWQgb3IgZXZlbiB0ZXN0ZWQ/DQoNCg0KL21hcnRpbg0K From nobody Sun Mar 9 08:18:17 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD7D1A0368 for ; Sun, 9 Mar 2014 08:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPG9WI74Hi1z for ; Sun, 9 Mar 2014 08:18:07 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id B34321A0265 for ; Sun, 9 Mar 2014 08:18:07 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 5DA6737C2C6; Sun, 9 Mar 2014 16:18:02 +0100 (CET) Date: Sun, 09 Mar 2014 16:18:01 +0100 (CET) Message-Id: <20140309.161801.325149710.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140309.104836.277008943.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/TMfKxSjJMRt54fPEOc35HTxlL3o Cc: netmod@ietf.org Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 15:18:09 -0000 Andy Bierman wrote: > On Sun, Mar 9, 2014 at 1:48 AM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > OK -- so we are back to square 1: > > > > > > 1) The client should decide which type of advertisement to make, if > > > possible. > > > 2) A new client should indicate its version before sending the > > > 3) A new server must not need to have the client before deciding > > > > > > What about a new SSH subsystem? > > > > Unfortunatley, this would be a protocol change, and only work for the > > SSH transport. > > > > I still think the solution where the server MAY advertise an "etag" is > > ok. View this is an optimization that we allow depolyments to enable > > if all clients speak 1.1. > > > > It still might make sense for 1.1 servers that advertise just a small > > set of modules to do that in the hello, in order to save one > > round-trip, and avoid keeping state on the client side. > > > > > Hi, > > I do not think this is a workable plan. Why doesn't this work? In environments with mixed 1.0 and 1.1 clients, the optimization can be disabled. In environments with only standard-compliant 1.1 clients, the optimization can be enabled. > Too many requirements and too little gain. One requirement: a 1.1 server MAY send the "etag", and thus a 1.1 client must be prepared to handle it. > This feature should be left out of YANG 1.1. > The old advertisement scheme should be used > without any changes at all. If we don't take the opportunity to specify this now, it won't happen - unless we do YANG 1.2 or 2.0; and at that point we'll have the same discussion again. It would be interesting to hear what others think. /martin From nobody Sun Mar 9 08:35:14 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E251A0278 for ; Sun, 9 Mar 2014 08:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuZJA8IEQEh1 for ; Sun, 9 Mar 2014 08:35:10 -0700 (PDT) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCE71A0268 for ; Sun, 9 Mar 2014 08:35:09 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id j5so6059560qaq.14 for ; Sun, 09 Mar 2014 08:35:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gLD0GOs3UuQPLIT7I3oWT6IyYHligOcwaQw3MYKIEm0=; b=bpw05yeOXVhVz94RDtI2RgE4oCpSq8mH+XTwTd5+dVUnbwmRaapR/FfVaBhAVpAxUw yRVTqVfw8r2/aw67xi8QyAXJBAfxaCEXJ9UDqeGsDLehQ1n7Hk0yuKOcQ/7Uny3mgfKx jCSocmYzwKk5ZDgmXbSGayafHePhPQxJbqhXh7zK6lIP0IqQaPuCJOG1FnavLqE2+MZq YnR6vnb/bT/48zBFu0cw6eTNKFtNlByIDDyRT5wd++6YmajbZGfve5WxDuSNzNMIyEQh MIzGSvCXJEnl7SoQeicMDWUbky9AiKyVVX2NK4Cw1dhk4yB+H9W9vmwbqoHsyGeLB9xe JStg== X-Gm-Message-State: ALoCoQnKuKewnZQZTKSmrBfQWVXskVvcMBi5eOSFJ7RQH3oziHs+BBsfpLg9i7QxS80M3Y4G0uWO MIME-Version: 1.0 X-Received: by 10.140.92.6 with SMTP id a6mr4917070qge.34.1394379304651; Sun, 09 Mar 2014 08:35:04 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Sun, 9 Mar 2014 08:35:04 -0700 (PDT) In-Reply-To: <20140309.161115.323245671.mbj@tail-f.com> References: <3EC30BF5-E7A0-408C-9CB6-41E41970EB15@nic.cz> <20140309.144655.457263402.mbj@tail-f.com> <527CF187-0AE2-4328-A79F-BE1C7DD7E4E5@nic.cz> <20140309.161115.323245671.mbj@tail-f.com> Date: Sun, 9 Mar 2014 08:35:04 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a1139a9702314b904f42e3bfb Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/G7t3LPOIEaFm3TWy4XRNlfKfMK4 Cc: "netmod@ietf.org" Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 15:35:12 -0000 --001a1139a9702314b904f42e3bfb Content-Type: text/plain; charset=ISO-8859-1 Hi, On Sun, Mar 9, 2014 at 8:11 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > I don't see any statement in 6020 saying that the client is free to > ignore > > parts of the data model as advertised in server's hello. > > The server tells the client what it implements, the client does > whatever it wants with this information. > > I think you are right. If the client builds the server schema tree from the import statements of the modules it cares about, then the import chain will never hit the new YANG 1.1 module that is augmenting the old data structure. This is how import-by-revision allows different versions of the same imported module to be used by multiple importing modules. In addition, the client can skip modules that fail to compile when the server modules are processed. It won't have he new schema nodes for sending requests. Any replies with these unknown nodes get parsed as 'anyxml' instead of the real schema. (This is how our client code works today.) How exactly would such a requirement be phrased? How would it be > enforced or even tested? > > > > /martin > Andy --001a1139a9702314b904f42e3bfb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,



On Sun, Mar 9, 2014 at 8:11 AM, Marti= n Bjorklund <mbj@tail-f.com> wrote:
Ladislav Lhotka <lhotk= a@nic.cz> wrote:
> I don’t see any statement in 6020 saying that the client is free= to ignore
> parts of the data model as advertised in server’s hello.

The server tells the client what it implements, the client does
whatever it wants with this information.


I think you are right.
If th= e client builds the server schema tree from the import statements
of the modules it cares about, then the import chain will never hit the ne= w
YANG 1.1 module that is augmenting the old data structure. This is how=
import-by-revision allows different versions of the same importe= d
module to be used by multiple importing modules.

In addition, the client can skip modul= es that fail to compile
when the server <= ;hello> modules are processed.  It won't have he new
schema nodes for sending requests.  Any replies with these
unknown nodes get parsed as 'anyxml' instead o= f the real schema.
(This is how our client = code works today.)


How exactly would such a requirement be phrased?  How would it be
enforced or even tested?


 

/martin


Andy
=
--001a1139a9702314b904f42e3bfb-- From nobody Sun Mar 9 08:54:04 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3CA1A0278 for ; Sun, 9 Mar 2014 08:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srFsLeVgti6J for ; Sun, 9 Mar 2014 08:54:02 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 380AA1A0268 for ; Sun, 9 Mar 2014 08:54:02 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 721FC13F7D8; Sun, 9 Mar 2014 16:53:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394380436; bh=LH6IhkwbqE+zPKD871h+ONkNdt9jB1fiF+RzFCCkzag=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=eM9rCUVx2xwwWbzgwAvV4olHYvfSPT3N00aU8QfjxIdWEqkiDYi/5KFuSsLIEs6op u+GRMXBd3sstmLCE1Ta9Le4jP468l8WNqx/vHqSq3NIBAIg1XlPa+auELvZVMb86Je FgRcoWTjcG0z2KKYX8SsQwwhIulXLrl3bBTtTsd0= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140309.161115.323245671.mbj@tail-f.com> Date: Sun, 9 Mar 2014 16:53:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <95285163-18D4-460D-9A25-8E0739979F08@nic.cz> References: <3EC30BF5-E7A0-408C-9CB6-41E41970EB15@nic.cz> <20140309.144655.457263402.mbj@tail-f.com> <527CF187-0AE2-4328-A79F-BE1C7DD7E4E5@nic.cz> <20140309.161115.323245671.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rzITayqgUIAImgxRQLaoDjt-A-Y Cc: netmod@ietf.org Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 15:54:03 -0000 On 09 Mar 2014, at 16:11, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> I don=92t see any statement in 6020 saying that the client is free to = ignore >> parts of the data model as advertised in server=92s hello. >=20 > The server tells the client what it implements, the client does > whatever it wants with this information. >=20 > How exactly would such a requirement be phrased? How would it be > enforced or even tested? What I meant was =93=85 that it is safe for the client to ignore parts = =85=94. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Mar 9 09:02:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0016B1A0367 for ; Sun, 9 Mar 2014 09:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1xL1K8NKb9r for ; Sun, 9 Mar 2014 09:02:30 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id BFAD31A0360 for ; Sun, 9 Mar 2014 09:02:30 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 4139A14017A; Sun, 9 Mar 2014 17:02:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394380945; bh=tMXSzUuYWuyaom1UXTfdR0PCS1PkJ7rdueXQAnVPJt4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=r1W7MNurqMuKSf7f8Z2H5xmovqfRWu1YQbmrTayVsJlYV1cBsfJ0wA0yRp2iCdD8S yhS3KbvyS+Qf2hYIJXScmWK+kjJwh2s0+FDIR2IV73wwq2oD19X7pvymGOIj9r8TgQ gbPoR9mLobMxICRtuJ4uUhWZFPN7O0OP/cmqTNzU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Sun, 9 Mar 2014 17:02:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3EC30BF5-E7A0-408C-9CB6-41E41970EB15@nic.cz> <20140309.144655.457263402.mbj@tail-f.com> <527CF187-0AE2-4328-A79F-BE1C7DD7E4E5@nic.cz> <20140309.161115.323245671.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/uAdwGXZysgvP79EQTkYY6U0YmBo Cc: "netmod@ietf.org" Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 16:02:32 -0000 On 09 Mar 2014, at 16:35, Andy Bierman wrote: > Hi, >=20 >=20 >=20 > On Sun, Mar 9, 2014 at 8:11 AM, Martin Bjorklund = wrote: > Ladislav Lhotka wrote: > > I don=92t see any statement in 6020 saying that the client is free = to ignore > > parts of the data model as advertised in server=92s hello. >=20 > The server tells the client what it implements, the client does > whatever it wants with this information. >=20 >=20 > I think you are right. > If the client builds the server schema tree from the import statements > of the modules it cares about, then the import chain will never hit = the new > YANG 1.1 module that is augmenting the old data structure. This is how > import-by-revision allows different versions of the same imported > module to be used by multiple importing modules. >=20 > In addition, the client can skip modules that fail to compile > when the server modules are processed. It won't have he new > schema nodes for sending requests. Any replies with these > unknown nodes get parsed as 'anyxml' instead of the real schema. > (This is how our client code works today.) My point is that the skipped modules may change semantics of the = remaining modules. So the client should not be surprised by error = conditions or unexpected behaviour of the server. Lada >=20 >=20 > How exactly would such a requirement be phrased? How would it be > enforced or even tested? >=20 >=20 > =20 >=20 > /martin >=20 >=20 > Andy >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 10 09:30:27 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BF51A04B6 for ; Mon, 10 Mar 2014 09:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETwZXBBA5NLu for ; Mon, 10 Mar 2014 09:30:23 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACFE1A0496 for ; Mon, 10 Mar 2014 09:30:23 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5DD26EB2; Mon, 10 Mar 2014 17:30:17 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id yQsHy2FDACAY; Mon, 10 Mar 2014 17:30:16 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 10 Mar 2014 17:30:16 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id AD1FD2002F; Mon, 10 Mar 2014 17:30:16 +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 KUpU0pCG5Zgl; Mon, 10 Mar 2014 17:30:15 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 19ECA2002C; Mon, 10 Mar 2014 17:30:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 723DF2BAED83; Mon, 10 Mar 2014 17:30:12 +0100 (CET) Date: Mon, 10 Mar 2014 17:30:11 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140310163011.GA76540@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org References: <20140309.104836.277008943.mbj@tail-f.com> <20140309.161801.325149710.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140309.161801.325149710.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/NUXp2kVCYdvd-VhsOBQd5fgYuiI Cc: netmod@ietf.org Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 10 Mar 2014 16:30:26 -0000 On Sun, Mar 09, 2014 at 04:18:01PM +0100, Martin Bjorklund wrote: > > If we don't take the opportunity to specify this now, it won't happen > - unless we do YANG 1.2 or 2.0; and at that point we'll have the same > discussion again. > > It would be interesting to hear what others think. > I think I do not really understand the various options yet. One option could be that YANG 1.1 modules won't be announced anymore during the ; YANG 1.1 clients are expected to pick modules them from the monitoring data model. There could also be an etag like mechanism so that I can safely cache knowledge of available YANG 1.1 modules. Over time, the list of announced data models announced in the hello will get shorter. (A different issue is an etag like mechanism for the config state itself.) The unanswered question seems to be whether the server can learn that it is talking to a client supporting YANG 1.1 before the or whether this is needed to support. But I am likely missing part of the discussion. Perhaps we need to break this into separate issues so we can track things more easily? /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 Mar 10 11:56:35 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1691A03FC for ; Mon, 10 Mar 2014 11:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3ddarlZxthJ for ; Mon, 10 Mar 2014 11:56:33 -0700 (PDT) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id E294C1A036F for ; Mon, 10 Mar 2014 11:56:32 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id w8so7313237qac.41 for ; Mon, 10 Mar 2014 11:56:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=9oBDe9YsrQcutvcc+1soedoVT5fZz/IjqWSFr33A6+E=; b=PAa9YmWmMqT8W9yMK55vvV9k9ij3+T/uwuwCSa8ZDNRI6dnneu2YyzT/fQQeSlJKmw Yrmg865joLpqlnJXTszhmwsUShUrFsOYSRhCcljKhceWeH/YN1I8vQTpL8Ihuuz2NC+h rm88isinsgnSBsAENqJDcaychksTkPHp63nk4gAIFsH+q/By7djgFobQFLoPjbD7QEiv 56yX13yQvBoIesVME9m2C2tZzNDBU97Iz2ppWs/WOh/ms+dFR+eSakf1hx/hnvLlPvTG ED9GNJOcDIqVADONliUMPM9sHhB0WQGXQVfH5YF5Q3NcNKc2uNol+Ms4xKLYDxphLtMN 0mWA== X-Gm-Message-State: ALoCoQkGkIGee13jeP25tTqCLPiAyMQ/nxbKT7oWSIinviWaGxwM+JuXmyT/djC4TQ+ufybtqQN8 MIME-Version: 1.0 X-Received: by 10.140.92.6 with SMTP id a6mr12228116qge.34.1394477787176; Mon, 10 Mar 2014 11:56:27 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Mon, 10 Mar 2014 11:56:27 -0700 (PDT) In-Reply-To: <20140310163011.GA76540@elstar.local> References: <20140309.104836.277008943.mbj@tail-f.com> <20140309.161801.325149710.mbj@tail-f.com> <20140310163011.GA76540@elstar.local> Date: Mon, 10 Mar 2014 11:56:27 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Martin Bjorklund , Andy Bierman , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a1139a97027280104f4452992 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6bdGnIWVxRouGkzjWpYYSVcHR5g Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 18:56:35 -0000 --001a1139a97027280104f4452992 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 10, 2014 at 9:30 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Sun, Mar 09, 2014 at 04:18:01PM +0100, Martin Bjorklund wrote: > > > > If we don't take the opportunity to specify this now, it won't happen > > - unless we do YANG 1.2 or 2.0; and at that point we'll have the same > > discussion again. > > > > It would be interesting to hear what others think. > > > > I think I do not really understand the various options yet. One option > could be that YANG 1.1 modules won't be announced anymore during the > ; YANG 1.1 clients are expected to pick modules them from the > monitoring data model. There could also be an etag like mechanism so > that I can safely cache knowledge of available YANG 1.1 modules. Over > time, the list of announced data models announced in the hello will > get shorter. (A different issue is an etag like mechanism for the > config state itself.) > > The unanswered question seems to be whether the server can learn that > it is talking to a client supporting YANG 1.1 before the or > whether this is needed to support. > > But I am likely missing part of the discussion. Perhaps we need to > break this into separate issues so we can track things more easily? > > Here is some sort of list: - Big picture: how to support YANG 1.0 and 1.1 clients with the same server - A capability cache is for new clients only. An entity tag for the set of YANG module capabilities is advertised by the server somehow. - An abbreviated does not have any YANG module URIs. They are replaced with 1 capability-id URI with the current ETag value. - The client is not relevant since the server is not supposed to wait before sending its own . - The server has to be configured to either always send the full or always send the abbreviated . An operator must configure the full if any 1.0 applications are in use. Issues: - For new clients, the capability-id is matched to its own cached value. If no match, then the client has to get the capabilities somehow (A, B, ?) - A: make ietf-monitoring "schema" data subtree mandatory to implement and the client will retrieve it - B: introduce a new mandatory-to-implement RPC like "get-module-capabilities". - Is there any concern that YANG 1.0 applications cannot be upgraded quickly? If not, then this plan is OK. Not related to YANG capability caching: - Is there any concern about mixing YANG 1.0 and 1.1 modules in the same server? Will 1.0 clients be able to ignore new data augmenting old data? /js > Andy --001a1139a97027280104f4452992 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 10, 2014 at 9:30 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sun, Mar 09, 2014 at 04:18:01PM +0100, Martin Bjorklund= wrote:
>
> If we don't take the opportunity to specify this now, it won't= happen
> - unless we do YANG 1.2 or 2.0; and at that point we'll have the s= ame
> discussion again.
>
> It would be interesting to hear what others think.
>

I think I do not really understand the various options yet. One option
could be that YANG 1.1 modules won't be announced anymore during the <hello>; YANG 1.1 clients are expected to pick modules them from the<= br> monitoring data model. There could also be an etag like mechanism so
that I can safely cache knowledge of available YANG 1.1 modules. Over
time, the list of announced data models announced in the hello will
get shorter. (A different issue is an etag like mechanism for the
config state itself.)

The unanswered question seems to be whether the server can learn that
it is talking to a client supporting YANG 1.1 before the <hello> or whether this is needed to support.

But I am likely missing part of the discussion. Perhaps we need to
break this into separate issues so we can track things more easily?


Here is some sort of list:

=A0 = =A0- Big picture: how to support YANG 1.0 and 1.1 clients with the same ser= ver

=A0 =A0 =A0 =A0- A capability cache is for new clients = only. =A0An entity tag for the set of
=A0 =A0 =A0 =A0 =A0YANG mod= ule capabilities is advertised by the server somehow.

<= div>=A0 =A0 =A0 =A0- An abbreviated <hello> does not have any YANG mo= dule URIs.
=A0 =A0 =A0 =A0 They are replaced with 1 capability-id URI with the cu= rrent ETag value.

=A0 =A0 =A0 =A0- The client <= hello> is not relevant since the server is not
=A0 =A0 =A0 =A0= =A0supposed to wait before sending its own <hello>.

=A0 =A0 =A0 - =A0The server has to be configured to eit= her always send the full <hello>
=A0 =A0 =A0 =A0 =A0or alwa= ys send the abbreviated <hello>. =A0An operator must configure
<= div>=A0 =A0 =A0 =A0 =A0the full <hello> if any 1.0 applications are i= n use.

Issues:

=A0- For new clients, = the capability-id is matched to its own cached value.
=A0 =A0If n= o match, then the client has to get the capabilities somehow (A, B, ?)
=A0 =A0 =A0 - A: make ietf-monitoring "schema" data subtree manda= tory to implement
=A0 =A0 =A0 =A0 and the client will retrieve it=
=A0 =A0 =A0 - B: introduce a new mandatory-to-implement RPC like= "get-module-capabilities".

=A0- Is there any concern that YANG 1.0 applications ca= nnot be upgraded quickly?
=A0 =A0If not, then this plan is OK.


Not related to YANG capability cachin= g:

=A0- Is there any concern about mixing YANG 1.0 and 1.1= modules in the same server?
=A0 =A0Will 1.0 clients be able to i= gnore new data augmenting old data?



/js

Andy

--001a1139a97027280104f4452992-- From nobody Mon Mar 10 14:07:35 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFCFF1A063C for ; Mon, 10 Mar 2014 14:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bzHvWB526if for ; Mon, 10 Mar 2014 14:07:21 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id D08AC1A050E for ; Mon, 10 Mar 2014 14:07:20 -0700 (PDT) Received: from mail65-va3-R.bigfish.com (10.7.14.234) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.22; Mon, 10 Mar 2014 21:07:14 +0000 Received: from mail65-va3 (localhost [127.0.0.1]) by mail65-va3-R.bigfish.com (Postfix) with ESMTP id D9DB92201E6; Mon, 10 Mar 2014 21:07:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz168aJdbf2izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1033IL17326ah8275dh1de097h186068h1d68dehz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h1155h) Received-SPF: pass (mail65-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(57704003)(63696002)(46102001)(69226001)(81542001)(92726001)(74502001)(65816001)(76786001)(31966008)(53806001)(15975445006)(47976001)(77982001)(59766001)(76796001)(54356001)(74662001)(36756003)(81342001)(79102001)(92566001)(74876001)(81816001)(95416001)(81686001)(47736001)(80976001)(66066001)(50986001)(76482001)(47446002)(54316002)(94946001)(49866001)(4396001)(19273905006)(56776001)(94316002)(80022001)(93136001)(74366001)(15202345003)(51856001)(19580395003)(93516002)(83322001)(2656002)(83072002)(85852003)(85306002)(86362001)(90146001)(87266001)(97186001)(83506001)(97336001)(74706001)(56816005)(77096001)(87936001)(95666003)(563064011); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB769; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.13; FPR:ACCBCB79.99F04FDB.1FDAD7B.88A693F9.2020E; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail65-va3 (localhost.localdomain [127.0.0.1]) by mail65-va3 (MessageSwitch) id 139448563283590_14423; Mon, 10 Mar 2014 21:07:12 +0000 (UTC) Received: from VA3EHSMHS005.bigfish.com (unknown [10.7.14.248]) by mail65-va3.bigfish.com (Postfix) with ESMTP id 8FD9D3C004E; Mon, 10 Mar 2014 21:07:11 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS005.bigfish.com (10.7.99.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 10 Mar 2014 21:07:06 +0000 Received: from BLUPR05MB769.namprd05.prod.outlook.com (10.141.209.19) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.423.0; Mon, 10 Mar 2014 21:07:06 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BLUPR05MB769.namprd05.prod.outlook.com (10.141.209.19) with Microsoft SMTP Server (TLS) id 15.0.893.10; Mon, 10 Mar 2014 21:07:05 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.210]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.210]) with mapi id 15.00.0893.001; Mon, 10 Mar 2014 21:07:04 +0000 From: Kent Watsen To: Mikael Abrahamsson , Juergen Schoenwaelder Thread-Topic: [netmod] ietf 89 wg meeting summary Thread-Index: AQHPORZyBRVrmq/uVk+73h3kUiqOMprT8h+AgAAXKoCAABHsAIAGePWA Date: Mon, 10 Mar 2014 21:07:03 +0000 Message-ID: References: <20140306083054.GA32986@elstar.local> <20140306131231.GB33713@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.13] x-forefront-prvs: 014617085B Content-Type: text/plain; charset="us-ascii" Content-ID: <63FAC07F0C31A24488FB873B0125C378@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/QazMnyoP5fTrgJQAGHnWvvAmtLQ Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf 89 wg meeting summary X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 21:07:31 -0000 >"There was a request from a participant for guidance from the netmod >group=20 >regarding tools and ways of collaborating when developing YANG models, >and regarding the current process of developing YANG standards by means >of=20 >publishing them as RFCs instead of a more light-weight process. >This was discussed but no consensus was reached on how to proceed." It seems that working groups already have access to an issue tracker and a version control system: Trac: http://tools.ietf.org/wg/trackers SVN:=20 http://trac.tools.ietf.org/misc/venue/wiki/IetfSpecificFeatures#SourceContr olRepositorySVN For NETCONF and NETMOD WGs: NETCONF - SVN: http://svn.tools.ietf.org/svn/wg/netconf - Trac: http://tools.ietf.org/wg/netconf/trac/report NETMOD: - SVN: http://svn.tools.ietf.org/svn/wg/netmod - Trac: http://tools.ietf.org/wg/netmod/trac/report Looking at what's there already, it seems that they've been used, but not extensively; we just need to dust them off and use them. As I recall, the objectives are: 1) use SVN for co-authors to collaborate on draft 2) use Trac to drive closure on draft issues Makes sense? Should we each just start doing this? Do we need to agree on any naming conventions to keep things properly isolated? Cheers, Kent From nobody Tue Mar 11 03:19:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E331A0692 for ; Tue, 11 Mar 2014 03:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.758 X-Spam-Level: X-Spam-Status: No, score=0.758 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rcje6sncLlXw for ; Tue, 11 Mar 2014 03:19:18 -0700 (PDT) Received: from amalka.pantheon.sk (amalka.pantheon.sk [81.89.59.174]) by ietfa.amsl.com (Postfix) with ESMTP id 15C081A066C for ; Tue, 11 Mar 2014 03:19:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by amalka.pantheon.sk (Postfix) with ESMTP id 09FBD200FF for ; Tue, 11 Mar 2014 11:19:11 +0100 (CET) X-Virus-Scanned: amavisd-new at pantheon.sk Authentication-Results: amalka.pantheon.sk (amavisd-new); dkim=pass (1024-bit key) header.d=pantheon.sk Received: from amalka.pantheon.sk ([127.0.0.1]) by localhost (amalka.pantheon.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIsae6OeAbF0 for ; Tue, 11 Mar 2014 11:19:06 +0100 (CET) Received: from cipisek.dmz.pantheon.local (cipisek.pantheon.sk [81.89.59.176]) by amalka.pantheon.sk (Postfix) with ESMTP for ; Tue, 11 Mar 2014 11:19:06 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id 104E21695F2 for ; Tue, 11 Mar 2014 11:19:06 +0100 (CET) Received: from cipisek.dmz.pantheon.local ([127.0.0.1]) by localhost (cipisek.dmz.pantheon.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id qybV1-SCls5v for ; Tue, 11 Mar 2014 11:19:05 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id DD6F5172796 for ; Tue, 11 Mar 2014 11:19:04 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.7.1 cipisek.dmz.pantheon.local DD6F5172796 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.sk; s=D7204E10-2735-11E2-9595-0BDFE9028503; t=1394533144; bh=ch/wHmOK+kmrUtl419J0JX5P9KVwWbjq3vxUO7NiazY=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=AxFFz0MwJStAvLB8BsK0KNcFglR8aVLhZqbw8djBxAEaERNiQU2/HHUCgmz8cfYeQ y5qb9zTEo+YoDU7kKDz5+anTK/5JvSiPKTSSKXvn8nNhMP/GyG5+yF0BDN9NdmFSre sYVoOvGX+jVbuHKqzbmChzmhUzjwmY28l+Lnmw0s= X-Virus-Scanned: amavisd-new at pantheon.sk Received: from cipisek.dmz.pantheon.local ([127.0.0.1]) by localhost (cipisek.dmz.pantheon.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZCheyegjCAcx for ; Tue, 11 Mar 2014 11:19:04 +0100 (CET) Received: from [172.16.4.121] (unknown [172.16.4.121]) by cipisek.dmz.pantheon.local (Postfix) with ESMTPSA id B8E651695F2 for ; Tue, 11 Mar 2014 11:19:04 +0100 (CET) Message-ID: <531EE30E.6050407@pantheon.sk> Date: Tue, 11 Mar 2014 11:18:54 +0100 From: Robert Varga User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: netmod@ietf.org References: <3EC30BF5-E7A0-408C-9CB6-41E41970EB15@nic.cz> <20140309.144655.457263402.mbj@tail-f.com> <527CF187-0AE2-4328-A79F-BE1C7DD7E4E5@nic.cz> <20140309.161115.323245671.mbj@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rn9CzbS7lDYMK6T_Vc4r0peCED0 Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 10:19:22 -0000 On 03/09/2014 05:02 PM, Ladislav Lhotka wrote: > On 09 Mar 2014, at 16:35, Andy Bierman wrote: > >> Hi, >> >> >> >> On Sun, Mar 9, 2014 at 8:11 AM, Martin Bjorklund wrot= e: >> Ladislav Lhotka wrote: >>> I don=92t see any statement in 6020 saying that the client is free to= ignore >>> parts of the data model as advertised in server=92s hello. >> The server tells the client what it implements, the client does >> whatever it wants with this information. >> >> >> I think you are right. >> If the client builds the server schema tree from the import statements >> of the modules it cares about, then the import chain will never hit th= e new >> YANG 1.1 module that is augmenting the old data structure. This is how >> import-by-revision allows different versions of the same imported >> module to be used by multiple importing modules. >> >> In addition, the client can skip modules that fail to compile >> when the server modules are processed. It won't have he new >> schema nodes for sending requests. Any replies with these >> unknown nodes get parsed as 'anyxml' instead of the real schema. >> (This is how our client code works today.) > My point is that the skipped modules may change semantics of the remain= ing modules. So the client should not be surprised by error conditions or= unexpected behaviour of the server. I am not sure they can really *change* semantics. I think we agree that=20 the read-side of things is safe. The only trouble I see if a 1.0 client attempts to overwrite a tree=20 which currently contains 1.1 data with only 1.0 data, either in a=20 read-modify-write cycle or by a simple write. Since the server knows it=20 is talking to a 1.0 client, I think we can come up with a solution which=20 gives the client least surprises by tracking of what happened on the=20 session and making a few assumptions about what a reasonable client is=20 doing ;-) Bye, Robert From nobody Tue Mar 11 03:57:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0058A1A066C for ; Tue, 11 Mar 2014 03:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRQpN3Sb7p6D for ; Tue, 11 Mar 2014 03:57:28 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id AAE8F1A040E for ; Tue, 11 Mar 2014 03:57:27 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 82B2B13F8AB; Tue, 11 Mar 2014 11:57:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394535441; bh=dWxbosDLSxf/VlQLaGbP4CWUW8AALriZa+M+CFog8s8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ck51WcB6fDQhrjvlYruOZVhWbRNYv4gPLlAeTyia4OzNUJTd+irWDBCT3koPmofn3 I97NCiRC7Wj2ln6Ufh8mQtfZ1ejHcrWjB8cJbSnofI7Yt7L0TIV9t5PeelQhaB+/f/ ZhciaFC7SRpWBXxsl0GFqDrLBkjc1WMfDBeNu8pU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <531EE30E.6050407@pantheon.sk> Date: Tue, 11 Mar 2014 11:57:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3EC30BF5-E7A0-408C-9CB6-41E41970EB15@nic.cz> <20140309.144655.457263402.mbj@tail-f.com> <527CF187-0AE2-4328-A79F-BE1C7DD7E4E5@nic.cz> <20140309.161115.323245671.mbj@tail-f.com> <531EE30E.6050407@pantheon.sk> To: Robert Varga X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5r1OYhFa8YVWbMiGl98XQFGWqoQ Cc: netmod@ietf.org Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 10:57:30 -0000 On 11 Mar 2014, at 11:18, Robert Varga wrote: > On 03/09/2014 05:02 PM, Ladislav Lhotka wrote: >> On 09 Mar 2014, at 16:35, Andy Bierman wrote: >>=20 >>> Hi, >>>=20 >>>=20 >>>=20 >>> On Sun, Mar 9, 2014 at 8:11 AM, Martin Bjorklund = wrote: >>> Ladislav Lhotka wrote: >>>> I don=92t see any statement in 6020 saying that the client is free = to ignore >>>> parts of the data model as advertised in server=92s hello. >>> The server tells the client what it implements, the client does >>> whatever it wants with this information. >>>=20 >>>=20 >>> I think you are right. >>> If the client builds the server schema tree from the import = statements >>> of the modules it cares about, then the import chain will never hit = the new >>> YANG 1.1 module that is augmenting the old data structure. This is = how >>> import-by-revision allows different versions of the same imported >>> module to be used by multiple importing modules. >>>=20 >>> In addition, the client can skip modules that fail to compile >>> when the server modules are processed. It won't have he new >>> schema nodes for sending requests. Any replies with these >>> unknown nodes get parsed as 'anyxml' instead of the real schema. >>> (This is how our client code works today.) >> My point is that the skipped modules may change semantics of the = remaining modules. So the client should not be surprised by error = conditions or unexpected behaviour of the server. >=20 > I am not sure they can really *change* semantics. I think we agree = that the read-side of things is safe. Well, my example shows that the module that is being ignored by the = client can define default values that the server considers as being = present even if the client is not aware of them. Another problem is that the ignored module may define data nodes with = =93must=94 constraints that affect the contents of old modules. Anyway, the term =93data tree=94 is defined in RFC 6020 as follows: o data tree: The instantiated tree of configuration and state data on a device. The idea of a client cherry-picking modules from hello means that the = server and client work with different data trees. This is something I = can hardly accept. Lada =20 >=20 > The only trouble I see if a 1.0 client attempts to overwrite a tree = which currently contains 1.1 data with only 1.0 data, either in a = read-modify-write cycle or by a simple write. Since the server knows it = is talking to a 1.0 client, I think we can come up with a solution which = gives the client least surprises by tracking of what happened on the = session and making a few assumptions about what a reasonable client is = doing ;-) >=20 > Bye, > Robert >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Mar 11 09:14:08 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC3C1A0780 for ; Tue, 11 Mar 2014 09:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSmQDExMLQ6J for ; Tue, 11 Mar 2014 09:13:58 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id 892821A0499 for ; Tue, 11 Mar 2014 09:13:58 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id m20so9628849qcx.7 for ; Tue, 11 Mar 2014 09:13:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IffaZyb+ts07HCmPww9MMzVEgzAPsvNh0fKLCHhtGkU=; b=cXVJHMDP0VKUWZx4NkVZ6nsL2c29n35XkQIsYl3aR+DqQxMlcZDz5pJSZWLYLtrYHa OIstjqhKhTtgsUMGu8iOQUijuOrf9A5495LRlO23LwcHu8uduTB0JoynDrjseTID54zi wOAPtDF2RIsIdz0iXDE5iWxuU4w6SE1v0CXcVK8CHOkU6rC/sgLgsdjNACH9dx62rqJN s+hsPsFhe5Jrq5LdIBdSloh4cy3nAvUw5d40Otej+eUsDQ+Smf26+Rviij6W+0B8laNo 8n7babp1XRSzwUrq4uzLqycP+0J9QeiMKboxQ0voIf1ixxp7bmDaHzWDC/Qdvwly2P2V Tfmw== X-Gm-Message-State: ALoCoQmO2ALuhYNPhnf1UcpwFtr2EKdnaMSBs8bbP/64ZaBo5ZvtNGaSHQ11T0x1/1VOW1cbube4 MIME-Version: 1.0 X-Received: by 10.140.27.193 with SMTP id 59mr10473381qgx.18.1394554432562; Tue, 11 Mar 2014 09:13:52 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Tue, 11 Mar 2014 09:13:52 -0700 (PDT) In-Reply-To: References: <3EC30BF5-E7A0-408C-9CB6-41E41970EB15@nic.cz> <20140309.144655.457263402.mbj@tail-f.com> <527CF187-0AE2-4328-A79F-BE1C7DD7E4E5@nic.cz> <20140309.161115.323245671.mbj@tail-f.com> <531EE30E.6050407@pantheon.sk> Date: Tue, 11 Mar 2014 09:13:52 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c1233a92d2ff04f4570168 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jXNieC-qfRCeEidC35kT4leQhVc Cc: "netmod@ietf.org" Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 16:14:03 -0000 --001a11c1233a92d2ff04f4570168 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 11, 2014 at 3:57 AM, Ladislav Lhotka wrote: > > On 11 Mar 2014, at 11:18, Robert Varga wrote: > > > On 03/09/2014 05:02 PM, Ladislav Lhotka wrote: > >> On 09 Mar 2014, at 16:35, Andy Bierman wrote: > >> > >>> Hi, > >>> > >>> > >>> > >>> On Sun, Mar 9, 2014 at 8:11 AM, Martin Bjorklund > wrote: > >>> Ladislav Lhotka wrote: > >>>> I don't see any statement in 6020 saying that the client is free to > ignore > >>>> parts of the data model as advertised in server's hello. > >>> The server tells the client what it implements, the client does > >>> whatever it wants with this information. > >>> > >>> > >>> I think you are right. > >>> If the client builds the server schema tree from the import statements > >>> of the modules it cares about, then the import chain will never hit > the new > >>> YANG 1.1 module that is augmenting the old data structure. This is how > >>> import-by-revision allows different versions of the same imported > >>> module to be used by multiple importing modules. > >>> > >>> In addition, the client can skip modules that fail to compile > >>> when the server modules are processed. It won't have he new > >>> schema nodes for sending requests. Any replies with these > >>> unknown nodes get parsed as 'anyxml' instead of the real schema. > >>> (This is how our client code works today.) > >> My point is that the skipped modules may change semantics of the > remaining modules. So the client should not be surprised by error > conditions or unexpected behaviour of the server. > > > > I am not sure they can really *change* semantics. I think we agree that > the read-side of things is safe. > > Well, my example shows that the module that is being ignored by the client > can define default values that the server considers as being present even > if the client is not aware of them. > > Another problem is that the ignored module may define data nodes with > "must" constraints that affect the contents of old modules. > > Anyway, the term "data tree" is defined in RFC 6020 as follows: > > o data tree: The instantiated tree of configuration and state data > on a device. > > The idea of a client cherry-picking modules from hello means that the > server and client work with different data trees. This is something I can > hardly accept. > > The client is coded to use certain modules. It is not required to use modules written in the future or unrelated to the application. The client needs to use merge instead of replace. We already have this problem dues to access control. It does not even require augments to cause the problem. This is 1 reason that PUT/replace is not as good as PATCH/merge. In all likelihood, the addition of even 1 YANG 1.1 module to a server implementation is going to break all 1.0 applications, because clients tend to retrieve all the advertised modules, if they retrieve any modules at all. Apps that are hard-wired to only understand certain modules would have no way of knowing that a new 1.1 module is available to load. It is not cherry-picking -- it is just a hard-wired design. Lada > Andy > > > > > The only trouble I see if a 1.0 client attempts to overwrite a tree > which currently contains 1.1 data with only 1.0 data, either in a > read-modify-write cycle or by a simple write. Since the server knows it is > talking to a 1.0 client, I think we can come up with a solution which gives > the client least surprises by tracking of what happened on the session and > making a few assumptions about what a reasonable client is doing ;-) > > > > Bye, > > Robert > > > > _______________________________________________ > > 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 > --001a11c1233a92d2ff04f4570168 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Mar 11, 2014 at 3:57 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 11 Mar 2014, at 11:18, Robert Varga <robert.varga@pantheon.sk> wrote:

> On 03/09/2014 05:02 PM, Ladislav Lhotka wrote:
>> On 09 Mar 2014, at 16:35, Andy Bierman <andy@yumaworks.com> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> On Sun, Mar 9, 2014 at 8:11 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>>> Ladislav Lhotka <lhotka@ni= c.cz> wrote:
>>>> I don’t see any statement in 6020 saying that the cl= ient is free to ignore
>>>> parts of the data model as advertised in server’s he= llo.
>>> The server tells the client what it implements, the client doe= s
>>> whatever it wants with this information.
>>>
>>>
>>> I think you are right.
>>> If the client builds the server schema tree from the import st= atements
>>> of the modules it cares about, then the import chain will neve= r hit the new
>>> YANG 1.1 module that is augmenting the old data structure. Thi= s is how
>>> import-by-revision allows different versions of the same impor= ted
>>> module to be used by multiple importing modules.
>>>
>>> In addition, the client can skip modules that fail to compile<= br> >>> when the server <hello> modules are processed.  It = won't have he new
>>> schema nodes for sending requests.  Any replies with thes= e
>>> unknown nodes get parsed as 'anyxml' instead of the re= al schema.
>>> (This is how our client code works today.)
>> My point is that the skipped modules may change semantics of the r= emaining modules. So the client should not be surprised by error conditions= or unexpected behaviour of the server.
>
> I am not sure they can really *change* semantics. I think we agree tha= t the read-side of things is safe.

Well, my example shows that the module that is being ignored by the client = can define default values that the server considers as being present even i= f the client is not aware of them.

Another problem is that the ignored module may define data nodes with &ldqu= o;must” constraints that affect the contents of old modules.

Anyway, the term “data tree” is defined in RFC 6020 as follows:=

   o  data tree: The instantiated tree of configuration and = state data
      on a device.

The idea of a client cherry-picking modules from hello means that the serve= r and client work with different data trees. This is something I can hardly= accept.


The client is coded to use certain mod= ules.
It is not required to use modules written in the future or<= /div>
unrelated to the application.

The client= needs to use merge instead of replace.
We already have this problem dues to access control.
It does= not even require augments to cause the problem.
This is 1 reason= that PUT/replace is not as good as PATCH/merge.

In all likelihood, the addition of even 1 YANG 1.1 module to a server
=
implementation is going to break all 1.0 applications, because
clients tend to retrieve all the advertised modules, if they retrieve an= y
modules at all.  Apps that are hard-wired to only understand cert= ain
modules would have no way of knowing that a new 1.1 module
is available to load.

It is not cherry-pic= king -- it is just a hard-wired design.



Lada


Andy
&nbs= p;

>
> The only trouble I see if a 1.0 client attempts to overwrite a tree wh= ich currently contains 1.1 data with only 1.0 data, either in a read-modify= -write cycle or by a simple write. Since the server knows it is talking to = a 1.0 client, I think we can come up with a solution which gives the client= least surprises by tracking of what happened on the session and making a f= ew assumptions about what a reasonable client is doing ;-)
>
> Bye,
> Robert
>
> _______________________________________________
> 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

--001a11c1233a92d2ff04f4570168-- From nobody Tue Mar 11 09:31:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB9A1A048D for ; Tue, 11 Mar 2014 09:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Abe-UZCZ5lAX for ; Tue, 11 Mar 2014 09:31:42 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DE5081A01AD for ; Tue, 11 Mar 2014 09:31:41 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id CC35C140872; Tue, 11 Mar 2014 17:31:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394555492; bh=1enTGQbCawLh0THPVFkIYpkWNfIY4jLthRjZC6N0wlg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=xJsKbmrokHAEan0roIrS/Fa5YhOg+Lp7n85eR+cITSxjgvfd3OBQuyQVA9V6QfutG 297c2wiHHVTMbre+hQHiKHByWTS58R56hVaJjuGLqF63y8b9kcN1wh2JUfaIdKu+NP 4uBhU9BesTCcevjLsIfEAb5MuMrdcmxGBwHyAh4E= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 11 Mar 2014 17:31:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3EC30BF5-E7A0-408C-9CB6-41E41970EB15@nic.cz> <20140309.144655.457263402.mbj@tail-f.com> <527CF187-0AE2-4328-A79F-BE1C7DD7E4E5@nic.cz> <20140309.161115.323245671.mbj@tail-f.com> <531EE30E.6050407@pantheon.sk> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1Op7ttBRJOg8rHor3bpFuJhEEsc Cc: "netmod@ietf.org" Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 16:31:44 -0000 On 11 Mar 2014, at 17:13, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Mar 11, 2014 at 3:57 AM, Ladislav Lhotka = wrote: >=20 > On 11 Mar 2014, at 11:18, Robert Varga = wrote: >=20 > > On 03/09/2014 05:02 PM, Ladislav Lhotka wrote: > >> On 09 Mar 2014, at 16:35, Andy Bierman wrote: > >> > >>> Hi, > >>> > >>> > >>> > >>> On Sun, Mar 9, 2014 at 8:11 AM, Martin Bjorklund = wrote: > >>> Ladislav Lhotka wrote: > >>>> I don=92t see any statement in 6020 saying that the client is = free to ignore > >>>> parts of the data model as advertised in server=92s hello. > >>> The server tells the client what it implements, the client does > >>> whatever it wants with this information. > >>> > >>> > >>> I think you are right. > >>> If the client builds the server schema tree from the import = statements > >>> of the modules it cares about, then the import chain will never = hit the new > >>> YANG 1.1 module that is augmenting the old data structure. This is = how > >>> import-by-revision allows different versions of the same imported > >>> module to be used by multiple importing modules. > >>> > >>> In addition, the client can skip modules that fail to compile > >>> when the server modules are processed. It won't have he = new > >>> schema nodes for sending requests. Any replies with these > >>> unknown nodes get parsed as 'anyxml' instead of the real schema. > >>> (This is how our client code works today.) > >> My point is that the skipped modules may change semantics of the = remaining modules. So the client should not be surprised by error = conditions or unexpected behaviour of the server. > > > > I am not sure they can really *change* semantics. I think we agree = that the read-side of things is safe. >=20 > Well, my example shows that the module that is being ignored by the = client can define default values that the server considers as being = present even if the client is not aware of them. >=20 > Another problem is that the ignored module may define data nodes with = =93must=94 constraints that affect the contents of old modules. >=20 > Anyway, the term =93data tree=94 is defined in RFC 6020 as follows: >=20 > o data tree: The instantiated tree of configuration and state data > on a device. >=20 > The idea of a client cherry-picking modules from hello means that the = server and client work with different data trees. This is something I = can hardly accept. >=20 >=20 > The client is coded to use certain modules. > It is not required to use modules written in the future or > unrelated to the application. I think it really depends on the design of the data model. For example, = ietf-routing makes sense only together with at least one address-family = specific modul like ietf-ipv4-unicast-routing. In a sense, ietf-routing = is an abstract module.=20 >=20 > The client needs to use merge instead of replace. > We already have this problem dues to access control. > It does not even require augments to cause the problem. > This is 1 reason that PUT/replace is not as good as PATCH/merge. >=20 > In all likelihood, the addition of even 1 YANG 1.1 module to a server > implementation is going to break all 1.0 applications, because > clients tend to retrieve all the advertised modules, if they retrieve = any > modules at all. Apps that are hard-wired to only understand certain > modules would have no way of knowing that a new 1.1 module > is available to load. >=20 > It is not cherry-picking -- it is just a hard-wired design. If the client is hardwired, then it could also have problems with get = operations because unexpected elements can appear pretty much anywhere = in the reply. Lada >=20 >=20 >=20 > Lada >=20 >=20 > Andy > =20 >=20 > > > > The only trouble I see if a 1.0 client attempts to overwrite a tree = which currently contains 1.1 data with only 1.0 data, either in a = read-modify-write cycle or by a simple write. Since the server knows it = is talking to a 1.0 client, I think we can come up with a solution which = gives the client least surprises by tracking of what happened on the = session and making a few assumptions about what a reasonable client is = doing ;-) > > > > Bye, > > Robert > > > > _______________________________________________ > > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Mar 11 10:07:51 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2B71A0765 for ; Tue, 11 Mar 2014 10:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIN2fYNqvTfY for ; Tue, 11 Mar 2014 10:07:48 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0066A1A074D for ; Tue, 11 Mar 2014 10:07:47 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id j107so25667431qga.7 for ; Tue, 11 Mar 2014 10:07:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=792bio22i/KuWA9DsS7pBNzcQo5KaRQOqaQDS+kib0o=; b=Iai8GzeidRIhZtGsYw4HQ1M93wq0v+dMg/OgGg28hpZvpOYhdsbQj5D6pT9fmZs7+5 nZIQmRN5YwKvEEb0OrMszNmXOGb33L0uqOVtAQ7v2XgjUt4Vab+iWm1Y85Sm7VTurv61 1dBHnPBJhPyaUEucr0GQOxiXymlT+SixBsevPaJAAtJdP7aIj4vqBPiB33BoJnNKz1cQ aNTj7kdW/qOM2BSvw5IGEdMO+ANI2ggkTynRcfoe3Fu1OIVVosXBSvs7+4NvttxMdPQm CHHIIMWN41rNlIF0UBnxGR9S7jPsQniwaJVIPEgR35WifUcYMxgMWjpJM8z3JPHADA/F YRzw== X-Gm-Message-State: ALoCoQlxt6Gj6QQljuwKeT8tlj3TkyAKPkfl+iVS7O2BU4ak3RJ+AK4s26MhuQVjN7J9UqS0sSMg MIME-Version: 1.0 X-Received: by 10.224.112.6 with SMTP id u6mr4352970qap.78.1394557662113; Tue, 11 Mar 2014 10:07:42 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Tue, 11 Mar 2014 10:07:41 -0700 (PDT) In-Reply-To: References: <3EC30BF5-E7A0-408C-9CB6-41E41970EB15@nic.cz> <20140309.144655.457263402.mbj@tail-f.com> <527CF187-0AE2-4328-A79F-BE1C7DD7E4E5@nic.cz> <20140309.161115.323245671.mbj@tail-f.com> <531EE30E.6050407@pantheon.sk> Date: Tue, 11 Mar 2014 10:07:41 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c2e84811df9e04f457c2f6 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/poApCQYlURZOVJM4nDqObJpSSFg Cc: "netmod@ietf.org" Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 17:07:49 -0000 --001a11c2e84811df9e04f457c2f6 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 11, 2014 at 9:31 AM, Ladislav Lhotka wrote: > > On 11 Mar 2014, at 17:13, Andy Bierman wrote: > > ...... > > It is not cherry-picking -- it is just a hard-wired design. > > If the client is hardwired, then it could also have problems with get > operations because unexpected elements can appear pretty much anywhere in > the reply. > > The hard-wired implementations are on their own. We assume clients and servers are written to cope with module changes (RFC 6020, sec 10). We never thought about any upgrade guidelines for moving to a new language version. You are right. A well-designed schema-driven client is likely to retrieve all the YANG modules the server advertises, and it will reject all the YANG 1.1 modules. Whether it continues to function is data-model and implementation specific. We should assume that adding even 1 YANG 1.1 module to a deployment is likely to require all YANG-driven tools to be updated at once (a forklift upgrade). > Lada > > Andy --001a11c2e84811df9e04f457c2f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Mar 11, 2014 at 9:31 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 11 Mar 2014, at 17:13, Andy Bierman <andy@yumaworks.com> wrote:

......
> It is not cherry-picking -- it is just a hard-wired design.

If the client is hardwired, then it could also have problems with get opera= tions because unexpected elements can appear pretty much anywhere in the re= ply.


The hard-wired implementations are on = their own.
We assume clients and servers are written to cope
with module changes (RFC 6020, sec 10). We never thought about
any upgrade guidelines for moving to a new language version.

You are right.
A well-designed schema-driven clie= nt is likely to retrieve
all the YANG modules the server advertis= es, and it will
reject all the YANG 1.1 modules. =A0Whether it continues to function
is data-model and implementation specific.

We should assume that adding even 1 YANG 1.1 module to
a deploy= ment is likely to require all YANG-driven tools to
be updated at once (a forklift upgrade).

=A0<= /div>
Lada


Andy

<= /div> --001a11c2e84811df9e04f457c2f6-- From nobody Tue Mar 11 10:18:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0B71A0654 for ; Tue, 11 Mar 2014 10:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5aNpQcfN3S9 for ; Tue, 11 Mar 2014 10:18:01 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9B21C1A0769 for ; Tue, 11 Mar 2014 10:17:58 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A104F1107; Tue, 11 Mar 2014 18:17:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id n7LztbPY_oUM; Tue, 11 Mar 2014 18:17:52 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 11 Mar 2014 18:17:52 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0C70F2002C; Tue, 11 Mar 2014 18:17:52 +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 WM-lCTGlPUG6; Tue, 11 Mar 2014 18:17:51 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F8F22002F; Tue, 11 Mar 2014 18:17:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 463D52BB049D; Tue, 11 Mar 2014 18:17:50 +0100 (CET) Date: Tue, 11 Mar 2014 18:17:50 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140311171750.GB79247@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , "netmod@ietf.org" References: <20140309.144655.457263402.mbj@tail-f.com> <527CF187-0AE2-4328-A79F-BE1C7DD7E4E5@nic.cz> <20140309.161115.323245671.mbj@tail-f.com> <531EE30E.6050407@pantheon.sk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7lru4hKsxmeVX95p8TNXMlleV20 Cc: "netmod@ietf.org" Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 11 Mar 2014 17:18:03 -0000 On Tue, Mar 11, 2014 at 10:07:41AM -0700, Andy Bierman wrote: > You are right. > A well-designed schema-driven client is likely to retrieve > all the YANG modules the server advertises, and it will > reject all the YANG 1.1 modules. Whether it continues to function > is data-model and implementation specific. > > We should assume that adding even 1 YANG 1.1 module to > a deployment is likely to require all YANG-driven tools to > be updated at once (a forklift upgrade). In case 1.1 modules are not announced anymore automatically, an old client will never see them. That said, it is likely that clients are much easier and faster to upgrade than servers. /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 Mar 11 10:21:57 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494C91A0654 for ; Tue, 11 Mar 2014 10:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbBQaamL-910 for ; Tue, 11 Mar 2014 10:21:53 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) by ietfa.amsl.com (Postfix) with ESMTP id 01F131A0770 for ; Tue, 11 Mar 2014 10:21:50 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id 63so7189585qgz.6 for ; Tue, 11 Mar 2014 10:21:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=aiZdbE9WU6NYQX/Egge6HA/FtcixLX5XwoEa+5+HIPU=; b=P1kKi+GFVvIRZNwuBy1dI71fSxRW9yfu55UBKM+HiHbFnsYezs30JOImcMHqSEkX2P /+4SusVjb3NYV91GyD1DUvNPCW4SUJjCA90WqPF7BNrXBxIapgF96yoMlKJF/U1PTh4F Ux+05VaSD3pPKQvPM++EPpY0dlLX9h9VcIspq+J46e98ZVEthiJqVg5Pep/zpaUxQq34 6dP+JeJ8p2hagRJZ0uyBmLlbIPtNdrnKNASQIxioPfCdtgeY6k4KzOAZiwtNrfu/hnRI kExV/eMOeulSCTLRSOuftEv/NePCJv1M32N54rooNOcVjR4erueoltqLREbPmHe43teL ZOqQ== X-Gm-Message-State: ALoCoQmhZVo/nsEtOxFYEVRdZ4EsJ87BLglfgJZSS7X8Wc5OEjnANETt3LsiarJ/ZuiK/SYUGkA3 MIME-Version: 1.0 X-Received: by 10.229.84.198 with SMTP id k6mr4460536qcl.20.1394558504911; Tue, 11 Mar 2014 10:21:44 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Tue, 11 Mar 2014 10:21:44 -0700 (PDT) In-Reply-To: <20140311171750.GB79247@elstar.local> References: <20140309.144655.457263402.mbj@tail-f.com> <527CF187-0AE2-4328-A79F-BE1C7DD7E4E5@nic.cz> <20140309.161115.323245671.mbj@tail-f.com> <531EE30E.6050407@pantheon.sk> <20140311171750.GB79247@elstar.local> Date: Tue, 11 Mar 2014 10:21:44 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Ladislav Lhotka , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a1134541a4dd68604f457f447 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/r03Utw4tegmeM0BQnEfOy2sNejc Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 17:21:55 -0000 --001a1134541a4dd68604f457f447 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 11, 2014 at 10:17 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Mar 11, 2014 at 10:07:41AM -0700, Andy Bierman wrote: > > > You are right. > > A well-designed schema-driven client is likely to retrieve > > all the YANG modules the server advertises, and it will > > reject all the YANG 1.1 modules. Whether it continues to function > > is data-model and implementation specific. > > > > We should assume that adding even 1 YANG 1.1 module to > > a deployment is likely to require all YANG-driven tools to > > be updated at once (a forklift upgrade). > > In case 1.1 modules are not announced anymore automatically, an old > client will never see them. That said, it is likely that clients are > much easier and faster to upgrade than servers. > > Good point. They will have to upgrade if they expect to find module capabilities in the and they all disappear. Applications will definitely stop working if this happens. /js > Andy --001a1134541a4dd68604f457f447 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Mar 11, 2014 at 10:17 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Mar 11, 2014 at 10:07:41AM -0700, An= dy Bierman wrote:

> You are right.
> A well-designed schema-driven client is likely to retrieve
> all the YANG modules the server advertises, and it will
> reject all the YANG 1.1 modules. =A0Whether it continues to function > is data-model and implementation specific.
>
> We should assume that adding even 1 YANG 1.1 module to
> a deployment is likely to require all YANG-driven tools to
> be updated at once (a forklift upgrade).

In case 1.1 modules are not announced anymore automatically, an old
client will never see them. That said, it is likely that clients are
much easier and faster to upgrade than servers.


Good point.
They will have to upgrade if t= hey expect to find module capabilities
in the <hello> and t= hey all disappear. =A0Applications will definitely stop
working if this happens.


/js

Andy

--001a1134541a4dd68604f457f447-- From nobody Wed Mar 12 15:55:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54011A07A8 for ; Wed, 12 Mar 2014 15:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFno1HTAwFoy for ; Wed, 12 Mar 2014 15:55:05 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 94BC71A07A5 for ; Wed, 12 Mar 2014 15:55:04 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DFD5AF69 for ; Wed, 12 Mar 2014 23:54:57 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id VzqKnPYbriHG for ; Wed, 12 Mar 2014 23:54:57 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 12 Mar 2014 23:54:57 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 162542002F for ; Wed, 12 Mar 2014 23:54:57 +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 tFbBeZQgvdL7; Wed, 12 Mar 2014 23:54:56 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C9342002C; Wed, 12 Mar 2014 23:54:56 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 58C2F2BB27E1; Wed, 12 Mar 2014 23:54:54 +0100 (CET) Date: Wed, 12 Mar 2014 23:54:53 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140312225453.GA84698@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/n5AGml-MFrWc2S2oNuT8gOiYJe8 Subject: [netmod] draft minutes of the london meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 12 Mar 2014 22:55:09 -0000 Hi, please review the draft minutes of the meeting last week in London: http://www.ietf.org/proceedings/89/minutes/minutes-89-netmod /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 Mar 13 08:44:22 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAE21A09A3 for ; Thu, 13 Mar 2014 08:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pfs_9ipsmp_e for ; Thu, 13 Mar 2014 08:44:15 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id A2B721A088B for ; Thu, 13 Mar 2014 08:44:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 10BA7540394; Thu, 13 Mar 2014 16:44:08 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+uNiNjk+P-V; Thu, 13 Mar 2014 16:44:02 +0100 (CET) Received: from localhost (37-48-42-98.tmcz.cz [37.48.42.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id EF3DD540216; Thu, 13 Mar 2014 16:44:00 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder , Andy Bierman In-Reply-To: <20140308173950.GB72376@elstar.local> References: <20140308.171907.224328665.mbj@tail-f.com> <20140308173950.GB72376@elstar.local> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Thu, 13 Mar 2014 16:43:57 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BqkEIA6dIHgi50KsvVVlCnM06Mg Cc: "netmod@ietf.org" Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 15:44:18 -0000 Juergen Schoenwaelder writes: > On Sat, Mar 08, 2014 at 09:15:29AM -0800, Andy Bierman wrote: > >> So how does a server know if a YANG 1.0 or 1.1 client is going >> to connect without seeing its message? The server >> can never send the abbreviated if it wants to continue >> supporting existing YANG 1.0 applications. Not OK. > > In London, I suggested to do translation of 1.1 to 1.0 and hence a > server could announce 1.0 versions of 1.1 modules to clients that do > not grok 1.1 format. I got told this is not a good idea... > >> In our code, the thin client that is called by OpenSSH >> is triggered because the client sent a message, >> so there is no delay. It may not be hard to deliver >> the client hello in the initial connect message. >> So no delay or timeout is needed, just some code changes. >> >> Are there server implementations that send the hello >> as soon as the TCP or SSH session is started? > > Relying on hello timing is brittle. > > In hindsight, we should not have announced the yang modules during the > and instead mandated implementation of the monitoring data > model or a separate get-yang-modules RPC. The should really I am now looking to the monitoring data model and wondering: is there any way for the server to announce the supported features? The "schema/namespace" leaf is only supposed to contain the module namespace, according to the description. Lada > have only been used for protocol capabilities, not for announcing data > models. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Mar 13 08:50:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB111A0A1D for ; Thu, 13 Mar 2014 08:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTQVfmRczCb2 for ; Thu, 13 Mar 2014 08:50:06 -0700 (PDT) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 539731A0A1C for ; Thu, 13 Mar 2014 08:50:06 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id w8so1175003qac.41 for ; Thu, 13 Mar 2014 08:49:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ow+SfHk9pcd9G8r4ntB5HuWa9yfpzjV/VrOtsjhh27Y=; b=H/Sby1bKhvy5OWnqiSqueG1GAxV4ic8/7wdQZqZ6xcL1ulkOEKPyEqrhpKqJjVrx9h oicZCkMrBzrkbMnpqXcp+fBOqcp3p6zThiMLvfSgUeEJfW+8kx6XPcWAp3TZ7Rh85Z5I /XMIh+BUoKZ5eS4YWro5NZe+ZZRzY9puFklnYcaN46OMIRtg7A4m181d+eX2SNMHOMQ1 lev33VUJ2vp/PzsoPRr8UqECwa41kyhtt1jZ3x3r+XeD5L/z5i1MLtW1/+Xy5PpsZOXx /VMoEK1gvpzU2eq7mJQd2jPYWBbs/yzkpOc2SKuxeKbJc3lRvFPkX9bp985OjAeBdAbk bmMg== X-Gm-Message-State: ALoCoQmDEVhmKkMPxIjELRZUgWotKZIvVVx92wLqEM6VJI4dcoDXNVK79noLs1iIyrIZV4Bn/LUr MIME-Version: 1.0 X-Received: by 10.140.36.77 with SMTP id o71mr3103260qgo.25.1394725799558; Thu, 13 Mar 2014 08:49:59 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Thu, 13 Mar 2014 08:49:59 -0700 (PDT) In-Reply-To: References: <20140308.171907.224328665.mbj@tail-f.com> <20140308173950.GB72376@elstar.local> Date: Thu, 13 Mar 2014 08:49:59 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c15fa6d79a9f04f47ee744 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SeZranAwHiI2GU6Y-YISF8q2--A Cc: "netmod@ietf.org" Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 15:50:09 -0000 --001a11c15fa6d79a9f04f47ee744 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 13, 2014 at 8:43 AM, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > On Sat, Mar 08, 2014 at 09:15:29AM -0800, Andy Bierman wrote: > > > >> So how does a server know if a YANG 1.0 or 1.1 client is going > >> to connect without seeing its message? The server > >> can never send the abbreviated if it wants to continue > >> supporting existing YANG 1.0 applications. Not OK. > > > > In London, I suggested to do translation of 1.1 to 1.0 and hence a > > server could announce 1.0 versions of 1.1 modules to clients that do > > not grok 1.1 format. I got told this is not a good idea... > > > >> In our code, the thin client that is called by OpenSSH > >> is triggered because the client sent a message, > >> so there is no delay. It may not be hard to deliver > >> the client hello in the initial connect message. > >> So no delay or timeout is needed, just some code changes. > >> > >> Are there server implementations that send the hello > >> as soon as the TCP or SSH session is started? > > > > Relying on hello timing is brittle. > > > > In hindsight, we should not have announced the yang modules during the > > and instead mandated implementation of the monitoring data > > model or a separate get-yang-modules RPC. The should really > > I am now looking to the monitoring data model and wondering: is there any > way for the server to announce the supported features? The > "schema/namespace" leaf is only supposed to contain the module namespace, > according to the description. > > The full capability URIs are in the /netconf-state/capabilities/capability list. Lada > Andy > > > have only been used for protocol capabilities, not for announcing data > > models. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --001a11c15fa6d79a9f04f47ee744 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 13, 2014 at 8:43 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<= /a>> writes:

> On Sat, Mar 08, 2014 at 09:15:29AM -0800, Andy Bierman wrote:
>
>> So how does a server know if a YANG 1.0 or 1.1 client is going
>> to connect without seeing its <hello> message? =A0The server=
>> can never send the abbreviated <hello> if it wants to contin= ue
>> supporting existing YANG 1.0 applications. Not OK.
>
> In London, I suggested to do translation of 1.1 to 1.0 and hence a
> server could announce 1.0 versions of 1.1 modules to clients that do > not grok 1.1 format. I got told this is not a good idea...
>
>> In our code, the thin client that is called by OpenSSH
>> is triggered because the client sent a <hello> message,
>> so there is no delay. =A0It may not be hard to deliver
>> the client hello in the initial connect message.
>> So no delay or timeout is needed, just some code changes.
>>
>> Are there server implementations that send the hello
>> as soon as the TCP or SSH session is started?
>
> Relying on hello timing is brittle.
>
> In hindsight, we should not have announced the yang modules during the=
> <hello> and instead mandated implementation of the monitoring da= ta
> model or a separate get-yang-modules RPC. The <hello> should rea= lly

I am now looking to the monitoring data model and wondering: is there any w= ay for the server to announce the supported features? The "schema/name= space" leaf is only supposed to contain the module namespace, accordin= g to the description.




--001a11c15fa6d79a9f04f47ee744-- From nobody Thu Mar 13 08:58:36 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161C81A0A0D for ; Thu, 13 Mar 2014 08:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osgXVj3gfII6 for ; Thu, 13 Mar 2014 08:58:31 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1750A1A08ED for ; Thu, 13 Mar 2014 08:58:31 -0700 (PDT) Received: from [192.168.42.97] (37-48-42-98.tmcz.cz [37.48.42.98]) by mail.nic.cz (Postfix) with ESMTPSA id D809F140872; Thu, 13 Mar 2014 16:58:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394726303; bh=SRj3qhooD2XPC/3gRJUh68WRJvOqh9ymdRikXOnB+5k=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=OsrcVABrbJ+ua3HZefMqJqou8oxGwQDVSPstG37prJXoyFmFZn26dQp6iiJLHIUNK X9SWtevxewCpeC378E+DFxMMbtKxUaQVorBBeHjAl9BfFbvJeD1mj+8TczRa6L8OPa vNIPu/l50T95JvGOKCs4H4i5N3GwUWOiRqMy8Z9A= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 13 Mar 2014 16:58:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140308.171907.224328665.mbj@tail-f.com> <20140308173950.GB72376@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/oA0RBItojlQFOIKLecAvXewQsIg Cc: "netmod@ietf.org" Subject: Re: [netmod] capability set caching X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 15:58:33 -0000 On 13 Mar 2014, at 16:49, Andy Bierman wrote: >=20 >=20 >=20 > On Thu, Mar 13, 2014 at 8:43 AM, Ladislav Lhotka = wrote: > Juergen Schoenwaelder writes: >=20 > > On Sat, Mar 08, 2014 at 09:15:29AM -0800, Andy Bierman wrote: > > > >> So how does a server know if a YANG 1.0 or 1.1 client is going > >> to connect without seeing its message? The server > >> can never send the abbreviated if it wants to continue > >> supporting existing YANG 1.0 applications. Not OK. > > > > In London, I suggested to do translation of 1.1 to 1.0 and hence a > > server could announce 1.0 versions of 1.1 modules to clients that do > > not grok 1.1 format. I got told this is not a good idea... > > > >> In our code, the thin client that is called by OpenSSH > >> is triggered because the client sent a message, > >> so there is no delay. It may not be hard to deliver > >> the client hello in the initial connect message. > >> So no delay or timeout is needed, just some code changes. > >> > >> Are there server implementations that send the hello > >> as soon as the TCP or SSH session is started? > > > > Relying on hello timing is brittle. > > > > In hindsight, we should not have announced the yang modules during = the > > and instead mandated implementation of the monitoring data > > model or a separate get-yang-modules RPC. The should really >=20 > I am now looking to the monitoring data model and wondering: is there = any way for the server to announce the supported features? The = "schema/namespace" leaf is only supposed to contain the module = namespace, according to the description. >=20 >=20 > The full capability URIs are in the = /netconf-state/capabilities/capability list. OK, so this list may also include capabilities that were not advertised = in hello, right? Lada >=20 >=20 > Lada >=20 > Andy > =20 >=20 > > have only been used for protocol capabilities, not for announcing = data > > models. > > > > /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 >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Mar 14 07:53:13 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3951A015B for ; Fri, 14 Mar 2014 07:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.254 X-Spam-Level: X-Spam-Status: No, score=0.254 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Gw3CkGjwlDL for ; Fri, 14 Mar 2014 07:53:02 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5580E1A0159 for ; Fri, 14 Mar 2014 07:53:01 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id s2EEqqVC002688 for ; Fri, 14 Mar 2014 15:52:53 +0100 Message-ID: <532317C2.8090204@mg-soft.com> Date: Fri, 14 Mar 2014 15:52:50 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: multipart/alternative; boundary="------------060602020007060601030207" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cYXJNE4KMkJfhnFeJvlZuExLIbw Subject: [netmod] Is current() broken for path expressions defined inside notifications/rpcs? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 14:53:10 -0000 This is a multi-part message in MIME format. --------------060602020007060601030207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, RFC6020, Section 9.9.2.: o The context node is the node in the data tree for which the "path" statement is defined. The accessible tree depends on the context node: o If the context node represents configuration data, the tree is the data in the NETCONF datastore where the context node exists. The XPath root node has all top-level configuration data nodes in all modules as children. o Otherwise, the tree is all state data on the device, and the datastore. The XPath root node has all top-level data nodes in all modules as children. RFC6020, Section 3. o data node: A node in the schema tree that can be instantiated in a data tree. One of container, leaf, leaf-list, list, and anyxml. o data tree: The instantiated tree of configuration and state data on a device. A leafref defined within a notification/rpc definition is a not part of the data tree, right? It cannot be instantiated as configuration or state data, since it represents neither. So what is current() supposed to return in this case? RFC6020, Section 6.4.1. o The function library is the core function library defined in [XPATH ], and a function "current()" that returns a node set with the initial context node. This function should only be able to return nodes, that are part of the accessible tree for an expression, yet in case of notifications and rpcs, the text seems to say that the initial context node is not part of the accessible tree. Are there two accessible trees? Section 9.9.2. has an example where current() is used inside a notification, which indicates what's supposed to happen, but can it? The following notification defines two leafrefs to refer to an existing admin-status: notification link-failure { leaf if-name { type leafref { path "/interface/name"; } } leaf admin-status { type leafref { path "/interface[name = current()/../if-name]" + "/admin-status"; } } } LP, Jernej --------------060602020007060601030207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

RFC6020, Section 9.9.2.:
   o  The context node is the node in the data tree for which the "path"
      statement is defined.

   The accessible tree depends on the context node:

   o  If the context node represents configuration data, the tree is the
      data in the NETCONF datastore where the context node exists.  The
      XPath root node has all top-level configuration data nodes in all
      modules as children.

   o  Otherwise, the tree is all state data on the device, and the
      <running/> datastore.  The XPath root node has all top-level data
      nodes in all modules as children.
RFC6020, Section 3.
   o  data node: A node in the schema tree that can be instantiated in a
      data tree.  One of container, leaf, leaf-list, list, and anyxml.

   o  data tree: The instantiated tree of configuration and state data
      on a device.
A leafref defined within a notification/rpc definition is a not part of the data tree, right? It cannot be instantiated as configuration or state data, since it represents neither.  So what is current() supposed to return in this case?

RFC6020, Section 6.4.1.
   o  The function library is the core function library defined in
      [XPATH], and a function "current()" that returns a node set with
      the initial context node.
This function should only be able to return nodes, that are part of the accessible tree for an expression, yet in case of notifications and rpcs, the text seems to say that the initial context node is not part of the accessible tree. Are there two accessible trees?

Section 9.9.2. has an example where current() is used inside a notification, which indicates what's supposed to happen, but can it?
   The following notification defines two leafrefs to refer to an
   existing admin-status:

     notification link-failure {
         leaf if-name {
             type leafref {
                 path "/interface/name";
             }
         }
         leaf admin-status {
             type leafref {
                 path
                   "/interface[name = current()/../if-name]"
                 + "/admin-status";
             }
         }
     }

LP, Jernej

 
--------------060602020007060601030207-- From nobody Fri Mar 14 07:58:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386D21A015E for ; Fri, 14 Mar 2014 07:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFb89HPCCro0 for ; Fri, 14 Mar 2014 07:58:51 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id EB2E01A0158 for ; Fri, 14 Mar 2014 07:58:50 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 554D937C2E6; Fri, 14 Mar 2014 15:58:43 +0100 (CET) Date: Fri, 14 Mar 2014 15:58:43 +0100 (CET) Message-Id: <20140314.155843.1161893672918712029.mbj@tail-f.com> To: jernej.tuljak@mg-soft.si From: Martin Bjorklund In-Reply-To: <532317C2.8090204@mg-soft.com> References: <532317C2.8090204@mg-soft.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_5uTuy3nPYsKx-c5770WyNxpd64 Cc: netmod@ietf.org Subject: Re: [netmod] Is current() broken for path expressions defined inside notifications/rpcs? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 14:58:53 -0000 Hi, Yes this is broken. It is on the list of issues to consider for YANG 1.1. See inline. Jernej Tuljak wrote: > Hi, > > RFC6020, Section 9.9.2.: > > o The context node is the node in the data tree for which the "path" > statement is defined. > > The accessible tree depends on the context node: > > o If the context node represents configuration data, the tree is the > data in the NETCONF datastore where the context node exists. The > XPath root node has all top-level configuration data nodes in all > modules as children. > > o Otherwise, the tree is all state data on the device, and the > datastore. The XPath root node has all top-level data > nodes in all modules as children. > > RFC6020, Section 3. > > o data node: A node in the schema tree that can be instantiated in a > data tree. One of container, leaf, leaf-list, list, and anyxml. > > o data tree: The instantiated tree of configuration and state data > on a device. > > A leafref defined within a notification/rpc definition is a not part > of the data tree, right? It cannot be instantiated as configuration or > state data, since it represents neither. So what is current() > supposed to return in this case? The root node of the state + running tree, which makes it pretty meaningless. > RFC6020, Section 6.4.1. > > o The function library is the core function library defined in > [XPATH ], and a > function "current()" that returns a node set with > the initial context node. > > This function should only be able to return nodes, that are part of > the accessible tree for an expression, yet in case of notifications > and rpcs, the text seems to say that the initial context node is not > part of the accessible tree. Are there two accessible trees? > > Section 9.9.2. has an example where current() is used inside a > notification, which indicates what's supposed to happen, but can it? > > The following notification defines two leafrefs to refer to an > existing admin-status: > > notification link-failure { > leaf if-name { > type leafref { > path "/interface/name"; > } > } > leaf admin-status { > type leafref { > path > "/interface[name = current()/../if-name]" > + "/admin-status"; > } > } > } This needs to be fixed. /martin From nobody Fri Mar 14 08:25:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5591A016E for ; Fri, 14 Mar 2014 08:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sx_XoBu7RsPE for ; Fri, 14 Mar 2014 08:25:21 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id E34261A0169 for ; Fri, 14 Mar 2014 08:25:20 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id i8so2999040qcq.37 for ; Fri, 14 Mar 2014 08:25:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cKRqiLfLI639iiVU7vqq/zJfgO6lZ5BJ0htKnDO+q/E=; b=GN4My5TdDqgIcJkYSYvugm6sJt/WmS2NB951OeENrbNqy1+qNLnLpHour8wRdkk7Ky T4nQj9GYTEQGoDTaQgXdhcikzLGeJc/2odIZgaUXZChkwfGoyMy8ylNXK4Wgf7HIirm5 yX8hU8IM7BrM6ng4NSgLnh3LQKVFlpXfEnlBEzxypSPu6FuGcPCEXv8AbKPOezU0o5r8 L8MN+KTLhq53uasKY6XQFZIoOlvxIdRosLGS+q+QLEU0YdAD6EhkbuTERp1C0SSl8LJX UXf+UPPVOfyTToMBgQNlV2uttBtDnIX0+FYNI3uBh998D/Onyxx0o3m8kqBXi2fD0fwR X+CQ== X-Gm-Message-State: ALoCoQkLXt7LmpPtulC0kbu48zeSZ84Hq9K28SuhpfFPimGZ2NrF4O1yWV0NMUjNuBGPtSilJ9Gz MIME-Version: 1.0 X-Received: by 10.140.36.77 with SMTP id o71mr9938247qgo.25.1394810713912; Fri, 14 Mar 2014 08:25:13 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Fri, 14 Mar 2014 08:25:13 -0700 (PDT) In-Reply-To: <20140314.155843.1161893672918712029.mbj@tail-f.com> References: <532317C2.8090204@mg-soft.com> <20140314.155843.1161893672918712029.mbj@tail-f.com> Date: Fri, 14 Mar 2014 08:25:13 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c15fa621cdd104f492ad3e Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/--PCb2_p8ko722m_x9QFhHd689Y Cc: "netmod@ietf.org" Subject: Re: [netmod] Is current() broken for path expressions defined inside notifications/rpcs? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 15:25:24 -0000 --001a11c15fa621cdd104f492ad3e Content-Type: text/plain; charset=ISO-8859-1 Hi, On Fri, Mar 14, 2014 at 7:58 AM, Martin Bjorklund wrote: > Hi, > > Yes this is broken. It is on the list of issues to consider for YANG > 1.1. > > Same applies for leafref in a typedef-stmt or within a grouping. See inline. > > > Jernej Tuljak wrote: > > Hi, > > > > RFC6020, Section 9.9.2.: > > > > o The context node is the node in the data tree for which the "path" > > statement is defined. > > > > The accessible tree depends on the context node: > > > > o If the context node represents configuration data, the tree is the > > data in the NETCONF datastore where the context node exists. The > > XPath root node has all top-level configuration data nodes in all > > modules as children. > > > > o Otherwise, the tree is all state data on the device, and the > > datastore. The XPath root node has all top-level data > > nodes in all modules as children. > > > > RFC6020, Section 3. > > > > o data node: A node in the schema tree that can be instantiated in a > > data tree. One of container, leaf, leaf-list, list, and anyxml. > > > > o data tree: The instantiated tree of configuration and state data > > on a device. > > > > A leafref defined within a notification/rpc definition is a not part > > of the data tree, right? It cannot be instantiated as configuration or > > state data, since it represents neither. So what is current() > > supposed to return in this case? > > The root node of the state + running tree, which makes it pretty > meaningless. > The root, no -- the expression: yes. The root is just a conceptual node that has as its child nodes all top-level YANG data nodes. This part is easy to implement. The problem is the current() function since the context node is not part of the same document as the rest of the expression. This is broken. Our code does a simple hack that sort of works ;-) The context node is set to the document root if it is unknown. > > > RFC6020, Section 6.4.1. > > > > o The function library is the core function library defined in > > [XPATH ], and a > > function "current()" that returns a node set with > > the initial context node. > > > > This function should only be able to return nodes, that are part of > > the accessible tree for an expression, yet in case of notifications > > and rpcs, the text seems to say that the initial context node is not > > part of the accessible tree. Are there two accessible trees? > > > > Section 9.9.2. has an example where current() is used inside a > > notification, which indicates what's supposed to happen, but can it? > > > > The following notification defines two leafrefs to refer to an > > existing admin-status: > > > > notification link-failure { > > leaf if-name { > > type leafref { > > path "/interface/name"; > > } > > } > > leaf admin-status { > > type leafref { > > path > > "/interface[name = current()/../if-name]" > > + "/admin-status"; > > } > > } > > } > > This needs to be fixed. > > > /martin > > Andy --001a11c15fa621cdd104f492ad3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,


On Fri, Mar 14, 2014 at 7:58 AM, Martin Bjorklund <mbj@tail-f.com<= /a>> wrote:
Hi,

Yes this is broken. =A0It is on the list of issues to consider for YANG
1.1.


Same applies for leafref in a typedef-= stmt or within a grouping.


See inline.


Jernej Tuljak <jernej.tuljak= @mg-soft.si> wrote:
> Hi,
>
> RFC6020, Section 9.9.2.:
>
> =A0 =A0o =A0The context node is the node in the data tree for which th= e "path"
> =A0 =A0 =A0 statement is defined.
>
> =A0 =A0The accessible tree depends on the context node:
>
> =A0 =A0o =A0If the context node represents configuration data, the tre= e is the
> =A0 =A0 =A0 data in the NETCONF datastore where the context node exist= s. =A0The
> =A0 =A0 =A0 XPath root node has all top-level configuration data nodes= in all
> =A0 =A0 =A0 modules as children.
>
> =A0 =A0o =A0Otherwise, the tree is all state data on the device, and t= he
> =A0 =A0 =A0 <running/> datastore. =A0The XPath root node has all= top-level data
> =A0 =A0 =A0 nodes in all modules as children.
>
> RFC6020, Section 3.
>
> =A0 =A0o =A0data node: A node in the schema tree that can be instantia= ted in a
> =A0 =A0 =A0 data tree. =A0One of container, leaf, leaf-list, list, and= anyxml.
>
> =A0 =A0o =A0data tree: The instantiated tree of configuration and stat= e data
> =A0 =A0 =A0 on a device.
>
> A leafref defined within a notification/rpc definition is a not part > of the data tree, right? It cannot be instantiated as configuration or=
> state data, since it represents neither. =A0So what is current()
> supposed to return in this case?

The root node of the state + running tree, which makes it pretty
meaningless.


This part is easy to implement.

The problem i= s the current() function since the context node is not part
of th= e same document as the rest of the expression. =A0This is broken.

The context node is set to the document root if it is unknown.

> RFC6020, Section 6.4.1.
>
> =A0 =A0o =A0The function library is the core function library defined = in
> =A0 =A0 =A0 [XPATH <https://tools.ietf.org/html/rfc6020#ref-XPATH<= /a>>], and a
> =A0 =A0 =A0 function "current()" that returns a node set wit= h
> =A0 =A0 =A0 the initial context node.
>
> This function should only be able to return nodes, that are part of > the accessible tree for an expression, yet in case of notifications > and rpcs, the text seems to say that the initial context node is not > part of the accessible tree. Are there two accessible trees?
>
> Section 9.9.2. has an example where current() is used inside a
> notification, which indicates what's supposed to happen, but can i= t?
>
> =A0 =A0The following notification defines two leafrefs to refer to an<= br> > =A0 =A0existing admin-status:
>
> =A0 =A0 =A0notification link-failure {
> =A0 =A0 =A0 =A0 =A0leaf if-name {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0type leafref {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0path "/interface/name"; > =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0 =A0leaf admin-status {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0type leafref {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0path
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"/interface[name =3D curre= nt()/../if-name]"
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+ "/admin-status";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0 =A0}
> =A0 =A0 =A0}

This needs to be fixed.


/martin



--001a11c15fa621cdd104f492ad3e-- From nobody Fri Mar 14 12:32:43 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF961A0196 for ; Fri, 14 Mar 2014 12:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcikEk9OPq4M for ; Fri, 14 Mar 2014 12:32:40 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 69DF11A0092 for ; Fri, 14 Mar 2014 12:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3808; q=dns/txt; s=iport; t=1394825553; x=1396035153; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=N0DkBEkTlGI6dR0CZc9OLK/f+76gq+SF0lWHXJZiurc=; b=ANFkWBAwYSqziYQtqtorgIdHHtThY9CQdA7BlSMBrQqSJLSWsqkjq8Ze 1rNxHFWGtIEU3iDZPl7y4UCdtMAtVDBSVkkdb0ZnaCoRn8gJVUsHlyrK1 zJcWQ+DfvCiDTuEfZZKXbobaA7x5EluVpZqZZhg1dWza8AN1nzjy06qwK 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMGAA9YI1OtJXG//2dsb2JhbABZgwY7UQa6RoZhT4EZFnSCJQEBAQQBAQE3MQMLEAIBCBgeECcLJQIEAQ0FCYdwCAXUMxeOZweEOASYRYEykHyDLYIr X-IronPort-AV: E=Sophos;i="4.97,656,1389744000"; d="scan'208";a="310407612" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 14 Mar 2014 19:32:33 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2EJWXVT022977 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Mar 2014 19:32:33 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.3]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Fri, 14 Mar 2014 14:32:33 -0500 From: "Derek Man-Kit Yeung (myeung)" To: Ladislav Lhotka , "Yi Yang (yiya)" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt Thread-Index: AQHPDgglTcSsF5Wm80Ok259R/K6NOZrW54cAgAAKUQCACkjaAA== Date: Fri, 14 Mar 2014 19:32:32 +0000 Message-ID: References: <20140110133016.24678.42711.idtracker@ietfa.amsl.com> <9C81158E-5B4C-4479-AEA5-23CBCC020ADD@nic.cz> In-Reply-To: <9C81158E-5B4C-4479-AEA5-23CBCC020ADD@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.154.210.99] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/huh_EDp-hqFkbLKFkGQ-dVyP-TI Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 19:32:42 -0000 On 3/7/14 2:29 PM, "Ladislav Lhotka" wrote: > >On 07 Mar 2014, at 22:52, Yi Yang (yiya) wrote: > >> One thing is missing from the data model is association with vrf. > >I agree with what Martin wrote in a parallel thread. I believe the >routing module (and YANG augment statement) provide sufficient hooks for >implementing VRF as a specific type of routing-instance. The draft mentioned the routing-instance could be used to represents a logical router.=20 The term "logical router" in one or more vendors mean a partition of the physical router into multiple logical units, each could have multiple VRFs. Does the draft intend to manage "logical router" in the above definition? Some clarification will be useful. - Derek > >I think though that other work extending the routing module is much more >needed, namely vendor-neutral data models for routing protocols. > >The consensus of the NETMOD WG was that these new modules should be >developed by experts in the Routing Area (VRF in the MPLS WG?). The >NETMOD WG and YANG Doctors will certainly help but the bulk of this work >should be done by domain experts. > >Lada > >>=20 >> Another concern I have is about address family. To facilitate a query >> based on AFI only, or SAFI only, it seems more convenient to use two >>leafs >> (AFI and SAFI) instead of one (AFI-SAFI). >>=20 >> Yi >>=20 >>=20 >>=20 >>=20 >> On 1/10/14 8:30 AM, "internet-drafts@ietf.org" >> >> wrote: >>=20 >>>=20 >>> 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 Working >>> Group of the IETF. >>>=20 >>> Title : A YANG Data Model for Routing Management >>> Author : Ladislav Lhotka >>> Filename : draft-ietf-netmod-routing-cfg-13.txt >>> Pages : 95 >>> Date : 2014-01-10 >>>=20 >>> Abstract: >>> This document contains a specification of three YANG modules. >>> Together they form the core routing data model which serves as a >>> framework for configuring and managing a routing subsystem. It is >>> expected that these modules will be augmented by additional YANG >>> modules defining data models for individual routing protocols and >>> other related functions. The core routing data model provides common >>> building blocks for such extensions - routing instances, routes, >>> routing information bases (RIB), routing protocols and route filters. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg-13 >>>=20 >>>=20 >>> 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. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> _______________________________________________ >> 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 From nobody Fri Mar 14 12:48:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491501A01B5 for ; Fri, 14 Mar 2014 12:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRXPRlhl86tO for ; Fri, 14 Mar 2014 12:48:06 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 908D11A01B0 for ; Fri, 14 Mar 2014 12:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6722; q=dns/txt; s=iport; t=1394826480; x=1396036080; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hTuLO3UBulWiz7M/G+QAPHh/qEeylASgn+oZUWlryaQ=; b=VDoEWprp1J9LLBjTy8IRv5bsNNeXaWmeGKdyT4KVMIOHIfiqGjG8dkBx qMqqv4Rc4c/nudlhtAt1iCkS0UKUJxhBav9EUgVTwIlxpkJKOoXGoNO4b wLNcF8D4KUjXrdb+UibL9w6gXMw91MUwOZ5WME4D1ewFqABKf0rRyrVTT I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFABBcI1OtJXG+/2dsb2JhbABZgwY7V4MGviFPGYEAFnSCJQEBAQMBNDoLEAIBCBwoAgIwJQIEDgUJEodWCA2VTZwPBqJVF4EjjHMBAU8HBIJlgU8EmEWSLoMtgXI5 X-IronPort-AV: E=Sophos;i="4.97,656,1389744000"; d="scan'208";a="27590789" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-5.cisco.com with ESMTP; 14 Mar 2014 19:47:59 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2EJlxNq014539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Mar 2014 19:47:59 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.3]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Fri, 14 Mar 2014 14:47:58 -0500 From: "Derek Man-Kit Yeung (myeung)" To: Ladislav Lhotka Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt Thread-Index: AQHPN6a8TcSsF5Wm80Ok259R/K6NOZrRZ2eAgAJK3ACAAJT0AIAMpIsA Date: Fri, 14 Mar 2014 19:47:58 +0000 Message-ID: References: <20140111.133634.462426147.mbj@tail-f.com> <12A63CCF-69CE-4D43-A3EC-F420635B5237@nic.cz> <20140220134130.GA19665@elstar.local> <20140220.145129.73716044088019744.mbj@tail-f.com> <657A1870-B234-4489-8F0E-A85559843C16@nic.cz> <7AC19724-68FC-4A06-B491-8DA29BD2A1B7@nic.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.154.210.99] Content-Type: text/plain; charset="euc-kr" Content-ID: <947BEFEE17142B4B8CD19A0AF1EEE735@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/MHertpzGU6aoK5iz860KYJwKCf8 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 19:48:09 -0000 DQoNCk9uIDMvNi8xNCAyOjQzIEFNLCAiTGFkaXNsYXYgTGhvdGthIiA8bGhvdGthQG5pYy5jej4g d3JvdGU6DQoNCj4iRGVyZWsgTWFuLUtpdCBZZXVuZyAobXlldW5nKSIgPG15ZXVuZ0BjaXNjby5j b20+IHdyaXRlczoNCj4NCj4uLi4NCj4NCj4+Pj4gMykgR2l2ZW4gcm91dGluZy1wcm90b2NvbCBo YXMgb25seSBuYW1lIGFzIHRoZSBrZXkNCj4+Pj4gICAgICAgICAgIGxpc3Qgcm91dGluZy1wcm90 b2NvbCB7DQo+Pj4+ICAgICAgICAgICAgICAga2V5ICJuYW1lIjsNCj4+Pj4gICBXb3VsZCBpdCBw cmV2ZW50IGRpZmZlcmVudCBwcm90b2NvbHMgZnJvbSB1c2luZyB0aGUgc2FtZSBuYW1lPyBMaWtl DQo+Pj4+ICJyb3V0ZXIgb3NwZiAxMDEiIGFuZCAicm91dGVyIHJpcCAxMDEiIGF0IHRoZSBzYW1l IHRpbWUgdXNpbmcgSU9TDQo+Pj4+c3ludGF4Pw0KPj4+DQo+Pj5MaXN0IGtleXMgaGF2ZSB0byBi ZSB1bmlxdWUsIHNvIGluIHRoaXMgY2FzZSB5b3Ugd291bGQgbmVlZCB0byB1c2UgZS5nLg0KPj4+ qfhvc3BmLTEwMan3IGFuZCCp+HJpcC0xMDGp9yBhcyB0aGUga2V5cy4NCj4+DQo+Pg0KPj4gRFk+ IE9uZSB0aGUgcm91dGVyLCB0aGUgcm91dGluZyBwcm90b2NvbCBpcyBpZGVudGlmaWVkIGJ5IHRo ZSB0eXBlIGFuZCBhDQo+PiB0YWcuDQo+PiBEWT4gRXhhbXBsZSBpcyB0eXBlIE9TUEYgYW5kIHRh ZyAxMDEuIEZvciBkaXNwbGF5IHB1cnBvc2UsIHlvdSBtYXkgc2VlDQo+PiAib3NwZiAxMDEiLCAi UHJvdG9jb2w6IE9TUEYsIFRhZzogMTAxIiBvciAib3NwZi0xMDEiIGRlcGVuZGluZyBvbg0KPj4g aW1wbGVtZW50YXRpb24uDQo+PiBEWT4gV2hlbiBJIHJlYWQgeW91ciBkcmFmdCwgSSB0b29rIHRo YXQgbmFtZSBtZWFuIHRhZyBhbmQgaGVuY2UgdGhlDQo+PiB1bmlxdWVuZXNzIHF1ZXN0aW9uLg0K Pg0KPkFzIHRoaXMgaXMgYSB2ZW5kb3ItbmV1dHJhbCBtb2R1bGUsIHdlIHRyaWVkIHRvIGF2b2lk IGFzc2lnbmluZyBzZW1hbnRpY3MNCj50byB0aGUgbmFtZXMgb2Ygb2JqZWN0cyBiZWNhdXNlIHRo YXQgd291bGQgaGFyZGx5IHdvcmsgZm9yIGRpZmZlcmVudA0KPnZlbmRvcnMuIEFuIGltcGxlbWVu dGF0aW9uIG1heSB1c2UgcmFuZG9tIHN0cmluZ3MgYXMgbGlzdCBrZXlzIHByb3ZpZGVkDQo+dGhl eSBhcmUgdW5pcXVlLg0KDQpDb21iaW5hdGlvbiBvZiB0eXBlIGFuZCB0YWcgaXMgdmVyeSBnZW5l cmljIGZvciBpZGVudGlmeWluZyBhIHJvdXRpbmcNCnByb3RvY29sLg0KSWYgd2UgdXNlIGEgbmFt ZSBzdHJpbmcgd2hpY2ggaW5jbHVkZSBib3RoIHRoZSB0eXBlIGFuZCB0YWcgaW5mbyBhbmQgZG8N Cm5vdCBwcm92aWRlIGEgZm9ybWF0IGZvciBpdCwNCnRoZW4gSSBhbSBjb25jZXJuZWQgdGhhdCB0 aGUgY29udHJvbGxlciBuZWVkIHRvIHRvIGFkanVzdCBuYW1lIHN0cmluZw0KYWNjb3JkaW5nbHkg ZGVwZW5kaW5nIG9uIHdoaWNoIHZlbmRvciBpdCBpcyB0YWxraW5nIHRvLg0KSXQgaXMgZG9hYmxl IGJ1dCBpdCBzZWVtcyB0byBkZWZlYXQgdGhlIHB1cnBvc2Ugb2YgaGF2aW5nIHRoZSBzYW1lIGRh dGENCm1vZGVsIGluIHRoZSBmaXJzdCBwbGFjZS4NCg0KPg0KPj4gRFk+IElmIG5hbWUgZXF1YXRl IGEgc3RyaW5nIGxpa2UgIm9zcGYtMTAxIiwgdGhlbiB0aGUgc3RyaW5nIGNhbm5vdCBiZQ0KPj4g anVzdCBhcmJpdHJhcnkgYXMgdGhlIGRyYWZ0IHNhaWQuDQo+DQo+Im9zcGYtMTAxIiBpcyBqdXN0 IGFuIGV4YW1wbGUgaG93IHRoZSBuYW1lIGNhbiBiZSBkaXNhbWJpZ3VhdGVkIGluIGEgd2F5DQo+ dGhhdCBpcyAiZnJpZW5kbHkiIHRvIGEgcGFydGljdWxhciBwbGF0Zm9ybS4NCj4NCj4+IERZPiBJ dCBoYXMgdG8gaGF2ZSBzb21lIGZvcndhcmQgbGlrZSA8Um91dGluZyBQcm90b2NvbCBUeXBlDQo+ PiBTdHI+PFNlcGFyYXRvcj48VGFnPiBzbyB0aGUgbmV0d29yayBkZXZpY2UgY2FuIGV4dHJhY3Qg dGhlIHRhZyBmcm9tIGl0Lg0KPg0KPkkgZG9uJ3Qga25vdyB3aGF0IHlvdSBtZWFuIGJ5IGEgImZv cndhcmQiLiBIb3cgaXMgdGhpcyB0YWcgc3VwcG9zZWQgdG8gYmUNCj51c2VkPw0KDQpTb3JyeS4g VHlwb3MuIEkgbWVhbiAiZm9ybWF0Ii4NCkZvciB0aGUgc3RyaW5nICJvc3BmLTEiLCAib3NwZiIg aXMgdGhlIHR5cGUgYW5kICIxIiBpcyB0aGUgdGFnLg0KDQo+DQo+PiBEWT4gTXkgcHJlZmVyZW5j ZSBpcyB0byB0cmVhdCB0aGUgbmFtZSBhcyA8VGFnPiBhbmQgaW5jbHVkZSB0eXBlIGEgcGFydA0K Pj5vZg0KPj4gdGhlIGtleS4gDQo+PiBEWT4gRXZlbiBpZiBuYW1lIG1lYW4ganVzdCB0aGUgdGFn LCBzdGlsbCBuZWVkIHNvbWUga2luZCBvZiBwYXR0ZXJuIGFzDQo+Pm5vdA0KPj4gYWxsIGNoYXJh Y3RlciBpcyBhbGxvd2VkLg0KPj4gRFk+IElzIHRoaXMgYSB3YXkgaW4gWUFORyB0byBhdWdtZW50 IHRoZSBuYW1lIHdpdGggcGF0dGVybiB3aGljaCBzdWl0DQo+PnRoZQ0KPj4gaW1wbGVtZW50YXRp b24gdGhhdCBpdCB0YWxrIHRvPw0KPg0KPlllcywgaXQgaXMuIFNvbWUgcHJvdG9jb2xzIGFkZCBh IHRhZyBhcyBhIG5ldyByb3V0ZSBhdHRyaWJ1dGUgLSBzZWUgdGhlDQo+ZXhhbXBsZSBSSVAgaW1w bGVtZW50YXRpb24gaW4gQXBwZW5kaXggQy4NCj4NCj5JZiBhIHZlbmRvciB0aGVuIHdhbnRzIHRv IHVzZSBhIHRhZyBvciBhbnl0aGluZyBlbHNlIGluIGFuDQo+aW1wbGVtZW50YXRpb24tc3BlY2lm aWMgd2F5LCBpdCBjYW4gZG8gc28gYnkgd3JpdGluZyBhIHByb3ByaWV0YXJ5IG1vZHVsZQ0KPnRo YXQgYXVnbWVudHMgdGhlIHN0YW5kYXJkIG1vZHVsZSB3aGVyZSBuZWNlc3NhcnkuIFRoaXMgaXMg SU1PIG11Y2gNCj5iZXR0ZXIgdGhhbiBlbmNvZGUgc2VtYW50aWNzIGludG8gcm91dGluZyBwcm90 b2NvbCBuYW1lcy4NCg0KDQpXaGF0IGFib3V0IG1ha2luZyBib3RoIHR5cGUgYW5kIG5hbWUgYXMg dGhlIGtleT8NCg0KPg0KPj4NCj4+IERZPiBGb3IgdG9wb2xvZ3ksIGl0IGlzIGp1c3QgYSBSSUIu DQo+PiBEWT4gQmVmb3JlIHRvcG9sb2d5LCBhIFJJQiBpcyBpZGVudGlmaWVkIGJ5IChOYW1lLCBB RkksIFNBRkkpIGxpa2UNCj4+ICgiQ3VzdG9tZXIxIiwgSVB2NCwgVU5JQ0FTVCkuDQo+PiBEWT4g VG9wb2xvZ3kgYWRkIGFuIGV4dHJhY3QgdG9wb2xvZ3kgbmFtZSBzbyB0aGUgaWRlbnRpZmllciBi ZWNvbWUgKFZSRg0KPj4gbmFtZSwgQUZJLCBTQUZJLCBUb3BvIG5hbWUpLg0KPj4gRFk+IEV4YW1w bGUgYXJlICgiQ3VzdG9tZXIxIiwgSVB2NCwgVU5JQ0FTVCwgIkdvbGQiKSwgKCJDdXN0b21lcjEi LA0KPj5JUHY0LA0KPj4gVU5JQ0FTVCwgIlNsaXZlciIpLCAoIkN1c3RvbWVyMSIsIElQdjQsIFVO SUNBU1QsICJCcm9uemUiKQ0KPj4gRFk+IEl0IGlzIGxpa2UgcHJvdmlkaW5nIG11bHRpcGxlIGRh dGEgaW4gdGhlIHVuZGVyIHRoZSBzYW1lIFZSRiwgQUZJDQo+PmFuZA0KPj4gU0FGSS4NCj4+IERZ PiBJdCBpcyBzaW1pbGFyIHRvIHRoZSByb3V0aW5nIHByb3RvY29sIG5hbWUgZGlzY3Vzc2lvbi4N Cj4+IERZPiBFaXRoZXIgYW4gdG9wb2xvZ3kgbmFtZSBpcyBhZGRlZCAoQ291bGQgaXQgYmUgdGhy b3VnaCBhdWdtZW50YXRpb24NCj4+YXMNCj4+IG5vdCBhbGwgdmVuZG9ycyBzdXBwb3J0IHRvcG9s b2d5KSwNCj4NCj5JIGJlbGlldmUgdGhpcyB0b3BvbG9neSBvYmplY3QgaGFzIHRvIGRvIHdpdGgg bGluay1zdGF0ZSBwcm90b2NvbHMsIHNvIGluDQo+bXkgdmlldyBhIGZ1dHVyZSBpbXBsZW1lbnRh dGlvbiBvZiBPU1BGIG9yIElTLUlTIGhhcyB0byBkZXNpZ24gbmV3DQo+Y29uZmlndXJhdGlvbiBh bmQvb3Igc3RhdGUgZGF0YSByZXByZXNlbnRpbmcgdG9wb2xvZ2llcywgYW5kIGF1Z21lbnQNCj4i cnQ6cm91dGluZy1wcm90b2NvbCIgKG9yICJydDppbnRlcmZhY2UiKSB3aXRoIGl0Lg0KDQoNCk5v LiBpdCBpcyBub3QgbGluayBzdGF0ZSBwcm90b2NvbHMgc3BlY2lmaWMuIEl0IGlzIHBhcnQgb2Yg dGhlIFJJQiBkZXNpZ24uDQpTdXBwb3NlIHJvdXRpbmctaW5zdGFuY2VzIGNvdWxkIG1lYW4gVlJG IChmcm9tIGJlbG93KS4gSW4gdGhhdCBjYXNlLCB0aGUNClJJQiBpbnNpZGUgdGhlIHJvdXRpbmct c3RhbmNlcyBjb3VsZCBiZSBhICJ0b3BvbG9neSIuIFdlIHN0aWxsIGhhdmUgZmlndXJlDQpvdXQg aG93IHRoZSBpZGVudGlmaWVyIHNob3VsZCBsb29rIGxpa2UuDQoNClRoYW5rcywNCi0gRGVyZWsN Cg0KPg0KPj4gRFk+IG9yIHRoZSBSSUIgbmFtZSBpcyBtYWRlIHRvIGhhdmUgY2VydGFpbiBmb3Jt YXQgbGlrZSA8VlJGIE5hbWU+IG9yDQo+PjxWUkYNCj4+IE5hbWU+OjxUb3BvIE5hbWU+Lg0KPg0K PkEgZGlzY3Vzc2lvbiBvZiBWUkZzIGlzIG5vdyBnb2luZyBvbiBpbiB0aGUgTkVUQ09ORiBtYWls aW5nIGxpc3QgYW5kIEkNCj5hbHJlYWR5IGV4cHJlc3NlZCBteSBvcGluaW9uIHRoZXJlOg0KPg0K Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRjb25mL2N1cnJlbnQvbXNn MDg3NTUuaHRtbA0KPg0KPkluIHNob3J0LCBJIHRoaW5rIHRoZSBWUkYgY29uY2VwdCBzaG91bGQg YmUgZGVmaW5lZCBhcyBhIHNwZWNpYWwgdHlwZSBvZg0KPnJvdXRpbmctaW5zdGFuY2UuDQo+DQo+ VGhhbmtzLCBMYWRhDQo+DQo+PiBEWT4gSXQgd2lsbCBuZWVkIG1vcmUgZGlzY3Vzc2lvbiB0byBh Z3JlZSBvbiBzb2x1dGlvbi4NCj4NCj4NCj4NCj4+DQo+PiBUaGFua3MsDQo+PiAtIERlcmVrDQo+ Pg0KPj4+DQo+Pj5MYWRhDQo+Pj4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiBUaGFua3MsDQo+Pj4+IC0g RGVyZWsNCj4+Pj4gDQo+Pj4+IA0KPj4+DQo+Pj4tLQ0KPj4+TGFkaXNsYXYgTGhvdGthLCBDWi5O SUMgTGFicw0KPj4+UEdQIEtleSBJRDogRTc0RThDMEMNCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4N Cj4NCj4tLSANCj5MYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+UEdQIEtleSBJRDogRTc0 RThDMEMNCg0K From nobody Fri Mar 14 12:50:04 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B03C1A01C3 for ; Fri, 14 Mar 2014 12:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnxm--bI6mzR for ; Fri, 14 Mar 2014 12:50:01 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 258F51A01C1 for ; Fri, 14 Mar 2014 12:50:01 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id F3B5C13FAF1; Fri, 14 Mar 2014 20:49:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394826593; bh=/aUqMEXvC4QnWnUI5rZ+KU9U3xeOHlTT1Fdkh//q5bA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Np1QrqptFsskqKsqLmpDaTQYO3zBEVFhWR+woHuVUcRlYoyO38uBAsffV5qzYfEQl Gb9PjfaF/LNnn9k/9vAs734z05jamzerwpHAJlxWQn3Rms2sv9fHLH7GOVFaJAyN3O WlHjxZt4XqVEql6YaqP9A05GRSh237GrIaVq1wLo= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 14 Mar 2014 20:49:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0ED855DA-51BE-4DE6-AB22-E1A9E04C0E5F@nic.cz> References: <20140110133016.24678.42711.idtracker@ietfa.amsl.com> <9C81158E-5B4C-4479-AEA5-23CBCC020ADD@nic.cz> To: "Derek Man-Kit Yeung (myeung)" X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/h7avn_vQ4c9gwo_9qxYTWWpKlsc Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 19:50:03 -0000 On 14 Mar 2014, at 20:32, Derek Man-Kit Yeung (myeung) = wrote: >=20 >=20 > On 3/7/14 2:29 PM, "Ladislav Lhotka" wrote: >=20 >>=20 >> On 07 Mar 2014, at 22:52, Yi Yang (yiya) wrote: >>=20 >>> One thing is missing from the data model is association with vrf. >>=20 >> I agree with what Martin wrote in a parallel thread. I believe the >> routing module (and YANG augment statement) provide sufficient hooks = for >> implementing VRF as a specific type of routing-instance. >=20 >=20 > The draft mentioned the routing-instance could be used to represents a > logical router.=20 >=20 > The term "logical router" in one or more vendors mean a partition of = the > physical router into multiple logical units, each could have multiple = VRFs. >=20 > Does the draft intend to manage "logical router" in the above = definition? > Some clarification will be useful. One way to implement this is to introduce two types of routing = instances, say 'logical-router=92 and =91vrf=92. The =91vrf=92 type then = would have another leaf linking it to a logical router. This is quite = like the various methods of interface stacking, see the examples in = draft-ietf-netmod-interfaces-cfg-16. Lada >=20 > - Derek >=20 >>=20 >> I think though that other work extending the routing module is much = more >> needed, namely vendor-neutral data models for routing protocols. >>=20 >> The consensus of the NETMOD WG was that these new modules should be >> developed by experts in the Routing Area (VRF in the MPLS WG?). The >> NETMOD WG and YANG Doctors will certainly help but the bulk of this = work >> should be done by domain experts. >>=20 >> Lada >>=20 >>>=20 >>> Another concern I have is about address family. To facilitate a = query >>> based on AFI only, or SAFI only, it seems more convenient to use two >>> leafs >>> (AFI and SAFI) instead of one (AFI-SAFI). >>>=20 >>> Yi >>>=20 >>>=20 >>>=20 >>>=20 >>> On 1/10/14 8:30 AM, "internet-drafts@ietf.org" >>> >>> wrote: >>>=20 >>>>=20 >>>> 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 = Working >>>> Group of the IETF. >>>>=20 >>>> Title : A YANG Data Model for Routing Management >>>> Author : Ladislav Lhotka >>>> Filename : draft-ietf-netmod-routing-cfg-13.txt >>>> Pages : 95 >>>> Date : 2014-01-10 >>>>=20 >>>> Abstract: >>>> This document contains a specification of three YANG modules. >>>> Together they form the core routing data model which serves as a >>>> framework for configuring and managing a routing subsystem. It is >>>> expected that these modules will be augmented by additional YANG >>>> modules defining data models for individual routing protocols and >>>> other related functions. The core routing data model provides = common >>>> building blocks for such extensions - routing instances, routes, >>>> routing information bases (RIB), routing protocols and route = filters. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13 >>>>=20 >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg-13 >>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Mar 14 13:00:58 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9104D1A0155 for ; Fri, 14 Mar 2014 13:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3ZDQaJiwmJV for ; Fri, 14 Mar 2014 13:00:53 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 21D321A014C for ; Fri, 14 Mar 2014 13:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5818; q=dns/txt; s=iport; t=1394827246; x=1396036846; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=svfFT2SyByuQvCaGOW/PtDa+r4LxqbrevSleOZsqHSg=; b=L2CBxrcccj9WXQw3nixsy7ipdBGJesKIEwCG9s6ODhkpgwZV+J0okbSU BauMcA7KyQl2tTNYbwqDxCgvuOUT2zX4cIpRFrxATDaW2LSJM2OhtuCBi zddgM7bIiYA5KZ6oGbQodUUqMSOhEg/NDs5pxx+ZxiJ6NpDUWClCd6uP5 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFACFfI1OtJXG//2dsb2JhbABZgwY7V4MGviFPGYEAFnSCJgEBBDQ6CxACAQgcKAICMCUCBA4FCRKHXg2VUZwPBqJVF4EjjHMBARwzBwSCZYFPBJhFki6DLYFyOQ X-IronPort-AV: E=Sophos;i="4.97,656,1389744000"; d="scan'208";a="310229978" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 14 Mar 2014 20:00:46 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2EK0jMP017713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Mar 2014 20:00:45 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.3]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Fri, 14 Mar 2014 15:00:45 -0500 From: "Derek Man-Kit Yeung (myeung)" To: Ladislav Lhotka Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt Thread-Index: AQHPN6a8TcSsF5Wm80Ok259R/K6NOZrRZ2eAgAJK3ACAAJT0AIAMqCCA Date: Fri, 14 Mar 2014 20:00:45 +0000 Message-ID: References: <20140111.133634.462426147.mbj@tail-f.com> <12A63CCF-69CE-4D43-A3EC-F420635B5237@nic.cz> <20140220134130.GA19665@elstar.local> <20140220.145129.73716044088019744.mbj@tail-f.com> <657A1870-B234-4489-8F0E-A85559843C16@nic.cz> <7AC19724-68FC-4A06-B491-8DA29BD2A1B7@nic.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.154.210.99] Content-Type: text/plain; charset="euc-kr" Content-ID: <0C7DCAFA7FD4D04B9EA58A846C195E1E@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/pSjz-oHL7QhBZ4izTHSF2okYt2o Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 20:00:55 -0000 DQoNCk9uIDMvNi8xNCAyOjQzIEFNLCAiTGFkaXNsYXYgTGhvdGthIiA8bGhvdGthQG5pYy5jej4g d3JvdGU6DQoNCj4iRGVyZWsgTWFuLUtpdCBZZXVuZyAobXlldW5nKSIgPG15ZXVuZ0BjaXNjby5j b20+IHdyaXRlczoNCj4NCj4uLi4NCj4NCj4+Pj4gMykgR2l2ZW4gcm91dGluZy1wcm90b2NvbCBo YXMgb25seSBuYW1lIGFzIHRoZSBrZXkNCj4+Pj4gICAgICAgICAgIGxpc3Qgcm91dGluZy1wcm90 b2NvbCB7DQo+Pj4+ICAgICAgICAgICAgICAga2V5ICJuYW1lIjsNCj4+Pj4gICBXb3VsZCBpdCBw cmV2ZW50IGRpZmZlcmVudCBwcm90b2NvbHMgZnJvbSB1c2luZyB0aGUgc2FtZSBuYW1lPyBMaWtl DQo+Pj4+ICJyb3V0ZXIgb3NwZiAxMDEiIGFuZCAicm91dGVyIHJpcCAxMDEiIGF0IHRoZSBzYW1l IHRpbWUgdXNpbmcgSU9TDQo+Pj4+c3ludGF4Pw0KPj4+DQo+Pj5MaXN0IGtleXMgaGF2ZSB0byBi ZSB1bmlxdWUsIHNvIGluIHRoaXMgY2FzZSB5b3Ugd291bGQgbmVlZCB0byB1c2UgZS5nLg0KPj4+ qfhvc3BmLTEwMan3IGFuZCCp+HJpcC0xMDGp9yBhcyB0aGUga2V5cy4NCj4+DQo+Pg0KPj4gRFk+ IE9uZSB0aGUgcm91dGVyLCB0aGUgcm91dGluZyBwcm90b2NvbCBpcyBpZGVudGlmaWVkIGJ5IHRo ZSB0eXBlIGFuZCBhDQo+PiB0YWcuDQo+PiBEWT4gRXhhbXBsZSBpcyB0eXBlIE9TUEYgYW5kIHRh ZyAxMDEuIEZvciBkaXNwbGF5IHB1cnBvc2UsIHlvdSBtYXkgc2VlDQo+PiAib3NwZiAxMDEiLCAi UHJvdG9jb2w6IE9TUEYsIFRhZzogMTAxIiBvciAib3NwZi0xMDEiIGRlcGVuZGluZyBvbg0KPj4g aW1wbGVtZW50YXRpb24uDQo+PiBEWT4gV2hlbiBJIHJlYWQgeW91ciBkcmFmdCwgSSB0b29rIHRo YXQgbmFtZSBtZWFuIHRhZyBhbmQgaGVuY2UgdGhlDQo+PiB1bmlxdWVuZXNzIHF1ZXN0aW9uLg0K Pg0KPkFzIHRoaXMgaXMgYSB2ZW5kb3ItbmV1dHJhbCBtb2R1bGUsIHdlIHRyaWVkIHRvIGF2b2lk IGFzc2lnbmluZyBzZW1hbnRpY3MNCj50byB0aGUgbmFtZXMgb2Ygb2JqZWN0cyBiZWNhdXNlIHRo YXQgd291bGQgaGFyZGx5IHdvcmsgZm9yIGRpZmZlcmVudA0KPnZlbmRvcnMuIEFuIGltcGxlbWVu dGF0aW9uIG1heSB1c2UgcmFuZG9tIHN0cmluZ3MgYXMgbGlzdCBrZXlzIHByb3ZpZGVkDQo+dGhl eSBhcmUgdW5pcXVlLg0KPg0KPj4gRFk+IElmIG5hbWUgZXF1YXRlIGEgc3RyaW5nIGxpa2UgIm9z cGYtMTAxIiwgdGhlbiB0aGUgc3RyaW5nIGNhbm5vdCBiZQ0KPj4ganVzdCBhcmJpdHJhcnkgYXMg dGhlIGRyYWZ0IHNhaWQuDQo+DQo+Im9zcGYtMTAxIiBpcyBqdXN0IGFuIGV4YW1wbGUgaG93IHRo ZSBuYW1lIGNhbiBiZSBkaXNhbWJpZ3VhdGVkIGluIGEgd2F5DQo+dGhhdCBpcyAiZnJpZW5kbHki IHRvIGEgcGFydGljdWxhciBwbGF0Zm9ybS4NCj4NCj4+IERZPiBJdCBoYXMgdG8gaGF2ZSBzb21l IGZvcndhcmQgbGlrZSA8Um91dGluZyBQcm90b2NvbCBUeXBlDQo+PiBTdHI+PFNlcGFyYXRvcj48 VGFnPiBzbyB0aGUgbmV0d29yayBkZXZpY2UgY2FuIGV4dHJhY3QgdGhlIHRhZyBmcm9tIGl0Lg0K Pg0KPkkgZG9uJ3Qga25vdyB3aGF0IHlvdSBtZWFuIGJ5IGEgImZvcndhcmQiLiBIb3cgaXMgdGhp cyB0YWcgc3VwcG9zZWQgdG8gYmUNCj51c2VkPw0KPg0KPj4gRFk+IE15IHByZWZlcmVuY2UgaXMg dG8gdHJlYXQgdGhlIG5hbWUgYXMgPFRhZz4gYW5kIGluY2x1ZGUgdHlwZSBhIHBhcnQNCj4+b2YN Cj4+IHRoZSBrZXkuIA0KPj4gRFk+IEV2ZW4gaWYgbmFtZSBtZWFuIGp1c3QgdGhlIHRhZywgc3Rp bGwgbmVlZCBzb21lIGtpbmQgb2YgcGF0dGVybiBhcw0KPj5ub3QNCj4+IGFsbCBjaGFyYWN0ZXIg aXMgYWxsb3dlZC4NCj4+IERZPiBJcyB0aGlzIGEgd2F5IGluIFlBTkcgdG8gYXVnbWVudCB0aGUg bmFtZSB3aXRoIHBhdHRlcm4gd2hpY2ggc3VpdA0KPj50aGUNCj4+IGltcGxlbWVudGF0aW9uIHRo YXQgaXQgdGFsayB0bz8NCj4NCj5ZZXMsIGl0IGlzLiBTb21lIHByb3RvY29scyBhZGQgYSB0YWcg YXMgYSBuZXcgcm91dGUgYXR0cmlidXRlIC0gc2VlIHRoZQ0KPmV4YW1wbGUgUklQIGltcGxlbWVu dGF0aW9uIGluIEFwcGVuZGl4IEMuDQo+DQo+SWYgYSB2ZW5kb3IgdGhlbiB3YW50cyB0byB1c2Ug YSB0YWcgb3IgYW55dGhpbmcgZWxzZSBpbiBhbg0KPmltcGxlbWVudGF0aW9uLXNwZWNpZmljIHdh eSwgaXQgY2FuIGRvIHNvIGJ5IHdyaXRpbmcgYSBwcm9wcmlldGFyeSBtb2R1bGUNCj50aGF0IGF1 Z21lbnRzIHRoZSBzdGFuZGFyZCBtb2R1bGUgd2hlcmUgbmVjZXNzYXJ5LiBUaGlzIGlzIElNTyBt dWNoDQo+YmV0dGVyIHRoYW4gZW5jb2RlIHNlbWFudGljcyBpbnRvIHJvdXRpbmcgcHJvdG9jb2wg bmFtZXMuDQoNCg0KTmVlZCB0byBhZGRyZXNzIHRoaXMgcGFydGljdWxhciBwb2ludC4gVGhlICJ0 YWciIEkgbWVudGlvbmVkIGlzIGRpZmZlcmVudA0KdGhlbiB0aGUgdGFnIGluIHRoZSByb3V0ZS4N ClRoZSAidGFnIiBJIG1lYW4gaXMgdGhlIG5hbWUgb2YgdGhhdCByb3V0aW5nIHByb3RvY29sIG9m IGEgcGFydGljdWxhciB0eXBlLg0KDQpUaGFua3MsDQotIERlcmVrDQoNCj4NCj4+DQo+PiBEWT4g Rm9yIHRvcG9sb2d5LCBpdCBpcyBqdXN0IGEgUklCLg0KPj4gRFk+IEJlZm9yZSB0b3BvbG9neSwg YSBSSUIgaXMgaWRlbnRpZmllZCBieSAoTmFtZSwgQUZJLCBTQUZJKSBsaWtlDQo+PiAoIkN1c3Rv bWVyMSIsIElQdjQsIFVOSUNBU1QpLg0KPj4gRFk+IFRvcG9sb2d5IGFkZCBhbiBleHRyYWN0IHRv cG9sb2d5IG5hbWUgc28gdGhlIGlkZW50aWZpZXIgYmVjb21lIChWUkYNCj4+IG5hbWUsIEFGSSwg U0FGSSwgVG9wbyBuYW1lKS4NCj4+IERZPiBFeGFtcGxlIGFyZSAoIkN1c3RvbWVyMSIsIElQdjQs IFVOSUNBU1QsICJHb2xkIiksICgiQ3VzdG9tZXIxIiwNCj4+SVB2NCwNCj4+IFVOSUNBU1QsICJT bGl2ZXIiKSwgKCJDdXN0b21lcjEiLCBJUHY0LCBVTklDQVNULCAiQnJvbnplIikNCj4+IERZPiBJ dCBpcyBsaWtlIHByb3ZpZGluZyBtdWx0aXBsZSBkYXRhIGluIHRoZSB1bmRlciB0aGUgc2FtZSBW UkYsIEFGSQ0KPj5hbmQNCj4+IFNBRkkuDQo+PiBEWT4gSXQgaXMgc2ltaWxhciB0byB0aGUgcm91 dGluZyBwcm90b2NvbCBuYW1lIGRpc2N1c3Npb24uDQo+PiBEWT4gRWl0aGVyIGFuIHRvcG9sb2d5 IG5hbWUgaXMgYWRkZWQgKENvdWxkIGl0IGJlIHRocm91Z2ggYXVnbWVudGF0aW9uDQo+PmFzDQo+ PiBub3QgYWxsIHZlbmRvcnMgc3VwcG9ydCB0b3BvbG9neSksDQo+DQo+SSBiZWxpZXZlIHRoaXMg dG9wb2xvZ3kgb2JqZWN0IGhhcyB0byBkbyB3aXRoIGxpbmstc3RhdGUgcHJvdG9jb2xzLCBzbyBp bg0KPm15IHZpZXcgYSBmdXR1cmUgaW1wbGVtZW50YXRpb24gb2YgT1NQRiBvciBJUy1JUyBoYXMg dG8gZGVzaWduIG5ldw0KPmNvbmZpZ3VyYXRpb24gYW5kL29yIHN0YXRlIGRhdGEgcmVwcmVzZW50 aW5nIHRvcG9sb2dpZXMsIGFuZCBhdWdtZW50DQo+InJ0OnJvdXRpbmctcHJvdG9jb2wiIChvciAi cnQ6aW50ZXJmYWNlIikgd2l0aCBpdC4NCj4NCj4+IERZPiBvciB0aGUgUklCIG5hbWUgaXMgbWFk ZSB0byBoYXZlIGNlcnRhaW4gZm9ybWF0IGxpa2UgPFZSRiBOYW1lPiBvcg0KPj48VlJGDQo+PiBO YW1lPjo8VG9wbyBOYW1lPi4NCj4NCj5BIGRpc2N1c3Npb24gb2YgVlJGcyBpcyBub3cgZ29pbmcg b24gaW4gdGhlIE5FVENPTkYgbWFpbGluZyBsaXN0IGFuZCBJDQo+YWxyZWFkeSBleHByZXNzZWQg bXkgb3BpbmlvbiB0aGVyZToNCj4NCj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvbmV0Y29uZi9jdXJyZW50L21zZzA4NzU1Lmh0bWwNCj4NCj5JbiBzaG9ydCwgSSB0aGluayB0 aGUgVlJGIGNvbmNlcHQgc2hvdWxkIGJlIGRlZmluZWQgYXMgYSBzcGVjaWFsIHR5cGUgb2YNCj5y b3V0aW5nLWluc3RhbmNlLg0KPg0KPlRoYW5rcywgTGFkYQ0KPg0KPj4gRFk+IEl0IHdpbGwgbmVl ZCBtb3JlIGRpc2N1c3Npb24gdG8gYWdyZWUgb24gc29sdXRpb24uDQo+DQo+DQo+DQo+Pg0KPj4g VGhhbmtzLA0KPj4gLSBEZXJlaw0KPj4NCj4+Pg0KPj4+TGFkYQ0KPj4+DQo+Pj4+IA0KPj4+PiAN Cj4+Pj4gVGhhbmtzLA0KPj4+PiAtIERlcmVrDQo+Pj4+IA0KPj4+PiANCj4+Pg0KPj4+LS0NCj4+ PkxhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj4+PlBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+ Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+DQo+DQo+LS0gDQo+TGFkaXNsYXYgTGhvdGthLCBDWi5OSUMg TGFicw0KPlBHUCBLZXkgSUQ6IEU3NEU4QzBDDQoNCg== From nobody Sat Mar 15 02:12:18 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23E61A00A8 for ; Sat, 15 Mar 2014 02:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7lf9qmGdVG9 for ; Sat, 15 Mar 2014 02:12:15 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id D760C1A00A6 for ; Sat, 15 Mar 2014 02:12:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 6D7EC540608; Sat, 15 Mar 2014 10:12:05 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0G-AF4lh-2rA; Sat, 15 Mar 2014 10:11:59 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 0483B5400BB; Sat, 15 Mar 2014 10:11:58 +0100 (CET) From: Ladislav Lhotka To: "Derek Man-Kit Yeung \(myeung\)" In-Reply-To: References: <20140111.133634.462426147.mbj@tail-f.com> <12A63CCF-69CE-4D43-A3EC-F420635B5237@nic.cz> <20140220134130.GA19665@elstar.local> <20140220.145129.73716044088019744.mbj@tail-f.com> <657A1870-B234-4489-8F0E-A85559843C16@nic.cz> <7AC19724-68FC-4A06-B491-8DA29BD2A1B7@nic.cz> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Sat, 15 Mar 2014 10:11:59 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/TsXV1GGQFoTV8EiLpiU2J4eAoeU Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 09:12:18 -0000 Hi Derek, please see my responses inline. "Derek Man-Kit Yeung (myeung)" writes: > On 3/6/14 2:43 AM, "Ladislav Lhotka" wrote: > >>"Derek Man-Kit Yeung (myeung)" writes: >> >>... >> >>>>> 3) Given routing-protocol has only name as the key >>>>> list routing-protocol { >>>>> key "name"; >>>>> Would it prevent different protocols from using the same name? Like >>>>> "router ospf 101" and "router rip 101" at the same time using IOS >>>>>syntax? >>>> >>>>List keys have to be unique, so in this case you would need to use e.g. >>>>=C2=B3ospf-101=C2=B2 and =C2=B3rip-101=C2=B2 as the keys. >>> >>> >>> DY> One the router, the routing protocol is identified by the type and a >>> tag. >>> DY> Example is type OSPF and tag 101. For display purpose, you may see >>> "ospf 101", "Protocol: OSPF, Tag: 101" or "ospf-101" depending on >>> implementation. >>> DY> When I read your draft, I took that name mean tag and hence the >>> uniqueness question. >> >>As this is a vendor-neutral module, we tried to avoid assigning semantics >>to the names of objects because that would hardly work for different >>vendors. An implementation may use random strings as list keys provided >>they are unique. > > Combination of type and tag is very generic for identifying a routing > protocol. I don't think it is that generic - two examples: - JUNOS doesn't use such tags at all because multiple instances of the same= routing protocol have to be in different routing instances. - BIRD routing daemon does use tags for protocol instances, e.g. protocol ospf foo { ... } but the same tag ("foo") cannot be reused for a different protocol type. > If we use a name string which include both the type and tag info and do > not provide a format for it, > then I am concerned that the controller need to to adjust name string > accordingly depending on which vendor it is talking to. > It is doable but it seems to defeat the purpose of having the same data > model in the first place. > >> >>> DY> If name equate a string like "ospf-101", then the string cannot be >>> just arbitrary as the draft said. >> >>"ospf-101" is just an example how the name can be disambiguated in a way >>that is "friendly" to a particular platform. >> >>> DY> It has to have some forward like >> Str> so the network device can extract the tag from it. >> >>I don't know what you mean by a "forward". How is this tag supposed to be >>used? > > Sorry. Typos. I mean "format". > For the string "ospf-1", "ospf" is the type and "1" is the tag. > >> >>> DY> My preference is to treat the name as and include type a part >>>of >>> the key.=20 >>> DY> Even if name mean just the tag, still need some kind of pattern as >>>not >>> all character is allowed. >>> DY> Is this a way in YANG to augment the name with pattern which suit >>>the >>> implementation that it talk to? >> >>Yes, it is. Some protocols add a tag as a new route attribute - see the >>example RIP implementation in Appendix C. >> >>If a vendor then wants to use a tag or anything else in an >>implementation-specific way, it can do so by writing a proprietary module >>that augments the standard module where necessary. This is IMO much >>better than encode semantics into routing protocol names. > > > What about making both type and name as the key? > This would be possible in principle but first I don't see really convincing= reasons for this change, and second, as Juergen already pointed out, we ar= e past WGLC and I am concerned that we will never finish this work. >> >>> >>> DY> For topology, it is just a RIB. >>> DY> Before topology, a RIB is identified by (Name, AFI, SAFI) like >>> ("Customer1", IPv4, UNICAST). >>> DY> Topology add an extract topology name so the identifier become (VRF >>> name, AFI, SAFI, Topo name). >>> DY> Example are ("Customer1", IPv4, UNICAST, "Gold"), ("Customer1", >>>IPv4, >>> UNICAST, "Sliver"), ("Customer1", IPv4, UNICAST, "Bronze") >>> DY> It is like providing multiple data in the under the same VRF, AFI >>>and >>> SAFI. >>> DY> It is similar to the routing protocol name discussion. >>> DY> Either an topology name is added (Could it be through augmentation >>>as >>> not all vendors support topology), >> >>I believe this topology object has to do with link-state protocols, so in >>my view a future implementation of OSPF or IS-IS has to design new >>configuration and/or state data representing topologies, and augment >>"rt:routing-protocol" (or "rt:interface") with it. > > > No. it is not link state protocols specific. It is part of the RIB design. > Suppose routing-instances could mean VRF (from below). In that case, the > RIB inside the routing-stances could be a "topology". We still have figure > out how the identifier should look like. I am still not sure this is something that has to be dealt with in the core= routing data model. IMO, the model in its current state is a reasonable co= mmon denominator of routing subsystem implementations (note it's not intend= ed only for routers, let alone only "big" ones). I think we should finish this data model soon and let routing experts augme= nt and extend it via new modules covering routing protocols, route filterin= g, various kinds of virtualization etc. It is quite possible that this work will identify flaws in the routing mode= l, and then it will have to be revised. Recently, we aligned the model with= the info model of the I2RS WG. However, we cannot continue adding new feat= ures here and there because then we will never be done. Lada > > Thanks, > - Derek > >> >>> DY> or the RIB name is made to have certain format like or >>>>> Name>:. >> >>A discussion of VRFs is now going on in the NETCONF mailing list and I >>already expressed my opinion there: >> >>http://www.ietf.org/mail-archive/web/netconf/current/msg08755.html >> >>In short, I think the VRF concept should be defined as a special type of >>routing-instance. >> >>Thanks, Lada >> >>> DY> It will need more discussion to agree on solution. >> >> >> >>> >>> Thanks, >>> - Derek >>> >>>> >>>>Lada >>>> >>>>>=20 >>>>>=20 >>>>> Thanks, >>>>> - Derek >>>>>=20 >>>>>=20 >>>> >>>>-- >>>>Ladislav Lhotka, CZ.NIC Labs >>>>PGP Key ID: E74E8C0C >>>> >>>> >>>> >>>> >>> >> >>--=20 >>Ladislav Lhotka, CZ.NIC Labs >>PGP Key ID: E74E8C0C > --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 17 01:50:50 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003B11A004A for ; Mon, 17 Mar 2014 01:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.053 X-Spam-Level: X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWoc9_eToIxY for ; Mon, 17 Mar 2014 01:50:45 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id EB2011A0089 for ; Mon, 17 Mar 2014 01:50:44 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id s2H8oY9u020179; Mon, 17 Mar 2014 09:50:34 +0100 Message-ID: <5326B758.9020208@mg-soft.com> Date: Mon, 17 Mar 2014 09:50:32 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andy Bierman References: <532317C2.8090204@mg-soft.com> <20140314.155843.1161893672918712029.mbj@tail-f.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010100060705070801050104" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Hbz0i0b1WLdEKsKzxFqbVdbb0FE Cc: "netmod@ietf.org" Subject: Re: [netmod] Is current() broken for path expressions defined inside notifications/rpcs? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 08:50:50 -0000 This is a multi-part message in MIME format. --------------010100060705070801050104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dne 14.3.2014 16:25, pis(e Andy Bierman: > Hi, > > > On Fri, Mar 14, 2014 at 7:58 AM, Martin Bjorklund > wrote: > > Hi, > > Yes this is broken. It is on the list of issues to consider for YANG > 1.1. > > > Same applies for leafref in a typedef-stmt or within a grouping. > > > See inline. > > > Jernej Tuljak > wrote: > > Hi, > > > > RFC6020, Section 9.9.2. : > > > > o The context node is the node in the data tree for which > the "path" > > statement is defined. > > > > The accessible tree depends on the context node: > > > > o If the context node represents configuration data, the > tree is the > > data in the NETCONF datastore where the context node > exists. The > > XPath root node has all top-level configuration data nodes > in all > > modules as children. > > > > o Otherwise, the tree is all state data on the device, and the > > datastore. The XPath root node has all > top-level data > > nodes in all modules as children. > > > > RFC6020, Section 3. > > > > o data node: A node in the schema tree that can be > instantiated in a > > data tree. One of container, leaf, leaf-list, list, and > anyxml. > > > > o data tree: The instantiated tree of configuration and > state data > > on a device. > > > > A leafref defined within a notification/rpc definition is a not part > > of the data tree, right? It cannot be instantiated as > configuration or > > state data, since it represents neither. So what is current() > > supposed to return in this case? > > The root node of the state + running tree, which makes it pretty > meaningless. > > > > The root, no -- the expression: yes. > The root is just a conceptual node that > has as its child nodes all top-level YANG data nodes. > This part is easy to implement. > > The problem is the current() function since the context node is not part > of the same document as the rest of the expression. This is broken. > > Our code does a simple hack that sort of works ;-) > The context node is set to the document root if it is unknown. > Doesn't this just break things further for you? The grammar definition for path-arg in section 12. specifies that current function invocation *must* be followed by a relative path, which always starts with a dot-dot (an abbreviation for parent::node()), which always selects nothing in your case. Document root has no parent. path-arg = absolute-path / relative-path absolute-path = 1*("/" (node-identifier *path-predicate)) relative-path = 1*(".." "/") descendant-path descendant-path = node-identifier [*path-predicate absolute-path] path-predicate = "[" *WSP path-equality-expr *WSP "]" path-equality-expr = node-identifier *WSP "=" *WSP path-key-expr path-key-expr = current-function-invocation *WSP "/" *WSP rel-path-keyexpr rel-path-keyexpr = 1*(".." *WSP "/" *WSP) *(node-identifier *WSP "/" *WSP) node-identifier Your hack would have to work so "current()/.." selects the document root, right? Seems, well, broken further.. :) A proper implementation of RFC6020 would probably have to prohibit usage of current() for notifications and rpcs, therefore prohibiting usage of path predicates. Not so sure about typedefs and groupings though ("the node in the data tree for which the "path" statement is defined" seems to suggest otherwise; not a problem for used groupings and typedefs where the expressions actually matter). Perhaps temporarily adding the accessible tree of a notification/rpc to whatever the text specifies ATM would be a more appropriate solution (add a fake notification/rpc sibling to "state + running", where this fake subtree is constructed the same way as an accessible tree for must/when expressions in the analogous case). I get the feeling that this was the original intention so I think I'll try to implement this instead of current() returning the document root. Jernej > > > RFC6020, Section 6.4.1. > > > > o The function library is the core function library defined in > > [XPATH ], and a > > function "current()" that returns a node set with > > the initial context node. > > > > This function should only be able to return nodes, that are part of > > the accessible tree for an expression, yet in case of notifications > > and rpcs, the text seems to say that the initial context node is not > > part of the accessible tree. Are there two accessible trees? > > > > Section 9.9.2. has an example where current() is used inside a > > notification, which indicates what's supposed to happen, but can it? > > > > The following notification defines two leafrefs to refer to an > > existing admin-status: > > > > notification link-failure { > > leaf if-name { > > type leafref { > > path "/interface/name"; > > } > > } > > leaf admin-status { > > type leafref { > > path > > "/interface[name = current()/../if-name]" > > + "/admin-status"; > > } > > } > > } > > This needs to be fixed. > > > /martin > > > > Andy > --------------010100060705070801050104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dne 14.3.2014 16:25, piše Andy Bierman:
Hi,


On Fri, Mar 14, 2014 at 7:58 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Hi,

Yes this is broken.  It is on the list of issues to consider for YANG
1.1.


Same applies for leafref in a typedef-stmt or within a grouping.


See inline.


Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote:
> Hi,
>
> RFC6020, Section 9.9.2.:
>
>    o  The context node is the node in the data tree for which the "path"
>       statement is defined.
>
>    The accessible tree depends on the context node:
>
>    o  If the context node represents configuration data, the tree is the
>       data in the NETCONF datastore where the context node exists.  The
>       XPath root node has all top-level configuration data nodes in all
>       modules as children.
>
>    o  Otherwise, the tree is all state data on the device, and the
>       <running/> datastore.  The XPath root node has all top-level data
>       nodes in all modules as children.
>
> RFC6020, Section 3.
>
>    o  data node: A node in the schema tree that can be instantiated in a
>       data tree.  One of container, leaf, leaf-list, list, and anyxml.
>
>    o  data tree: The instantiated tree of configuration and state data
>       on a device.
>
> A leafref defined within a notification/rpc definition is a not part
> of the data tree, right? It cannot be instantiated as configuration or
> state data, since it represents neither.  So what is current()
> supposed to return in this case?

The root node of the state + running tree, which makes it pretty
meaningless.


The root, no -- the expression: yes.
The root is just a conceptual node that
has as its child nodes all top-level YANG data nodes.
This part is easy to implement.

The problem is the current() function since the context node is not part
of the same document as the rest of the expression.  This is broken.

Our code does a simple hack that sort of works ;-)
The context node is set to the document root if it is unknown.


Doesn't this just break things further for you? The grammar definition for path-arg in section 12. specifies that current function invocation *must* be followed by a relative path, which always starts with a dot-dot (an abbreviation for parent::node()), which always selects nothing in your case. Document root has no parent.
   path-arg            = absolute-path / relative-path

   absolute-path       = 1*("/" (node-identifier *path-predicate))

   relative-path       = 1*(".." "/") descendant-path

   descendant-path     = node-identifier
                         [*path-predicate absolute-path]

   path-predicate      = "[" *WSP path-equality-expr *WSP "]"

   path-equality-expr  = node-identifier *WSP "=" *WSP path-key-expr

   path-key-expr       = current-function-invocation *WSP "/" *WSP
                         rel-path-keyexpr

   rel-path-keyexpr    = 1*(".." *WSP "/" *WSP)
                         *(node-identifier *WSP "/" *WSP)
                         node-identifier
Your hack would have to work so "current()/.." selects the document root, right? Seems, well, broken further.. :)

A proper implementation of RFC6020 would probably have to prohibit usage of current() for notifications and rpcs, therefore prohibiting usage of path predicates. Not so sure about typedefs and groupings though ("the node in the data tree for which the "path" statement is defined" seems to suggest otherwise; not a problem for used groupings and typedefs where the expressions actually matter).

Perhaps temporarily adding the accessible tree of a notification/rpc to whatever the text specifies ATM would be a more appropriate solution (add a fake notification/rpc sibling to "state + running", where this fake subtree is constructed the same way as an accessible tree for must/when expressions in the analogous case). I get the feeling that this was the original intention so I think I'll try to implement this instead of current() returning the document root.

Jernej

 

> RFC6020, Section 6.4.1.
>
>    o  The function library is the core function library defined in
>       [XPATH <https://tools.ietf.org/html/rfc6020#ref-XPATH>], and a
>       function "current()" that returns a node set with
>       the initial context node.
>
> This function should only be able to return nodes, that are part of
> the accessible tree for an expression, yet in case of notifications
> and rpcs, the text seems to say that the initial context node is not
> part of the accessible tree. Are there two accessible trees?
>
> Section 9.9.2. has an example where current() is used inside a
> notification, which indicates what's supposed to happen, but can it?
>
>    The following notification defines two leafrefs to refer to an
>    existing admin-status:
>
>      notification link-failure {
>          leaf if-name {
>              type leafref {
>                  path "/interface/name";
>              }
>          }
>          leaf admin-status {
>              type leafref {
>                  path
>                    "/interface[name = current()/../if-name]"
>                  + "/admin-status";
>              }
>          }
>      }

This needs to be fixed.


/martin



Andy 


--------------010100060705070801050104-- From nobody Mon Mar 17 07:26:53 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C901A0361 for ; Mon, 17 Mar 2014 07:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gS8FWNXwdo1O for ; Mon, 17 Mar 2014 07:26:48 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id 6661D1A034B for ; Mon, 17 Mar 2014 07:26:48 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id w8so5382049qac.12 for ; Mon, 17 Mar 2014 07:26:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ymos1Xu5bx/4kvB2U9E+iOQh97llhjeav2I7dn/nLgk=; b=lrykSRTS9k9OwF57DjsKzPV45Ln0NVQOgZOW4LZkWXNcNydNi0ZPZbOKzq+UtFsFsn 5a8jExVvHl6me8PcerHa+Ymiy71nI+pgpKI2sPoLsvSfdGxenRlYcMzqzk1F8LNhD3eB ZYUY1223mz1tj9P8AVyGsXStn9TJpYhjSTiVnGYO3ORWzJ1FYddBEpk8MrpdXtLUPAIj IRqE073EjhFzuBfBBAaf56W2N3SvnM1Jzy5+Onz9Lfl4nafqckG2ihb5wtdJkTn6O4ph HOvEC+hKb+pZuNHJ8pQJs9/CScgzdzLA9wSszoMjznM5RPWqqzjggS5u+n+CA+0PpRlX YH8w== X-Gm-Message-State: ALoCoQmMLiKNviD/6PuAx2SG1eTVkcK6s3eIFdo9hdviIu/eE8GR2gaBBKqxYXzicFwgUSDO0Ozf MIME-Version: 1.0 X-Received: by 10.140.87.9 with SMTP id q9mr2388683qgd.94.1395066400332; Mon, 17 Mar 2014 07:26:40 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Mon, 17 Mar 2014 07:26:40 -0700 (PDT) In-Reply-To: <5326B758.9020208@mg-soft.com> References: <532317C2.8090204@mg-soft.com> <20140314.155843.1161893672918712029.mbj@tail-f.com> <5326B758.9020208@mg-soft.com> Date: Mon, 17 Mar 2014 07:26:40 -0700 Message-ID: From: Andy Bierman To: Jernej Tuljak Content-Type: multipart/alternative; boundary=001a113a359c3b0aec04f4ce3532 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OpcSB9ZpEzBChIYDM28OQr5PO9Q Cc: "netmod@ietf.org" Subject: Re: [netmod] Is current() broken for path expressions defined inside notifications/rpcs? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 14:26:52 -0000 --001a113a359c3b0aec04f4ce3532 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 17, 2014 at 1:50 AM, Jernej Tuljak wr= ote: > Dne 14.3.2014 16:25, pi=C5=A1e Andy Bierman: > > Hi, > > > On Fri, Mar 14, 2014 at 7:58 AM, Martin Bjorklund wrote: > >> Hi, >> >> Yes this is broken. It is on the list of issues to consider for YANG >> 1.1. >> >> > Same applies for leafref in a typedef-stmt or within a grouping. > > > See inline. >> >> >> Jernej Tuljak wrote: >> > Hi, >> > >> > RFC6020, Section 9.9.2.: >> > >> > o The context node is the node in the data tree for which the "pat= h" >> > statement is defined. >> > >> > The accessible tree depends on the context node: >> > >> > o If the context node represents configuration data, the tree is t= he >> > data in the NETCONF datastore where the context node exists. Th= e >> > XPath root node has all top-level configuration data nodes in al= l >> > modules as children. >> > >> > o Otherwise, the tree is all state data on the device, and the >> > datastore. The XPath root node has all top-level dat= a >> > nodes in all modules as children. >> > >> > RFC6020, Section 3. >> > >> > o data node: A node in the schema tree that can be instantiated in= a >> > data tree. One of container, leaf, leaf-list, list, and anyxml. >> > >> > o data tree: The instantiated tree of configuration and state data >> > on a device. >> > >> > A leafref defined within a notification/rpc definition is a not part >> > of the data tree, right? It cannot be instantiated as configuration or >> > state data, since it represents neither. So what is current() >> > supposed to return in this case? >> >> The root node of the state + running tree, which makes it pretty >> meaningless. >> > > > The root, no -- the expression: yes. > The root is just a conceptual node that > has as its child nodes all top-level YANG data nodes. > This part is easy to implement. > > The problem is the current() function since the context node is not part > of the same document as the rest of the expression. This is broken. > > Our code does a simple hack that sort of works ;-) > The context node is set to the document root if it is unknown. > > > Doesn't this just break things further for you? The grammar definition fo= r > path-arg in section 12. specifies that current function invocation *must* > be followed by a relative path, which always starts with a dot-dot (an > abbreviation for parent::node()), which always selects nothing in your > case. Document root has no parent. > > path-arg =3D absolute-path / relative-path > > absolute-path =3D 1*("/" (node-identifier *path-predicate)) > > relative-path =3D 1*(".." "/") descendant-path > > descendant-path =3D node-identifier > [*path-predicate absolute-path] > > path-predicate =3D "[" *WSP path-equality-expr *WSP "]" > > path-equality-expr =3D node-identifier *WSP "=3D" *WSP path-key-expr > > path-key-expr =3D current-function-invocation *WSP "/" *WSP > rel-path-keyexpr > > rel-path-keyexpr =3D 1*(".." *WSP "/" *WSP) > *(node-identifier *WSP "/" *WSP) > node-identifier > > Your hack would have to work so "current()/.." selects the document root, > right? Seems, well, broken further.. :) > > A proper implementation of RFC6020 would probably have to prohibit usage > of current() for notifications and rpcs, therefore prohibiting usage of > path predicates. Not so sure about typedefs and groupings though ("the no= de > in the data tree for which the "path" statement is defined" seems to > suggest otherwise; not a problem for used groupings and typedefs where th= e > expressions actually matter). > > The code goes through the XPath 3 at least 3 separate times. The docroot hack will only generate warnings. The current() syntax is checked completely when there is a context node to check. (e.g, check the typedef, check the grouping, check the uses expansion). > Perhaps temporarily adding the accessible tree of a notification/rpc to > whatever the text specifies ATM would be a more appropriate solution (add= a > fake notification/rpc sibling to "state + running", where this fake subtr= ee > is constructed the same way as an accessible tree for must/when expressio= ns > in the analogous case). I get the feeling that this was the original > intention so I think I'll try to implement this instead of current() > returning the document root. > I don't think mixing documents in the same expression was ever discussed or intended. It is not clear if increasing the XPath complexity required for YANG is warranted or not. > Jernej > Andy > > > >> >> > RFC6020, Section 6.4.1. >> > >> > o The function library is the core function library defined in >> > [XPATH ], and a >> > function "current()" that returns a node set with >> > the initial context node. >> > >> > This function should only be able to return nodes, that are part of >> > the accessible tree for an expression, yet in case of notifications >> > and rpcs, the text seems to say that the initial context node is not >> > part of the accessible tree. Are there two accessible trees? >> > >> > Section 9.9.2. has an example where current() is used inside a >> > notification, which indicates what's supposed to happen, but can it? >> > >> > The following notification defines two leafrefs to refer to an >> > existing admin-status: >> > >> > notification link-failure { >> > leaf if-name { >> > type leafref { >> > path "/interface/name"; >> > } >> > } >> > leaf admin-status { >> > type leafref { >> > path >> > "/interface[name =3D current()/../if-name]" >> > + "/admin-status"; >> > } >> > } >> > } >> >> This needs to be fixed. >> >> >> /martin >> >> > > Andy > > > --001a113a359c3b0aec04f4ce3532 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 17, 2014 at 1:50 AM, Jernej Tuljak &l= t;jernej.tulj= ak@mg-soft.si> wrote:
=20 =20 =20
Dne 14.3.2014 16:25, pi=C5=A1e Andy Bierman:
Hi,


On Fri, Mar 14, 2014 at 7:58 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Hi,

Yes this is broken. =C2=A0It is on the list of issues to consider for YANG
1.1.


Same applies for leafref in a typedef-stmt or within a grouping.


See inline.


Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote:
> Hi,
>
> RFC6020, Section 9.9.2.:
>
> =C2=A0 =C2=A0o =C2=A0The context node is the node in the= data tree for which the "path"
> =C2=A0 =C2=A0 =C2=A0 statement is defined.
>
> =C2=A0 =C2=A0The accessible tree depends on the context = node:
>
> =C2=A0 =C2=A0o =C2=A0If the context node represents conf= iguration data, the tree is the
> =C2=A0 =C2=A0 =C2=A0 data in the NETCONF datastore where= the context node exists. =C2=A0The
> =C2=A0 =C2=A0 =C2=A0 XPath root node has all top-level c= onfiguration data nodes in all
> =C2=A0 =C2=A0 =C2=A0 modules as children.
>
> =C2=A0 =C2=A0o =C2=A0Otherwise, the tree is all state da= ta on the device, and the
> =C2=A0 =C2=A0 =C2=A0 <running/> datastore. =C2=A0T= he XPath root node has all top-level data
> =C2=A0 =C2=A0 =C2=A0 nodes in all modules as children. >
> RFC6020, Section 3.
>
> =C2=A0 =C2=A0o =C2=A0data node: A node in the schema tre= e that can be instantiated in a
> =C2=A0 =C2=A0 =C2=A0 data tree. =C2=A0One of container, = leaf, leaf-list, list, and anyxml.
>
> =C2=A0 =C2=A0o =C2=A0data tree: The instantiated tree of configuration and state data
> =C2=A0 =C2=A0 =C2=A0 on a device.
>
> A leafref defined within a notification/rpc definition is a not part
> of the data tree, right? It cannot be instantiated as configuration or
> state data, since it represents neither. =C2=A0So what i= s current()
> supposed to return in this case?

The root node of the state + running tree, which makes it pretty
meaningless.


The root, no -- the expression: yes.
The root is just a conceptual node that
has as its child nodes all top-level YANG data nodes.
This part is easy to implement.

The problem is the current() function since the context node is not part
of the same document as the rest of the expression. =C2=A0This is broken.

Our code does a simple hack that sort of works ;-)
The context node is set to the document root if it is unknown.


Doesn't this just break things further for you? The grammar definition for path-arg in section 12. specifies that current function invocation *must* be followed by a relative path, which always starts with a dot-dot (an abbreviation for parent::node()), which always selects nothing in your case. Document root has no parent.
   path-arg            =3D absolute-path / relative-path

   absolute-path       =3D 1*("/" (node-identifier *path-predicat=
e))

   relative-path       =3D 1*(".." "/") descendant-path

   descendant-path     =3D node-identifier
                         [*path-predicate absolute-path]

   path-predicate      =3D "[" *WSP path-equality-expr *WSP "=
;]"

   path-equality-expr  =3D node-identifier *WSP "=3D" *WSP path-k=
ey-expr

   path-key-expr       =3D current-function-invocation *WSP "/" *=
WSP
                         rel-path-keyexpr

   rel-path-keyexpr    =3D 1*(".." *WSP "/" *WSP)
                         *(node-identifier *WSP "/" *WSP)
                         node-identifier
Your hack would have to work so "current()/.." selects the do= cument root, right? Seems, well, broken further.. :)

A proper implementation of RFC6020 would probably have to prohibit usage of current() for notifications and rpcs, therefore prohibiting usage of path predicates. Not so sure about typedefs and groupings though ("the node in the data tree for which the "path" = statement is defined" seems to suggest otherwise; not a problem for used groupings and typedefs where the expressions actually matter).



The code goes= through the XPath 3 at least 3 separate times.
The docroot hack = will only generate warnings. =C2=A0The current() syntax is checked
completely when there is a context node to check. =C2=A0(e.g, check the typ= edef,
check the grouping, check the uses expansion).
=C2=A0
Perhaps temporarily adding the accessible tree of a notification/rpc to whatever the text specifies ATM would be a more appropriate solution (add a fake notification/rpc sibling to "state + running&= quot;, where this fake subtree is constructed the same way as an accessible tree for must/when expressions in the analogous case). I get the feeling that this was the original intention so I think I'll try to implement this instead of current() returning the document root.=C2=A0<= br>

I don't think mixing document= s in the same expression was ever
discussed or intended. It is no= t clear if increasing the XPath complexity
required for YANG is warranted or not.


Jernej

Andy
=C2=A0<= /div>

=C2=A0

> RFC6020, Section 6.4.1.
>
> =C2=A0 =C2=A0o =C2=A0The function library is the core fu= nction library defined in
> =C2=A0 =C2=A0 =C2=A0 [XPATH <https://tools.ietf.org/= html/rfc6020#ref-XPATH>], and a
> =C2=A0 =C2=A0 =C2=A0 function "current()" that= returns a node set with
> =C2=A0 =C2=A0 =C2=A0 the initial context node.
>
> This function should only be able to return nodes, that are part of
> the accessible tree for an expression, yet in case of notifications
> and rpcs, the text seems to say that the initial context node is not
> part of the accessible tree. Are there two accessible trees?
>
> Section 9.9.2. has an example where current() is used inside a
> notification, which indicates what's supposed to happen, but can it?
>
> =C2=A0 =C2=A0The following notification defines two leaf= refs to refer to an
> =C2=A0 =C2=A0existing admin-status:
>
> =C2=A0 =C2=A0 =C2=A0notification link-failure {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf if-name {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type lea= fref {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0path "/interface/name";
> =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=A0leaf admin-status { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type lea= fref {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0path
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0"/interface[name =3D current()/../if-name]"
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+ "/admin-status";
> =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}

This needs to be fixed.


/martin



Andy=C2=A0



--001a113a359c3b0aec04f4ce3532-- From nobody Tue Mar 18 16:04:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216361A049D for ; Tue, 18 Mar 2014 16:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwDURrE79w-C for ; Tue, 18 Mar 2014 16:04:08 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 903101A0476 for ; Tue, 18 Mar 2014 16:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5326; q=dns/txt; s=iport; t=1395183839; x=1396393439; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rOGoGW0M7zKYgquPda+Y1EWhPV+ECAElodmTlWmr7uY=; b=JnPhAwzPOzvFgB/9ZSf2WVD40/NPsBllqUKV8Pwk6gTrbivIjlULUGWO tm7PkVn8IxzZqHSeSablY203uA0eeNGMP+N4a0ONDWBWbCkqW3kF/0zmM 6Mnn1NIvNaEgbNyDD/aLagDOOVU48Vk8KAmTv6v3CptbkrKH4LiwAeik6 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEFAGbQKFOtJV2b/2dsb2JhbABagwY7UQa6aIZrUYEqFnSCJQEBAQQBAQFoAwsQAgEIGC4nCyUCBA4FCYdwCAXQPheOLzMHhDgEmEaBMpB+gy2CKw X-IronPort-AV: E=Sophos;i="4.97,681,1389744000"; d="scan'208";a="311186992" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 18 Mar 2014 23:03:59 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2IN3wIH012234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Mar 2014 23:03:58 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.3]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Tue, 18 Mar 2014 18:03:58 -0500 From: "Derek Man-Kit Yeung (myeung)" To: Ladislav Lhotka Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt Thread-Index: AQHPDgglTcSsF5Wm80Ok259R/K6NOZrW54cAgAAKUQCACkjaAIAAei+AgAYKNAA= Date: Tue, 18 Mar 2014 23:03:58 +0000 Message-ID: References: <20140110133016.24678.42711.idtracker@ietfa.amsl.com> <9C81158E-5B4C-4479-AEA5-23CBCC020ADD@nic.cz> <0ED855DA-51BE-4DE6-AB22-E1A9E04C0E5F@nic.cz> In-Reply-To: <0ED855DA-51BE-4DE6-AB22-E1A9E04C0E5F@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.154.210.99] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4CE229F982370C4CB4E26366572A608A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_R6LO66xqKcL4uCencSE-BWgzeM Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 23:04:10 -0000 On 3/14/14 12:49 PM, "Ladislav Lhotka" wrote: > >On 14 Mar 2014, at 20:32, Derek Man-Kit Yeung (myeung) >wrote: > >>=20 >>=20 >> On 3/7/14 2:29 PM, "Ladislav Lhotka" wrote: >>=20 >>>=20 >>> On 07 Mar 2014, at 22:52, Yi Yang (yiya) wrote: >>>=20 >>>> One thing is missing from the data model is association with vrf. >>>=20 >>> I agree with what Martin wrote in a parallel thread. I believe the >>> routing module (and YANG augment statement) provide sufficient hooks >>>for >>> implementing VRF as a specific type of routing-instance. >>=20 >>=20 >> The draft mentioned the routing-instance could be used to represents a >> logical router.=20 >>=20 >> The term "logical router" in one or more vendors mean a partition of the >> physical router into multiple logical units, each could have multiple >>VRFs. >>=20 >> Does the draft intend to manage "logical router" in the above >>definition? >> Some clarification will be useful. > >One way to implement this is to introduce two types of routing instances, >say 'logical-router=B9 and =8Cvrf=B9. The =8Cvrf=B9 type then would have a= nother >leaf linking it to a logical router. This is quite like the various >methods of interface stacking, see the examples in >draft-ietf-netmod-interfaces-cfg-16. > >Lada It is one way.=20 However, given that current model that everything is put inside a routing-instance, things like RIB, routing-protocols etc are no longer needed directly under the 'logical-router'. What needed in the 'logical router' are resources allocation like interfaces, CPU etc. Though routing-instance could be augmented to include 'logical router' specific field and add new condition to restrict existing leaf that no long apply, I think a new container above routing-instance is cleaner. It could be a new data model that reference the definition in the current draft. - Derek > >>=20 >> - Derek >>=20 >>>=20 >>> I think though that other work extending the routing module is much >>>more >>> needed, namely vendor-neutral data models for routing protocols. >>>=20 >>> The consensus of the NETMOD WG was that these new modules should be >>> developed by experts in the Routing Area (VRF in the MPLS WG?). The >>> NETMOD WG and YANG Doctors will certainly help but the bulk of this >>>work >>> should be done by domain experts. >>>=20 >>> Lada >>>=20 >>>>=20 >>>> Another concern I have is about address family. To facilitate a query >>>> based on AFI only, or SAFI only, it seems more convenient to use two >>>> leafs >>>> (AFI and SAFI) instead of one (AFI-SAFI). >>>>=20 >>>> Yi >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 1/10/14 8:30 AM, "internet-drafts@ietf.org" >>>> >>>> wrote: >>>>=20 >>>>>=20 >>>>> 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 >>>>>Working >>>>> Group of the IETF. >>>>>=20 >>>>> Title : A YANG Data Model for Routing Management >>>>> Author : Ladislav Lhotka >>>>> Filename : draft-ietf-netmod-routing-cfg-13.txt >>>>> Pages : 95 >>>>> Date : 2014-01-10 >>>>>=20 >>>>> Abstract: >>>>> This document contains a specification of three YANG modules. >>>>> Together they form the core routing data model which serves as a >>>>> framework for configuring and managing a routing subsystem. It is >>>>> expected that these modules will be augmented by additional YANG >>>>> modules defining data models for individual routing protocols and >>>>> other related functions. The core routing data model provides common >>>>> building blocks for such extensions - routing instances, routes, >>>>> routing information bases (RIB), routing protocols and route filters. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ >>>>>=20 >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg-13 >>>>>=20 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>=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 > >-- >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: E74E8C0C > > > > From nobody Tue Mar 18 16:47:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89DF91A049F for ; Tue, 18 Mar 2014 16:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hhtopy8t0Hzn for ; Tue, 18 Mar 2014 16:47:02 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3311A0434 for ; Tue, 18 Mar 2014 16:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12876; q=dns/txt; s=iport; t=1395186414; x=1396396014; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Jygl2kjhNy+J3G0TG1XpAsFM61o+PKPUha9xvFWgdMM=; b=bDYjZ7lMT0ntTZqPQMiUdWp5JlaDKnJDuxFXQpZp/Uwnydn4cBp+E2Dg Txw7i29cXXUiwGmo/Mq+oo30eB8CIzAQ6s6vkHsI8MwC/tLRxf6LhRF+N 7ts4sm/1pl+hhUYe6ezIb+ZaThOunTXAjnQuYI2EFwGeyXoEctSYGSdkN k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFANnZKFOtJXHB/2dsb2JhbABQCoMGO1eDBr5OURmBEBZ0giUBAQEDATQ3AwsQAgEIGAQoAgIwJQIEDgUJEodWCA2RdpwPBqI7F4EjjGMLAQFPBwICgmWBTwSYRpIwgy2Bcjk X-IronPort-AV: E=Sophos;i="4.97,681,1389744000"; d="scan'208";a="28505719" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-1.cisco.com with ESMTP; 18 Mar 2014 23:46:53 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2INkrpL011237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Mar 2014 23:46:53 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.3]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Tue, 18 Mar 2014 18:46:53 -0500 From: "Derek Man-Kit Yeung (myeung)" To: Ladislav Lhotka Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt Thread-Index: AQHPN6a8TcSsF5Wm80Ok259R/K6NOZrRZ2eAgAJK3ACAAJT0AIAMpIsAgAFV/4CABTYUAA== Date: Tue, 18 Mar 2014 23:46:52 +0000 Message-ID: References: <20140111.133634.462426147.mbj@tail-f.com> <12A63CCF-69CE-4D43-A3EC-F420635B5237@nic.cz> <20140220134130.GA19665@elstar.local> <20140220.145129.73716044088019744.mbj@tail-f.com> <657A1870-B234-4489-8F0E-A85559843C16@nic.cz> <7AC19724-68FC-4A06-B491-8DA29BD2A1B7@nic.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.154.210.99] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ggraNgWOjjgSG8Lo7LDPLP2f-zY Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 23:47:06 -0000 DQoNCk9uIDMvMTUvMTQgMjoxMSBBTSwgIkxhZGlzbGF2IExob3RrYSIgPGxob3RrYUBuaWMuY3o+ IHdyb3RlOg0KDQo+SGkgRGVyZWssDQo+DQo+cGxlYXNlIHNlZSBteSByZXNwb25zZXMgaW5saW5l Lg0KPg0KPiJEZXJlayBNYW4tS2l0IFlldW5nIChteWV1bmcpIiA8bXlldW5nQGNpc2NvLmNvbT4g d3JpdGVzOg0KPg0KPj4gT24gMy82LzE0IDI6NDMgQU0sICJMYWRpc2xhdiBMaG90a2EiIDxsaG90 a2FAbmljLmN6PiB3cm90ZToNCj4+DQo+Pj4iRGVyZWsgTWFuLUtpdCBZZXVuZyAobXlldW5nKSIg PG15ZXVuZ0BjaXNjby5jb20+IHdyaXRlczoNCj4+Pg0KPj4+Li4uDQo+Pj4NCj4+Pj4+PiAzKSBH aXZlbiByb3V0aW5nLXByb3RvY29sIGhhcyBvbmx5IG5hbWUgYXMgdGhlIGtleQ0KPj4+Pj4+ICAg ICAgICAgICBsaXN0IHJvdXRpbmctcHJvdG9jb2wgew0KPj4+Pj4+ICAgICAgICAgICAgICAga2V5 ICJuYW1lIjsNCj4+Pj4+PiAgIFdvdWxkIGl0IHByZXZlbnQgZGlmZmVyZW50IHByb3RvY29scyBm cm9tIHVzaW5nIHRoZSBzYW1lIG5hbWU/DQo+Pj4+Pj5MaWtlDQo+Pj4+Pj4gInJvdXRlciBvc3Bm IDEwMSIgYW5kICJyb3V0ZXIgcmlwIDEwMSIgYXQgdGhlIHNhbWUgdGltZSB1c2luZyBJT1MNCj4+ Pj4+PnN5bnRheD8NCj4+Pj4+DQo+Pj4+Pkxpc3Qga2V5cyBoYXZlIHRvIGJlIHVuaXF1ZSwgc28g aW4gdGhpcyBjYXNlIHlvdSB3b3VsZCBuZWVkIHRvIHVzZQ0KPj4+Pj5lLmcuDQo+Pj4+Pqn4b3Nw Zi0xMDGp9yBhbmQgqfhyaXAtMTAxqfcgYXMgdGhlIGtleXMuDQo+Pj4+DQo+Pj4+DQo+Pj4+IERZ PiBPbmUgdGhlIHJvdXRlciwgdGhlIHJvdXRpbmcgcHJvdG9jb2wgaXMgaWRlbnRpZmllZCBieSB0 aGUgdHlwZQ0KPj4+PmFuZCBhDQo+Pj4+IHRhZy4NCj4+Pj4gRFk+IEV4YW1wbGUgaXMgdHlwZSBP U1BGIGFuZCB0YWcgMTAxLiBGb3IgZGlzcGxheSBwdXJwb3NlLCB5b3UgbWF5IHNlZQ0KPj4+PiAi b3NwZiAxMDEiLCAiUHJvdG9jb2w6IE9TUEYsIFRhZzogMTAxIiBvciAib3NwZi0xMDEiIGRlcGVu ZGluZyBvbg0KPj4+PiBpbXBsZW1lbnRhdGlvbi4NCj4+Pj4gRFk+IFdoZW4gSSByZWFkIHlvdXIg ZHJhZnQsIEkgdG9vayB0aGF0IG5hbWUgbWVhbiB0YWcgYW5kIGhlbmNlIHRoZQ0KPj4+PiB1bmlx dWVuZXNzIHF1ZXN0aW9uLg0KPj4+DQo+Pj5BcyB0aGlzIGlzIGEgdmVuZG9yLW5ldXRyYWwgbW9k dWxlLCB3ZSB0cmllZCB0byBhdm9pZCBhc3NpZ25pbmcNCj4+PnNlbWFudGljcw0KPj4+dG8gdGhl IG5hbWVzIG9mIG9iamVjdHMgYmVjYXVzZSB0aGF0IHdvdWxkIGhhcmRseSB3b3JrIGZvciBkaWZm ZXJlbnQNCj4+PnZlbmRvcnMuIEFuIGltcGxlbWVudGF0aW9uIG1heSB1c2UgcmFuZG9tIHN0cmlu Z3MgYXMgbGlzdCBrZXlzIHByb3ZpZGVkDQo+Pj50aGV5IGFyZSB1bmlxdWUuDQo+Pg0KPj4gQ29t YmluYXRpb24gb2YgdHlwZSBhbmQgdGFnIGlzIHZlcnkgZ2VuZXJpYyBmb3IgaWRlbnRpZnlpbmcg YSByb3V0aW5nDQo+PiBwcm90b2NvbC4NCj4NCj5JIGRvbid0IHRoaW5rIGl0IGlzIHRoYXQgZ2Vu ZXJpYyAtIHR3byBleGFtcGxlczoNCj4NCj4tIEpVTk9TIGRvZXNuJ3QgdXNlIHN1Y2ggdGFncyBh dCBhbGwgYmVjYXVzZSBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhlDQo+c2FtZSByb3V0aW5nIHBy b3RvY29sIGhhdmUgdG8gYmUgaW4gZGlmZmVyZW50IHJvdXRpbmcgaW5zdGFuY2VzLg0KDQoNCklm IHJvdXRpbmctcHJvdG9jb2wgaXMga2V5ZWQgb24gYm90aCB0eXBlIGFuZCBuYW1lICh3aGF0IEkg c3VnZ2VzdGVkKSwNCnRoZW4gdGhlIG5hbWUgY291bGQgYmUgZW1wdHkgc3RyaW5nLiAoTmFtZSBi ZWNvbWVzIHRoZSB0YWcgSSBtZW50aW9uZWQpLg0KDQoNClRoZW4gZm9yIEpVTk9TLCB0aGUgdGFn IGNvdWxkIGp1c3QgYmUgZW1wdHkgc3RyaW5nLg0KDQpyb3V0aW5nLWluc3RhbmNlcyB7DQoJcm91 dGluZy1pbnN0YW5jZS1uYW1lIHsNCgkJcHJvdG9jb2xzIHsNCgkJCWJncCB7DQoJCQkJYmdwLWNv bmZpZ3VyYXRpb247DQoJCQl9DQoJCQlpc2lzIHsNCgkJCQlpc2lzLWNvbmZpZ3VyYXRpb247DQoJ CQl9DQoJCQlvc3BmIHsNCgkJCQlvc3BmLWNvbmZpZ3VyYXRpb247DQoJCQl9DQqhpg0KDQpUaGUg cm91dGluZy1pbnN0YW5jZS1uYW1lIGlzIHRoZSAnbmFtZScgb2YgdGhlIHJvdXRpbmctaW5zdGFu Y2UgY29udGFpbmVyLg0KVGhlIGJncCwgaXNpcywgb3NwZiBpcyBpbmRpY2F0ZWQgYnkgdGhlICd0 eXBlJyBvZiB0aGUgcm91dGluZy1wcm90b2NvbA0KY29udGFpbmVyIGFuZCAnbmFtZScgb2YgdGhl IHJvdXRpbmctcHJvdG9jb2wgd2lsbCBiZSBlbXB0eSBzdHJpbmcuDQoNCkZvciB2ZW5kb3Igd2hp Y2ggc3VwcG9ydCBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgcm91dGluZyBwcm90b2Nv bA0KaW4gdGhlIHNhbWUgcm91dGluZy1pbnN0YW5jZXMgKFZSRiksIHRoZSAnbmFtZScgb2YgdGhl IHJvdXRpbmctcHJvdG9jb2wNCmNvdWxkIGJlIHRoZSBkaXN0aW5ndWlzaGVyLg0KDQoNCg0KDQoN Cj4NCj4tIEJJUkQgcm91dGluZyBkYWVtb24gZG9lcyB1c2UgdGFncyBmb3IgcHJvdG9jb2wgaW5z dGFuY2VzLCBlLmcuDQo+DQo+cHJvdG9jb2wgb3NwZiBmb28gew0KPiAgLi4uDQo+fQ0KPg0KPmJ1 dCB0aGUgc2FtZSB0YWcgKCJmb28iKSBjYW5ub3QgYmUgcmV1c2VkIGZvciBhIGRpZmZlcmVudCBw cm90b2NvbCB0eXBlLg0KDQpUaGlzIGlzIHJlc3RyaWN0aW9uIG9mIHRoYXQgcGFydGljdWxhciBp bXBsZW1lbnRhdGlvbiwgSSB0aGluayB0aGUgZGF0YQ0KbW9kZWwgc2hvdWxkIGFsbG93IHRoYXQg YW5kIHRoZSBiYWNrZW5kIGNvdWxkIHJlamVjdCBpZiBpdCBpcyBub3QNCnN1cHBvcnRlZC4NCg0K QWN0dWFsbHksIHRoZSBjdXJyZW50IG1vZGVsIGFsbG93IHJvdXRpbmctcHJvdGNvbCBuYW1lIGFs cmVhZHksIHRoZSBwb2ludA0Kd2UgYXJlIGFyZ3VtZW50IGlzIHdoeSBkbyB3ZSBuZWVkIHJvdXRp bmctdHlwZSBpbmZvcm1hdGlvbiBlbmNvZGVkIGludG8NCnRoZSBuYW1lIHN0cmluZyBhcyB0aGUg Y3VycmVudCBtb2RlbCByZXF1aXJlZC4NCg0KPg0KPj4gSWYgd2UgdXNlIGEgbmFtZSBzdHJpbmcg d2hpY2ggaW5jbHVkZSBib3RoIHRoZSB0eXBlIGFuZCB0YWcgaW5mbyBhbmQgZG8NCj4+IG5vdCBw cm92aWRlIGEgZm9ybWF0IGZvciBpdCwNCj4+IHRoZW4gSSBhbSBjb25jZXJuZWQgdGhhdCB0aGUg Y29udHJvbGxlciBuZWVkIHRvIHRvIGFkanVzdCBuYW1lIHN0cmluZw0KPj4gYWNjb3JkaW5nbHkg ZGVwZW5kaW5nIG9uIHdoaWNoIHZlbmRvciBpdCBpcyB0YWxraW5nIHRvLg0KPj4gSXQgaXMgZG9h YmxlIGJ1dCBpdCBzZWVtcyB0byBkZWZlYXQgdGhlIHB1cnBvc2Ugb2YgaGF2aW5nIHRoZSBzYW1l IGRhdGENCj4+IG1vZGVsIGluIHRoZSBmaXJzdCBwbGFjZS4NCj4+DQo+Pj4NCj4+Pj4gRFk+IElm IG5hbWUgZXF1YXRlIGEgc3RyaW5nIGxpa2UgIm9zcGYtMTAxIiwgdGhlbiB0aGUgc3RyaW5nIGNh bm5vdCBiZQ0KPj4+PiBqdXN0IGFyYml0cmFyeSBhcyB0aGUgZHJhZnQgc2FpZC4NCj4+Pg0KPj4+ Im9zcGYtMTAxIiBpcyBqdXN0IGFuIGV4YW1wbGUgaG93IHRoZSBuYW1lIGNhbiBiZSBkaXNhbWJp Z3VhdGVkIGluIGEgd2F5DQo+Pj50aGF0IGlzICJmcmllbmRseSIgdG8gYSBwYXJ0aWN1bGFyIHBs YXRmb3JtLg0KPj4+DQo+Pj4+IERZPiBJdCBoYXMgdG8gaGF2ZSBzb21lIGZvcndhcmQgbGlrZSA8 Um91dGluZyBQcm90b2NvbCBUeXBlDQo+Pj4+IFN0cj48U2VwYXJhdG9yPjxUYWc+IHNvIHRoZSBu ZXR3b3JrIGRldmljZSBjYW4gZXh0cmFjdCB0aGUgdGFnIGZyb20NCj4+Pj5pdC4NCj4+Pg0KPj4+ SSBkb24ndCBrbm93IHdoYXQgeW91IG1lYW4gYnkgYSAiZm9yd2FyZCIuIEhvdyBpcyB0aGlzIHRh ZyBzdXBwb3NlZCB0bw0KPj4+YmUNCj4+PnVzZWQ/DQo+Pg0KPj4gU29ycnkuIFR5cG9zLiBJIG1l YW4gImZvcm1hdCIuDQo+PiBGb3IgdGhlIHN0cmluZyAib3NwZi0xIiwgIm9zcGYiIGlzIHRoZSB0 eXBlIGFuZCAiMSIgaXMgdGhlIHRhZy4NCj4+DQo+Pj4NCj4+Pj4gRFk+IE15IHByZWZlcmVuY2Ug aXMgdG8gdHJlYXQgdGhlIG5hbWUgYXMgPFRhZz4gYW5kIGluY2x1ZGUgdHlwZSBhDQo+Pj4+cGFy dA0KPj4+Pm9mDQo+Pj4+IHRoZSBrZXkuIA0KPj4+PiBEWT4gRXZlbiBpZiBuYW1lIG1lYW4ganVz dCB0aGUgdGFnLCBzdGlsbCBuZWVkIHNvbWUga2luZCBvZiBwYXR0ZXJuIGFzDQo+Pj4+bm90DQo+ Pj4+IGFsbCBjaGFyYWN0ZXIgaXMgYWxsb3dlZC4NCj4+Pj4gRFk+IElzIHRoaXMgYSB3YXkgaW4g WUFORyB0byBhdWdtZW50IHRoZSBuYW1lIHdpdGggcGF0dGVybiB3aGljaCBzdWl0DQo+Pj4+dGhl DQo+Pj4+IGltcGxlbWVudGF0aW9uIHRoYXQgaXQgdGFsayB0bz8NCj4+Pg0KPj4+WWVzLCBpdCBp cy4gU29tZSBwcm90b2NvbHMgYWRkIGEgdGFnIGFzIGEgbmV3IHJvdXRlIGF0dHJpYnV0ZSAtIHNl ZSB0aGUNCj4+PmV4YW1wbGUgUklQIGltcGxlbWVudGF0aW9uIGluIEFwcGVuZGl4IEMuDQo+Pj4N Cj4+PklmIGEgdmVuZG9yIHRoZW4gd2FudHMgdG8gdXNlIGEgdGFnIG9yIGFueXRoaW5nIGVsc2Ug aW4gYW4NCj4+PmltcGxlbWVudGF0aW9uLXNwZWNpZmljIHdheSwgaXQgY2FuIGRvIHNvIGJ5IHdy aXRpbmcgYSBwcm9wcmlldGFyeQ0KPj4+bW9kdWxlDQo+Pj50aGF0IGF1Z21lbnRzIHRoZSBzdGFu ZGFyZCBtb2R1bGUgd2hlcmUgbmVjZXNzYXJ5LiBUaGlzIGlzIElNTyBtdWNoDQo+Pj5iZXR0ZXIg dGhhbiBlbmNvZGUgc2VtYW50aWNzIGludG8gcm91dGluZyBwcm90b2NvbCBuYW1lcy4NCj4+DQo+ Pg0KPj4gV2hhdCBhYm91dCBtYWtpbmcgYm90aCB0eXBlIGFuZCBuYW1lIGFzIHRoZSBrZXk/DQo+ Pg0KPg0KPlRoaXMgd291bGQgYmUgcG9zc2libGUgaW4gcHJpbmNpcGxlIGJ1dCBmaXJzdCBJIGRv bid0IHNlZSByZWFsbHkNCj5jb252aW5jaW5nIHJlYXNvbnMgZm9yIHRoaXMgY2hhbmdlLCBhbmQg c2Vjb25kLCBhcyBKdWVyZ2VuIGFscmVhZHkNCj5wb2ludGVkIG91dCwgd2UgYXJlIHBhc3QgV0dM QyBhbmQgSSBhbSBjb25jZXJuZWQgdGhhdCB3ZSB3aWxsIG5ldmVyDQo+ZmluaXNoIHRoaXMgd29y ay4NCg0KDQpJIHRoaW5rIHRoZXJlIGlzIHZlcnkgZ29vZCByZWFzb24gdG8gY2hhbmdlIDstKQ0K DQpCVFcsIGl0IGlzIHNpbWlsYXIgbGltaXRhdGlvbiBmb3IgdGhlIHJvdXRpbmctaW5zdGFuY2Ug bmFtZSwgZWl0aGVyDQpkaWZmZXJlbnQgdHlwZSBvZiByb3V0aW5nLWluc3RhbmNlIGNhbm5vdCBo YXZlIHRoZSBzYW1lIG5hbWUgb3IgdGhlIHR5cGUNCmhhcyB0byBiZSBlbmNvZGVkIGluIHRoZSBu YW1lIGl0c2VsZi4NCg0KPg0KPj4+DQo+Pj4+DQo+Pj4+IERZPiBGb3IgdG9wb2xvZ3ksIGl0IGlz IGp1c3QgYSBSSUIuDQo+Pj4+IERZPiBCZWZvcmUgdG9wb2xvZ3ksIGEgUklCIGlzIGlkZW50aWZp ZWQgYnkgKE5hbWUsIEFGSSwgU0FGSSkgbGlrZQ0KPj4+PiAoIkN1c3RvbWVyMSIsIElQdjQsIFVO SUNBU1QpLg0KPj4+PiBEWT4gVG9wb2xvZ3kgYWRkIGFuIGV4dHJhY3QgdG9wb2xvZ3kgbmFtZSBz byB0aGUgaWRlbnRpZmllciBiZWNvbWUNCj4+Pj4oVlJGDQo+Pj4+IG5hbWUsIEFGSSwgU0FGSSwg VG9wbyBuYW1lKS4NCj4+Pj4gRFk+IEV4YW1wbGUgYXJlICgiQ3VzdG9tZXIxIiwgSVB2NCwgVU5J Q0FTVCwgIkdvbGQiKSwgKCJDdXN0b21lcjEiLA0KPj4+PklQdjQsDQo+Pj4+IFVOSUNBU1QsICJT bGl2ZXIiKSwgKCJDdXN0b21lcjEiLCBJUHY0LCBVTklDQVNULCAiQnJvbnplIikNCj4+Pj4gRFk+ IEl0IGlzIGxpa2UgcHJvdmlkaW5nIG11bHRpcGxlIGRhdGEgaW4gdGhlIHVuZGVyIHRoZSBzYW1l IFZSRiwgQUZJDQo+Pj4+YW5kDQo+Pj4+IFNBRkkuDQo+Pj4+IERZPiBJdCBpcyBzaW1pbGFyIHRv IHRoZSByb3V0aW5nIHByb3RvY29sIG5hbWUgZGlzY3Vzc2lvbi4NCj4+Pj4gRFk+IEVpdGhlciBh biB0b3BvbG9neSBuYW1lIGlzIGFkZGVkIChDb3VsZCBpdCBiZSB0aHJvdWdoIGF1Z21lbnRhdGlv bg0KPj4+PmFzDQo+Pj4+IG5vdCBhbGwgdmVuZG9ycyBzdXBwb3J0IHRvcG9sb2d5KSwNCj4+Pg0K Pj4+SSBiZWxpZXZlIHRoaXMgdG9wb2xvZ3kgb2JqZWN0IGhhcyB0byBkbyB3aXRoIGxpbmstc3Rh dGUgcHJvdG9jb2xzLCBzbw0KPj4+aW4NCj4+Pm15IHZpZXcgYSBmdXR1cmUgaW1wbGVtZW50YXRp b24gb2YgT1NQRiBvciBJUy1JUyBoYXMgdG8gZGVzaWduIG5ldw0KPj4+Y29uZmlndXJhdGlvbiBh bmQvb3Igc3RhdGUgZGF0YSByZXByZXNlbnRpbmcgdG9wb2xvZ2llcywgYW5kIGF1Z21lbnQNCj4+ PiJydDpyb3V0aW5nLXByb3RvY29sIiAob3IgInJ0OmludGVyZmFjZSIpIHdpdGggaXQuDQo+Pg0K Pj4NCj4+IE5vLiBpdCBpcyBub3QgbGluayBzdGF0ZSBwcm90b2NvbHMgc3BlY2lmaWMuIEl0IGlz IHBhcnQgb2YgdGhlIFJJQg0KPj5kZXNpZ24uDQo+PiBTdXBwb3NlIHJvdXRpbmctaW5zdGFuY2Vz IGNvdWxkIG1lYW4gVlJGIChmcm9tIGJlbG93KS4gSW4gdGhhdCBjYXNlLCB0aGUNCj4+IFJJQiBp bnNpZGUgdGhlIHJvdXRpbmctc3RhbmNlcyBjb3VsZCBiZSBhICJ0b3BvbG9neSIuIFdlIHN0aWxs IGhhdmUNCj4+ZmlndXJlDQo+PiBvdXQgaG93IHRoZSBpZGVudGlmaWVyIHNob3VsZCBsb29rIGxp a2UuDQo+DQo+SSBhbSBzdGlsbCBub3Qgc3VyZSB0aGlzIGlzIHNvbWV0aGluZyB0aGF0IGhhcyB0 byBiZSBkZWFsdCB3aXRoIGluIHRoZQ0KPmNvcmUgcm91dGluZyBkYXRhIG1vZGVsLiBJTU8sIHRo ZSBtb2RlbCBpbiBpdHMgY3VycmVudCBzdGF0ZSBpcyBhDQo+cmVhc29uYWJsZSBjb21tb24gZGVu b21pbmF0b3Igb2Ygcm91dGluZyBzdWJzeXN0ZW0gaW1wbGVtZW50YXRpb25zIChub3RlDQo+aXQn cyBub3QgaW50ZW5kZWQgb25seSBmb3Igcm91dGVycywgbGV0IGFsb25lIG9ubHkgImJpZyIgb25l cykuDQoNCklmIGl0IGlzIGp1c3QgdGhlIG5hbWluZyBjb252ZW50aW9uIGlzIGxlZnQgZm9yIGxh dGVyIHNwZWNpZmljYXRpb24sIGl0DQpjb3VsZCBiZSBmaW5lLiANCk15IHBvaW50IGlzIHRoYXQg aXQgc2hvdWxkIG5vdCBiZSBsZWZ0IGZvciBlYWNoIGltcGxlbWVudGF0aW9uIHRvIHBpY2sNCnRo ZWlyIG93biBjb252ZW50aW9uLg0KRm9yIHJlZmVyZW5jZSwgdGhlIEpVTk9TIGVuY29kZSB0aGUg dG9wb2xvZ3kgbmFtZSBpbiB0aGUgUklCIG5hbWUuDQoNCkJ1dCB0aGVyZSBpcyByZXN0cmljdGlv biB0aGF0IGlzIG5vdCBuZWNlc3NhcnksIGluIHRlcm0gb2YgbXVsdGlwbGUNCnRvcG9sb2d5LCBp biB0aGUgZHJhZnQuDQpGb3IgZXhhbXBsZSwNCg0KICBvICBFYWNoIHJvdXRpbmcgcHJvdG9jb2wg aW5zdGFuY2UsIGluY2x1ZGluZyB0aGUgInN0YXRpYyIgYW5kDQogICAgICAiZGlyZWN0IiBwc2V1 ZG8tcHJvdG9jb2xzLCBpcyBjb25uZWN0ZWQgdG8gZXhhY3RseSBvbmUgUklCIHdpdGgNCiAgICAg IHdoaWNoIGl0IGNhbiBleGNoYW5nZSByb3V0ZXMgKGluIGJvdGggZGlyZWN0aW9ucywgZXhjZXB0 IGZvciB0aGUNCiAgICAgICJzdGF0aWMiIGFuZCAiZGlyZWN0IiBwc2V1ZG8tcHJvdG9jb2xzKS4N Cg0KY29udGFpbmVyIGNvbm5lY3RlZC1yaWJzIHsNCglkZXNjcmlwdGlvbg0KCSJDb250YWluZXIg Zm9yIGNvbm5lY3RlZCBSSUJzLiI7DQoJbGlzdCBjb25uZWN0ZWQtcmliIHsNCgkJa2V5ICJyaWIt bmFtZSI7DQoJCWRlc2NyaXB0aW9uDQoJCSJMaXN0IG9mIFJJQnMgdG8gd2hpY2ggdGhlIHJvdXRp bmcgcHJvdG9jb2wgaW5zdGFuY2UNCgkJaXMgY29ubmVjdGVkIChhdCBtb3N0IG9uZSBSSUIgcGVy IGFkZHJlc3MNCgkJZmFtaWx5KS4iOw0KDQpGb3Igcm91dGluZyBwcm90b2NvbCB0aGF0IHN1cHBv cnQgbXVsdGlwbGUgdG9wb2xvZ2llcywgdGhvc2UgUklCcyBjb3VsZA0KYmVsb25nIHRvIHRoZSBz YW1lIGFkZHJlc3MgZmFtaWx5Lg0KRm9yIGV4YW1wbGUsIE9TUEYgY291bGQgYmUgY29ubmVjdGVk IHRvIHR3byBJUHY0IHVuaWNhc3QgUklCLg0KDQotIERlcmVrDQoNCg0KDQoNCg0KPg0KPkkgdGhp bmsgd2Ugc2hvdWxkIGZpbmlzaCB0aGlzIGRhdGEgbW9kZWwgc29vbiBhbmQgbGV0IHJvdXRpbmcg ZXhwZXJ0cw0KPmF1Z21lbnQgYW5kIGV4dGVuZCBpdCB2aWEgbmV3IG1vZHVsZXMgY292ZXJpbmcg cm91dGluZyBwcm90b2NvbHMsIHJvdXRlDQo+ZmlsdGVyaW5nLCB2YXJpb3VzIGtpbmRzIG9mIHZp cnR1YWxpemF0aW9uIGV0Yy4NCj5JdCBpcyBxdWl0ZSBwb3NzaWJsZSB0aGF0IHRoaXMgd29yayB3 aWxsIGlkZW50aWZ5IGZsYXdzIGluIHRoZSByb3V0aW5nDQo+bW9kZWwsIGFuZCB0aGVuIGl0IHdp bGwgaGF2ZSB0byBiZSByZXZpc2VkLiBSZWNlbnRseSwgd2UgYWxpZ25lZCB0aGUNCj5tb2RlbCB3 aXRoIHRoZSBpbmZvIG1vZGVsIG9mIHRoZSBJMlJTIFdHLiBIb3dldmVyLCB3ZSBjYW5ub3QgY29u dGludWUNCj5hZGRpbmcgbmV3IGZlYXR1cmVzIGhlcmUgYW5kIHRoZXJlIGJlY2F1c2UgdGhlbiB3 ZSB3aWxsIG5ldmVyIGJlIGRvbmUuDQo+DQo+TGFkYQ0KPg0KPj4NCj4+IFRoYW5rcywNCj4+IC0g RGVyZWsNCj4+DQo+Pj4NCj4+Pj4gRFk+IG9yIHRoZSBSSUIgbmFtZSBpcyBtYWRlIHRvIGhhdmUg Y2VydGFpbiBmb3JtYXQgbGlrZSA8VlJGIE5hbWU+IG9yDQo+Pj4+PFZSRg0KPj4+PiBOYW1lPjo8 VG9wbyBOYW1lPi4NCj4+Pg0KPj4+QSBkaXNjdXNzaW9uIG9mIFZSRnMgaXMgbm93IGdvaW5nIG9u IGluIHRoZSBORVRDT05GIG1haWxpbmcgbGlzdCBhbmQgSQ0KPj4+YWxyZWFkeSBleHByZXNzZWQg bXkgb3BpbmlvbiB0aGVyZToNCj4+Pg0KPj4+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL25ldGNvbmYvY3VycmVudC9tc2cwODc1NS5odG1sDQo+Pj4NCj4+PkluIHNob3J0LCBJ IHRoaW5rIHRoZSBWUkYgY29uY2VwdCBzaG91bGQgYmUgZGVmaW5lZCBhcyBhIHNwZWNpYWwgdHlw ZSBvZg0KPj4+cm91dGluZy1pbnN0YW5jZS4NCj4+Pg0KPj4+VGhhbmtzLCBMYWRhDQo+Pj4NCj4+ Pj4gRFk+IEl0IHdpbGwgbmVlZCBtb3JlIGRpc2N1c3Npb24gdG8gYWdyZWUgb24gc29sdXRpb24u DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4+DQo+Pj4+IFRoYW5rcywNCj4+Pj4gLSBEZXJlaw0KPj4+Pg0K Pj4+Pj4NCj4+Pj4+TGFkYQ0KPj4+Pj4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBUaGFua3Ms DQo+Pj4+Pj4gLSBEZXJlaw0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4NCj4+Pj4+LS0NCj4+Pj4+ TGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPj4+Pj5QR1AgS2V5IElEOiBFNzRFOEMwQw0K Pj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4NCj4+Pg0KPj4+LS0gDQo+Pj5MYWRpc2xh diBMaG90a2EsIENaLk5JQyBMYWJzDQo+Pj5QR1AgS2V5IElEOiBFNzRFOEMwQw0KPj4NCj4NCj4t LSANCj5MYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+UEdQIEtleSBJRDogRTc0RThDMEMN Cg0K From nobody Wed Mar 19 00:24:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC711A001C for ; Wed, 19 Mar 2014 00:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V18np01pNAc6 for ; Wed, 19 Mar 2014 00:24:03 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 625951A0654 for ; Wed, 19 Mar 2014 00:24:03 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7B5A515F8; Wed, 19 Mar 2014 08:23:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id QCMOwDNsrK_1; Wed, 19 Mar 2014 08:23:53 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 19 Mar 2014 08:23:53 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D9929219A6; Wed, 19 Mar 2014 08:23:53 +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 YiRB_RJzT3U1; Wed, 19 Mar 2014 08:23: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 03EBA219A4; Wed, 19 Mar 2014 08:23:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 29B062BCFA34; Wed, 19 Mar 2014 08:23:52 +0100 (CET) Date: Wed, 19 Mar 2014 08:23:52 +0100 From: Juergen Schoenwaelder To: "Derek Man-Kit Yeung (myeung)" Message-ID: <20140319072352.GC5120@elstar.local> Mail-Followup-To: "Derek Man-Kit Yeung (myeung)" , Ladislav Lhotka , "netmod@ietf.org" References: <20140220134130.GA19665@elstar.local> <20140220.145129.73716044088019744.mbj@tail-f.com> <657A1870-B234-4489-8F0E-A85559843C16@nic.cz> <7AC19724-68FC-4A06-B491-8DA29BD2A1B7@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9ok-ZSHM6nAUApw7S94PlqG1VCc Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 19 Mar 2014 07:24:05 -0000 On Tue, Mar 18, 2014 at 11:46:52PM +0000, Derek Man-Kit Yeung (myeung) wrote: > > >This would be possible in principle but first I don't see really > >convincing reasons for this change, and second, as Juergen already > >pointed out, we are past WGLC and I am concerned that we will never > >finish this work. > > I think there is very good reason to change ;-) > > BTW, it is similar limitation for the routing-instance name, either > different type of routing-instance cannot have the same name or the type > has to be encoded in the name itself. As WG chair, I strongly believe we need to deliver. So far, I have only heard one voice asking for a change and one voice saying the change is not strictly needed. Correct me if I am wrong. It is not clear to me that we have a fundamental flaw. If we do have a _fundamental_ flaw, you need to describe this flaw clearly and concisely and it would help if others can confirm that it is a flaw. As long as we have a "this could have been done differently to make it easier for some implementations" discussion, I will not hold the document. Note that there is going to be an IETF last call - so there is another chance to raise _fundamental_ flaws if there are any. /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 Mar 19 00:30:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729D51A0652 for ; Wed, 19 Mar 2014 00:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQrkrjcX0JRr for ; Wed, 19 Mar 2014 00:30:40 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 58C891A001C for ; Wed, 19 Mar 2014 00:30:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id A4C2854039F; Wed, 19 Mar 2014 08:30:30 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tW-wjsVw-fGI; Wed, 19 Mar 2014 08:30:24 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 13ADF54027A; Wed, 19 Mar 2014 08:30:23 +0100 (CET) From: Ladislav Lhotka To: "Derek Man-Kit Yeung \(myeung\)" In-Reply-To: References: <20140111.133634.462426147.mbj@tail-f.com> <12A63CCF-69CE-4D43-A3EC-F420635B5237@nic.cz> <20140220134130.GA19665@elstar.local> <20140220.145129.73716044088019744.mbj@tail-f.com> <657A1870-B234-4489-8F0E-A85559843C16@nic.cz> <7AC19724-68FC-4A06-B491-8DA29BD2A1B7@nic.cz> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Wed, 19 Mar 2014 08:30:16 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/8tgNEXrmH8J6Pjro4WaLmHWc1Qo Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 07:30:44 -0000 "Derek Man-Kit Yeung (myeung)" writes: > On 3/15/14 2:11 AM, "Ladislav Lhotka" wrote: > >>Hi Derek, >> >>please see my responses inline. >> >>"Derek Man-Kit Yeung (myeung)" writes: >> >>> On 3/6/14 2:43 AM, "Ladislav Lhotka" wrote: >>> >>>>"Derek Man-Kit Yeung (myeung)" writes: >>>> >>>>... >>>> >>>>>>> 3) Given routing-protocol has only name as the key >>>>>>> list routing-protocol { >>>>>>> key "name"; >>>>>>> Would it prevent different protocols from using the same name? >>>>>>>Like >>>>>>> "router ospf 101" and "router rip 101" at the same time using IOS >>>>>>>syntax? >>>>>> >>>>>>List keys have to be unique, so in this case you would need to use >>>>>>e.g. >>>>>>=C2=B3ospf-101=C2=B2 and =C2=B3rip-101=C2=B2 as the keys. >>>>> >>>>> >>>>> DY> One the router, the routing protocol is identified by the type >>>>>and a >>>>> tag. >>>>> DY> Example is type OSPF and tag 101. For display purpose, you may see >>>>> "ospf 101", "Protocol: OSPF, Tag: 101" or "ospf-101" depending on >>>>> implementation. >>>>> DY> When I read your draft, I took that name mean tag and hence the >>>>> uniqueness question. >>>> >>>>As this is a vendor-neutral module, we tried to avoid assigning >>>>semantics >>>>to the names of objects because that would hardly work for different >>>>vendors. An implementation may use random strings as list keys provided >>>>they are unique. >>> >>> Combination of type and tag is very generic for identifying a routing >>> protocol. >> >>I don't think it is that generic - two examples: >> >>- JUNOS doesn't use such tags at all because multiple instances of the >>same routing protocol have to be in different routing instances. > > > If routing-protocol is keyed on both type and name (what I suggested), > then the name could be empty string. (Name becomes the tag I mentioned). > > > Then for JUNOS, the tag could just be empty string. My point was that the IOS convention is by no means universal. > > routing-instances { > routing-instance-name { > protocols { > bgp { > bgp-configuration; > } > isis { > isis-configuration; > } > ospf { > ospf-configuration; > } > =E2=80=A6 > > The routing-instance-name is the 'name' of the routing-instance container. > The bgp, isis, ospf is indicated by the 'type' of the routing-protocol > container and 'name' of the routing-protocol will be empty string. > > For vendor which support multiple instances of the same routing protocol > in the same routing-instances (VRF), the 'name' of the routing-protocol > could be the distinguisher. > > > > > >> >>- BIRD routing daemon does use tags for protocol instances, e.g. >> >>protocol ospf foo { >> ... >>} >> >>but the same tag ("foo") cannot be reused for a different protocol type. > > This is restriction of that particular implementation, I think the data > model should allow that and the backend could reject if it is not > supported. > > Actually, the current model allow routing-protcol name already, the point > we are argument is why do we need routing-type information encoded into > the name string as the current model required. The data model doesn't require this, only the routing protocol instances wi= thin a routing instance have to have unique keys. Choosing " " a= s the key is just one way for satifying this constraint. It is pretty much the same situation as with the "interface" list as define= d in the "ietf-interfaces" module: "name" is the only key and its value wil= l quite often encode the type of the interface, e.g. "eth0" or "GigabitEthe= rnet1/0", even though this information is also contained in the "type" leaf. > >> >>> If we use a name string which include both the type and tag info and do >>> not provide a format for it, >>> then I am concerned that the controller need to to adjust name string >>> accordingly depending on which vendor it is talking to. >>> It is doable but it seems to defeat the purpose of having the same data >>> model in the first place. >>> >>>> >>>>> DY> If name equate a string like "ospf-101", then the string cannot be >>>>> just arbitrary as the draft said. >>>> >>>>"ospf-101" is just an example how the name can be disambiguated in a way >>>>that is "friendly" to a particular platform. >>>> >>>>> DY> It has to have some forward like >>>> Str> so the network device can extract the tag from >>>>>it. >>>> >>>>I don't know what you mean by a "forward". How is this tag supposed to >>>>be >>>>used? >>> >>> Sorry. Typos. I mean "format". >>> For the string "ospf-1", "ospf" is the type and "1" is the tag. >>> >>>> >>>>> DY> My preference is to treat the name as and include type a >>>>>part >>>>>of >>>>> the key. >>>>> DY> Even if name mean just the tag, still need some kind of pattern as >>>>>not >>>>> all character is allowed. >>>>> DY> Is this a way in YANG to augment the name with pattern which suit >>>>>the >>>>> implementation that it talk to? >>>> >>>>Yes, it is. Some protocols add a tag as a new route attribute - see the >>>>example RIP implementation in Appendix C. >>>> >>>>If a vendor then wants to use a tag or anything else in an >>>>implementation-specific way, it can do so by writing a proprietary >>>>module >>>>that augments the standard module where necessary. This is IMO much >>>>better than encode semantics into routing protocol names. >>> >>> >>> What about making both type and name as the key? >>> >> >>This would be possible in principle but first I don't see really >>convincing reasons for this change, and second, as Juergen already >>pointed out, we are past WGLC and I am concerned that we will never >>finish this work. > > > I think there is very good reason to change ;-) > > BTW, it is similar limitation for the routing-instance name, either > different type of routing-instance cannot have the same name or the type > has to be encoded in the name itself. Right, although I don't see it as a limitation. Having a flat list of routi= ng instances, possibly of different types seems to be the most flexible str= ucture. > >> >>>> >>>>> >>>>> DY> For topology, it is just a RIB. >>>>> DY> Before topology, a RIB is identified by (Name, AFI, SAFI) like >>>>> ("Customer1", IPv4, UNICAST). >>>>> DY> Topology add an extract topology name so the identifier become >>>>>(VRF >>>>> name, AFI, SAFI, Topo name). >>>>> DY> Example are ("Customer1", IPv4, UNICAST, "Gold"), ("Customer1", >>>>>IPv4, >>>>> UNICAST, "Sliver"), ("Customer1", IPv4, UNICAST, "Bronze") >>>>> DY> It is like providing multiple data in the under the same VRF, AFI >>>>>and >>>>> SAFI. >>>>> DY> It is similar to the routing protocol name discussion. >>>>> DY> Either an topology name is added (Could it be through augmentation >>>>>as >>>>> not all vendors support topology), >>>> >>>>I believe this topology object has to do with link-state protocols, so >>>>in >>>>my view a future implementation of OSPF or IS-IS has to design new >>>>configuration and/or state data representing topologies, and augment >>>>"rt:routing-protocol" (or "rt:interface") with it. >>> >>> >>> No. it is not link state protocols specific. It is part of the RIB >>>design. >>> Suppose routing-instances could mean VRF (from below). In that case, the >>> RIB inside the routing-stances could be a "topology". We still have >>>figure >>> out how the identifier should look like. >> >>I am still not sure this is something that has to be dealt with in the >>core routing data model. IMO, the model in its current state is a >>reasonable common denominator of routing subsystem implementations (note >>it's not intended only for routers, let alone only "big" ones). > > If it is just the naming convention is left for later specification, it > could be fine. > My point is that it should not be left for each implementation to pick > their own convention. An implementation can choose either native names (or combinations thereof) = as keys of various list entries, such as "ospf 101", or an opaque string th= at is internally mapped to native names (and this mapping can be recorded i= n state data). Yes, if an implementation chooses the former approach, its configuration ma= y not be directly transferable to another platform, but it is again the sam= e situation as with interface naming. > For reference, the JUNOS encode the topology name in the RIB name. > > But there is restriction that is not necessary, in term of multiple > topology, in the draft. > For example, > > o Each routing protocol instance, including the "static" and > "direct" pseudo-protocols, is connected to exactly one RIB with > which it can exchange routes (in both directions, except for the > "static" and "direct" pseudo-protocols). > > container connected-ribs { > description > "Container for connected RIBs."; > list connected-rib { > key "rib-name"; > description > "List of RIBs to which the routing protocol instance > is connected (at most one RIB per address > family)."; > > For routing protocol that support multiple topologies, those RIBs could > belong to the same address family. > For example, OSPF could be connected to two IPv4 unicast RIB. Then the organization can be as follows: +--------+ | OSPF | +---+----+ | | +----------+ | RIB-ospf | +----------+ / \ / \ +------+ +------+ | RIB1 | | RIB2 | +------+ +------+ where RIB-ospf is the RIB that's connected to the OSPF routing instance, an= d RIB1 and RIB2 exchange routes with RIB-ospf (in one or both directions) v= ia the "recipient-rib" mechanism. Lada > > - Derek > > > > > >> >>I think we should finish this data model soon and let routing experts >>augment and extend it via new modules covering routing protocols, route >>filtering, various kinds of virtualization etc. >>It is quite possible that this work will identify flaws in the routing >>model, and then it will have to be revised. Recently, we aligned the >>model with the info model of the I2RS WG. However, we cannot continue >>adding new features here and there because then we will never be done. >> >>Lada >> >>> >>> Thanks, >>> - Derek >>> >>>> >>>>> DY> or the RIB name is made to have certain format like or >>>>>>>>> Name>:. >>>> >>>>A discussion of VRFs is now going on in the NETCONF mailing list and I >>>>already expressed my opinion there: >>>> >>>>http://www.ietf.org/mail-archive/web/netconf/current/msg08755.html >>>> >>>>In short, I think the VRF concept should be defined as a special type of >>>>routing-instance. >>>> >>>>Thanks, Lada >>>> >>>>> DY> It will need more discussion to agree on solution. >>>> >>>> >>>> >>>>> >>>>> Thanks, >>>>> - Derek >>>>> >>>>>> >>>>>>Lada >>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> - Derek >>>>>>> >>>>>>> >>>>>> >>>>>>-- >>>>>>Ladislav Lhotka, CZ.NIC Labs >>>>>>PGP Key ID: E74E8C0C >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>>-- >>>>Ladislav Lhotka, CZ.NIC Labs >>>>PGP Key ID: E74E8C0C >>> >> >>-- >>Ladislav Lhotka, CZ.NIC Labs >>PGP Key ID: E74E8C0C > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 19 00:51:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30DB1A023B for ; Wed, 19 Mar 2014 00:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AN8Io7wHvVoj for ; Wed, 19 Mar 2014 00:51:31 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 164061A00D8 for ; Wed, 19 Mar 2014 00:51:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 74EFF54039F; Wed, 19 Mar 2014 08:51:21 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01NcuM6oxM-0; Wed, 19 Mar 2014 08:51:16 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id BCC5954027A; Wed, 19 Mar 2014 08:51:16 +0100 (CET) From: Ladislav Lhotka To: "Derek Man-Kit Yeung \(myeung\)" In-Reply-To: References: <20140110133016.24678.42711.idtracker@ietfa.amsl.com> <9C81158E-5B4C-4479-AEA5-23CBCC020ADD@nic.cz> <0ED855DA-51BE-4DE6-AB22-E1A9E04C0E5F@nic.cz> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Wed, 19 Mar 2014 08:51:15 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/E0aZBcgbv3tOhiUMPvak2Olw5X4 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 07:51:33 -0000 "Derek Man-Kit Yeung (myeung)" writes: > On 3/14/14 12:49 PM, "Ladislav Lhotka" wrote: > >> >>On 14 Mar 2014, at 20:32, Derek Man-Kit Yeung (myeung) >>wrote: >> >>>=20 >>>=20 >>> On 3/7/14 2:29 PM, "Ladislav Lhotka" wrote: >>>=20 >>>>=20 >>>> On 07 Mar 2014, at 22:52, Yi Yang (yiya) wrote: >>>>=20 >>>>> One thing is missing from the data model is association with vrf. >>>>=20 >>>> I agree with what Martin wrote in a parallel thread. I believe the >>>> routing module (and YANG augment statement) provide sufficient hooks >>>>for >>>> implementing VRF as a specific type of routing-instance. >>>=20 >>>=20 >>> The draft mentioned the routing-instance could be used to represents a >>> logical router.=20 >>>=20 >>> The term "logical router" in one or more vendors mean a partition of the >>> physical router into multiple logical units, each could have multiple >>>VRFs. >>>=20 >>> Does the draft intend to manage "logical router" in the above >>>definition? >>> Some clarification will be useful. >> >>One way to implement this is to introduce two types of routing instances, >>say 'logical-router=C2=B9 and =C5=92vrf=C2=B9. The =C5=92vrf=C2=B9 type t= hen would have another >>leaf linking it to a logical router. This is quite like the various >>methods of interface stacking, see the examples in >>draft-ietf-netmod-interfaces-cfg-16. >> >>Lada > > > It is one way.=20 > However, given that current model that everything is put inside a > routing-instance, things like RIB, routing-protocols etc are no longer > needed directly under the 'logical-router'. Note that RIBs are not inside "routing-instance", although an implementatio= n may define some RIBs to be routing-instance-specific. > What needed in the 'logical router' are resources allocation like > interfaces, CPU etc. "interfaces" is a container inside "routing-instance", and "cpu" can be eas= ily added by another module via augmentation. > Though routing-instance could be augmented to include 'logical router' > specific field and add new condition to restrict existing leaf that no > long apply, I think a new container above routing-instance is cleaner. It > could be a new data model that reference the definition in the current > draft. I guess part of the confusion stems from the name "routing-instance" which = already means a particular (platform-specific) style of router virtualizati= on. Earlier revisions of the draft used "router" list in this place but it = was an specific requirement of I2RS folks to change this name to "routing-i= nstance". Oh well ... So please keep in mind that "routing-instance" can really mean different th= ings depending on its type (and can be augmented in different ways dependin= g on the type). Again, this approach is very similar to the one adopted for= the "interface" list in "ietf-interfaces" module.=20=20 Lada > > - Derek > >> >>>=20 >>> - Derek >>>=20 >>>>=20 >>>> I think though that other work extending the routing module is much >>>>more >>>> needed, namely vendor-neutral data models for routing protocols. >>>>=20 >>>> The consensus of the NETMOD WG was that these new modules should be >>>> developed by experts in the Routing Area (VRF in the MPLS WG?). The >>>> NETMOD WG and YANG Doctors will certainly help but the bulk of this >>>>work >>>> should be done by domain experts. >>>>=20 >>>> Lada >>>>=20 >>>>>=20 >>>>> Another concern I have is about address family. To facilitate a query >>>>> based on AFI only, or SAFI only, it seems more convenient to use two >>>>> leafs >>>>> (AFI and SAFI) instead of one (AFI-SAFI). >>>>>=20 >>>>> Yi >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 1/10/14 8:30 AM, "internet-drafts@ietf.org" >>>>> >>>>> wrote: >>>>>=20 >>>>>>=20 >>>>>> 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 >>>>>>Working >>>>>> Group of the IETF. >>>>>>=20 >>>>>> Title : A YANG Data Model for Routing Management >>>>>> Author : Ladislav Lhotka >>>>>> Filename : draft-ietf-netmod-routing-cfg-13.txt >>>>>> Pages : 95 >>>>>> Date : 2014-01-10 >>>>>>=20 >>>>>> Abstract: >>>>>> This document contains a specification of three YANG modules. >>>>>> Together they form the core routing data model which serves as a >>>>>> framework for configuring and managing a routing subsystem. It is >>>>>> expected that these modules will be augmented by additional YANG >>>>>> modules defining data models for individual routing protocols and >>>>>> other related functions. The core routing data model provides common >>>>>> building blocks for such extensions - routing instances, routes, >>>>>> routing information bases (RIB), routing protocols and route filters. >>>>>>=20 >>>>>>=20 >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ >>>>>>=20 >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13 >>>>>>=20 >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg-13 >>>>>>=20 >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>=20 >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> netmod@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>=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 >> >>-- >>Ladislav Lhotka, CZ.NIC Labs >>PGP Key ID: E74E8C0C >> >> >> >> > --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 19 10:02:20 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0A51A042E for ; Wed, 19 Mar 2014 10:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ig0zGzgpK-RZ for ; Wed, 19 Mar 2014 10:02:17 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id CED2E1A02F5 for ; Wed, 19 Mar 2014 10:02:16 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id m5so8762194qaj.25 for ; Wed, 19 Mar 2014 10:02:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=NT7OalWg0TXsGwxMw3XWuGSq07FF+LGlEhtEx/w2TvQ=; b=LJYqN2l5MJWN0uIciBQUY7cdqyuL+RjVaaSKyzbPCWhp2U1WxyTXk6OJNurCkVqd+9 SlC8Fa2nA5DO0auXObOodhJXylW1UdcGvL4nScOyanG7En/d6gDMMgsGTfnuEC3pHp5I BjHFiuRH13Y2uoB5uUfKVIYAXUzhqPgLSl3xNQuMrZU1WGCS60xhQYs/74mWO1+4YxwZ gcFEbF1xDx0UYYwKsSiKPZjzzg2pFmO18hodrrnM1lhgBqjgdIvl5yFr7yV5t7TCmqsT srlbn1dcsQwODKJBa2yK/Uf7Wv2xaFgZijUsBNKGK/NBtJakXTqpckb2JZVNtPZvqk4h RNpA== X-Gm-Message-State: ALoCoQlpKt7su4Pcz8BqJB2JeghMgu8ggdhWmj8+O5k+1q89/JtPQJ4k/kVRO+fA5xjq9DAT8Ie+ MIME-Version: 1.0 X-Received: by 10.140.36.77 with SMTP id o71mr42056483qgo.25.1395248527940; Wed, 19 Mar 2014 10:02:07 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Wed, 19 Mar 2014 10:02:07 -0700 (PDT) In-Reply-To: <20140319072352.GC5120@elstar.local> References: <20140220134130.GA19665@elstar.local> <20140220.145129.73716044088019744.mbj@tail-f.com> <657A1870-B234-4489-8F0E-A85559843C16@nic.cz> <7AC19724-68FC-4A06-B491-8DA29BD2A1B7@nic.cz> <20140319072352.GC5120@elstar.local> Date: Wed, 19 Mar 2014 10:02:07 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "Derek Man-Kit Yeung (myeung)" , Ladislav Lhotka , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c15fa6e1fdc104f4f89ce9 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6z6O1t0V9qzQGKPBAkHpp4NwWnw Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 17:02:19 -0000 --001a11c15fa6e1fdc104f4f89ce9 Content-Type: text/plain; charset=ISO-8859-1 Hi, On Wed, Mar 19, 2014 at 12:23 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Mar 18, 2014 at 11:46:52PM +0000, Derek Man-Kit Yeung (myeung) > wrote: > > > > >This would be possible in principle but first I don't see really > > >convincing reasons for this change, and second, as Juergen already > > >pointed out, we are past WGLC and I am concerned that we will never > > >finish this work. > > > > I think there is very good reason to change ;-) > > > > BTW, it is similar limitation for the routing-instance name, either > > different type of routing-instance cannot have the same name or the type > > has to be encoded in the name itself. > > As WG chair, I strongly believe we need to deliver. > > So far, I have only heard one voice asking for a change and one voice > saying the change is not strictly needed. Correct me if I am wrong. It > is not clear to me that we have a fundamental flaw. If we do have a > _fundamental_ flaw, you need to describe this flaw clearly and > concisely and it would help if others can confirm that it is a flaw. > > As long as we have a "this could have been done differently to make it > easier for some implementations" discussion, I will not hold the > document. Note that there is going to be an IETF last call - so there > is another chance to raise _fundamental_ flaws if there are any. > > big +1 There was lots of WG discussion wrt/ instance naming (even more for interfaces), and no consensus could be reached on picking 1 naming scheme. We did not start with a plain string containing proprietary syntax. We ended up there. Carving up the string into fields that are vendor-specific would be like starting over. /js > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > Andy --001a11c15fa6e1fdc104f4f89ce9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,


On Wed, Mar 19, 2014 at 12:23 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Mar 18, 2014 at 11:46:52PM +0000, De= rek Man-Kit Yeung (myeung) wrote:
>
> >This would be possible in principle but first I don't see real= ly
> >convincing reasons for this change, and second, as Juergen already=
> >pointed out, we are past WGLC and I am concerned that we will neve= r
> >finish this work.
>
> I think there is very good reason to change ;-)
>
> BTW, it is similar limitation for the routing-instance name, either > different type of routing-instance cannot have the same name or the ty= pe
> has to be encoded in the name itself.

As WG chair, I strongly believe we need to deliver.

So far, I have only heard one voice asking for a change and one voice
saying the change is not strictly needed. Correct me if I am wrong. It
is not clear to me that we have a fundamental flaw. If we do have a
_fundamental_ flaw, you need to describe this flaw clearly and
concisely and it would help if others can confirm that it is a flaw.

As long as we have a "this could have been done differently to make it=
easier for some implementations" discussion, I will not hold the
document. Note that there is going to be an IETF last call - so there
is another chance to raise _fundamental_ flaws if there are any.


big +1

There was lots of WG= discussion wrt/ instance naming (even more for interfaces),
and = no consensus could be reached on picking 1 naming scheme. We did not start<= /div>
with a plain string containing proprietary syntax. We ended up there. = =A0Carving up
the string into fields that are vendor-specific wou= ld be like starting over.


/js

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br>

Andy

--001a11c15fa6e1fdc104f4f89ce9-- From nobody Wed Mar 19 11:47:59 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267E21A04AF for ; Wed, 19 Mar 2014 11:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwDalPF8El-P for ; Wed, 19 Mar 2014 11:47:56 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3A95A1A078A for ; Wed, 19 Mar 2014 11:47:55 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 7E18713F8AB; Wed, 19 Mar 2014 19:47:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395254864; bh=YVyyRJl14mt366ZPR5YhcNHCKLfNklUHFVPb5pi58xc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=c2pWAtwsOR9GrZwnQkjhz5+RNd/Ax97sU64MBuBRi9gmKcOdtUdSyRSLibjv/HBas 8FilbRO5/9pvIa6Revnlsr1bHEjZyiPEMign4hLA4ud8C4AJrMKUuJiqDl6bsz5+h/ 80Bd2wMtTRQZ8U6BnKYJTYxJj42UkTiLmrfxNj6g= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 19 Mar 2014 19:47:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140220134130.GA19665@elstar.local> <20140220.145129.73716044088019744.mbj@tail-f.com> <657A1870-B234-4489-8F0E-A85559843C16@nic.cz> <7AC19724-68FC-4A06-B491-8DA29BD2A1B7@nic.cz> <20140319072352.GC5120@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OLpuMjDFF_aFTZjghcGLcvjo3yo Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 18:47:58 -0000 On 19 Mar 2014, at 18:02, Andy Bierman wrote: > Hi, >=20 >=20 > On Wed, Mar 19, 2014 at 12:23 AM, Juergen Schoenwaelder = wrote: > On Tue, Mar 18, 2014 at 11:46:52PM +0000, Derek Man-Kit Yeung (myeung) = wrote: > > > > >This would be possible in principle but first I don't see really > > >convincing reasons for this change, and second, as Juergen already > > >pointed out, we are past WGLC and I am concerned that we will never > > >finish this work. > > > > I think there is very good reason to change ;-) > > > > BTW, it is similar limitation for the routing-instance name, either > > different type of routing-instance cannot have the same name or the = type > > has to be encoded in the name itself. >=20 > As WG chair, I strongly believe we need to deliver. >=20 > So far, I have only heard one voice asking for a change and one voice > saying the change is not strictly needed. Correct me if I am wrong. It > is not clear to me that we have a fundamental flaw. If we do have a > _fundamental_ flaw, you need to describe this flaw clearly and > concisely and it would help if others can confirm that it is a flaw. >=20 > As long as we have a "this could have been done differently to make it > easier for some implementations" discussion, I will not hold the > document. Note that there is going to be an IETF last call - so there > is another chance to raise _fundamental_ flaws if there are any. >=20 >=20 > big +1 >=20 > There was lots of WG discussion wrt/ instance naming (even more for = interfaces), > and no consensus could be reached on picking 1 naming scheme. We did = not start > with a plain string containing proprietary syntax. We ended up there. = Carving up > the string into fields that are vendor-specific would be like starting = over. Agreed. It it not that everybody likes the naming schemes (including = myself), but this has indeed been the result of looong WG discussions. A = good thing is that the naming of instances is reasonably uniform across = all the core data models. Lada >=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 > Andy >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Mar 20 05:46:51 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5128B1A03CE for ; Thu, 20 Mar 2014 05:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vD0PyR3HPgTJ for ; Thu, 20 Mar 2014 05:46:47 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id A80FC1A0735 for ; Thu, 20 Mar 2014 05:46:46 -0700 (PDT) Received: from mail77-am1-R.bigfish.com (10.3.201.250) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.22; Thu, 20 Mar 2014 12:46:36 +0000 Received: from mail77-am1 (localhost [127.0.0.1]) by mail77-am1-R.bigfish.com (Postfix) with ESMTP id B0DE42404F5 for ; Thu, 20 Mar 2014 12:46:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzzz2fh109h2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3h2218h2216h226dh22d0h24afh2327h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh2668h1155h) Received-SPF: pass (mail77-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=deanb@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(93136001)(85852003)(81686001)(92566001)(92726001)(51856001)(74876001)(47446002)(80976001)(74706001)(76482001)(53806001)(65816001)(80022001)(66066001)(74502001)(69226001)(54316002)(56776001)(74662001)(31966008)(81542001)(86362001)(93516002)(50226001)(49866001)(46102001)(4396001)(81342001)(95666003)(95416001)(93916002)(83072002)(82746002)(56816005)(90146001)(47736001)(89996001)(83322001)(81816001)(88136002)(94316002)(62966002)(47976001)(50986001)(83716003)(2656002)(79102001)(59766001)(87936001)(33656001)(97336001)(97186001)(77156001)(76176001)(77096001)(87286001)(87266001)(76796001)(77982001)(36756003)(57306001)(20776003)(63696002)(85306002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB422; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:ADB9E39F.3954CF09.68E18E4B.544A8159.200C2; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail77-am1 (localhost.localdomain [127.0.0.1]) by mail77-am1 (MessageSwitch) id 1395319594109308_7387; Thu, 20 Mar 2014 12:46:34 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.227]) by mail77-am1.bigfish.com (Postfix) with ESMTP id 1711A380076 for ; Thu, 20 Mar 2014 12:46:34 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 20 Mar 2014 12:46:34 +0000 Received: from BN1PR05MB422.namprd05.prod.outlook.com (10.141.58.142) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.423.0; Thu, 20 Mar 2014 12:46:32 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB422.namprd05.prod.outlook.com (10.141.58.142) with Microsoft SMTP Server (TLS) id 15.0.898.11; Thu, 20 Mar 2014 12:46:30 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.3]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.3]) with mapi id 15.00.0898.005; Thu, 20 Mar 2014 12:46:30 +0000 From: Dean Bogdanovic To: "netmod@ietf.org" Thread-Topic: attributes in draft-lhotka-netmod-yang-json Thread-Index: AQHPRDpqdAOo+d/gwEuJDj9/zOMZ4g== Date: Thu, 20 Mar 2014 12:46:30 +0000 Message-ID: <3FADE5E8-88AC-4FD0-A2F6-72F408FAFFC4@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.12] x-forefront-prvs: 01565FED4C Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/voAKYHvK1S6GEWjha61o4SEEzUk Subject: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 12:46:49 -0000 Hi,=20 In draft yang leaf node is defined as name value pair in json If it would be represented, as an object then we can assign attributes to i= t. Example "host-name" { "data" : "router", "attributes" : { "protect" : protect} } We need attributes for several things, so lets try to figure out how to ena= ble them. Dean From nobody Thu Mar 20 07:05:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D76B1A08DA for ; Thu, 20 Mar 2014 07:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7p1IjqxohYVk for ; Thu, 20 Mar 2014 07:04:38 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3511A08D1 for ; Thu, 20 Mar 2014 07:04:36 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id AAF803B4090; Thu, 20 Mar 2014 15:04:26 +0100 (CET) Date: Thu, 20 Mar 2014 15:04:26 +0100 (CET) Message-Id: <20140320.150426.496532825.mbj@tail-f.com> To: deanb@juniper.net From: Martin Bjorklund In-Reply-To: <3FADE5E8-88AC-4FD0-A2F6-72F408FAFFC4@juniper.net> References: <3FADE5E8-88AC-4FD0-A2F6-72F408FAFFC4@juniper.net> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cNndzqrly4KJjkhhHdMN2BAanWA Cc: netmod@ietf.org Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 14:04:46 -0000 X-List-Received-Date: Thu, 20 Mar 2014 14:04:46 -0000 Dean Bogdanovic wrote: > Hi, > > In draft yang leaf node is defined as name value pair in json > > If it would be represented, as an object then we can assign attributes to it. > > Example > "host-name" { > "data" : "router", > "attributes" : { "protect" : protect} > } > > We need attributes for several things, so lets try to figure out how to enable > them. I agree that the lack of attributes is a problem with the JSON mapping. The problem with your solution is that it adds noise to the normal case where there are no attributes. We're using another encoding: "host-name": "router", "@host-name": { "protect": "protect", ... } Yep, not very elegant... /martin From nobody Thu Mar 20 08:26:15 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374321A0759 for ; Thu, 20 Mar 2014 08:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iu7NDJtPaTcG for ; Thu, 20 Mar 2014 08:26:09 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 15ABC1A0750 for ; Thu, 20 Mar 2014 08:26:08 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id r5so1143238qcx.4 for ; Thu, 20 Mar 2014 08:25:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=g3vXF2IQA7KvvGCBeb7VRDWRdUC0NVqN5dpVy7Te6Vk=; b=E9y5EVvpvIUrRk/H4B4i5AKV63O1jaoAbLyIZpazP4ZSGnRTVRPnvsKFDCQBeJIkLI R4XOi6dbN3LZDQeY3chUUcBnGgT+io9VW8d0R9fiSJaf4gWyHUsBO+meTpPO8hI8APcr FnnVhKFdS8tj4n5Yh/S2z7xQSnFsOi5c0EzDLRBk6Yylgj3HOnbdPWQ0w1p4VxbjqB0J XIIjOJYcuTrihnAudgw8a7iIF5j8DA/0N+XRixkz+HIEQWesssLvoFy+LaHVWrhE7w1N kGa+QuZoYju5qim+y+FhiwfeTJcLRMYvuDDq5HyQZ6rRbn2HNz5Scpx2Gc99qfKz1y1s 9jIQ== X-Gm-Message-State: ALoCoQlK3T9PQkdmuwirX/8XH963EQJxh8DjcntmzBUnahSTEhD9SqnuhzEL1h+pqOo/RtV2yNR8 MIME-Version: 1.0 X-Received: by 10.140.87.9 with SMTP id q9mr10020427qgd.94.1395329159837; Thu, 20 Mar 2014 08:25:59 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Thu, 20 Mar 2014 08:25:59 -0700 (PDT) In-Reply-To: <20140320.150426.496532825.mbj@tail-f.com> References: <3FADE5E8-88AC-4FD0-A2F6-72F408FAFFC4@juniper.net> <20140320.150426.496532825.mbj@tail-f.com> Date: Thu, 20 Mar 2014 08:25:59 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a113a359ceb050e04f50b62cc Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/d0YuDWGwAqfa4aNhMQeJIn4cQto Cc: "netmod@ietf.org" Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 15:26:12 -0000 --001a113a359ceb050e04f50b62cc Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 20, 2014 at 7:04 AM, Martin Bjorklund wrote: > Dean Bogdanovic wrote: > > Hi, > > > > In draft yang leaf node is defined as name value pair in json > > > > If it would be represented, as an object then we can assign attributes > to it. > > > > Example > > "host-name" { > > "data" : "router", > > "attributes" : { "protect" : protect} > > } > > > > We need attributes for several things, so lets try to figure out how to > enable > > them. > > I agree that the lack of attributes is a problem with the JSON > mapping. > > The problem with your solution is that it adds noise to the normal > case where there are no attributes. We're using another encoding: > > "host-name": "router", > "@host-name": { > "protect": "protect", > ... > } > > Yep, not very elegant... > > This is how RESTCONF encodes these attributes in a leaf: (see sec. 3.4.1) "host-name" : { "@protect" : "protect", "host-name" : "router" } Lada says that this is a YANG to JSON mapping and YANG has no attributes, so the attribute encoding is in RESTCONF. I think it would be better if there was 1 mapping, instead of a different mapping in each protocol that uses this JSON encoding of YANG data. I do not think YANG needs to model attributes! The protocol may need to use them to tag data with meta-data. We do not need to model some leafs as attributes and others as child nodes in YANG data models. Use RelaxNG instead of YANG to do that. > /martin > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a113a359ceb050e04f50b62cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 20, 2014 at 7:04 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Dean Bogdanovic <deanb@juniper.net> wrote:
> Hi,
>
> In draft yang leaf node is defined as name value pair in json
>
> If it would be represented, as an object then we can assign attributes= to it.
>
> Example
> "host-name" {
> =A0 =A0"data" : "router",
> =A0 =A0 =A0 "attributes" : { "protect" : protect}<= br> > }
>
> We need attributes for several things, so lets try to figure out how t= o enable
> them.

I agree that the lack of attributes is a problem with the JSON
mapping.

The problem with your solution is that it adds noise to the normal
case where there are no attributes. =A0We're using another encoding:
=A0 =A0"host-name": "router",
=A0 =A0"@host-name": {
=A0 =A0 =A0 =A0"protect": "protect",
=A0 =A0 =A0 =A0...
=A0 =A0 }

Yep, not very elegant...


This is how RESTCONF encodes these att= ributes in a leaf:
(see sec. 3.4.1)

=A0 = =A0"host-name" : {
=A0 =A0 =A0 =A0"@protect" = : "protect",
=A0 =A0 =A0 =A0"host-name" : "router"
= =A0 =A0}

Lada says that this is a YANG to JSON map= ping and YANG has no attributes,
so the attribute encoding is in = RESTCONF. =A0I think it would be better
if there was 1 mapping, instead of a different mapping in each protoco= l
that uses this JSON encoding of YANG data.

=
I do not think YANG needs to model attributes!
The protocol = may need to use them to tag data with meta-data.
We do not need to model some leafs as attributes and others
= as child nodes in YANG data models. =A0Use RelaxNG instead
of YAN= G to do that.




/martin


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

--001a113a359ceb050e04f50b62cc-- From nobody Thu Mar 20 08:36:51 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBAF1A0750 for ; Thu, 20 Mar 2014 08:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wA8t8gwWBvBj for ; Thu, 20 Mar 2014 08:36:47 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA1E1A06D2 for ; Thu, 20 Mar 2014 08:36:47 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 77ED539407C; Thu, 20 Mar 2014 16:36:37 +0100 (CET) Date: Thu, 20 Mar 2014 16:36:36 +0100 (CET) Message-Id: <20140320.163636.376501686.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <3FADE5E8-88AC-4FD0-A2F6-72F408FAFFC4@juniper.net> <20140320.150426.496532825.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OWkur0bOLSE4R58NOBJBaftN4nY Cc: netmod@ietf.org Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 15:36:50 -0000 Andy Bierman wrote: > On Thu, Mar 20, 2014 at 7:04 AM, Martin Bjorklund wrote: > > > Dean Bogdanovic wrote: > > > Hi, > > > > > > In draft yang leaf node is defined as name value pair in json > > > > > > If it would be represented, as an object then we can assign attributes > > to it. > > > > > > Example > > > "host-name" { > > > "data" : "router", > > > "attributes" : { "protect" : protect} > > > } > > > > > > We need attributes for several things, so lets try to figure out how to > > enable > > > them. > > > > I agree that the lack of attributes is a problem with the JSON > > mapping. > > > > The problem with your solution is that it adds noise to the normal > > case where there are no attributes. We're using another encoding: > > > > "host-name": "router", > > "@host-name": { > > "protect": "protect", > > ... > > } > > > > Yep, not very elegant... > > > > > This is how RESTCONF encodes these attributes in a leaf: > (see sec. 3.4.1) > > "host-name" : { > "@protect" : "protect", > "host-name" : "router" > } So this means that RESTCONF does not follow the JSON mapping document. If we can avoid that it would be ... good. > Lada says that this is a YANG to JSON mapping and YANG has no attributes, > so the attribute encoding is in RESTCONF. I think it would be better > if there was 1 mapping, instead of a different mapping in each protocol > that uses this JSON encoding of YANG data. +1 I think the JSON mapping document should define how meta data are encoded, if the protocol supports meta data. > I do not think YANG needs to model attributes! +1 > The protocol may need to use them to tag data with meta-data. Yes. /martin From nobody Thu Mar 20 15:32:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06A81A07F2 for ; Thu, 20 Mar 2014 15:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpAuua4DU8OR for ; Thu, 20 Mar 2014 15:32:06 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id EB3761A077C for ; Thu, 20 Mar 2014 15:32:05 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id D6A5514011F; Thu, 20 Mar 2014 23:31:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395354716; bh=KA7fp0aGM7Tdn/xFb9isdqf+MoQSluhG0503C7oQI2E=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=uzfA2Umd61nvXUnUK2yajocxxOsYMJYMcTn0WwYVh33xKEWhfvS2ZqFsTj8ocvWKI bquSgHL4fVSxYausiBm84nOhwyG1pPNiVeu7DqH78SBx1EfMeDoT+Eg0qcLauHGgpj i2nspGCGsYyjNjwONBoQ+S224GZldlQn2H/OgVNY= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140320.150426.496532825.mbj@tail-f.com> Date: Thu, 20 Mar 2014 23:31:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <581E695D-7892-4CCE-9CF8-E534FD323F7F@nic.cz> References: <3FADE5E8-88AC-4FD0-A2F6-72F408FAFFC4@juniper.net> <20140320.150426.496532825.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kBIio6WPL6e_7gcSm9adfTrYad0 Cc: netmod@ietf.org Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 22:32:08 -0000 On 20 Mar 2014, at 15:04, Martin Bjorklund wrote: > Dean Bogdanovic wrote: >> Hi,=20 >>=20 >> In draft yang leaf node is defined as name value pair in json >>=20 >> If it would be represented, as an object then we can assign = attributes to it. >>=20 >> Example >> "host-name" { >> "data" : "router", >> "attributes" : { "protect" : protect} >> } >>=20 >> We need attributes for several things, so lets try to figure out how = to enable >> them. >=20 > I agree that the lack of attributes is a problem with the JSON > mapping. YANG doesn=92t model XML attributes, so attributes are out of scope for = the mapping. I=92d be happy to provide decent place for attributes, but = I don=92t like Dean=92s proposal - it just makes JSON text terribly = messy. >=20 > The problem with your solution is that it adds noise to the normal > case where there are no attributes. We're using another encoding: >=20 > "host-name": "router", > "@host-name": { > "protect": "protect", > ... > } >=20 > Yep, not very elegant=85 But still much much better. As you say, it spoils only places where = attributes are really needed. I am inclined to include this kind of = attribute mapping in the draft, if we can reach a rough consensus on it. Lada >=20 >=20 > /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Mar 21 03:10:14 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9228A1A06B9 for ; Fri, 21 Mar 2014 03:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdmF3AlIQsA3 for ; Fri, 21 Mar 2014 03:10:10 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6EF1A06B4 for ; Fri, 21 Mar 2014 03:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=757; q=dns/txt; s=iport; t=1395396601; x=1396606201; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=wihOKQkcU0osSHK03SGwgjpz2T9BwXXae/sLJNA42cE=; b=duFXK6qE9oUw7IXB5bztXYksWhkES4uVyIVJsDeIWVOlvGCMqEf+fUu9 vHitg2b42qQzVueDQB/B9DPb3Z5NGeb1H0VXXUhED+t1V8OS+AtTINFSF LXq7/zbx/AKGN919yWryftKJKfGN4pAv6bz4P6vyhmcGxMyUvmN0ztlrb 0=; X-IronPort-AV: E=Sophos;i="4.97,703,1389744000"; d="scan'208";a="9682465" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 21 Mar 2014 10:10:00 +0000 Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2LA9xiW016478; Fri, 21 Mar 2014 10:10:00 GMT Message-ID: <532C0FF7.3090808@cisco.com> Date: Fri, 21 Mar 2014 11:09:59 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Yi Yang (yiya)" , Ladislav Lhotka , "netmod@ietf.org" References: <20140213183325.16175.99400.idtracker@ietfa.amsl.com> <20140307.231152.435558401.mbj@tail-f.com> <20140308080908.GB71516@elstar.local> In-Reply-To: <20140308080908.GB71516@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/sYxHcCkmFt9j3jegiPu9YWwWezc Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 10:10:12 -0000 Dear all, I take as granted that this issue is closed. If this is not the case, quickly let me know as this draft is on the IESG telechat next Thursday. Regards, Benoit > On Fri, Mar 07, 2014 at 10:50:04PM +0000, Yi Yang (yiya) wrote: >> [yi]: A vrf can be associated with multiple routing tables, so yes, a >> separated data model for vrf is required. But in the DM for routing table, >> we need a reference to the vrf. >> > Can you make a concrete proposal what you think is missing? Note that > the routing model passed WG last call and unless there is a major bug > I prefer to move this document forward as is. So please come up with a > concrete detailed proposal so that we can decide whether we have a bug > or not. > > /js > From nobody Fri Mar 21 08:38:19 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583261A098A for ; Fri, 21 Mar 2014 08:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5pGkrU_WFs2 for ; Fri, 21 Mar 2014 08:38:04 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id 39D591A09AA for ; Fri, 21 Mar 2014 08:37:55 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id o15so2562616qap.37 for ; Fri, 21 Mar 2014 08:37:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eIU8RVK04Oy24WSXDMDy0HFbVihwqjnmoDUTd/cBShM=; b=RlY3f1ycDlpCuQzc0EIzHB9xRrl3yFdhEtEFS+qeOn2AQTEXFhEtkaGBLPAtCjVw+O Um9+BFauFh3LE0QjaR1DAJ/Uox0ma/zFmE0cYMgjCHHPU1wSpkTsMee71/WbHTwzf1vK omNVJy/55qUYtyGnLXKFMqQppSMsfN/I56uVVCGLgASA7Qx1kWHx0dBNfzZgiJ7GJH7r kQEhh5OCY3dPgga4Ac0knX2cEyXpXKGy7M4QYXl7XsU7dYJnDCL4RuLdoCsEiAO/AVyr efhT3q6QQ0D7/2P9+6kOZ0saCQi6fO1EcqNEN9OTgTl51dTCQ/Uhl/KXGmU2/vZNl1h6 U3Pg== X-Gm-Message-State: ALoCoQn4D5151CBLKCkls5nXMCLcILGCwkbKHLUMwaWQV9tzpp44q6VoCM/lcvXshgpYLknEKl0x MIME-Version: 1.0 X-Received: by 10.224.112.6 with SMTP id u6mr33272890qap.78.1395416265651; Fri, 21 Mar 2014 08:37:45 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Fri, 21 Mar 2014 08:37:45 -0700 (PDT) In-Reply-To: References: <3FADE5E8-88AC-4FD0-A2F6-72F408FAFFC4@juniper.net> <20140320.150426.496532825.mbj@tail-f.com> Date: Fri, 21 Mar 2014 08:37:45 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c2e848d407b604f51faae8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/utyiULB2f-ENd4ntsRDaVq0FH4w Cc: "netmod@ietf.org" Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 15:38:09 -0000 --001a11c2e848d407b604f51faae8 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 20, 2014 at 8:25 AM, Andy Bierman wrote: > > > > On Thu, Mar 20, 2014 at 7:04 AM, Martin Bjorklund wrote: > >> Dean Bogdanovic wrote: >> > Hi, >> > >> > In draft yang leaf node is defined as name value pair in json >> > >> > If it would be represented, as an object then we can assign attributes >> to it. >> > >> > Example >> > "host-name" { >> > "data" : "router", >> > "attributes" : { "protect" : protect} >> > } >> > >> > We need attributes for several things, so lets try to figure out how to >> enable >> > them. >> >> I agree that the lack of attributes is a problem with the JSON >> mapping. >> >> The problem with your solution is that it adds noise to the normal >> case where there are no attributes. We're using another encoding: >> >> "host-name": "router", >> "@host-name": { >> "protect": "protect", >> ... >> } >> >> Yep, not very elegant... >> >> More importantly, it doesn't work for lists or leaf-lists. The attributes cannot be siblings (or ancestors) of the target data node. Consider the following YANG data-stmt, and how an attribute would be encoded in every data node (as a worse-case example). container top { list A { key id; leaf id { type string; } leaf-list aa { type int8; } } leaf host-name { type string; } } Plain JSON { "top" : { "A" : [ { "id":"entry-1", "aa": [42, 19] }, { "id":"entry-2", "aa" : [99, 11] } ] }, "host-name":"router" } Add attribute to each node: leaf owner { type string; } With Owner Attribute using RESTCONF encoding: { "top" : { "@owner":"system", "A" : [ { "@owner":"admin1", "id" : { "@owner":"admin1", "id": "entry-1" }, "aa" : [ { "@owner":"admin1", "aa": 42 }, { "@owner":"admin1", "aa": 19 } ] }, { "@owner":"admin2", "id" : { "@owner":"admin2", "id": "entry-2" }, "aa" : [ { "@owner":"admin2", "aa": 99 }, { "@owner":"admin2", "aa": 11 } ] } ] }, "host-name" : { "@owner":"system", "host-name":"router" } } This is not elegant either, but it works for all YANG node types. How would your encoding look for this example? Andy > > This is how RESTCONF encodes these attributes in a leaf: > (see sec. 3.4.1) > > "host-name" : { > "@protect" : "protect", > "host-name" : "router" > } > > Lada says that this is a YANG to JSON mapping and YANG has no attributes, > so the attribute encoding is in RESTCONF. I think it would be better > if there was 1 mapping, instead of a different mapping in each protocol > that uses this JSON encoding of YANG data. > > I do not think YANG needs to model attributes! > The protocol may need to use them to tag data with meta-data. > We do not need to model some leafs as attributes and others > as child nodes in YANG data models. Use RelaxNG instead > of YANG to do that. > > > > >> /martin >> >> > Andy > > >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > --001a11c2e848d407b604f51faae8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 20, 2014 at 8:25 AM, Andy Bierman <= ;andy@yumaworks.com= > wrote:



On Thu, Mar 20, 2014 at 7:04 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Dean Bogdanovic <deanb@juniper.net> wrote:
> Hi,
>
> In draft yang leaf node is defined as name value pair in json
>
> If it would be represented, as an object then we can assign attributes= to it.
>
> Example
> "host-name" {
> =A0 =A0"data" : "router",
> =A0 =A0 =A0 "attributes" : { "protect" : protect}<= br> > }
>
> We need attributes for several things, so lets try to figure out how t= o enable
> them.

I agree that the lack of attributes is a problem with the JSON
mapping.

The problem with your solution is that it adds noise to the normal
case where there are no attributes. =A0We're using another encoding:
=A0 =A0"host-name": "router",
=A0 =A0"@host-name": {
=A0 =A0 =A0 =A0"protect": "protect",
=A0 =A0 =A0 =A0...
=A0 =A0 }

Yep, not very elegant...



More importantly, it doesn't work for lists or leaf-lists.
The attributes cannot be siblings (or ancestors) of the target data n= ode.

Consider the following YANG data-stmt, and how an attri= bute
would be encoded in every data node (as a worse-case example= ).


container top {
=A0 list A {
=A0 =A0 key id;
=A0 =A0 leaf id { type str= ing; }
=A0 =A0 leaf-list aa { type int8; }
=A0 }
<= div>=A0 leaf host-name { type string; }
}

Plain JSON

{ "top" : {
=A0 "A" : [
=A0 =A0 { "id":"entry-1",
=A0 =A0 = =A0 "aa": [42, 19]
=A0 =A0 },
=A0 =A0 { "= ;id":"entry-2",
=A0 =A0 =A0 "aa" : [99, 11]
=A0 =A0 } ]
= =A0 },
=A0 "host-name":"router"
}

Add attribute to each node:
=A0 =A0leaf o= wner { type string; }

With Owner Attribute using RESTCONF encoding:

{ "top" : {
=A0 "@owner":&quo= t;system",
=A0 "A" : [
=A0 =A0 { "@= owner":"admin1",
=A0 =A0 =A0 "id" : {
=A0 =A0 =A0 =A0 "@owner&= quot;:"admin1",
=A0 =A0 =A0 =A0 "id": "e= ntry-1"
=A0 =A0 =A0 },
=A0 =A0 =A0 "aa" = : [ { "@owner":"admin1", =A0"aa": 42 },
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0{ "@owner":"admin1&q= uot;, =A0"aa": 19 } ]
=A0 =A0 },
=A0 =A0 { &q= uot;@owner":"admin2",
=A0 =A0 =A0 "id" := {
=A0 =A0 =A0 =A0 "@owner":"admin2",
=A0 =A0 =A0 =A0 "id": "entry-2"
=A0 =A0 = =A0 },
=A0 =A0 =A0 "aa" : [ { "@owner":"= admin2", =A0"aa": 99 },
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0{ "@owner":"admin2", =A0"aa": 11 }= ]
=A0 =A0 } ]
=A0 },
=A0 "host-name" : { &= quot;@owner":"system",
=A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0"host-name":"router" }
}


This is not elegant either, but it works for all YANG n= ode types.
How would your encoding look for this example?



Andy


=A0

This is how RESTCONF encodes these attributes in a leaf:
(see sec= . 3.4.1)

=A0 =A0"host-name" : {
=A0 =A0 =A0 =A0"@protect" : "protect",
=A0 =A0 =A0 =A0"host-name" : "router"
= =A0 =A0}

Lada says that this is a YANG to JSON mapping and YANG has no a= ttributes,
so the attribute encoding is in RESTCONF. =A0I think i= t would be better
if there was 1 mapping, instead of a different mapping in each protoco= l
that uses this JSON encoding of YANG data.

=
I do not think YANG needs to model attributes!
The protocol = may need to use them to tag data with meta-data.
We do not need to model some leafs as attributes and others
= as child nodes in YANG data models. =A0Use RelaxNG instead
of YAN= G to do that.




/martin


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


--001a11c2e848d407b604f51faae8-- From nobody Fri Mar 21 09:43:18 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF491A09F4 for ; Fri, 21 Mar 2014 09:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRZ-ScP-X9oU for ; Fri, 21 Mar 2014 09:43:12 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4A89A1A0794 for ; Fri, 21 Mar 2014 09:43:12 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id e89so7787842qgf.5 for ; Fri, 21 Mar 2014 09:43:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=r+YsSq0eun4Ew5w2vSX0zuvz8DqJ5viGqw7ApWFHHlo=; b=a3nVgE1nWmCVYAaKz5+22TyDmhMGWwioYaoMxxetKP6gXeFLfe/0Di6LXUFwyo1qff G9DtlYk8vK7EP9sWTHxFebtxoU961TtUUhkfVDERMyu4zs76qiOmK9szsVg+9GOKlBe+ VFvog2cS9C28QiSgjnOUB23YEup3sN0j+l1chJAQbPI993vd84anBoCMi2Tc2DIspWAP obzRj/RQD7vYJio1IUw8PtqesPb7fGxGdJas2bvbx8rjWPBDLXO4SRyatoFRNMmkS6Cs 5VbpdcrvfkUY2Jk0axGACYYnlo4MrrNf9cqebL0I/gLvjnNHkXluKG5KaZAJFXMk3E9k vvYw== X-Gm-Message-State: ALoCoQkpNwY1B6VOXYJH9KH2/wON/hFg4mAY4yS9FXAcce4kQoTCRrhm4ZU80pf24owtSi3JtDza MIME-Version: 1.0 X-Received: by 10.140.27.193 with SMTP id 59mr55099694qgx.18.1395420182453; Fri, 21 Mar 2014 09:43:02 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Fri, 21 Mar 2014 09:43:02 -0700 (PDT) In-Reply-To: References: <3FADE5E8-88AC-4FD0-A2F6-72F408FAFFC4@juniper.net> <20140320.150426.496532825.mbj@tail-f.com> Date: Fri, 21 Mar 2014 09:43:02 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c1233a4a3f5904f5209450 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/M_mZ34nr4ufu6iTa5HVcWOkmyr0 Cc: "netmod@ietf.org" Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 16:43:14 -0000 --001a11c1233a4a3f5904f5209450 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 21, 2014 at 8:37 AM, Andy Bierman wrote: > > > > On Thu, Mar 20, 2014 at 8:25 AM, Andy Bierman wrote: > >> >> >> >> On Thu, Mar 20, 2014 at 7:04 AM, Martin Bjorklund wrote: >> >>> Dean Bogdanovic wrote: >>> > Hi, >>> > >>> > In draft yang leaf node is defined as name value pair in json >>> > >>> > If it would be represented, as an object then we can assign attributes >>> to it. >>> > >>> > Example >>> > "host-name" { >>> > "data" : "router", >>> > "attributes" : { "protect" : protect} >>> > } >>> > >>> > We need attributes for several things, so lets try to figure out how >>> to enable >>> > them. >>> >>> I agree that the lack of attributes is a problem with the JSON >>> mapping. >>> >>> The problem with your solution is that it adds noise to the normal >>> case where there are no attributes. We're using another encoding: >>> >>> "host-name": "router", >>> "@host-name": { >>> "protect": "protect", >>> ... >>> } >>> >>> Yep, not very elegant... >>> >>> > > More importantly, it doesn't work for lists or leaf-lists. > The attributes cannot be siblings (or ancestors) of the target data node. > > Consider the following YANG data-stmt, and how an attribute > would be encoded in every data node (as a worse-case example). > > > container top { > list A { > key id; > leaf id { type string; } > leaf-list aa { type int8; } > } > leaf host-name { type string; } > } > > Plain JSON > > { "top" : { > "A" : [ > { "id":"entry-1", > "aa": [42, 19] > }, > { "id":"entry-2", > "aa" : [99, 11] > } ] > }, > "host-name":"router" > oops -- host-name should be up 1 level, sibling of A Same mistake below... Andy } > > Add attribute to each node: > leaf owner { type string; } > > With Owner Attribute using RESTCONF encoding: > > { "top" : { > "@owner":"system", > "A" : [ > { "@owner":"admin1", > "id" : { > "@owner":"admin1", > "id": "entry-1" > }, > "aa" : [ { "@owner":"admin1", "aa": 42 }, > { "@owner":"admin1", "aa": 19 } ] > }, > { "@owner":"admin2", > "id" : { > "@owner":"admin2", > "id": "entry-2" > }, > "aa" : [ { "@owner":"admin2", "aa": 99 }, > { "@owner":"admin2", "aa": 11 } ] > } ] > }, > "host-name" : { "@owner":"system", > "host-name":"router" } > } > > > This is not elegant either, but it works for all YANG node types. > How would your encoding look for this example? > > > > Andy > > > > >> >> This is how RESTCONF encodes these attributes in a leaf: >> (see sec. 3.4.1) >> >> "host-name" : { >> "@protect" : "protect", >> "host-name" : "router" >> } >> >> Lada says that this is a YANG to JSON mapping and YANG has no attributes, >> so the attribute encoding is in RESTCONF. I think it would be better >> if there was 1 mapping, instead of a different mapping in each protocol >> that uses this JSON encoding of YANG data. >> >> I do not think YANG needs to model attributes! >> The protocol may need to use them to tag data with meta-data. >> We do not need to model some leafs as attributes and others >> as child nodes in YANG data models. Use RelaxNG instead >> of YANG to do that. >> >> >> >> >>> /martin >>> >>> >> Andy >> >> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> >> > --001a11c1233a4a3f5904f5209450 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Mar 21, 2014 at 8:37 AM, Andy Bierman <= ;andy@yumaworks.com= > wrote:



On Thu, Mar 20, 2014 at 8:25 AM, And= y Bierman <andy@yumaworks.com> wrote:



On Thu, Mar 20, 2014 at 7:04 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Dean Bogdanovic <deanb@juniper.net> wrote:
> Hi,
>
> In draft yang leaf node is defined as name value pair in json
>
> If it would be represented, as an object then we can assign attributes= to it.
>
> Example
> "host-name" {
> =A0 =A0"data" : "router",
> =A0 =A0 =A0 "attributes" : { "protect" : protect}<= br> > }
>
> We need attributes for several things, so lets try to figure out how t= o enable
> them.

I agree that the lack of attributes is a problem with the JSON
mapping.

The problem with your solution is that it adds noise to the normal
case where there are no attributes. =A0We're using another encoding:
=A0 =A0"host-name": "router",
=A0 =A0"@host-name": {
=A0 =A0 =A0 =A0"protect": "protect",
=A0 =A0 =A0 =A0...
=A0 =A0 }

Yep, not very elegant...



More importantly, it doesn't work for lists or leaf-lists.
The attributes cannot be siblings (or ancestors) of the target data n= ode.

Consider the following YANG data-stmt, and how an attri= bute
would be encoded in every data node (as a worse-case example= ).


container top {
=A0 list A {
=A0 =A0 key id;
=A0 =A0 leaf id { type str= ing; }
=A0 =A0 leaf-list aa { type int8; }
=A0 }
<= div>=A0 leaf host-name { type string; }
}

Plain JSON

{ "top" : {
=A0 "A" : [
=A0 =A0 { "id":"entry-1",
=A0 =A0 = =A0 "aa": [42, 19]
=A0 =A0 },
=A0 =A0 { "= ;id":"entry-2",
=A0 =A0 =A0 "aa" : [99, 11]
=A0 =A0 } ]
= =A0 },
=A0 "host-name":"router"


oops -- hos= t-name should be up 1 level, sibling of A
Same mistake below...

Andy


}

Add attribu= te to each node:
=A0 =A0leaf owner { type string; }

With Owner Attribute using RESTCONF encoding:

{ "top" : {
=A0 "@owner":&quo= t;system",
=A0 "A" : [
=A0 =A0 { "@= owner":"admin1",
=A0 =A0 =A0 "id" : {
=A0 =A0 =A0 =A0 "@owner&= quot;:"admin1",
=A0 =A0 =A0 =A0 "id": "e= ntry-1"
=A0 =A0 =A0 },
=A0 =A0 =A0 "aa" = : [ { "@owner":"admin1", =A0"aa": 42 },
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0{ "@owner":"admin1&q= uot;, =A0"aa": 19 } ]
=A0 =A0 },
=A0 =A0 { &q= uot;@owner":"admin2",
=A0 =A0 =A0 "id" := {
=A0 =A0 =A0 =A0 "@owner":"admin2",
=A0 =A0 =A0 =A0 "id": "entry-2"
=A0 =A0 = =A0 },
=A0 =A0 =A0 "aa" : [ { "@owner":"= admin2", =A0"aa": 99 },
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0{ "@owner":"admin2", =A0"aa": 11 }= ]
=A0 =A0 } ]
=A0 },
=A0 "host-name" : { &= quot;@owner":"system",
=A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0"host-name":"router" }
}


This is not elegant either, but it works for all YANG n= ode types.
How would your encoding look for this example?



Andy


=A0

This is how RESTCONF encodes these attributes in a leaf:
(see sec= . 3.4.1)

=A0 =A0"host-name" : {
=A0 =A0 =A0 =A0"@protect" : "protect",
=A0 =A0 =A0 =A0"host-name" : "router"
= =A0 =A0}

Lada says that this is a YANG to JSON mapping and YANG has no a= ttributes,
so the attribute encoding is in RESTCONF. =A0I think i= t would be better
if there was 1 mapping, instead of a different mapping in each protoco= l
that uses this JSON encoding of YANG data.

=
I do not think YANG needs to model attributes!
The protocol = may need to use them to tag data with meta-data.
We do not need to model some leafs as attributes and others
= as child nodes in YANG data models. =A0Use RelaxNG instead
of YAN= G to do that.




/martin


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



--001a11c1233a4a3f5904f5209450-- From nobody Sat Mar 22 01:08:57 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01CB21A0584 for ; Sat, 22 Mar 2014 01:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTtgnLMG8Cyh for ; Sat, 22 Mar 2014 01:08:51 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 433FE1A0079 for ; Sat, 22 Mar 2014 01:08:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 833F0540594; Sat, 22 Mar 2014 09:08:40 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DkV+kvT+W1n; Sat, 22 Mar 2014 09:08:35 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id F2879540192; Sat, 22 Mar 2014 09:08:33 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman , Martin Bjorklund In-Reply-To: References: <3FADE5E8-88AC-4FD0-A2F6-72F408FAFFC4@juniper.net> <20140320.150426.496532825.mbj@tail-f.com> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Sat, 22 Mar 2014 09:08:35 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xFqW1ZRrTBWf8Vmx2A8QqCsQHT0 Cc: "netmod@ietf.org" Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 08:08:55 -0000 Andy Bierman writes: > On Thu, Mar 20, 2014 at 8:25 AM, Andy Bierman wrote: > >> >> >> >> On Thu, Mar 20, 2014 at 7:04 AM, Martin Bjorklund wrote: >> >>> Dean Bogdanovic wrote: >>> > Hi, >>> > >>> > In draft yang leaf node is defined as name value pair in json >>> > >>> > If it would be represented, as an object then we can assign attributes >>> to it. >>> > >>> > Example >>> > "host-name" { >>> > "data" : "router", >>> > "attributes" : { "protect" : protect} >>> > } >>> > >>> > We need attributes for several things, so lets try to figure out how to >>> enable >>> > them. >>> >>> I agree that the lack of attributes is a problem with the JSON >>> mapping. >>> >>> The problem with your solution is that it adds noise to the normal >>> case where there are no attributes. We're using another encoding: >>> >>> "host-name": "router", >>> "@host-name": { >>> "protect": "protect", >>> ... >>> } >>> >>> Yep, not very elegant... >>> >>> > > More importantly, it doesn't work for lists or leaf-lists. > The attributes cannot be siblings (or ancestors) of the target data node. An option for boolean-type properties is to wrap the affected object or value, e.g. "@protect": { "host-name": ... } or "foo" : [ 1, 2, {"@protect": 3}, 4] Instead of defining a general JSON equivalent of XML attributes, it might actually be easier to come up with an ad hoc representation for every use case. This is the approach of some native JSON applications such as MongoDB. So, the specification of each global property (e.g. "protected") would also define an appropriate encoding in both XML and JSON. > > Consider the following YANG data-stmt, and how an attribute > would be encoded in every data node (as a worse-case example). > > > container top { > list A { > key id; > leaf id { type string; } > leaf-list aa { type int8; } > } > leaf host-name { type string; } > } > > Plain JSON > > { "top" : { > "A" : [ > { "id":"entry-1", > "aa": [42, 19] > }, > { "id":"entry-2", > "aa" : [99, 11] > } ] > }, > "host-name":"router" > } > > Add attribute to each node: > leaf owner { type string; } > > With Owner Attribute using RESTCONF encoding: > > { "top" : { > "@owner":"system", > "A" : [ > { "@owner":"admin1", > "id" : { > "@owner":"admin1", > "id": "entry-1" > }, > "aa" : [ { "@owner":"admin1", "aa": 42 }, > { "@owner":"admin1", "aa": 19 } ] > }, > { "@owner":"admin2", > "id" : { > "@owner":"admin2", > "id": "entry-2" > }, > "aa" : [ { "@owner":"admin2", "aa": 99 }, > { "@owner":"admin2", "aa": 11 } ] > } ] > }, > "host-name" : { "@owner":"system", > "host-name":"router" } > } > > > This is not elegant either, but it works for all YANG node types. > How would your encoding look for this example? "@owned-object": { "@owner": "system", "host-name": "router" } Lada > > > > Andy > > > > >> >> This is how RESTCONF encodes these attributes in a leaf: >> (see sec. 3.4.1) >> >> "host-name" : { >> "@protect" : "protect", >> "host-name" : "router" >> } >> >> Lada says that this is a YANG to JSON mapping and YANG has no attributes, >> so the attribute encoding is in RESTCONF. I think it would be better >> if there was 1 mapping, instead of a different mapping in each protocol >> that uses this JSON encoding of YANG data. >> >> I do not think YANG needs to model attributes! >> The protocol may need to use them to tag data with meta-data. >> We do not need to model some leafs as attributes and others >> as child nodes in YANG data models. Use RelaxNG instead >> of YANG to do that. >> >> >> >> >>> /martin >>> >>> >> Andy >> >> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sat Mar 22 03:47:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D5B1A0954 for ; Sat, 22 Mar 2014 03:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bebXErs3lhvI for ; Sat, 22 Mar 2014 03:47:28 -0700 (PDT) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) by ietfa.amsl.com (Postfix) with ESMTP id A69B21A0951 for ; Sat, 22 Mar 2014 03:47:28 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id q108so10361226qgd.9 for ; Sat, 22 Mar 2014 03:47:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zvZZY/RbnEHO2kHmipI96qINdsJ2r24zGDJp69qkmug=; b=HAjK39kU0gceSjxx1VX8NqKJS7sbBX94Va7Qv1jwcmZ6jtZ7pnAIKCBmGSoimX7uBQ lrqklvC5ma++qXTsio9n4oLlE4sCw/wfpwLhEaev2l0u+BdEq8PTSjogdHAqJSGIvFzu KfeRrHMCEdZswP2QWrTqOK8labMi23t4ia0yKgZLGGB8EXc4G/ADP28Ofo3tG6g3041b zxeHu3omnUOiT5MaqO/2S94PSnkni9gqwA52kQaoAYfpiajHZgCkqrxwjpTQS1MZgBsX 5KO9avNOEWxwlNphfdr7PnlsG0UTwnxkgrKtks1fGn1SlxKK+KPcbzTV31NFORgt0Spl +L9A== X-Gm-Message-State: ALoCoQmabswZ+lKz3ESvAE10bLl1k9ZZ9G3gVD0WcKt7WsSVoO8/5DpeBdGIxARTcPa5nmnQrpFp MIME-Version: 1.0 X-Received: by 10.224.89.71 with SMTP id d7mr62792999qam.54.1395485248345; Sat, 22 Mar 2014 03:47:28 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Sat, 22 Mar 2014 03:47:28 -0700 (PDT) In-Reply-To: References: <3FADE5E8-88AC-4FD0-A2F6-72F408FAFFC4@juniper.net> <20140320.150426.496532825.mbj@tail-f.com> Date: Sat, 22 Mar 2014 03:47:28 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c3e166846b5c04f52fba58 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/GfZw0Xjld5qaN4Jb_7em5lVNfL8 Cc: "netmod@ietf.org" Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 10:47:31 -0000 --001a11c3e166846b5c04f52fba58 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Mar 22, 2014 at 1:08 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Thu, Mar 20, 2014 at 8:25 AM, Andy Bierman > wrote: > > > >> > >> > >> > >> On Thu, Mar 20, 2014 at 7:04 AM, Martin Bjorklund > wrote: > >> > >>> Dean Bogdanovic wrote: > >>> > Hi, > >>> > > >>> > In draft yang leaf node is defined as name value pair in json > >>> > > >>> > If it would be represented, as an object then we can assign > attributes > >>> to it. > >>> > > >>> > Example > >>> > "host-name" { > >>> > "data" : "router", > >>> > "attributes" : { "protect" : protect} > >>> > } > >>> > > >>> > We need attributes for several things, so lets try to figure out how > to > >>> enable > >>> > them. > >>> > >>> I agree that the lack of attributes is a problem with the JSON > >>> mapping. > >>> > >>> The problem with your solution is that it adds noise to the normal > >>> case where there are no attributes. We're using another encoding: > >>> > >>> "host-name": "router", > >>> "@host-name": { > >>> "protect": "protect", > >>> ... > >>> } > >>> > >>> Yep, not very elegant... > >>> > >>> > > > > More importantly, it doesn't work for lists or leaf-lists. > > The attributes cannot be siblings (or ancestors) of the target data node. > > An option for boolean-type properties is to wrap the affected object or > value, e.g. > > "@protect": { > "host-name": ... > } > > or > > "foo" : [ 1, 2, {"@protect": 3}, 4] > > Instead of defining a general JSON equivalent of XML attributes, it might > actually be easier to come up with an ad hoc representation for every use > case. This is the approach of some native JSON applications such as MongoDB. > > So, the specification of each global property (e.g. "protected") would > also define an appropriate encoding in both XML and JSON. > > > > > Consider the following YANG data-stmt, and how an attribute > > would be encoded in every data node (as a worse-case example). > > > > > > container top { > > list A { > > key id; > > leaf id { type string; } > > leaf-list aa { type int8; } > > } > > leaf host-name { type string; } > > } > > > > Plain JSON > > > > { "top" : { > > "A" : [ > > { "id":"entry-1", > > "aa": [42, 19] > > }, > > { "id":"entry-2", > > "aa" : [99, 11] > > } ] > > }, > > "host-name":"router" > > } > > > > Add attribute to each node: > > leaf owner { type string; } > > > > With Owner Attribute using RESTCONF encoding: > > > > { "top" : { > > "@owner":"system", > > "A" : [ > > { "@owner":"admin1", > > "id" : { > > "@owner":"admin1", > > "id": "entry-1" > > }, > > "aa" : [ { "@owner":"admin1", "aa": 42 }, > > { "@owner":"admin1", "aa": 19 } ] > > }, > > { "@owner":"admin2", > > "id" : { > > "@owner":"admin2", > > "id": "entry-2" > > }, > > "aa" : [ { "@owner":"admin2", "aa": 99 }, > > { "@owner":"admin2", "aa": 11 } ] > > } ] > > }, > > "host-name" : { "@owner":"system", > > "host-name":"router" } > > } > > > > > > This is not elegant either, but it works for all YANG node types. > > How would your encoding look for this example? > > "@owned-object": { > "@owner": "system", > "host-name": "router" > } > > Can you show how 2 list entries and 2 leaf-list entries have different attribute values. Of course we need to support string values, not just boolean. > Lada > Andy > > > > > > > > > Andy > > > > > > > > > >> > >> This is how RESTCONF encodes these attributes in a leaf: > >> (see sec. 3.4.1) > >> > >> "host-name" : { > >> "@protect" : "protect", > >> "host-name" : "router" > >> } > >> > >> Lada says that this is a YANG to JSON mapping and YANG has no > attributes, > >> so the attribute encoding is in RESTCONF. I think it would be better > >> if there was 1 mapping, instead of a different mapping in each protocol > >> that uses this JSON encoding of YANG data. > >> > >> I do not think YANG needs to model attributes! > >> The protocol may need to use them to tag data with meta-data. > >> We do not need to model some leafs as attributes and others > >> as child nodes in YANG data models. Use RelaxNG instead > >> of YANG to do that. > >> > >> > >> > >> > >>> /martin > >>> > >>> > >> Andy > >> > >> > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > >>> > >> > >> > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --001a11c3e166846b5c04f52fba58 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Mar 22, 2014 at 1:08 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:
Andy Bierman <andy@yumaworks.com> writes:

> On Thu, Mar 20, 2014 at 8:25 AM, Andy Bierman <andy@yumaworks.com> wrote:
>
>>
>>
>>
>> On Thu, Mar 20, 2014 at 7:04 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>>
>>> Dean Bogdanovic <deanb= @juniper.net> wrote:
>>> > Hi,
>>> >
>>> > In draft yang leaf node is defined as name value pair in = json
>>> >
>>> > If it would be represented, as an object then we can assi= gn attributes
>>> to it.
>>> >
>>> > Example
>>> > "host-name" {
>>> > =A0 =A0"data" : "router",
>>> > =A0 =A0 =A0 "attributes" : { "protect"= ; : protect}
>>> > }
>>> >
>>> > We need attributes for several things, so lets try to fig= ure out how to
>>> enable
>>> > them.
>>>
>>> I agree that the lack of attributes is a problem with the JSON=
>>> mapping.
>>>
>>> The problem with your solution is that it adds noise to the no= rmal
>>> case where there are no attributes. =A0We're using another= encoding:
>>>
>>> =A0 =A0"host-name": "router",
>>> =A0 =A0"@host-name": {
>>> =A0 =A0 =A0 =A0"protect": "protect",
>>> =A0 =A0 =A0 =A0...
>>> =A0 =A0 }
>>>
>>> Yep, not very elegant...
>>>
>>>
>
> More importantly, it doesn't work for lists or leaf-lists.
> The attributes cannot be siblings (or ancestors) of the target data no= de.

An option for boolean-type properties is to wrap the affected object or val= ue, e.g.

"@protect": {
=A0 =A0 "host-name": ...
}

or

"foo" : [ 1, 2, {"@protect": 3}, 4]

Instead of defining a general JSON equivalent of XML attributes, it might a= ctually be easier to come up with an ad hoc representation for every use ca= se. This is the approach of some native JSON applications such as MongoDB.<= br>
So, the specification of each global property (e.g. "protected") = would also define an appropriate encoding in both XML and JSON.

>
> Consider the following YANG data-stmt, and how an attribute
> would be encoded in every data node (as a worse-case example).
>
>
> container top {
> =A0 list A {
> =A0 =A0 key id;
> =A0 =A0 leaf id { type string; }
> =A0 =A0 leaf-list aa { type int8; }
> =A0 }
> =A0 leaf host-name { type string; }
> }
>
> Plain JSON
>
> { "top" : {
> =A0 "A" : [
> =A0 =A0 { "id":"entry-1",
> =A0 =A0 =A0 "aa": [42, 19]
> =A0 =A0 },
> =A0 =A0 { "id":"entry-2",
> =A0 =A0 =A0 "aa" : [99, 11]
> =A0 =A0 } ]
> =A0 },
> =A0 "host-name":"router"
> }
>
> Add attribute to each node:
> =A0 =A0leaf owner { type string; }
>
> With Owner Attribute using RESTCONF encoding:
>
> { "top" : {
> =A0 "@owner":"system",
> =A0 "A" : [
> =A0 =A0 { "@owner":"admin1",
> =A0 =A0 =A0 "id" : {
> =A0 =A0 =A0 =A0 "@owner":"admin1",
> =A0 =A0 =A0 =A0 "id": "entry-1"
> =A0 =A0 =A0 },
> =A0 =A0 =A0 "aa" : [ { "@owner":"admin1"= , =A0"aa": 42 },
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0{ "@owner":"admin1&q= uot;, =A0"aa": 19 } ]
> =A0 =A0 },
> =A0 =A0 { "@owner":"admin2",
> =A0 =A0 =A0 "id" : {
> =A0 =A0 =A0 =A0 "@owner":"admin2",
> =A0 =A0 =A0 =A0 "id": "entry-2"
> =A0 =A0 =A0 },
> =A0 =A0 =A0 "aa" : [ { "@owner":"admin2"= , =A0"aa": 99 },
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0{ "@owner":"admin2&q= uot;, =A0"aa": 11 } ]
> =A0 =A0 } ]
> =A0 },
> =A0 "host-name" : { "@owner":"system", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"host-name&quo= t;:"router" }
> }
>
>
> This is not elegant either, but it works for all YANG node types.
> How would your encoding look for this example?

"@owned-object": {
=A0 =A0 "@owner": "system",
=A0 =A0 "host-name": "router"
}


Can you show how 2 list entries and 2 = leaf-list entries
have different attribute values. =A0Of course w= e need to
support string values, not just boolean.

=A0
Lada

Andy

=A0<= /div>

>
>
>
> Andy
>
>
>
>
>>
>> This is how RESTCONF encodes these attributes in a leaf:
>> (see sec. 3.4.1)
>>
>> =A0 =A0"host-name" : {
>> =A0 =A0 =A0 =A0"@protect" : "protect",
>> =A0 =A0 =A0 =A0"host-name" : "router"
>> =A0 =A0}
>>
>> Lada says that this is a YANG to JSON mapping and YANG has no attr= ibutes,
>> so the attribute encoding is in RESTCONF. =A0I think it would be b= etter
>> if there was 1 mapping, instead of a different mapping in each pro= tocol
>> that uses this JSON encoding of YANG data.
>>
>> I do not think YANG needs to model attributes!
>> The protocol may need to use them to tag data with meta-data.
>> We do not need to model some leafs as attributes and others
>> as child nodes in YANG data models. =A0Use RelaxNG instead
>> of YANG to do that.
>>
>>
>>
>>
>>> /martin
>>>
>>>
>> Andy
>>
>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

--001a11c3e166846b5c04f52fba58-- From nobody Sat Mar 22 09:41:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4941A099A for ; Sat, 22 Mar 2014 09:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZV9dHmPTE0co for ; Sat, 22 Mar 2014 09:41:16 -0700 (PDT) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) by ietfa.amsl.com (Postfix) with ESMTP id 026ED1A0768 for ; Sat, 22 Mar 2014 09:41:15 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id w7so4172381qcr.22 for ; Sat, 22 Mar 2014 09:41:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gfDrYGyBYAZW/vd9OUT6GhmhbgksPqsXfsyLpo6Ey1g=; b=irIbjcH9O54bqm2nGgXbmoV1QUREAaL4Cx1ukfIjyCdg9D8JjHp3PISR48x0QwFCWP UgrvFPAyB2Yq38WRNJR7H/zxGUrGO7Qr4SR4aJgrYBEacrTBIzpG65xPEqwXKrAF0W8T 2egGjzob+xBeUhan0VLQ9rgprWgtRbCIuFJFOuWqPLvHdfDZ5ZJFK54fgV4uHDr5B2Ud 7mHs9BNZ1MULotV2iEqi0Z7NP8IjzDlOGuMdyGgEmkaGnqoDMmY6fGZb60G7NWkKX67E JaUcHA2epFtxOhN2TfakkyuOKYZvOsN6dNZmfOhmFf2n3vwIVjsg+sLQOUWimtemg2ZH Y49w== X-Gm-Message-State: ALoCoQlgTBtEbq7pc9D7FEZTfeyPSV9W+DTN0KcFQ4NSIFq4xkO3y5lNjDcorropkTW9LOmMVR1g MIME-Version: 1.0 X-Received: by 10.140.36.77 with SMTP id o71mr60970051qgo.25.1395506475632; Sat, 22 Mar 2014 09:41:15 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Sat, 22 Mar 2014 09:41:15 -0700 (PDT) In-Reply-To: References: <3FADE5E8-88AC-4FD0-A2F6-72F408FAFFC4@juniper.net> <20140320.150426.496532825.mbj@tail-f.com> Date: Sat, 22 Mar 2014 09:41:15 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c15fa6c3293604f534ab45 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/psr99MQ5qebaW8YtgrhE9GTdmAc Cc: "netmod@ietf.org" Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 16:41:20 -0000 --001a11c15fa6c3293604f534ab45 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Mar 22, 2014 at 1:08 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Thu, Mar 20, 2014 at 8:25 AM, Andy Bierman > wrote: > > > >> > >> > >> > >> On Thu, Mar 20, 2014 at 7:04 AM, Martin Bjorklund > wrote: > >> > >>> Dean Bogdanovic wrote: > >>> > Hi, > >>> > > >>> > In draft yang leaf node is defined as name value pair in json > >>> > > >>> > If it would be represented, as an object then we can assign > attributes > >>> to it. > >>> > > >>> > Example > >>> > "host-name" { > >>> > "data" : "router", > >>> > "attributes" : { "protect" : protect} > >>> > } > >>> > > >>> > We need attributes for several things, so lets try to figure out how > to > >>> enable > >>> > them. > >>> > >>> I agree that the lack of attributes is a problem with the JSON > >>> mapping. > >>> > >>> The problem with your solution is that it adds noise to the normal > >>> case where there are no attributes. We're using another encoding: > >>> > >>> "host-name": "router", > >>> "@host-name": { > >>> "protect": "protect", > >>> ... > >>> } > >>> > >>> Yep, not very elegant... > >>> > >>> > > > > More importantly, it doesn't work for lists or leaf-lists. > > The attributes cannot be siblings (or ancestors) of the target data node. > > An option for boolean-type properties is to wrap the affected object or > value, e.g. > > "@protect": { > "host-name": ... > } > > or > > "foo" : [ 1, 2, {"@protect": 3}, 4] > > Instead of defining a general JSON equivalent of XML attributes, it might > actually be easier to come up with an ad hoc representation for every use > case. This is the approach of some native JSON applications such as MongoDB. > > The attribute mapping needs to correspond to the XML attribute mapping. Attributes have string values, so the mapping above will not work. Attributes can be qualified or unqualified. If qualified, then the module-name is used as a prefix: "foo" [ 1, 2, { "@foo-mod:owner":"admin1", "foo":3}, { "@foo-mod:owner":"admin2", "foo":4}, This approach presumes the attribute has a YANG module name that defines the attribute, which is of course not allowed. RFC 6241 defines XML attributes for the operation, using a hack called the 'get-filter-element-attributes' extension. http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#get-filter-element-attributes.56 The NETCONF-EX operation has a "with-metadata" parameter that uses identities to map attributes to YANG. I think a standard mechanism is needed to properly map attributes to JSON and XML. A robust deterministic mapping is required, ad-hoc or not. Perhaps an identity registration scheme is good enough, since it provides a module-name for the attribute name. (i.e., the tool needs to know all the identities derived-from the 'metadata' base identity) module foo-mod { ... import nexconf-ex { prefix nx; } identity owner { base nx:metadata; } } Andy So, the specification of each global property (e.g. "protected") would also > define an appropriate encoding in both XML and JSON. > > > > Consider the following YANG data-stmt, and how an attribute > > would be encoded in every data node (as a worse-case example). > > > > > > container top { > > list A { > > key id; > > leaf id { type string; } > > leaf-list aa { type int8; } > > } > > leaf host-name { type string; } > > } > > > > Plain JSON > > > > { "top" : { > > "A" : [ > > { "id":"entry-1", > > "aa": [42, 19] > > }, > > { "id":"entry-2", > > "aa" : [99, 11] > > } ] > > }, > > "host-name":"router" > > } > > > > Add attribute to each node: > > leaf owner { type string; } > > > > With Owner Attribute using RESTCONF encoding: > > > > { "top" : { > > "@owner":"system", > > "A" : [ > > { "@owner":"admin1", > > "id" : { > > "@owner":"admin1", > > "id": "entry-1" > > }, > > "aa" : [ { "@owner":"admin1", "aa": 42 }, > > { "@owner":"admin1", "aa": 19 } ] > > }, > > { "@owner":"admin2", > > "id" : { > > "@owner":"admin2", > > "id": "entry-2" > > }, > > "aa" : [ { "@owner":"admin2", "aa": 99 }, > > { "@owner":"admin2", "aa": 11 } ] > > } ] > > }, > > "host-name" : { "@owner":"system", > > "host-name":"router" } > > } > > > > > > This is not elegant either, but it works for all YANG node types. > > How would your encoding look for this example? > > "@owned-object": { > "@owner": "system", > "host-name": "router" > } > > Lada > > > > > > > > > Andy > > > > > > > > > >> > >> This is how RESTCONF encodes these attributes in a leaf: > >> (see sec. 3.4.1) > >> > >> "host-name" : { > >> "@protect" : "protect", > >> "host-name" : "router" > >> } > >> > >> Lada says that this is a YANG to JSON mapping and YANG has no > attributes, > >> so the attribute encoding is in RESTCONF. I think it would be better > >> if there was 1 mapping, instead of a different mapping in each protocol > >> that uses this JSON encoding of YANG data. > >> > >> I do not think YANG needs to model attributes! > >> The protocol may need to use them to tag data with meta-data. > >> We do not need to model some leafs as attributes and others > >> as child nodes in YANG data models. Use RelaxNG instead > >> of YANG to do that. > >> > >> > >> > >> > >>> /martin > >>> > >>> > >> Andy > >> > >> > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > >>> > >> > >> > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --001a11c15fa6c3293604f534ab45 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Mar 22, 2014 at 1:08 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:
Andy Bierman <and= y@yumaworks.com> writes:

> On Thu, Mar 20, 2014 at 8:25 AM, Andy Bierman <andy@yumaworks.com> wrote:
>
>>
>>
>>
>> On Thu, Mar 20, 2014 at 7:04 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>>
>>> Dean Bogdanovic <deanb= @juniper.net> wrote:
>>> > Hi,
>>> >
>>> > In draft yang leaf node is defined as name value pair in = json
>>> >
>>> > If it would be represented, as an object then we can assi= gn attributes
>>> to it.
>>> >
>>> > Example
>>> > "host-name" {
>>> > =A0 =A0"data" : "router",
>>> > =A0 =A0 =A0 "attributes" : { "protect"= ; : protect}
>>> > }
>>> >
>>> > We need attributes for several things, so lets try to fig= ure out how to
>>> enable
>>> > them.
>>>
>>> I agree that the lack of attributes is a problem with the JSON=
>>> mapping.
>>>
>>> The problem with your solution is that it adds noise to the no= rmal
>>> case where there are no attributes. =A0We're using another= encoding:
>>>
>>> =A0 =A0"host-name": "router",
>>> =A0 =A0"@host-name": {
>>> =A0 =A0 =A0 =A0"protect": "protect",
>>> =A0 =A0 =A0 =A0...
>>> =A0 =A0 }
>>>
>>> Yep, not very elegant...
>>>
>>>
>
> More importantly, it doesn't work for lists or leaf-lists.
> The attributes cannot be siblings (or ancestors) of the target data no= de.

An option for boolean-type properties is to wrap the affected object or val= ue, e.g.

"@protect": {
=A0 =A0 "host-name": ...
}

or

"foo" : [ 1, 2, {"@protect": 3}, 4]

Instead of defining a general JSON equivalent of XML attributes, it might a= ctually be easier to come up with an ad hoc representation for every use ca= se. This is the approach of some native JSON applications such as MongoDB.<= br>


The attribute mapping n= eeds to correspond to the XML attribute mapping.
Attributes have = string values, so the mapping above will not work.

Attributes can be qualified or unqualified. =A0If qualified, then the = module-name
is used as a prefix:

=A0 &qu= ot;foo" [ 1, 2, { "@foo-mod:owner":"admin1", "= ;foo":3}, { "@foo-mod:owner":"admin2", "foo&q= uot;:4},=A0


This approach presumes the attribute has= a YANG module name that defines the attribute,
which is of c= ourse not allowed.=A0

RFC 6241 defines XML attribu= tes for the <get> operation, using a hack
called the=A0 &#= 39;get-filter-element-attributes' extension.

The NETCONF-EX <get2> operation has a "= ;with-metadata" parameter that uses identities
to map attrib= utes to YANG.=A0

I think a standard mechanism is n= eeded to properly map attributes to JSON and XML.
A robust deterministic mapping is required, ad-hoc or not. Perhaps an = identity registration
scheme is good enough, since it provides a = module-name for the attribute name.
(i.e., the tool needs to know= all the identities derived-from the 'metadata' base identity)

=A0 module foo-mod {
=A0 =A0 ...
= =A0 =A0 import nexconf-ex { prefix nx; }

=A0 =A0 i= dentity owner {
=A0 =A0 =A0 =A0base nx:metadata;
=A0 = =A0 }
=A0 }




Andy
=


So, the specification of each global property (e.g. "protected") = would also define an appropriate encoding in both XML and JSON.=A0
>
> Consider the following YANG data-stmt, and how an attribute
> would be encoded in every data node (as a worse-case example).
>
>
> container top {
> =A0 list A {
> =A0 =A0 key id;
> =A0 =A0 leaf id { type string; }
> =A0 =A0 leaf-list aa { type int8; }
> =A0 }
> =A0 leaf host-name { type string; }
> }
>
> Plain JSON
>
> { "top" : {
> =A0 "A" : [
> =A0 =A0 { "id":"entry-1",
> =A0 =A0 =A0 "aa": [42, 19]
> =A0 =A0 },
> =A0 =A0 { "id":"entry-2",
> =A0 =A0 =A0 "aa" : [99, 11]
> =A0 =A0 } ]
> =A0 },
> =A0 "host-name":"router"
> }
>
> Add attribute to each node:
> =A0 =A0leaf owner { type string; }
>
> With Owner Attribute using RESTCONF encoding:
>
> { "top" : {
> =A0 "@owner":"system",
> =A0 "A" : [
> =A0 =A0 { "@owner":"admin1",
> =A0 =A0 =A0 "id" : {
> =A0 =A0 =A0 =A0 "@owner":"admin1",
> =A0 =A0 =A0 =A0 "id": "entry-1"
> =A0 =A0 =A0 },
> =A0 =A0 =A0 "aa" : [ { "@owner":"admin1"= , =A0"aa": 42 },
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0{ "@owner":"admin1&q= uot;, =A0"aa": 19 } ]
> =A0 =A0 },
> =A0 =A0 { "@owner":"admin2",
> =A0 =A0 =A0 "id" : {
> =A0 =A0 =A0 =A0 "@owner":"admin2",
> =A0 =A0 =A0 =A0 "id": "entry-2"
> =A0 =A0 =A0 },
> =A0 =A0 =A0 "aa" : [ { "@owner":"admin2"= , =A0"aa": 99 },
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0{ "@owner":"admin2&q= uot;, =A0"aa": 11 } ]
> =A0 =A0 } ]
> =A0 },
> =A0 "host-name" : { "@owner":"system", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"host-name&quo= t;:"router" }
> }
>
>
> This is not elegant either, but it works for all YANG node types.
> How would your encoding look for this example?

"@owned-object": {
=A0 =A0 "@owner": "system",
=A0 =A0 "host-name": "router"
}

Lada

>
>
>
> Andy
>
>
>
>
>>
>> This is how RESTCONF encodes these attributes in a leaf:
>> (see sec. 3.4.1)
>>
>> =A0 =A0"host-name" : {
>> =A0 =A0 =A0 =A0"@protect" : "protect",
>> =A0 =A0 =A0 =A0"host-name" : "router"
>> =A0 =A0}
>>
>> Lada says that this is a YANG to JSON mapping and YANG has no attr= ibutes,
>> so the attribute encoding is in RESTCONF. =A0I think it would be b= etter
>> if there was 1 mapping, instead of a different mapping in each pro= tocol
>> that uses this JSON encoding of YANG data.
>>
>> I do not think YANG needs to model attributes!
>> The protocol may need to use them to tag data with meta-data.
>> We do not need to model some leafs as attributes and others
>> as child nodes in YANG data models. =A0Use RelaxNG instead
>> of YANG to do that.
>>
>>
>>
>>
>>> /martin
>>>
>>>
>> Andy
>>
>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

--001a11c15fa6c3293604f534ab45-- From nobody Sun Mar 23 02:43:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4971A6F58 for ; Sun, 23 Mar 2014 02:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzR2lBXLKotb for ; Sun, 23 Mar 2014 02:42:52 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id D0D681A0654 for ; Sun, 23 Mar 2014 02:42:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 5713454050C; Sun, 23 Mar 2014 10:42:50 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lZhtYFF1FNQ; Sun, 23 Mar 2014 10:42:45 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 4FF5D5402CD; Sun, 23 Mar 2014 10:42:43 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <3FADE5E8-88AC-4FD0-A2F6-72F408FAFFC4@juniper.net> <20140320.150426.496532825.mbj@tail-f.com> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Sun, 23 Mar 2014 10:42:44 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LDCXFgFnf3j-bs8E3AHjJVb7PuY Cc: "netmod@ietf.org" Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 09:43:00 -0000 Andy Bierman writes: ... > > The attribute mapping needs to correspond to the XML attribute mapping. > Attributes have string values, so the mapping above will not work. I don't understand. XML schemas can define attribute values to be of other types, too, not only string. > > Attributes can be qualified or unqualified. If qualified, then the > module-name > is used as a prefix: > > "foo" [ 1, 2, { "@foo-mod:owner":"admin1", "foo":3}, { > "@foo-mod:owner":"admin2", "foo":4}, > > > This approach presumes the attribute has a YANG module name that defines > the attribute, > which is of course not allowed. > > RFC 6241 defines XML attributes for the operation, using a hack > called the 'get-filter-element-attributes' extension. > http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#get-filter-element-attributes.56 This is another extension that violates the rule stated in RFC 6020, sec. 6.3.1: If a YANG compiler does not support a particular extension, which appears in a YANG module as an unknown-statement (see Section 12), the entire unknown-statement MAY be ignored by the compiler. > > The NETCONF-EX operation has a "with-metadata" parameter that uses > identities > to map attributes to YANG. > > I think a standard mechanism is needed to properly map attributes to JSON > and XML. I'd suggest to define two generic constructs: 1. Metadata Every JSON value (false / null / true / object / array / number / string) can be changed into a "@tagged-value" object, e.g. the number 42 can become { "@tagged-value" : { "@owner": "admin1", "@value": 42 } } Multiple metadata key-value pairs may be present inside the "@tagged-value" object. 2. Properties For a property "foo", every JSON value can be changed into a "@foo" object, e.g. { "@foo": 42 } Such property objects may nest, e.g. { "@bar": { "@foo": 42 } } Both constructs work for list and leaf-list entries, and may be also combined. > A robust deterministic mapping is required, ad-hoc or not. Perhaps an > identity registration > scheme is good enough, since it provides a module-name for the attribute > name. > (i.e., the tool needs to know all the identities derived-from the > 'metadata' base identity) > > module foo-mod { > ... > import nexconf-ex { prefix nx; } > > identity owner { > base nx:metadata; > } > } I would prefer either to define global attributes outside YANG, or to introduce a new top-level statement for them in YANG 1.1, e.g. "global-attribute". Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Mar 23 03:07:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C961A6F58 for ; Sun, 23 Mar 2014 03:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8j4JdVjT-pM for ; Sun, 23 Mar 2014 03:07:44 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id B85461A6F60 for ; Sun, 23 Mar 2014 03:07:43 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 5574937C30C; Sun, 23 Mar 2014 11:07:42 +0100 (CET) Date: Sun, 23 Mar 2014 11:07:41 +0100 (CET) Message-Id: <20140323.110741.449355686.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cSQwpuGThTtblCJiVeWpEd24YTo Cc: netmod@ietf.org Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 10:07:46 -0000 Ladislav Lhotka wrote: > Andy Bierman writes: > > ... > > > > > The attribute mapping needs to correspond to the XML attribute mapping. > > Attributes have string values, so the mapping above will not work. > > I don't understand. XML schemas can define attribute values to be of other > types, too, not only string. > > > > > Attributes can be qualified or unqualified. If qualified, then the > > module-name > > is used as a prefix: > > > > "foo" [ 1, 2, { "@foo-mod:owner":"admin1", "foo":3}, { > > "@foo-mod:owner":"admin2", "foo":4}, > > > > > > This approach presumes the attribute has a YANG module name that defines > > the attribute, > > which is of course not allowed. > > > > RFC 6241 defines XML attributes for the operation, using a hack > > called the 'get-filter-element-attributes' extension. > > http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#get-filter-element-attributes.56 > > This is another extension that violates the rule stated in RFC 6020, > sec. 6.3.1: > > If a YANG compiler does not support a particular extension, which > appears in a YANG module as an unknown-statement (see Section 12), > the entire unknown-statement MAY be ignored by the compiler. > > > > > The NETCONF-EX operation has a "with-metadata" parameter that uses > > identities > > to map attributes to YANG. > > > > I think a standard mechanism is needed to properly map attributes to JSON > > and XML. > > I'd suggest to define two generic constructs: > > 1. Metadata > > Every JSON value (false / null / true / object / array / number / string) can > be changed into a "@tagged-value" object, e.g. the number 42 can become > > { > "@tagged-value" : { > "@owner": "admin1", > "@value": 42 > } > } > > Multiple metadata key-value pairs may be present inside the "@tagged-value" > object. > > 2. Properties > > For a property "foo", every JSON value can be changed into a "@foo" object, > e.g. > > { > "@foo": 42 > } > > Such property objects may nest, e.g. > > { > "@bar": > { > "@foo": 42 > } > } > > Both constructs work for list and leaf-list entries, and may be also combined. This makes both client and server programming much more complex. The whole point of using JSON is supposedly that it maps well to built-in datastructures in modern languages. This property makes parsing trivial, and makes it easy to get values. For example: res = json_parse(...) if res['ssh']['enabled']: ... now, with the proposed encoding, I have to be prepared for 'ssh' being a '@tagged-value', and '@enabled' being a tagged-value, and combinations thereof: if res['ssh']['enabled'] or res['@tagged-value']['ssh']['enabled'] or res['@tagged-value']['ssh']['@tagged-value']['enabled'] or ... As I write this I realize that I don't really understand your proposal..., so the code above is not correct - but the point is the same; as soon as you allow multiple encodings you make coding much more complex. Maybe the original JSON mapping idea is the only one that works; i.e., map pure YANG data to JSON. No meta data. A protocol that needs meta data should not use JSON; use XML instead. /martin From nobody Sun Mar 23 03:26:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5381A6EEC for ; Sun, 23 Mar 2014 03:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOYwvc8tup22 for ; Sun, 23 Mar 2014 03:26:30 -0700 (PDT) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id A2F4C1A05D1 for ; Sun, 23 Mar 2014 03:26:30 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id j5so4235938qaq.28 for ; Sun, 23 Mar 2014 03:26:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=op2/QQMEU/iR17xqXcm5jnmPF82JL7p3306ggwu1SFU=; b=ANS+o8jJii93N/+r2+52jmRMMXROWiAXOG7NSBcGbR0O7Ow37i++Rij/srP2dk247k YR3UAW2rXuH1EVEXSm3zyeJFj48s9MKAZQCGVl2kCPZBed9VlPX6n2Gx6kmzftZdQ9lf bCWPo1Jf5zQzFQU7ku90o7FIM/6Hkb0/fQvJfd7ImLTKXiKolxAUTFRfcz7VHBfqa7lB LefISHXJWGQJNoladaNpM5wUl3c8JSg7aCnb02NgfoWhn2RYO9QJNwYm2fMTJX3wKuGu pqkmvjAIK1KJdR/ke35E7MIpfr0d9XT0hEAXBnFj7/59PkYn0ZZtiBJzlbE0h6gEIQV6 Kmiw== X-Gm-Message-State: ALoCoQnqAc05GTugrNaAsO3pTwoqHCVpQbPo+owZXCNxWwDPn812YDn3LmTqx8B/vW/n3mZmqxOn MIME-Version: 1.0 X-Received: by 10.229.139.199 with SMTP id f7mr68625342qcu.2.1395570390122; Sun, 23 Mar 2014 03:26:30 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Sun, 23 Mar 2014 03:26:29 -0700 (PDT) In-Reply-To: References: <3FADE5E8-88AC-4FD0-A2F6-72F408FAFFC4@juniper.net> <20140320.150426.496532825.mbj@tail-f.com> Date: Sun, 23 Mar 2014 03:26:29 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c3e4545cd7f404f5438dfa Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/VgyVkb3OSkra77Hz1E9fm_unIWo Cc: "netmod@ietf.org" Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 10:26:33 -0000 --001a11c3e4545cd7f404f5438dfa Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 23, 2014 at 2:42 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > ... > > > > > The attribute mapping needs to correspond to the XML attribute mapping. > > Attributes have string values, so the mapping above will not work. > > I don't understand. XML schemas can define attribute values to be of other > types, too, not only string. > > I meant they are encoded in XML as quoted strings > > > > Attributes can be qualified or unqualified. If qualified, then the > > module-name > > is used as a prefix: > > > > "foo" [ 1, 2, { "@foo-mod:owner":"admin1", "foo":3}, { > > "@foo-mod:owner":"admin2", "foo":4}, > > > > > > This approach presumes the attribute has a YANG module name that defines > > the attribute, > > which is of course not allowed. > > > > RFC 6241 defines XML attributes for the operation, using a hack > > called the 'get-filter-element-attributes' extension. > > > http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#get-filter-element-attributes.56 > > This is another extension that violates the rule stated in RFC 6020, sec. > 6.3.1: > > If a YANG compiler does not support a particular extension, which > appears in a YANG module as an unknown-statement (see Section 12), > the entire unknown-statement MAY be ignored by the compiler. > > > > > The NETCONF-EX operation has a "with-metadata" parameter that uses > > identities > > to map attributes to YANG. > > > > I think a standard mechanism is needed to properly map attributes to JSON > > and XML. > > I'd suggest to define two generic constructs: > > 1. Metadata > > Every JSON value (false / null / true / object / array / number / string) > can be changed into a "@tagged-value" object, e.g. the number 42 can become > > { > "@tagged-value" : { > "@owner": "admin1", > "@value": 42 > } > } > > Multiple metadata key-value pairs may be present inside the > "@tagged-value" object. > > I don't think this works for lists and leaf-lists. Can you expand the encoding to show a real example with container, list, leaf, and leaf-list used? Not only doesn't it work for siblings, but it depends on the order (@owner followed by @value), and JSON objects are not ordered. > 2. Properties > > For a property "foo", every JSON value can be changed into a "@foo" > object, e.g. > > { > "@foo": 42 > } > > Such property objects may nest, e.g. > > { > "@bar": > { > "@foo": 42 > } > } why are properties needed? why do we need attributes within attributes? Both constructs work for list and leaf-list entries, and may be also > combined. > > > A robust deterministic mapping is required, ad-hoc or not. Perhaps an > > identity registration > > scheme is good enough, since it provides a module-name for the attribute > > name. > > (i.e., the tool needs to know all the identities derived-from the > > 'metadata' base identity) > > > > module foo-mod { > > ... > > import nexconf-ex { prefix nx; } > > > > identity owner { > > base nx:metadata; > > } > > } > > I would prefer either to define global attributes outside YANG, or to > introduce a new top-level statement for them in YANG 1.1, e.g. > "global-attribute". > > Lada > > Andy --001a11c3e4545cd7f404f5438dfa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Mar 23, 2014 at 2:42 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:
Andy Bierman <andy@yumaworks.com> writes:

...

>
> The attribute mapping needs to correspond to the XML attribute mapping= .
> Attributes have string values, so the mapping above will not work.

I don't understand. XML schemas can define attribute values to be of ot= her types, too, not only string.


I meant they are encoded in XML as quo= ted strings
=A0
>
> Attributes can be qualified or unqualified. =A0If qualified, then the<= br> > module-name
> is used as a prefix:
>
> =A0 "foo" [ 1, 2, { "@foo-mod:owner":"admin1&= quot;, "foo":3}, {
> "@foo-mod:owner":"admin2", "foo":4},
>
>
> This approach presumes the attribute has a YANG module name that defin= es
> the attribute,
> which is of course not allowed.
>
> RFC 6241 defines XML attributes for the <get> operation, using a= hack
> called the =A0'get-filter-element-attributes' extension.
> http://www.netconfce= ntral.org/modules/ietf-netconf/2011-06-01#get-filter-element-attributes.56<= /a>

This is another extension that violates the rule stated in RFC 6020, sec. 6= .3.1:

=A0 =A0If a YANG compiler does not support a particular extension, which =A0 =A0appears in a YANG module as an unknown-statement (see Section 12), =A0 =A0the entire unknown-statement MAY be ignored by the compiler.

>
> The NETCONF-EX <get2> operation has a "with-metadata" = parameter that uses
> identities
> to map attributes to YANG.
>
> I think a standard mechanism is needed to properly map attributes to J= SON
> and XML.

I'd suggest to define two generic constructs:

1. Metadata

Every JSON value (false / null / true / object / array / number / string) c= an be changed into a "@tagged-value" object, e.g. the number 42 c= an become

{
=A0 "@tagged-value" : {
=A0 =A0 "@owner": "admin1",
=A0 =A0 "@value": 42
=A0 }
}

Multiple metadata key-value pairs may be present inside the "@tagged-v= alue" object.



2. Properties

For a property "foo", every JSON value can be changed into a &quo= t;@foo" object, e.g.

{
=A0 "@foo": 42
}

Such property objects may nest, e.g.

{
=A0 "@bar":
=A0 {
=A0 =A0 "@foo": 42
=A0 }
}=A0


--001a11c3e4545cd7f404f5438dfa-- From nobody Sun Mar 23 03:53:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753CD1A0950 for ; Sun, 23 Mar 2014 03:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4bXatOLpyt3 for ; Sun, 23 Mar 2014 03:53:06 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 219C31A0639 for ; Sun, 23 Mar 2014 03:53:05 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id r5so4768179qcx.32 for ; Sun, 23 Mar 2014 03:53:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KnsceS2tV/tMWxx/bcNDaZItMzJuAQEkGX/IHEIZoco=; b=akLzZwyVhwlcb5oHP5JTAHs2SZGSFH+myNqE0OGsJZ2Nz4UCXXtylY0drOEDEws21H SJ1bjJ8HiDVNlaxyROKhuh7vZ7U1INkKGqyiWi+EM1wRZurx/JzvEHfWMBsiqNJYIQxO eAfMhZS9/u5MfMpNZZbtbr6bE5c/EsPnwZkqbPJejUpoRNQqBmJpToUBwWosQdO1LfWm +L4XdMk9qRET53YdBl6uKnuRbJwfvoZQvHlNAco5DqC3Ez9eLxnujODkrbyXSucTLSta 3QrRKkdjUd2ftQW56dPfkQ4vw1OYRP0qzA0WHVZqc+wg6gkvOeneiItj0iPMScQSo+6D u0Bg== X-Gm-Message-State: ALoCoQnKLjr81Fweu9bRSRw9AgDLaOCbs0PkPvqjl9R8Miw1gTQD68M6UFwxYMGMh3r7HAc7DN0s MIME-Version: 1.0 X-Received: by 10.224.72.12 with SMTP id k12mr873731qaj.81.1395571985309; Sun, 23 Mar 2014 03:53:05 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Sun, 23 Mar 2014 03:53:05 -0700 (PDT) In-Reply-To: <20140323.110741.449355686.mbj@tail-f.com> References: <20140323.110741.449355686.mbj@tail-f.com> Date: Sun, 23 Mar 2014 03:53:05 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7bea2f027172cd04f543ec42 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/GF-ASx-GxQgA6LL-gzEv4JjCxiY Cc: "netmod@ietf.org" Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 10:53:08 -0000 --047d7bea2f027172cd04f543ec42 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 23, 2014 at 3:07 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > Andy Bierman writes: > > > > ... > > > > > > > > The attribute mapping needs to correspond to the XML attribute mapping. > > > Attributes have string values, so the mapping above will not work. > > > > I don't understand. XML schemas can define attribute values to be of > other > > types, too, not only string. > > > > > > > > Attributes can be qualified or unqualified. If qualified, then the > > > module-name > > > is used as a prefix: > > > > > > "foo" [ 1, 2, { "@foo-mod:owner":"admin1", "foo":3}, { > > > "@foo-mod:owner":"admin2", "foo":4}, > > > > > > > > > This approach presumes the attribute has a YANG module name that > defines > > > the attribute, > > > which is of course not allowed. > > > > > > RFC 6241 defines XML attributes for the operation, using a hack > > > called the 'get-filter-element-attributes' extension. > > > > http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#get-filter-element-attributes.56 > > > > This is another extension that violates the rule stated in RFC 6020, > > sec. 6.3.1: > > > > If a YANG compiler does not support a particular extension, which > > appears in a YANG module as an unknown-statement (see Section 12), > > the entire unknown-statement MAY be ignored by the compiler. > > > > > > > > The NETCONF-EX operation has a "with-metadata" parameter that > uses > > > identities > > > to map attributes to YANG. > > > > > > I think a standard mechanism is needed to properly map attributes to > JSON > > > and XML. > > > > I'd suggest to define two generic constructs: > > > > 1. Metadata > > > > Every JSON value (false / null / true / object / array / number / > string) can > > be changed into a "@tagged-value" object, e.g. the number 42 can become > > > > { > > "@tagged-value" : { > > "@owner": "admin1", > > "@value": 42 > > } > > } > > > > Multiple metadata key-value pairs may be present inside the > "@tagged-value" > > object. > > > > 2. Properties > > > > For a property "foo", every JSON value can be changed into a "@foo" > object, > > e.g. > > > > { > > "@foo": 42 > > } > > > > Such property objects may nest, e.g. > > > > { > > "@bar": > > { > > "@foo": 42 > > } > > } > > > > Both constructs work for list and leaf-list entries, and may be also > combined. > > This makes both client and server programming much more complex. The > whole point of using JSON is supposedly that it maps well to built-in > datastructures in modern languages. This property makes parsing > trivial, and makes it easy to get values. For example: > > res = json_parse(...) > if res['ssh']['enabled']: > ... > > now, with the proposed encoding, I have to be prepared for 'ssh' being > a '@tagged-value', and '@enabled' being a tagged-value, and > combinations thereof: > > if res['ssh']['enabled'] > or res['@tagged-value']['ssh']['enabled'] > or res['@tagged-value']['ssh']['@tagged-value']['enabled'] > or ... > > As I write this I realize that I don't really understand your > proposal..., so the code above is not correct - but the point is the > same; as soon as you allow multiple encodings you make coding much > more complex. > > I agree this is getting too complicated. > Maybe the original JSON mapping idea is the only one that works; i.e., > map pure YANG data to JSON. No meta data. A protocol that needs meta > data should not use JSON; use XML instead. > > Clearly the protocol cannot rely on attributes if they are not supported in some encoding schemes. Only schemes that can map 100% of the protocol messages can be considered. I am OK with leaving attributes out of RESTCONF (so they can be left out of the YANG to JSON mapping). > /martin > Andy --047d7bea2f027172cd04f543ec42 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Mar 23, 2014 at 3:07 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:
> Andy Bierman <andy@yumaworks.= com> writes:
>
> ...
>
> >
> > The attribute mapping needs to correspond to the XML attribute ma= pping.
> > Attributes have string values, so the mapping above will not work= .
>
> I don't understand. XML schemas can define attribute values to be = of other
> types, too, not only string.
>
> >
> > Attributes can be qualified or unqualified. =A0If qualified, then= the
> > module-name
> > is used as a prefix:
> >
> > =A0 "foo" [ 1, 2, { "@foo-mod:owner":"ad= min1", "foo":3}, {
> > "@foo-mod:owner":"admin2", "foo":4}= ,
> >
> >
> > This approach presumes the attribute has a YANG module name that = defines
> > the attribute,
> > which is of course not allowed.
> >
> > RFC 6241 defines XML attributes for the <get> operation, us= ing a hack
> > called the =A0'get-filter-element-attributes' extension.<= br> > > http://www.netc= onfcentral.org/modules/ietf-netconf/2011-06-01#get-filter-element-attribute= s.56
>
> This is another extension that violates the rule stated in RFC 6020, > sec. 6.3.1:
>
> =A0 =A0If a YANG compiler does not support a particular extension, whi= ch
> =A0 =A0appears in a YANG module as an unknown-statement (see Section 1= 2),
> =A0 =A0the entire unknown-statement MAY be ignored by the compiler. >
> >
> > The NETCONF-EX <get2> operation has a "with-metadata&q= uot; parameter that uses
> > identities
> > to map attributes to YANG.
> >
> > I think a standard mechanism is needed to properly map attributes= to JSON
> > and XML.
>
> I'd suggest to define two generic constructs:
>
> 1. Metadata
>
> Every JSON value (false / null / true / object / array / number / stri= ng) can
> be changed into a "@tagged-value" object, e.g. the number 42= can become
>
> {
> =A0 "@tagged-value" : {
> =A0 =A0 "@owner": "admin1",
> =A0 =A0 "@value": 42
> =A0 }
> }
>
> Multiple metadata key-value pairs may be present inside the "@tag= ged-value"
> object.
>
> 2. Properties
>
> For a property "foo", every JSON value can be changed into a= "@foo" object,
> e.g.
>
> {
> =A0 "@foo": 42
> }
>
> Such property objects may nest, e.g.
>
> {
> =A0 "@bar":
> =A0 {
> =A0 =A0 "@foo": 42
> =A0 }
> }
>
> Both constructs work for list and leaf-list entries, and may be also c= ombined.

This makes both client and server programming much more complex. =A0The
whole point of using JSON is supposedly that it maps well to built-in
datastructures in modern languages. =A0This property makes parsing
trivial, and makes it easy to get values. =A0For example:

=A0 res =3D json_parse(...)
=A0 if res['ssh']['enabled']:
=A0 =A0 =A0...

now, with the proposed encoding, I have to be prepared for 'ssh' be= ing
a '@tagged-value', and '@enabled' being a tagged-value, and=
combinations thereof:

=A0 if res['ssh']['enabled']
=A0 =A0 =A0or res['@tagged-value']['ssh']['enabled'= ]
=A0 =A0 =A0or res['@tagged-value']['ssh']['@tagged-valu= e']['enabled']
=A0 =A0 =A0or ...

As I write this I realize that I don't really understand your
proposal..., so the code above is not correct - but the point is the
same; as soon as you allow multiple encodings you make coding much
more complex.


I agree this is getting too complicate= d.
=A0
Maybe the original JSON mapping idea is the only one that works; i.e.,
map pure YANG data to JSON. =A0No meta data. =A0A protocol that needs meta<= br> data should not use JSON; use XML instead.


Clearly the protocol cannot rely on attributes if th= ey are
not supported in some encoding schemes. Only schemes t= hat can
map 100% of the protocol messages can be considered.

I am OK with leaving attributes out of RESTCONF (so they can be lef= t
out of the YANG to JSON mapping).




/martin

Andy<= /div>

--047d7bea2f027172cd04f543ec42-- From nobody Sun Mar 23 07:04:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AEF1A0A73 for ; Sun, 23 Mar 2014 07:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wB6IIPNGYpPR for ; Sun, 23 Mar 2014 07:04:06 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE441A0988 for ; Sun, 23 Mar 2014 07:04:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B2F341088 for ; Sun, 23 Mar 2014 15:04:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ttPIAPfYmDN0 for ; Sun, 23 Mar 2014 15:04:05 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Sun, 23 Mar 2014 15:04:05 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1988C2002F for ; Sun, 23 Mar 2014 15:04:05 +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 J9LXdp34QhOC; Sun, 23 Mar 2014 15:04:04 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4594A2002C; Sun, 23 Mar 2014 15:04:04 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A3C752C09C7B; Sun, 23 Mar 2014 15:04:02 +0100 (CET) Date: Sun, 23 Mar 2014 15:04:02 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140323140402.GA42665@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/diMaPuHZb2FbU-dmpP5Tkm6DKFk Subject: [netmod] yang 1.1 issue list online X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 23 Mar 2014 14:04:09 -0000 Hi, during the WG meeting in London, we went through a collection of YANG issues to consider for YANG 1.1. Martin has meanwhile updated the list and it can now be found in the WG subversion repository: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.txt http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html For every issue, we have a short identifier, a short title, a description of the issue, a set of possible solutions and eventually a resolution (a short statement which solution was picked and why). Every issue has a state: NEW: an issue submitted OPEN: an issue accepted to be in scope of YANG 1.1 DONE: an issue closed (edits are in the I-D) DEAD: an issue that for some reason will not be further considered Users of emacs will recognize that the issues.txt file is in org-mode format. This format makes it very easy for Martin to maintain this list - thanks to Martin for taking care of the maintenance of the issue list. The issues.html version is generated from the org-mode file for people who might find it easier to read. For discussion of the issues, please use mailing list threads that include the issue identifier. For new issues that you want to open, start a new thread on the mailing list to define the issue. Martin will double check that submitted new issues will not repeat or overlap with existing issues (if so, he will respond on the mailing list thread). /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 Sun Mar 23 08:08:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920F11A072D for ; Sun, 23 Mar 2014 08:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGppmJr2SXZB for ; Sun, 23 Mar 2014 08:08:00 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 29ECD1A6FC7 for ; Sun, 23 Mar 2014 08:07:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id A8AC454050C; Sun, 23 Mar 2014 16:07:57 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLsrAqOlp62k; Sun, 23 Mar 2014 16:07:52 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id B4CFB540192; Sun, 23 Mar 2014 16:07:51 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <3FADE5E8-88AC-4FD0-A2F6-72F408FAFFC4@juniper.net> <20140320.150426.496532825.mbj@tail-f.com> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Sun, 23 Mar 2014 16:07:49 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZSyEOatJmj_aur_hS1YyDe__WaI Cc: "netmod@ietf.org" Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 15:08:08 -0000 Andy Bierman writes: > On Sun, Mar 23, 2014 at 2:42 AM, Ladislav Lhotka wrote: > >> Andy Bierman writes: >> >> ... >> >> > >> > The attribute mapping needs to correspond to the XML attribute mapping. >> > Attributes have string values, so the mapping above will not work. >> >> I don't understand. XML schemas can define attribute values to be of other >> types, too, not only string. >> >> > I meant they are encoded in XML as quoted strings > > >> > >> > Attributes can be qualified or unqualified. If qualified, then the >> > module-name >> > is used as a prefix: >> > >> > "foo" [ 1, 2, { "@foo-mod:owner":"admin1", "foo":3}, { >> > "@foo-mod:owner":"admin2", "foo":4}, >> > >> > >> > This approach presumes the attribute has a YANG module name that defines >> > the attribute, >> > which is of course not allowed. >> > >> > RFC 6241 defines XML attributes for the operation, using a hack >> > called the 'get-filter-element-attributes' extension. >> > >> http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#get-filter-element-attributes.56 >> >> This is another extension that violates the rule stated in RFC 6020, sec. >> 6.3.1: >> >> If a YANG compiler does not support a particular extension, which >> appears in a YANG module as an unknown-statement (see Section 12), >> the entire unknown-statement MAY be ignored by the compiler. >> >> > >> > The NETCONF-EX operation has a "with-metadata" parameter that uses >> > identities >> > to map attributes to YANG. >> > >> > I think a standard mechanism is needed to properly map attributes to JSON >> > and XML. >> >> I'd suggest to define two generic constructs: >> >> 1. Metadata >> >> Every JSON value (false / null / true / object / array / number / string) >> can be changed into a "@tagged-value" object, e.g. the number 42 can become >> >> { >> "@tagged-value" : { >> "@owner": "admin1", >> "@value": 42 >> } >> } >> >> Multiple metadata key-value pairs may be present inside the >> "@tagged-value" object. >> >> > I don't think this works for lists and leaf-lists. > Can you expand the encoding to show a real example with > container, list, leaf, and leaf-list used? container ========= "foo": { "bar": 42 } becomes "foo": { "@tagged-value": { "@tag1": 54, "@value": { "bar": 42 }, "@tag2": "hi!" } } leaf ==== "bar": 42 becomes "bar": { "@tagged-value": { "@tag3" = false, "@value": 42 } } leaf-list ========= "foos": [ 6, 3, 7, 8] when tagging the whole array becomes "foos": { "@tagged-value": { "@value": [ 6, 3, 7, 8 ] "tag4": true or, when tagging only one entry, becomes "foos": [ 6, { @tagged-value: { "@tag5": 1, "@value": 3 } }, 7, 8 ] list ==== is analogical, only scalar values (numbers in the above example) will be replaced with objects. > > Not only doesn't it work for siblings, but it depends on the order (@owner > followed by @value), > and JSON objects are not ordered. No, it doesn't, as you can see in the examples the "@value" member can appear at any place and the order of tags is also irrelevant. The only restriction is that no tag can have the key "@value". > > > >> 2. Properties >> >> For a property "foo", every JSON value can be changed into a "@foo" >> object, e.g. >> >> { >> "@foo": 42 >> } >> >> Such property objects may nest, e.g. >> >> { >> "@bar": >> { >> "@foo": 42 >> } >> } > > > > why are properties needed? They are not strictly needed, only their encoding is much nicer, and I assume quite often XML attributes are supposed to be used for such binary properties, such as "protect", "deactivate" etc. So the examples above could also be written "@tagged-value": { "@value": 42, "@foo": true } and "@tagged-value": { "@value": 42, "@foo": true, "@bar": true } > why do we need attributes within attributes? To be able to express that a single value has multiple properties. Lada > > > Both constructs work for list and leaf-list entries, and may be also >> combined. >> >> > A robust deterministic mapping is required, ad-hoc or not. Perhaps an >> > identity registration >> > scheme is good enough, since it provides a module-name for the attribute >> > name. >> > (i.e., the tool needs to know all the identities derived-from the >> > 'metadata' base identity) >> > >> > module foo-mod { >> > ... >> > import nexconf-ex { prefix nx; } >> > >> > identity owner { >> > base nx:metadata; >> > } >> > } >> >> I would prefer either to define global attributes outside YANG, or to >> introduce a new top-level statement for them in YANG 1.1, e.g. >> "global-attribute". > > > >> >> > Lada >> >> > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Mar 23 08:24:57 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4DB1A6FC4 for ; Sun, 23 Mar 2014 08:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dw5aSsr9Dkjc for ; Sun, 23 Mar 2014 08:24:50 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 234D41A08CC for ; Sun, 23 Mar 2014 08:24:49 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id f11so4311459qae.17 for ; Sun, 23 Mar 2014 08:24:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qgGZxt6Xe64ZL3PjXf1eTCe6VF4AaLqjGS05gbSbAAc=; b=HtGIqpKw90qp2gB0d+8JnnHymvXKkC1N8Tlni0SXQ42dQUX3OC0tjtQx+DcJDaFdL6 WnHvGR4I4C+v0zqDizYcZNXt5+FmvAqsacGZUynT+5U/t5/Tp2LJL+nyBWS4Ye0ZTz92 yimfwYEX7MVtiLp1rRgC7mVvSlFU9TVwtxDuMMAVJaBf5PlmmKCaqgKfPTHjTq2mxq+w /d2q+124pizCzLn7Xj+ibBNvh0lH3tGF8pv+1MyJVHlajm8wiK7dIoDnn4AkgYserZ9r FX1484w/9uwCutWRYc7EoKqtFMNXA7OesNU7tiIuoPt/1apyf0GR/scQ4YCNLrkDimu+ jMKQ== X-Gm-Message-State: ALoCoQmejSSO6NFGX1v6VgP+Sa1FxTV5qaVe5JBtY3/cpVLkDJ6gHQ89++JgyrhY2zTiGh8j6PpX MIME-Version: 1.0 X-Received: by 10.224.66.8 with SMTP id l8mr69703208qai.16.1395588289362; Sun, 23 Mar 2014 08:24:49 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Sun, 23 Mar 2014 08:24:49 -0700 (PDT) In-Reply-To: References: <3FADE5E8-88AC-4FD0-A2F6-72F408FAFFC4@juniper.net> <20140320.150426.496532825.mbj@tail-f.com> Date: Sun, 23 Mar 2014 08:24:49 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c2c27a3dac2704f547b82b Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/3fr3-36JSN8e7wVU53bpMtqBCmQ Cc: "netmod@ietf.org" Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 15:24:55 -0000 --001a11c2c27a3dac2704f547b82b Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 23, 2014 at 8:07 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Sun, Mar 23, 2014 at 2:42 AM, Ladislav Lhotka wrote: > > > >> Andy Bierman writes: > >> > >> ... > >> > >> > > >> > The attribute mapping needs to correspond to the XML attribute > mapping. > >> > Attributes have string values, so the mapping above will not work. > >> > >> I don't understand. XML schemas can define attribute values to be of > other > >> types, too, not only string. > >> > >> > > I meant they are encoded in XML as quoted strings > > > > > >> > > >> > Attributes can be qualified or unqualified. If qualified, then the > >> > module-name > >> > is used as a prefix: > >> > > >> > "foo" [ 1, 2, { "@foo-mod:owner":"admin1", "foo":3}, { > >> > "@foo-mod:owner":"admin2", "foo":4}, > >> > > >> > > >> > This approach presumes the attribute has a YANG module name that > defines > >> > the attribute, > >> > which is of course not allowed. > >> > > >> > RFC 6241 defines XML attributes for the operation, using a hack > >> > called the 'get-filter-element-attributes' extension. > >> > > >> > http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#get-filter-element-attributes.56 > >> > >> This is another extension that violates the rule stated in RFC 6020, > sec. > >> 6.3.1: > >> > >> If a YANG compiler does not support a particular extension, which > >> appears in a YANG module as an unknown-statement (see Section 12), > >> the entire unknown-statement MAY be ignored by the compiler. > >> > >> > > >> > The NETCONF-EX operation has a "with-metadata" parameter that > uses > >> > identities > >> > to map attributes to YANG. > >> > > >> > I think a standard mechanism is needed to properly map attributes to > JSON > >> > and XML. > >> > >> I'd suggest to define two generic constructs: > >> > >> 1. Metadata > >> > >> Every JSON value (false / null / true / object / array / number / > string) > >> can be changed into a "@tagged-value" object, e.g. the number 42 can > become > >> > >> { > >> "@tagged-value" : { > >> "@owner": "admin1", > >> "@value": 42 > >> } > >> } > >> > >> Multiple metadata key-value pairs may be present inside the > >> "@tagged-value" object. > >> > >> > > I don't think this works for lists and leaf-lists. > > Can you expand the encoding to show a real example with > > container, list, leaf, and leaf-list used? > > container > ========= > > "foo": { "bar": 42 } > > becomes > > "foo": { > "@tagged-value": { > "@tag1": 54, > "@value": { "bar": 42 }, > "@tag2": "hi!" > } > } > > leaf > ==== > > "bar": 42 > > becomes > > "bar": { > "@tagged-value": { > "@tag3" = false, > "@value": 42 > } > } > > leaf-list > ========= > > "foos": [ 6, 3, 7, 8] > > when tagging the whole array becomes > > "foos": { > "@tagged-value": { > "@value": [ 6, 3, 7, 8 ] > "tag4": true > > or, when tagging only one entry, becomes > > "foos": > [ 6, > { @tagged-value: { "@tag5": 1, "@value": 3 } }, > 7, > 8 > ] > > list > ==== > > is analogical, only scalar values (numbers in the above example) will be > replaced with objects. > Try the example I did where entry1 is owned by owner admin1 and entry2 is owned by admin2. I don't think this works. This approach is way too complicated. The encoding scheme in the RESTCONF draft is easier to implement and it works for list and leaf-list siblings. Andy > > > > Not only doesn't it work for siblings, but it depends on the order > (@owner > > followed by @value), > > and JSON objects are not ordered. > > No, it doesn't, as you can see in the examples the "@value" member can > appear at any place and the order of tags is also irrelevant. > > The only restriction is that no tag can have the key "@value". > > > > > > > > >> 2. Properties > >> > >> For a property "foo", every JSON value can be changed into a "@foo" > >> object, e.g. > >> > >> { > >> "@foo": 42 > >> } > >> > >> Such property objects may nest, e.g. > >> > >> { > >> "@bar": > >> { > >> "@foo": 42 > >> } > >> } > > > > > > > > why are properties needed? > > They are not strictly needed, only their encoding is much nicer, and I > assume quite often XML attributes are supposed to be used for such binary > properties, such as "protect", "deactivate" etc. > > So the examples above could also be written > > "@tagged-value": { > "@value": 42, > "@foo": true > } > > and > > "@tagged-value": { > "@value": 42, > "@foo": true, > "@bar": true > } > > > > why do we need attributes within attributes? > > To be able to express that a single value has multiple properties. > > Lada > > > > > > > Both constructs work for list and leaf-list entries, and may be also > >> combined. > >> > >> > A robust deterministic mapping is required, ad-hoc or not. Perhaps an > >> > identity registration > >> > scheme is good enough, since it provides a module-name for the > attribute > >> > name. > >> > (i.e., the tool needs to know all the identities derived-from the > >> > 'metadata' base identity) > >> > > >> > module foo-mod { > >> > ... > >> > import nexconf-ex { prefix nx; } > >> > > >> > identity owner { > >> > base nx:metadata; > >> > } > >> > } > >> > >> I would prefer either to define global attributes outside YANG, or to > >> introduce a new top-level statement for them in YANG 1.1, e.g. > >> "global-attribute". > > > > > > > >> > >> > > Lada > >> > >> > > Andy > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --001a11c2c27a3dac2704f547b82b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Mar 23, 2014 at 8:07 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:
Andy Bierman <andy@yumaworks.com> writes:

> On Sun, Mar 23, 2014 at 2:42 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
>> Andy Bierman <andy@yumawo= rks.com> writes:
>>
>> ...
>>
>> >
>> > The attribute mapping needs to correspond to the XML attribut= e mapping.
>> > Attributes have string values, so the mapping above will not = work.
>>
>> I don't understand. XML schemas can define attribute values to= be of other
>> types, too, not only string.
>>
>>
> I meant they are encoded in XML as quoted strings
>
>
>> >
>> > Attributes can be qualified or unqualified. =A0If qualified, = then the
>> > module-name
>> > is used as a prefix:
>> >
>> > =A0 "foo" [ 1, 2, { "@foo-mod:owner":&quo= t;admin1", "foo":3}, {
>> > "@foo-mod:owner":"admin2", "foo"= ;:4},
>> >
>> >
>> > This approach presumes the attribute has a YANG module name t= hat defines
>> > the attribute,
>> > which is of course not allowed.
>> >
>> > RFC 6241 defines XML attributes for the <get> operation= , using a hack
>> > called the =A0'get-filter-element-attributes' extensi= on.
>> >
>> http://www.netco= nfcentral.org/modules/ietf-netconf/2011-06-01#get-filter-element-attributes= .56
>>
>> This is another extension that violates the rule stated in RFC 602= 0, sec.
>> 6.3.1:
>>
>> =A0 =A0If a YANG compiler does not support a particular extension,= which
>> =A0 =A0appears in a YANG module as an unknown-statement (see Secti= on 12),
>> =A0 =A0the entire unknown-statement MAY be ignored by the compiler= .
>>
>> >
>> > The NETCONF-EX <get2> operation has a "with-metada= ta" parameter that uses
>> > identities
>> > to map attributes to YANG.
>> >
>> > I think a standard mechanism is needed to properly map attrib= utes to JSON
>> > and XML.
>>
>> I'd suggest to define two generic constructs:
>>
>> 1. Metadata
>>
>> Every JSON value (false / null / true / object / array / number / = string)
>> can be changed into a "@tagged-value" object, e.g. the n= umber 42 can become
>>
>> {
>> =A0 "@tagged-value" : {
>> =A0 =A0 "@owner": "admin1",
>> =A0 =A0 "@value": 42
>> =A0 }
>> }
>>
>> Multiple metadata key-value pairs may be present inside the
>> "@tagged-value" object.
>>
>>
> I don't think this works for lists and leaf-lists.
> Can you expand the encoding to show a real example with
> container, list, leaf, and leaf-list used?

container
=3D=3D=3D=3D=3D=3D=3D=3D=3D

"foo": { "bar": 42 }

becomes

"foo": {
=A0 "@tagged-value": {
=A0 =A0 "@tag1": 54,
=A0 =A0 "@value": { "bar": 42 },
=A0 =A0 "@tag2": "hi!"
=A0 }
}

leaf
=3D=3D=3D=3D

"bar": 42

becomes

"bar": {
=A0 "@tagged-value": {
=A0 =A0 "@tag3" =3D false,
=A0 =A0 "@value": 42
=A0 }
}

leaf-list
=3D=3D=3D=3D=3D=3D=3D=3D=3D

"foos": [ 6, 3, 7, 8]

when tagging the whole array becomes

"foos": {
=A0 "@tagged-value": {
=A0 =A0 "@value": [ 6, 3, 7, 8 ]
=A0 =A0 "tag4": true

or, when tagging only one entry, becomes

"foos":
=A0 [ 6,
=A0 =A0 { @tagged-value: { "@tag5": 1, "@value": 3 } },=
=A0 =A0 7,
=A0 =A0 8
=A0 ]

list
=3D=3D=3D=3D

is analogical, only scalar values (numbers in the above example) will be re= placed with objects.=A0


=
Try the example I did where entry1 is owned by owner admin1 = and entry2
is owned by admin2. =A0I don't think this works.

This approach is way too complicated. The encoding scheme in the RE= STCONF draft
is easier to implement and it works for list and lea= f-list siblings.


Andy


=

>
> Not only doesn't it work for siblings, but it depends on the order= (@owner
> followed by @value),
> and JSON objects are not ordered.

No, it doesn't, as you can see in the examples the "@value" m= ember can appear at any place and the order of tags is also irrelevant.

The only restriction is that no tag can have the key "@value".
>
>
>
>> 2. Properties
>>
>> For a property "foo", every JSON value can be changed in= to a "@foo"
>> object, e.g.
>>
>> {
>> =A0 "@foo": 42
>> }
>>
>> Such property objects may nest, e.g.
>>
>> {
>> =A0 "@bar":
>> =A0 {
>> =A0 =A0 "@foo": 42
>> =A0 }
>> }
>
>
>
> why are properties needed?

They are not strictly needed, only their encoding is much nicer, and I assu= me quite often XML attributes are supposed to be used for such binary prope= rties, such as "protect", "deactivate" etc.

So the examples above could also be written

"@tagged-value": {
=A0 "@value": 42,
=A0 "@foo": true
}

and

"@tagged-value": {
=A0 "@value": 42,
=A0 "@foo": true,
=A0 "@bar": true
}


> why do we need attributes within attributes?

To be able to express that a single value has multiple properties.

Lada

>
>
> Both constructs work for list and leaf-list entries, and may be also >> combined.
>>
>> > A robust deterministic mapping is required, ad-hoc or not. Pe= rhaps an
>> > identity registration
>> > scheme is good enough, since it provides a module-name for th= e attribute
>> > name.
>> > (i.e., the tool needs to know all the identities derived-from= the
>> > 'metadata' base identity)
>> >
>> > =A0 module foo-mod {
>> > =A0 =A0 ...
>> > =A0 =A0 import nexconf-ex { prefix nx; }
>> >
>> > =A0 =A0 identity owner {
>> > =A0 =A0 =A0 =A0base nx:metadata;
>> > =A0 =A0 }
>> > =A0 }
>>
>> I would prefer either to define global attributes outside YANG, or= to
>> introduce a new top-level statement for them in YANG 1.1, e.g.
>> "global-attribute".
>
>
>
>>
>>
> Lada
>>
>>
> Andy

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

--001a11c2c27a3dac2704f547b82b-- From nobody Sun Mar 23 08:26:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24E51A6FD1 for ; Sun, 23 Mar 2014 08:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GR5LF0CxaaP4 for ; Sun, 23 Mar 2014 08:26:09 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C1E871A6FD0 for ; Sun, 23 Mar 2014 08:26:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 348C554050C; Sun, 23 Mar 2014 16:26:07 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0SDCNPQ6XNI; Sun, 23 Mar 2014 16:26:02 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 36FFE540192; Sun, 23 Mar 2014 16:26:01 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20140323.110741.449355686.mbj@tail-f.com> References: <20140323.110741.449355686.mbj@tail-f.com> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Sun, 23 Mar 2014 16:26:00 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LfgvAHzHNJX5ZenFT6XcehukHsQ Cc: netmod@ietf.org Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 15:26:11 -0000 Martin Bjorklund writes: > Ladislav Lhotka wrote: >> Andy Bierman writes: >> >> ... >> >> > >> > The attribute mapping needs to correspond to the XML attribute mapping. >> > Attributes have string values, so the mapping above will not work. >> >> I don't understand. XML schemas can define attribute values to be of other >> types, too, not only string. >> >> > >> > Attributes can be qualified or unqualified. If qualified, then the >> > module-name >> > is used as a prefix: >> > >> > "foo" [ 1, 2, { "@foo-mod:owner":"admin1", "foo":3}, { >> > "@foo-mod:owner":"admin2", "foo":4}, >> > >> > >> > This approach presumes the attribute has a YANG module name that defines >> > the attribute, >> > which is of course not allowed. >> > >> > RFC 6241 defines XML attributes for the operation, using a hack >> > called the 'get-filter-element-attributes' extension. >> > http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#get-filter-element-attributes.56 >> >> This is another extension that violates the rule stated in RFC 6020, >> sec. 6.3.1: >> >> If a YANG compiler does not support a particular extension, which >> appears in a YANG module as an unknown-statement (see Section 12), >> the entire unknown-statement MAY be ignored by the compiler. >> >> > >> > The NETCONF-EX operation has a "with-metadata" parameter that uses >> > identities >> > to map attributes to YANG. >> > >> > I think a standard mechanism is needed to properly map attributes to JSON >> > and XML. >> >> I'd suggest to define two generic constructs: >> >> 1. Metadata >> >> Every JSON value (false / null / true / object / array / number / string) can >> be changed into a "@tagged-value" object, e.g. the number 42 can become >> >> { >> "@tagged-value" : { >> "@owner": "admin1", >> "@value": 42 >> } >> } >> >> Multiple metadata key-value pairs may be present inside the "@tagged-value" >> object. >> >> 2. Properties >> >> For a property "foo", every JSON value can be changed into a "@foo" object, >> e.g. >> >> { >> "@foo": 42 >> } >> >> Such property objects may nest, e.g. >> >> { >> "@bar": >> { >> "@foo": 42 >> } >> } >> >> Both constructs work for list and leaf-list entries, and may be also combined. > > This makes both client and server programming much more complex. The > whole point of using JSON is supposedly that it maps well to built-in > datastructures in modern languages. This property makes parsing > trivial, and makes it easy to get values. For example: > > res = json_parse(...) > if res['ssh']['enabled']: > ... > > now, with the proposed encoding, I have to be prepared for 'ssh' being > a '@tagged-value', and '@enabled' being a tagged-value, and > combinations thereof: > > if res['ssh']['enabled'] > or res['@tagged-value']['ssh']['enabled'] > or res['@tagged-value']['ssh']['@tagged-value']['enabled'] > or ... > > As I write this I realize that I don't really understand your > proposal..., so the code above is not correct - but the point is the > same; as soon as you allow multiple encodings you make coding much > more complex. I don't know whether the "enabled" parameter is a node in the data model or a global attribute that can be added to any instance. Show me the intended XML encoding. What I was trying to achieve was to be able to turn any JSON value into an object where the value is present together with any number of tags. Please check the examples in my response to Andy (and maybe ignore the "property" thing for the time being, it is just an optimization for a special case). > > Maybe the original JSON mapping idea is the only one that works; i.e., > map pure YANG data to JSON. No meta data. A protocol that needs meta > data should not use JSON; use XML instead. I tend to agree, and that's why I've been relucant to address attributes in the draft. For "pure" YANG-based data JSON is an excellent fit (IMO better than XML) and some applications should be just fine with it. Lada > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Mar 23 09:06:28 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D961A6FD4 for ; Sun, 23 Mar 2014 09:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCC2GQJmr7Cz for ; Sun, 23 Mar 2014 09:06:22 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) by ietfa.amsl.com (Postfix) with ESMTP id 08F071A0993 for ; Sun, 23 Mar 2014 09:06:21 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id 63so13553410qgz.6 for ; Sun, 23 Mar 2014 09:06:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=T8gqtMfGfHNMFhcicxLQTJQY0Eed6pHl5LUZ3aBaEjk=; b=dy7nL0FtM00OWQjWdeyt42nrUl+5H8WE7oAdsvTIOJnsaFt30hKVFFdF/wbjdKkWY6 2OQqJOOi/DU96xT5/MY3SC9dHxMLSRhEHdGSts/G9vE2x+jA7dYchIsCYGMlilXDUPE2 f6ggLmaIwo0ag6jm4ABlwkoq4dW49JRbxWMCf0+XL+PTPiUXid8lddKG59LZpdn5dCZB 0esu2UAV1rK6cFxx1olXKD8xBnEi+36AC+BLib1Q498fEYbsTGnucTaNeroYBwRZosiL YFTR28aEhLc2uXYn2fIzaL3LGk47+XuMcYoNvsacd0molJ39/H6Y4CjSQAyiBT0syqnB 6SYA== X-Gm-Message-State: ALoCoQlfl68Np14PqSKY9gegQl9XEqcK85gUCjF+sj4jBQ3ffmShYb3yjW+jAy64BqcHUbTnLsCA MIME-Version: 1.0 X-Received: by 10.229.139.199 with SMTP id f7mr70102298qcu.2.1395590781332; Sun, 23 Mar 2014 09:06:21 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Sun, 23 Mar 2014 09:06:21 -0700 (PDT) In-Reply-To: References: <20140323.110741.449355686.mbj@tail-f.com> Date: Sun, 23 Mar 2014 09:06:21 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c3e454c62ef704f5484c0f Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Jh5fAD-2kGNOcXFMT5FCuh31jxI Cc: "netmod@ietf.org" Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 16:06:25 -0000 --001a11c3e454c62ef704f5484c0f Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 23, 2014 at 8:26 AM, Ladislav Lhotka wrote: > Martin Bjorklund writes: > > > Ladislav Lhotka wrote: > >> Andy Bierman writes: > >> > >> ... > >> > >> > > >> > The attribute mapping needs to correspond to the XML attribute > mapping. > >> > Attributes have string values, so the mapping above will not work. > >> > >> I don't understand. XML schemas can define attribute values to be of > other > >> types, too, not only string. > >> > >> > > >> > Attributes can be qualified or unqualified. If qualified, then the > >> > module-name > >> > is used as a prefix: > >> > > >> > "foo" [ 1, 2, { "@foo-mod:owner":"admin1", "foo":3}, { > >> > "@foo-mod:owner":"admin2", "foo":4}, > >> > > >> > > >> > This approach presumes the attribute has a YANG module name that > defines > >> > the attribute, > >> > which is of course not allowed. > >> > > >> > RFC 6241 defines XML attributes for the operation, using a hack > >> > called the 'get-filter-element-attributes' extension. > >> > > http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#get-filter-element-attributes.56 > >> > >> This is another extension that violates the rule stated in RFC 6020, > >> sec. 6.3.1: > >> > >> If a YANG compiler does not support a particular extension, which > >> appears in a YANG module as an unknown-statement (see Section 12), > >> the entire unknown-statement MAY be ignored by the compiler. > >> > >> > > >> > The NETCONF-EX operation has a "with-metadata" parameter that > uses > >> > identities > >> > to map attributes to YANG. > >> > > >> > I think a standard mechanism is needed to properly map attributes to > JSON > >> > and XML. > >> > >> I'd suggest to define two generic constructs: > >> > >> 1. Metadata > >> > >> Every JSON value (false / null / true / object / array / number / > string) can > >> be changed into a "@tagged-value" object, e.g. the number 42 can become > >> > >> { > >> "@tagged-value" : { > >> "@owner": "admin1", > >> "@value": 42 > >> } > >> } > >> > >> Multiple metadata key-value pairs may be present inside the > "@tagged-value" > >> object. > >> > >> 2. Properties > >> > >> For a property "foo", every JSON value can be changed into a "@foo" > object, > >> e.g. > >> > >> { > >> "@foo": 42 > >> } > >> > >> Such property objects may nest, e.g. > >> > >> { > >> "@bar": > >> { > >> "@foo": 42 > >> } > >> } > >> > >> Both constructs work for list and leaf-list entries, and may be also > combined. > > > > This makes both client and server programming much more complex. The > > whole point of using JSON is supposedly that it maps well to built-in > > datastructures in modern languages. This property makes parsing > > trivial, and makes it easy to get values. For example: > > > > res = json_parse(...) > > if res['ssh']['enabled']: > > ... > > > > now, with the proposed encoding, I have to be prepared for 'ssh' being > > a '@tagged-value', and '@enabled' being a tagged-value, and > > combinations thereof: > > > > if res['ssh']['enabled'] > > or res['@tagged-value']['ssh']['enabled'] > > or res['@tagged-value']['ssh']['@tagged-value']['enabled'] > > or ... > > > This seems to be a problem in every proposal. In the RESTCONF approach, a leaf will either be a simple type or an object. I think the other 2 proposals alter objects even more, but to an application, moving data at all introduces complexity. Your comment assumes a plain JSON parser is going to parse this text into a plain object. A plain XML parser knows about attributes, but in JSON they are not handled special. There is no way to introduce attributes into JSON in a way that will be special handled by a plain JSON parser. > As I write this I realize that I don't really understand your > > proposal..., so the code above is not correct - but the point is the > > same; as soon as you allow multiple encodings you make coding much > > more complex. > > I don't know whether the "enabled" parameter is a node in the data model > or a global attribute that can be added to any instance. Show me the > intended XML encoding. > > What I was trying to achieve was to be able to turn any JSON value into an > object where the value is present together with any number of tags. > > Please check the examples in my response to Andy (and maybe ignore the > "property" thing for the time being, it is just an optimization for a > special case). > > > > > Maybe the original JSON mapping idea is the only one that works; i.e., > > map pure YANG data to JSON. No meta data. A protocol that needs meta > > data should not use JSON; use XML instead. > > I tend to agree, and that's why I've been relucant to address attributes > in the draft. For "pure" YANG-based data JSON is an excellent fit (IMO > better than XML) and some applications should be just fine with it. > > Dump Attributes? Cons: Protocols are going to find a need for meta-data, like with-defaults. A complete lack of meta-data might lead to solutions like the "enabled" leaf in some YANG modules -- a common property is spread across the data model in ad-hoc fashion. Simply adding the meta-data into the reply (but not in the schema) will mess up a parser not expecting the extra leafs. Pros: We should try to keep the work scope bounded by real requirements. RESTCONF has no operations that use attributes. It is only supported in case vendors add their own meta-data somehow. HTTP meta-data is returned in header lines, not within the message body. I would be OK with forbidding attributes in RESTCONF. Not so keen about using XML for 1 set of RESTCONF features and JSON for a different set of RESTCONF features. Lada > > > > > > > /martin > > Andy --001a11c3e454c62ef704f5484c0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Mar 23, 2014 at 8:26 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:
Martin Bjorklund <mbj@tail-f.com> writes:

> Ladislav Lhotka <lhotka@nic.cz= > wrote:
>> Andy Bierman <andy@yumawo= rks.com> writes:
>>
>> ...
>>
>> >
>> > The attribute mapping needs to correspond to the XML attribut= e mapping.
>> > Attributes have string values, so the mapping above will not = work.
>>
>> I don't understand. XML schemas can define attribute values to= be of other
>> types, too, not only string.
>>
>> >
>> > Attributes can be qualified or unqualified. =A0If qualified, = then the
>> > module-name
>> > is used as a prefix:
>> >
>> > =A0 "foo" [ 1, 2, { "@foo-mod:owner":&quo= t;admin1", "foo":3}, {
>> > "@foo-mod:owner":"admin2", "foo"= ;:4},
>> >
>> >
>> > This approach presumes the attribute has a YANG module name t= hat defines
>> > the attribute,
>> > which is of course not allowed.
>> >
>> > RFC 6241 defines XML attributes for the <get> operation= , using a hack
>> > called the =A0'get-filter-element-attributes' extensi= on.
>> > http://www.= netconfcentral.org/modules/ietf-netconf/2011-06-01#get-filter-element-attri= butes.56
>>
>> This is another extension that violates the rule stated in RFC 602= 0,
>> sec. 6.3.1:
>>
>> =A0 =A0If a YANG compiler does not support a particular extension,= which
>> =A0 =A0appears in a YANG module as an unknown-statement (see Secti= on 12),
>> =A0 =A0the entire unknown-statement MAY be ignored by the compiler= .
>>
>> >
>> > The NETCONF-EX <get2> operation has a "with-metada= ta" parameter that uses
>> > identities
>> > to map attributes to YANG.
>> >
>> > I think a standard mechanism is needed to properly map attrib= utes to JSON
>> > and XML.
>>
>> I'd suggest to define two generic constructs:
>>
>> 1. Metadata
>>
>> Every JSON value (false / null / true / object / array / number / = string) can
>> be changed into a "@tagged-value" object, e.g. the numbe= r 42 can become
>>
>> {
>> =A0 "@tagged-value" : {
>> =A0 =A0 "@owner": "admin1",
>> =A0 =A0 "@value": 42
>> =A0 }
>> }
>>
>> Multiple metadata key-value pairs may be present inside the "= @tagged-value"
>> object.
>>
>> 2. Properties
>>
>> For a property "foo", every JSON value can be changed in= to a "@foo" object,
>> e.g.
>>
>> {
>> =A0 "@foo": 42
>> }
>>
>> Such property objects may nest, e.g.
>>
>> {
>> =A0 "@bar":
>> =A0 {
>> =A0 =A0 "@foo": 42
>> =A0 }
>> }
>>
>> Both constructs work for list and leaf-list entries, and may be al= so combined.
>
> This makes both client and server programming much more complex. =A0Th= e
> whole point of using JSON is supposedly that it maps well to built-in<= br> > datastructures in modern languages. =A0This property makes parsing
> trivial, and makes it easy to get values. =A0For example:
>
> =A0 res =3D json_parse(...)
> =A0 if res['ssh']['enabled']:
> =A0 =A0 =A0...
>
> now, with the proposed encoding, I have to be prepared for 'ssh= 9; being
> a '@tagged-value', and '@enabled' being a tagged-value= , and
> combinations thereof:
>
> =A0 if res['ssh']['enabled']
> =A0 =A0 =A0or res['@tagged-value']['ssh']['enabled= ']
> =A0 =A0 =A0or res['@tagged-value']['ssh']['@tagged= -value']['enabled']
> =A0 =A0 =A0or ...
>


This seems to be a = problem in every proposal.
In the RESTCONF approach, a leaf will = either be a simple type
or an object. =A0I think the other 2 prop= osals alter objects
even more, but to an application, moving data at all introduces
<= div>complexity.

Your comment assumes a plain JSON = parser is going to
parse this text into a plain object. =A0A plai= n XML parser
knows about attributes, but in JSON they are not handled special.
There is no way to introduce attributes into JSON in a way
= that will be special handled by a plain JSON parser.


> As I write this I realize that I don't really understand your
> proposal..., so the code above is not correct - but the point is the > same; as soon as you allow multiple encodings you make coding much
> more complex.

I don't know whether the "enabled" parameter is a node in the= data model or a global attribute that can be added to any instance. Show m= e the intended XML encoding.

What I was trying to achieve was to be able to turn any JSON value into an = object where the value is present together with any number of tags.

Please check the examples in my response to Andy (and maybe ignore the &quo= t;property" thing for the time being, it is just an optimization for a= special case).

>
> Maybe the original JSON mapping idea is the only one that works; i.e.,=
> map pure YANG data to JSON. =A0No meta data. =A0A protocol that needs = meta
> data should not use JSON; use XML instead.

I tend to agree, and that's why I've been relucant to address attri= butes in the draft. For "pure" YANG-based data JSON is an excelle= nt fit (IMO better than XML) and some applications should be just fine with= it.


Dump Attributes?

<= div>Cons:

Protocols are going to find a need for m= eta-data, like with-defaults.

A complete lack of m= eta-data might lead to solutions like the "enabled" leaf in
some YANG modules -- a common property is spread across the data model=
in ad-hoc fashion. =A0Simply adding the meta-data into the reply= (but not in the schema)
will mess up a parser not expecting the = extra leafs.

Pros:

We should try to k= eep the work scope bounded by real requirements.
RESTCONF has no = operations that use attributes. =A0It is only supported in
case v= endors add their own meta-data somehow. =A0HTTP meta-data is returned
in header lines, not within the message body.

I would be OK with forbidding attributes in RESTCONF.
Not so kee= n about using XML for 1 set of RESTCONF features and JSON
for a d= ifferent set of RESTCONF features.



Lada

>
>
> /martin


Andy
=A0
--001a11c3e454c62ef704f5484c0f-- From nobody Sun Mar 23 09:15:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B3D1A6FD6 for ; Sun, 23 Mar 2014 09:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQZL2UHlD419 for ; Sun, 23 Mar 2014 09:14:57 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1A01A6FC9 for ; Sun, 23 Mar 2014 09:14:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 6A7DF54050C; Sun, 23 Mar 2014 17:14:56 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tq2TELY+oP7V; Sun, 23 Mar 2014 17:14:52 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 620B35402CD; Sun, 23 Mar 2014 17:14:51 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <3FADE5E8-88AC-4FD0-A2F6-72F408FAFFC4@juniper.net> <20140320.150426.496532825.mbj@tail-f.com> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Sun, 23 Mar 2014 17:14:49 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/dnLBJHJUDp_Y3hZw9uNuF_jUY7Y Cc: "netmod@ietf.org" Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 16:15:02 -0000 Andy Bierman writes: > > Try the example I did where entry1 is owned by owner admin1 and entry2 > is owned by admin2. I don't think this works. { "top": { "A": [ { "@tagged-value": { "@owner": "admin1", "@value": { "id": "entry-1", "aa": [42, 19] } } }, { "@tagged-value": { "@owner": "admin2", "@value": { "id": "entry-2", "aa": [99, 11] } } } ], "host-name": "router" } > > This approach is way too complicated. The encoding scheme in the RESTCONF > draft > is easier to implement and it works for list and leaf-list siblings. > I think it is more difficult to parse. If you have a container "foo" in the data model, you cannot tell whether "foo": { ... } is the "native" container or the encoding of attributes, without first inspecting the contents of the object, i.e. looking whether any keys of its members start with "@". In my encoding, the two alternatives can be distinguished immediately: "foo": { ... } (native container) versus "foo": { @tagged-value { ... } } Note also that in your example "host-name" : { "@protect" : "protect", "host-name" : "router" } the value of the "@protect" attribute is irrelevant, and this is where my "property" encoding is IMO more elegant: "host-name" : { "@protect" : "router" } My impression from previous discussions was that the proposed uses of XML attributes ("protect", "disable" etc.) are often of this type. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Mar 23 09:41:51 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938761A6FDC for ; Sun, 23 Mar 2014 09:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXc5DN5hs_sj for ; Sun, 23 Mar 2014 09:41:47 -0700 (PDT) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) by ietfa.amsl.com (Postfix) with ESMTP id C619C1A6FDB for ; Sun, 23 Mar 2014 09:41:46 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id i50so13640066qgf.0 for ; Sun, 23 Mar 2014 09:41:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bulCuKZiNzw3UAN9YgQRVjM4npVBlI1cCVglN09mkkU=; b=MIlIwb0L+i7hoMdBuSyZ/1BvQ99zDZd1iRy3n72qXkR9yg640NhlGSJX2kP/DwBFdJ VYCu3dEPTYI5SRJzOwLhM13OrV9tlNXBy85XgdWz5UePLQV2a1o1gI9fcIl2SnXtATYN QbFkFLyqYW8uSN/tBZgeQxZNoCnHoTemuaFi2qoL93eMZEK1tt+5ZUWAXtUcZNkLcnQ7 c+MYR/9CGTAsUN04fVH7F15J2vkolk5UULpZQkA23ZTXwfW5uDM5FDvoz1+1X5HZJ0Yr Nm1TFQJWww55P55BHztL+zBntNCO18ps6wEakw7ZFt+6G2nMCq/eItJDSfOznimu7OYI oOZw== X-Gm-Message-State: ALoCoQmGSl6ZvHVvz5kig8bd9UlRe7FCSGAKmOVKhqtlIUo+4H7w7LqiUCW5mi2V+gmLJkwUUZ46 MIME-Version: 1.0 X-Received: by 10.224.130.8 with SMTP id q8mr1222480qas.99.1395592906129; Sun, 23 Mar 2014 09:41:46 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Sun, 23 Mar 2014 09:41:46 -0700 (PDT) In-Reply-To: References: <3FADE5E8-88AC-4FD0-A2F6-72F408FAFFC4@juniper.net> <20140320.150426.496532825.mbj@tail-f.com> Date: Sun, 23 Mar 2014 09:41:46 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c2b34e6beed604f548cb1e Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/EE5Kei0wqj_N5meHe1zNSFJmPfw Cc: "netmod@ietf.org" Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 16:41:48 -0000 --001a11c2b34e6beed604f548cb1e Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 23, 2014 at 9:14 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > > Try the example I did where entry1 is owned by owner admin1 and entry2 > > is owned by admin2. I don't think this works. > > { "top": { > "A": [ > { "@tagged-value": { > "@owner": "admin1", > "@value": { > "id": "entry-1", > "aa": [42, 19] > } > } > }, > { "@tagged-value": { > "@owner": "admin2", > "@value": { > "id": "entry-2", > "aa": [99, 11] > } > } > } > ], > "host-name": "router" > } > > > > > This approach is way too complicated. The encoding scheme in the RESTCONF > > draft > > is easier to implement and it works for list and leaf-list siblings. > > > > I think it is more difficult to parse. If you have a container "foo" in > the data model, you cannot tell whether > > "foo": { ... } > > is the "native" container or the encoding of attributes, without first > inspecting the contents of the object, i.e. looking whether any keys of its > members start with "@". > > In my encoding, the two alternatives can be distinguished immediately: > > "foo": { ... } (native container) > > versus > > "foo": { > @tagged-value { ... } > } > > To a plain JSON parser it doesn't matter (just valid JSON). To a special parser that is looking for attributes, whatever ad-hoc formula is used will be coded, so it doesn't matter. > Note also that in your example > > "host-name" : { > "@protect" : "protect", > "host-name" : "router" > } > > the value of the "@protect" attribute is irrelevant, and this is where my > "property" encoding is IMO more elegant: > > "host-name" : { > "@protect" : "router" > } > > So if there are multiple boolean properties, the value is repeated? "host-name" : { "@protect" : "router", "@enabled": "router" } This seems really hard to parse. A variant that combines RESTCONF with yours: "host-name" : { "@protect" : true, "@enabled": true, "@owner": "admin1", "_@value":"router" } A real YANG identifier could never start with "_@" so it can be used to prevent "value" from being a reserved name. My impression from previous discussions was that the proposed uses of XML > attributes ("protect", "disable" etc.) are often of this type. > > There are plenty of examples like owner, etag, last-changed-time, and with-defaults that are not simple boolean properties. We know the attributes can be encoded in a way that a plain JSON parser will accept it. The real issue is whether the client or server code that needs to interpret the protocol message is going to be too complicated to be workable. HTTP header lines are for message-level meta-data. We have data-level meta-data associated with datastore nodes. I doubt it can be ignored. There are no issues with adding attributes to containers or lists. Only leaf and leaf-list encoding needs to be impacted. Lada > > Andy --001a11c2b34e6beed604f548cb1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Mar 23, 2014 at 9:14 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:
Andy Bierman <and= y@yumaworks.com> writes:
>
> Try the example I did where entry1 is owned by owner admin1 and entry2=
> is owned by admin2. =A0I don't think this works.

{ "top": {
=A0 "A": [
=A0 =A0 { "@tagged-value": {
=A0 =A0 =A0 =A0 "@owner": "admin1",
=A0 =A0 =A0 =A0 "@value": {
=A0 =A0 =A0 =A0 =A0 "id": "entry-1",
=A0 =A0 =A0 =A0 =A0 "aa": [42, 19]
=A0 =A0 =A0 =A0 }
=A0 =A0 =A0 }
=A0 =A0 },
=A0 =A0 { "@tagged-value": {
=A0 =A0 =A0 =A0 "@owner": "admin2",
=A0 =A0 =A0 =A0 "@value": {
=A0 =A0 =A0 =A0 =A0 "id": "entry-2",
=A0 =A0 =A0 =A0 =A0 "aa": [99, 11]
=A0 =A0 =A0 =A0 }
=A0 =A0 =A0 }
=A0 =A0 }
=A0 ],
=A0 "host-name": "router"
}

>
> This approach is way too complicated. The encoding scheme in the RESTC= ONF
> draft
> is easier to implement and it works for list and leaf-list siblings. >

I think it is more difficult to parse. If you have a container "foo&qu= ot; in the data model, you cannot tell whether

"foo": { ... }

is the "native" container or the encoding of attributes, without = first inspecting the contents of the object, i.e. looking whether any keys = of its members start with "@".

In my encoding, the two alternatives can be distinguished immediately:

"foo": { ... } =A0 =A0(native container)

versus

"foo": {
=A0 @tagged-value { ... }
}



To a plain JSON parser = it doesn't matter (just valid JSON).
To a special parser that= is looking for attributes, whatever ad-hoc
formula is used will = be coded, so it doesn't matter.

=A0
Note also that in your example

=A0 =A0"host-name" : {
=A0 =A0 =A0 =A0"@protect" : "protect",
=A0 =A0 =A0 =A0"host-name" : "router"
=A0 =A0}

the value of the "@protect" attribute is irrelevant, and this is = where my "property" encoding is IMO more elegant:

=A0 "host-name" : {
=A0 =A0 "@protect" : "router"
=A0 }


So if there are multiple boolean prope= rties, the value is repeated?

=A0 "host-name&= quot; : {
=A0 =A0 "@protect" : "router",
=
=A0 =A0 "@enabled": "router"
=A0 }

This seems really hard to parse.

=
A variant that combines RESTCONF with yours:

=A0 = "host-name" : {
=A0 =A0 "@protect" : true,
=A0 =A0 "@enabled": true,
=A0 =A0= "@owner": "admin1",
= =A0 =A0 "_@value":"router"
=A0 }

A real YANG identifier could never start with &q= uot;_@"
so it can be used to prevent &= quot;value" from being a reserved name.


=A0My impre= ssion from previous discussions was that the proposed uses of XML attribute= s ("protect", "disable" etc.) are often of this type.


There are plenty of exa= mples like owner, etag, last-changed-time, and with-defaults
that= are not simple boolean properties.

We know the at= tributes can be encoded in a way that a plain JSON parser will accept it.
The real issue is whether the client or server code that needs to inte= rpret the protocol
message is going to be too complicated to be w= orkable.

HTTP header lines are for message-level m= eta-data.
We have data-level meta-data associated with datastore nodes.
I doubt it can be ignored. There are no issues with
adding attr= ibutes to containers or lists. =A0Only leaf and leaf-list
encodin= g needs to be impacted.




Lada


Andy

=A0
--001a11c2b34e6beed604f548cb1e-- From nobody Sun Mar 23 09:58:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAA31A099A for ; Sun, 23 Mar 2014 09:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMDKOqqx_COk for ; Sun, 23 Mar 2014 09:58:43 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBB01A03FD for ; Sun, 23 Mar 2014 09:58:43 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9BF2E13FA60 for ; Sun, 23 Mar 2014 17:58:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395593921; bh=IEecZA24HlY89ou4hCMW0uhMRC9U1283DNb9XnVvwEw=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id: Date:To:Mime-Version; b=T1cHWl1YzWLzxUD4iwa+boO0A1ukbw03pKDFSbA2SZsG3FHRYCv1Zz8+ZlSkvuWjS /w5huST76K23WCoWTfVqbGJIdYF+C5W7PUvqsrk0XSNJjMbcqYbiBS+X3I9yIGp18u jvHRpI0iL1z4rml3LMKTALHg6sokaAP0vYLynNdM= From: Ladislav Lhotka Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <42BC513A-DCA3-49A4-A7E4-7F6268CD989F@nic.cz> Date: Sun, 23 Mar 2014 17:58:39 +0100 To: netmod@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yE7k09SGOCG2QHF5noP2wUDEFCU Subject: [netmod] YANG 1.1 issue: ill-defined XPath context for 'when' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 16:58:45 -0000 * ill-defined XPath context for 'when' ** Description The context for XPath expressions appearing in the 'when' statement is = not properly defined in = [[http://tools.ietf.org/html/rfc6020#section-7.19.5][Sec. 7.19.5]] = because the context node needn=92t exist in the data tree. Here is an example: container foo { when "..."; leaf bar { mandatory true; ... } } According to the third bullet in Sec. 7.19.5, the context node for the = 'when' expression is the container "foo". Then, a data tree which doesn't contain must be always considered = invalid because a mandatory leaf is missing. It is not possible to argue = that is missing due to the fact that the 'when' expression = evaluates to false because the XPath expression cannot be evaluated at = all (the context node is not present in the instance document). -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Mar 23 10:30:43 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D9A1A06D2 for ; Sun, 23 Mar 2014 10:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUB1Fgajs_6Y for ; Sun, 23 Mar 2014 10:30:39 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id 056D31A6FEC for ; Sun, 23 Mar 2014 10:30:38 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id j15so4432784qaq.16 for ; Sun, 23 Mar 2014 10:30:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nS5N+Sq9MBb0UXdKgGgBBdQihOS9vbz/646HgJ/zBBk=; b=DnatilQbi7OwQy+YAVi9MWnEB8f91smz23J/XB7fIWVzcdpz2J20oHGTDNmlmKyZ5P J/i+ket66aE1zWu3KB8dDpskxqaSFGrhiW45Ymm00zUv2SD+aE714w7awj4WWlMDKc+0 3KhozIwFyUbJkQXdu0uETBp/Djlwxaw+GFl+eeOj7egaXs4aH6067i0SJP57DIGKiwuu DQ2JKEv4gEvOyrY8MI/ja72yHpKU6FNy78c/JjzKfRGdkNxH2RcpqNRWE2/uaaGl+Xnz oyQSYBYQhx4gwoKFOzgUJHJ/BUAyPH4VZ5Oz+XCd0XsU8zUlXAKpko4OlHlrn+zZL8Bi oimw== X-Gm-Message-State: ALoCoQnWfoa6oK2NczEAn0Vd4v8qhRz0ZEWuCrG9d+NS0Y8p56JxX6JAxVskOVynlvgTj6b9Ysbd MIME-Version: 1.0 X-Received: by 10.224.79.133 with SMTP id p5mr1420467qak.98.1395595838402; Sun, 23 Mar 2014 10:30:38 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Sun, 23 Mar 2014 10:30:38 -0700 (PDT) In-Reply-To: <42BC513A-DCA3-49A4-A7E4-7F6268CD989F@nic.cz> References: <42BC513A-DCA3-49A4-A7E4-7F6268CD989F@nic.cz> Date: Sun, 23 Mar 2014 10:30:38 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7bf0de7a32c32d04f5497a93 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1tk8AdHc973cVr5wTScCVbsyVtg Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 issue: ill-defined XPath context for 'when' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 17:30:42 -0000 --047d7bf0de7a32c32d04f5497a93 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 23, 2014 at 9:58 AM, Ladislav Lhotka wrote: > * ill-defined XPath context for 'when' > > ** Description > > The context for XPath expressions appearing in the 'when' statement is not > properly defined in [[ > http://tools.ietf.org/html/rfc6020#section-7.19.5][Sec. 7.19.5]] because > the context node needn't exist in the data tree. > > Here is an example: > > container foo { > when "..."; > leaf bar { > mandatory true; > ... > } > } > > According to the third bullet in Sec. 7.19.5, the context node for the > 'when' expression is the container "foo". > > Then, a data tree which doesn't contain must be always considered > invalid because a mandatory leaf is missing. It is not possible to argue > that is missing due to the fact that the 'when' expression evaluates > to false because the XPath expression cannot be evaluated at all (the > context node is not present in the instance document). > > The when-stmt can be inherited in many ways, such as via uses or augment. It is too useful to prohibit the combination with mandatory, min-elements, or default. The solution is already in rfc6087bis. The when-stmt MUST NOT contain and descendant-or-self node references in any way. Then it is simply an implementation detail to process the expression as if the context node did exist. > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > Andy --047d7bf0de7a32c32d04f5497a93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Mar 23, 2014 at 9:58 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:
* ill-defined XPath context for 'when= 9;

** Description

The context for XPath expressions appearing in the 'when' statement= is not properly defined in [[http://tools.ietf.org/html/rfc6020#= section-7.19.5][Sec. 7.19.5]] because the context node needn’t ex= ist in the data tree.

Here is an example:

container foo {
    when "...";
    leaf bar {
        mandatory true;
        ...
    }
}

According to the third bullet in Sec. 7.19.5, the context node for the '= ;when' expression is the container "foo".

Then, a data tree which doesn't contain <foo> must be always cons= idered invalid because a mandatory leaf is missing. It is not possible to a= rgue that <foo> is missing due to the fact that the 'when' ex= pression evaluates to false because the XPath expression cannot be evaluate= d at all (the context node <foo> is not present in the instance docum= ent).



The when-stmt can be in= herited in many ways, such as via uses or augment.
It is too usef= ul to prohibit the combination with mandatory, min-elements, or default.

The solution is already in rfc6087bis. The when-stmt MU= ST NOT contain
and descendant-or-self node references in any way.=  Then it is simply an
implementation detail to process the = expression as if the context node did exist.

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



Andy
 
--047d7bf0de7a32c32d04f5497a93-- From nobody Sun Mar 23 10:37:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199F31A6FF0 for ; Sun, 23 Mar 2014 10:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4WlKcRE23yc for ; Sun, 23 Mar 2014 10:36:58 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDF31A6FEF for ; Sun, 23 Mar 2014 10:36:58 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9451C13FA60 for ; Sun, 23 Mar 2014 18:36:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395596216; bh=jQBr3Yyo4Thdlp9TWzRSE61JTo2zO911YR0xV6bnNiI=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id: Date:To:Mime-Version; b=Jlhp7yRhM0UZx0J3y4lytbFRMGvbLJGbN0Lb9QQiwAtlfoCWmwvo+vefUQRD9f5vE UwKR/1K9HvE0Fg/hFznZ6JEZNlEdZM7PJvaHSZ9fG90vMdaklt5kUUv2SjuUbV5jJV 8dOGZlDKFZm319XJ3B7eSGKgsK0F6eaGKqaBwZIg= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sun, 23 Mar 2014 18:36:54 +0100 To: netmod@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cBq611LRwRVsCU8fuSuKuJFW10c Subject: [netmod] YANG 1.1 issue: YIN -> YANG translation breaks text formatting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 17:37:00 -0000 * YIN -> YANG translation breaks text formatting ** Description When using YIN as the source format with the prospect of transforming it = to YANG (e.g. for publishing in an RFC), it is often impossible to get = longer text (in 'description' etc.) properly indented and formatted, = especially if the text consists of multiple paragraphs and/or contains = itemized lists or other structures. Further details and example use cases can be found = [[https://gitlab.labs.nic.cz/labs/yang-tools/wikis/editing_yang][here]]. ** Solution IN YIN, permit mixed content inside the element that is a child = of 'contact', 'description', 'organization' and 'reference' statements. = That is, the contents of may contain text nodes as well as XML = elements from foreign namespaces (any namespace other than the YIN = namespace, current module namespace and namespaces of all imported = modules). The default YIN->YANG translation of such a mixed content is similar to = XSLT: ignore all XML elements and concatenate the text nodes. However, = translators can make use of these elements. -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Mar 23 10:42:19 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D94A1A6FEA for ; Sun, 23 Mar 2014 10:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgsc_CM7BMxb for ; Sun, 23 Mar 2014 10:42:14 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 822DF1A0791 for ; Sun, 23 Mar 2014 10:42:14 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 895FC13FB6F; Sun, 23 Mar 2014 18:42:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395596533; bh=R89kr/gpcxdbMazNOI9H8DPS4RO0+UjTfwJdhddsXyA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=UBXrydz+XuIS3Ey3YfMg68U9JLHyGzxgi9W9uZNKnJ5ILAOkpJcdGjbwYlO6U0Y3t +D0mtnUmNVTNoewZIa+NUtW4p4gZG43YBV1/0W0Q6JGhJtyEhDUclK5CLSTLTNZHw/ raIMCX/7FnaLb/1rSV5XeymfWj8tgHpr5CLAV7Bc= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Sun, 23 Mar 2014 18:42:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <799F022F-BA28-425B-8D7F-F9F417C3E3DE@nic.cz> References: <42BC513A-DCA3-49A4-A7E4-7F6268CD989F@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/K83hLGzZUcOVh6yXVjpT9RvfJAM Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 issue: ill-defined XPath context for 'when' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 17:42:15 -0000 On 23 Mar 2014, at 18:30, Andy Bierman wrote: >=20 >=20 >=20 > On Sun, Mar 23, 2014 at 9:58 AM, Ladislav Lhotka = wrote: > * ill-defined XPath context for 'when' >=20 > ** Description >=20 > The context for XPath expressions appearing in the 'when' statement is = not properly defined in = [[http://tools.ietf.org/html/rfc6020#section-7.19.5][Sec. 7.19.5]] = because the context node needn=92t exist in the data tree. >=20 > Here is an example: >=20 > container foo { > when "..."; > leaf bar { > mandatory true; > ... > } > } >=20 > According to the third bullet in Sec. 7.19.5, the context node for the = 'when' expression is the container "foo". >=20 > Then, a data tree which doesn't contain must be always = considered invalid because a mandatory leaf is missing. It is not = possible to argue that is missing due to the fact that the 'when' = expression evaluates to false because the XPath expression cannot be = evaluated at all (the context node is not present in the instance = document). >=20 >=20 >=20 > The when-stmt can be inherited in many ways, such as via uses or = augment. > It is too useful to prohibit the combination with mandatory, = min-elements, or default. I haven=92t proposed anything like that, I am just pointing to an issue = with the spec that is IMO evident and should be corrected. >=20 > The solution is already in rfc6087bis. The when-stmt MUST NOT contain > and descendant-or-self node references in any way. Then it is simply = an > implementation detail to process the expression as if the context node = did exist. No. The =91when=92 expression in my example needn=92t reference anything = within =93foo=94 and the issue is still relevant. Lada=20 >=20 > =20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 > Andy > =20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Mar 23 11:15:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCA91A6FFA for ; Sun, 23 Mar 2014 11:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmvJ369uMKzU for ; Sun, 23 Mar 2014 11:15:37 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id 624CF1A6FF8 for ; Sun, 23 Mar 2014 11:15:37 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id e16so4886176qcx.6 for ; Sun, 23 Mar 2014 11:15:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jXMzodXlrzujcniUuXRCZrB66NY5/vam8tLOajjxA7I=; b=QM2scfpq0EldoiSqTUHPINCnmZP7z97/yRxkUhHZz2DRCJO3tocB+AvQvmugXPWKsu cLgD8d9w/SJdgfQ4ACUxAIPVv0h6TELw3+FrF/bnZvWlbXRUylOFy04xlKbdbiEZNwLv 2YTWZuW6RqTLRdWnIVdviGgfIWXyjRt3BBqdNKYzgHU90Sjsv30lnn20VARBAcClTRqc 3vGUA0HG5LPKZfUqHkTj+agx7R2q88QGdRV4IuYqZHkMnDuyTjdX8cUePjSY0uP5kICm uPrtJz8jsqZ4OzBd/uj6oE3d2/O2YqX7qKy53u1Kuo/MOMpX8ncv3V64dJvFfqvwCgPB O0qw== X-Gm-Message-State: ALoCoQlRZG3qg+j2DR5dKpZmBwYvN/Wo3IL3X1HcYCcgZD0W7LWRxnahZUOQ85JoIVTopLHSNF4t MIME-Version: 1.0 X-Received: by 10.140.101.74 with SMTP id t68mr51563qge.106.1395598536576; Sun, 23 Mar 2014 11:15:36 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Sun, 23 Mar 2014 11:15:36 -0700 (PDT) In-Reply-To: <799F022F-BA28-425B-8D7F-F9F417C3E3DE@nic.cz> References: <42BC513A-DCA3-49A4-A7E4-7F6268CD989F@nic.cz> <799F022F-BA28-425B-8D7F-F9F417C3E3DE@nic.cz> Date: Sun, 23 Mar 2014 11:15:36 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c16daa07246204f54a1b5c Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qjiX2jYSapQP1mwpPZycPQCj0gc Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 issue: ill-defined XPath context for 'when' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 18:15:40 -0000 --001a11c16daa07246204f54a1b5c Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 23, 2014 at 10:42 AM, Ladislav Lhotka wrote: > > On 23 Mar 2014, at 18:30, Andy Bierman wrote: > > > > > > > > > On Sun, Mar 23, 2014 at 9:58 AM, Ladislav Lhotka wrote: > > * ill-defined XPath context for 'when' > > > > ** Description > > > > The context for XPath expressions appearing in the 'when' statement is > not properly defined in [[ > http://tools.ietf.org/html/rfc6020#section-7.19.5][Sec. 7.19.5]] because > the context node needn't exist in the data tree. > > > > Here is an example: > > > > container foo { > > when "..."; > > leaf bar { > > mandatory true; > > ... > > } > > } > > > > According to the third bullet in Sec. 7.19.5, the context node for the > 'when' expression is the container "foo". > > > > Then, a data tree which doesn't contain must be always considered > invalid because a mandatory leaf is missing. It is not possible to argue > that is missing due to the fact that the 'when' expression evaluates > to false because the XPath expression cannot be evaluated at all (the > context node is not present in the instance document). > > > > > > > > The when-stmt can be inherited in many ways, such as via uses or augment. > > It is too useful to prohibit the combination with mandatory, > min-elements, or default. > > I haven't proposed anything like that, I am just pointing to an issue with > the spec that is IMO evident and should be corrected. > > > > > The solution is already in rfc6087bis. The when-stmt MUST NOT contain > > and descendant-or-self node references in any way. Then it is simply an > > implementation detail to process the expression as if the context node > did exist. > > No. The 'when' expression in my example needn't reference anything within > "foo" and the issue is still relevant. > > Not sure why... in our code this situation is handled just fine. When processing the parent of container foo, the tool can process the when-stmt since it does not refer to anything inside the foo container. Processing the expression as if the context node is the TBD foo node is just an implementation detail. This is interoperable, since the content of the foo container is not allowed to be in the when expression. > Lada > > Andy --001a11c16daa07246204f54a1b5c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Mar 23, 2014 at 10:42 AM, Ladislav Lhotka <lhotka@nic.cz&g= t; wrote:

On 23 Mar 2014, at 18:30, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Sun, Mar 23, 2014 at 9:58 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> * ill-defined XPath context for 'when'
>
> ** Description
>
> The context for XPath expressions appearing in the 'when' stat= ement is not properly defined in [[http://tools.ietf.org/html/rfc= 6020#section-7.19.5][Sec. 7.19.5]] because the context node needn&rsquo= ;t exist in the data tree.
>
> Here is an example:
>
> container foo {
>     when "...";
>     leaf bar {
>         mandatory true;
>         ...
>     }
> }
>
> According to the third bullet in Sec. 7.19.5, the context node for the= 'when' expression is the container "foo".
>
> Then, a data tree which doesn't contain <foo> must be always= considered invalid because a mandatory leaf is missing. It is not possible= to argue that <foo> is missing due to the fact that the 'when= 9; expression evaluates to false because the XPath expression cannot be eva= luated at all (the context node <foo> is not present in the instance = document).
>
>
>
> The when-stmt can be inherited in many ways, such as via uses or augme= nt.
> It is too useful to prohibit the combination with mandatory, min-eleme= nts, or default.

I haven’t proposed anything like that, I am just pointing to an issue= with the spec that is IMO evident and should be corrected.

>
> The solution is already in rfc6087bis. The when-stmt MUST NOT contain<= br> > and descendant-or-self node references in any way.  Then it is si= mply an
> implementation detail to process the expression as if the context node= did exist.

No. The ‘when’ expression in my example needn’t reference= anything within “foo” and the issue is still relevant.


Not sure why... in our code this situa= tion is handled just fine.
When processing the parent of containe= r foo, the tool can process the when-stmt
since it does not refer= to anything inside the foo container.  Processing the expression
as if the context node is the TBD foo node is just an implementation d= etail.
This is interoperable, since the content of the foo contai= ner is not allowed to
be in the when expression.

 
Lada


Andy

<= /div> --001a11c16daa07246204f54a1b5c-- From nobody Sun Mar 23 11:22:27 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DA31A08D2 for ; Sun, 23 Mar 2014 11:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TreHDN0JKqr3 for ; Sun, 23 Mar 2014 11:22:24 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id EB06F1A07C1 for ; Sun, 23 Mar 2014 11:22:23 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id hw13so4391071qab.4 for ; Sun, 23 Mar 2014 11:22:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yVZtndWjJlhg1PBmNsX/gVYAripXs1avc+YQRWUHMhc=; b=HHG0jPDELWsfP6vt7q38DjthPluEAAvxTyJCq1nXyO0BxLG5a7Q2lIlPkUW4LLtgSK 0NUvmGyy3KHUKoB0zhtNyHyCpxlWuhXi0c6qZc1OlBnjIe1i6mKV4YYTIPV2AXNZiDLV X8R7R6KmqUDhrF4ZtILqr3k43NOIBJrai/2oTqgOCvUX5xrZdm50X5wGJJ5yeoK/GsL1 ZLQzp4D2jc16bUZwwXWbxelCg2DKxZb4LlQGTNVzNvKITbHGyhny4RrjbzBDfHYjgsKb Az1QJYakYWKmp9kgtsVS+ju8GcOz0nUFL2BqbcPdR7m0ktYxEFVbybAppHVArwRVM3dO 9rzg== X-Gm-Message-State: ALoCoQn3prY7HaD06t6CAxzshUVNvuxuTsKnqKN7X5ZXsI+IkhVQdi3lgNrylwT3ERjeZ/EdpC7B MIME-Version: 1.0 X-Received: by 10.140.25.247 with SMTP id 110mr2607950qgt.83.1395598943323; Sun, 23 Mar 2014 11:22:23 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Sun, 23 Mar 2014 11:22:23 -0700 (PDT) In-Reply-To: References: Date: Sun, 23 Mar 2014 11:22:23 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c13a4044a65a04f54a3372 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Pdj5n_Av-r7xGnmjfGgG6axzy8c Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 issue: YIN -> YANG translation breaks text formatting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 18:22:26 -0000 --001a11c13a4044a65a04f54a3372 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 23, 2014 at 10:36 AM, Ladislav Lhotka wrote: > * YIN -> YANG translation breaks text formatting > > ** Description > > When using YIN as the source format with the prospect of transforming it > to YANG (e.g. for publishing in an RFC), it is often impossible to get > longer text (in 'description' etc.) properly indented and formatted, > especially if the text consists of multiple paragraphs and/or contains > itemized lists or other structures. > > Further details and example use cases can be found [[ > https://gitlab.labs.nic.cz/labs/yang-tools/wikis/editing_yang][here]]. > > ** Solution > > IN YIN, permit mixed content inside the element that is a child of > 'contact', 'description', 'organization' and 'reference' statements. That > is, the contents of may contain text nodes as well as XML elements > from foreign namespaces (any namespace other than the YIN namespace, > current module namespace and namespaces of all imported modules). > > The default YIN->YANG translation of such a mixed content is similar to > XSLT: ignore all XML elements and concatenate the text nodes. However, > translators can make use of these elements. > > This seems like a really complex solution for something that is barely used. I don't know of anybody except you who uses YIN format instead of YANG. Since YANG only preserves string indentation for a single statement, I don't see why mixed mode XML is needed for YIN. Since XML preserves whitespace for elements, it seems a parser could process a text block as if it was a YANG double quoted string. Why is the translation broken? > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > Andy --001a11c13a4044a65a04f54a3372 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Mar 23, 2014 at 10:36 AM, Ladislav Lhotka <lhotka@nic.cz&g= t; wrote:
* YIN -> YANG translation breaks text for= matting

** Description

When using YIN as the source format with the prospect of transforming it to= YANG (e.g. for publishing in an RFC), it is often impossible to get longer= text (in 'description' etc.) properly indented and formatted, espe= cially if the text consists of multiple paragraphs and/or contains itemized= lists or other structures.

Further details and example use cases can be found [[https://gitlab.labs.nic.cz/labs/yang-tools/wikis/editing_yang][here]]= .

** Solution

IN YIN, permit mixed content inside the <text> element that is a chil= d of 'contact', 'description', 'organization' and &= #39;reference' statements. That is, the contents of <text> may co= ntain text nodes as well as XML elements from foreign namespaces (any names= pace other than the YIN namespace, current module namespace and namespaces = of all imported modules).

The default YIN->YANG translation of such a mixed content is similar to = XSLT: ignore all XML elements and concatenate the text nodes. However, tran= slators can make use of these elements.


This seems like a really complex solut= ion for something that is barely used.
I don't know of anybod= y except you who uses YIN format instead of YANG.

Since YANG only preserves string indentation for a single statement, I= don't see
why mixed mode XML is needed for YIN. =A0Since XML= preserves whitespace for
elements, it seems a parser could proce= ss a text block as if it was a
YANG double quoted string. Why is the translation broken?


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




Andy
=A0
--001a11c13a4044a65a04f54a3372-- From nobody Mon Mar 24 00:32:17 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7511A013A for ; Mon, 24 Mar 2014 00:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZavenB5y6qA for ; Mon, 24 Mar 2014 00:32:14 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 520281A011E for ; Mon, 24 Mar 2014 00:32:13 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id s2O7WCYW007543; Mon, 24 Mar 2014 08:32:12 +0100 Message-ID: <532FDF7B.8060703@mg-soft.com> Date: Mon, 24 Mar 2014 08:32:11 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ladislav Lhotka References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2PeO51KQRxx68ZIU5hRTBMQqQok Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 issue: YIN -> YANG translation breaks text formatting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 07:32:17 -0000 Dne 23.3.2014 18:36, piše Ladislav Lhotka: > * YIN -> YANG translation breaks text formatting > > ** Description > > When using YIN as the source format with the prospect of transforming it to YANG (e.g. for publishing in an RFC), it is often impossible to get longer text (in 'description' etc.) properly indented and formatted, especially if the text consists of multiple paragraphs and/or contains itemized lists or other structures. > > Further details and example use cases can be found [[https://gitlab.labs.nic.cz/labs/yang-tools/wikis/editing_yang][here]]. This is due to the fact that YANG is capable of carrying more meta information than YIN (like comments between concatenated quoted strings, and string concatenation itself). But I think that's okay and don't see it as a problem. I find it quite strange that you use YIN as the format in which you write YANG code. I understand why (read the link you provided), but still...I don't think YIN was ever meant for that purpose. You will never be able to write YIN with the same "precision" as YANG. Note that you could probably avoid most formatting issues if you abandon the idea of pretty printing your YIN text values, since all whitespace within them should be considered as significant. A simpler solution than mixed content. Jernej > > ** Solution > > IN YIN, permit mixed content inside the element that is a child of 'contact', 'description', 'organization' and 'reference' statements. That is, the contents of may contain text nodes as well as XML elements from foreign namespaces (any namespace other than the YIN namespace, current module namespace and namespaces of all imported modules). > > The default YIN->YANG translation of such a mixed content is similar to XSLT: ignore all XML elements and concatenate the text nodes. However, translators can make use of these elements. > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Mar 24 00:47:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8381A014F for ; Mon, 24 Mar 2014 00:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.739 X-Spam-Level: X-Spam-Status: No, score=0.739 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiXj5sX9HnYz for ; Mon, 24 Mar 2014 00:47:19 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE231A0149 for ; Mon, 24 Mar 2014 00:47:18 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 23BFB13F98A for ; Mon, 24 Mar 2014 08:47:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395647237; bh=Y+/HWxtcGvcJK7/P62gDoIxvh5hWnh52kDYXRD+as6s=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id: Date:To:Mime-Version; b=gl6fultLZVnJQdzNn9s8uMxlLna02fT2UhWBRnNTGq9VDzIdOoMVB5JbOl7r1Fl15 8de/Mf8DMEv4vnEG124jmbW/rcv0TO81qG/h2V8if8ZFafk9ZKK/VMwfJWouWQuIzv IWrMFs7YlFZSRXjPlmuGIleOEPHU9+mpckLJfoX4= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 24 Mar 2014 08:47:17 +0100 To: netmod@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kTAmRzOWzqdshWYzZEQEKbIMyq4 Subject: [netmod] YANG 1.1 issue: make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 07:47:21 -0000 * make enum numbering purely informative and optional ** Description In an enumeration type, each enum has an integer value assigned to it, = either using the 'value' statement or via an automatic numbering = procedure. =46rom the NETCONF/RESTCONF protocol point of view, these = values are irrelevant because they never appear on the wire. RFC 6020 = also says in [[http://tools.ietf.org/html/rfc6020#section-9.6.4.2][Sec. = 9.6.4.2]]: "The value is unused by YANG and the XML encoding, but is = carried as a convenience to implementors." However, RFC 6020 states in = [[http://tools.ietf.org/html/rfc6020#section-10][Sec. 10]]: o An "enumeration" type may have new enums added, provided the old enums's values do not change. This rule makes updates of enumerations difficult and/or forces the data = modeller to assign the values explicitly even if they have no meaning = otherwise. The rule also contradicts the statement in Sec. 9.6.4.2 = because the value in fact *is* used by YANG. ** Solution Remove the auto-numbering procedure and the cited rule from Sec. 10. = Numeric values can be assigned where they have some meaning outside = NETCONF (e.g. protocols with port numbers), but they are indeed only = informative. -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 24 00:53:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908A21A0159 for ; Mon, 24 Mar 2014 00:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ml1LUlFSjEss for ; Mon, 24 Mar 2014 00:52:56 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id B7EC71A014D for ; Mon, 24 Mar 2014 00:52:56 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id B722B240C3A7; Mon, 24 Mar 2014 08:52:55 +0100 (CET) Date: Mon, 24 Mar 2014 08:52:55 +0100 (CET) Message-Id: <20140324.085255.116440426366187599.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <42BC513A-DCA3-49A4-A7E4-7F6268CD989F@nic.cz> References: <42BC513A-DCA3-49A4-A7E4-7F6268CD989F@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZcBkU7QwyHZzShoAi7a32xASzR8 Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 issue: ill-defined XPath context for 'when' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 07:53:00 -0000 SGksDQoNClRoaXMgaXMsIGFzIGZhciBhcyBJIGNhbiB0ZWxsLCBhIGR1cGxpY2F0aW9uIG9mIGlz c3VlIFkxOC4gIFJpZ2h0Pw0KDQoNCi9tYXJ0aW4NCg0KDQoNCkxhZGlzbGF2IExob3RrYSA8bGhv dGthQG5pYy5jej4gd3JvdGU6DQo+ICogaWxsLWRlZmluZWQgWFBhdGggY29udGV4dCBmb3IgJ3do ZW4nDQo+IA0KPiAqKiBEZXNjcmlwdGlvbg0KPiANCj4gVGhlIGNvbnRleHQgZm9yIFhQYXRoIGV4 cHJlc3Npb25zIGFwcGVhcmluZyBpbiB0aGUgJ3doZW4nIHN0YXRlbWVudCBpcw0KPiBub3QgcHJv cGVybHkgZGVmaW5lZCBpbg0KPiBbW2h0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYwMjAj c2VjdGlvbi03LjE5LjVdW1NlYy4gNy4xOS41XV0NCj4gYmVjYXVzZSB0aGUgY29udGV4dCBub2Rl IG5lZWRu4oCZdCBleGlzdCBpbiB0aGUgZGF0YSB0cmVlLg0KPiANCj4gSGVyZSBpcyBhbiBleGFt cGxlOg0KPiANCj4gY29udGFpbmVyIGZvbyB7DQo+ICAgICB3aGVuICIuLi4iOw0KPiAgICAgbGVh ZiBiYXIgew0KPiAgICAgICAgIG1hbmRhdG9yeSB0cnVlOw0KPiAgICAgICAgIC4uLg0KPiAgICAg fQ0KPiB9DQo+IA0KPiBBY2NvcmRpbmcgdG8gdGhlIHRoaXJkIGJ1bGxldCBpbiBTZWMuIDcuMTku NSwgdGhlIGNvbnRleHQgbm9kZSBmb3IgdGhlDQo+ICd3aGVuJyBleHByZXNzaW9uIGlzIHRoZSBj b250YWluZXIgImZvbyIuDQo+IA0KPiBUaGVuLCBhIGRhdGEgdHJlZSB3aGljaCBkb2Vzbid0IGNv bnRhaW4gPGZvbz4gbXVzdCBiZSBhbHdheXMNCj4gY29uc2lkZXJlZCBpbnZhbGlkIGJlY2F1c2Ug YSBtYW5kYXRvcnkgbGVhZiBpcyBtaXNzaW5nLiBJdCBpcyBub3QNCj4gcG9zc2libGUgdG8gYXJn dWUgdGhhdCA8Zm9vPiBpcyBtaXNzaW5nIGR1ZSB0byB0aGUgZmFjdCB0aGF0IHRoZQ0KPiAnd2hl bicgZXhwcmVzc2lvbiBldmFsdWF0ZXMgdG8gZmFsc2UgYmVjYXVzZSB0aGUgWFBhdGggZXhwcmVz c2lvbg0KPiBjYW5ub3QgYmUgZXZhbHVhdGVkIGF0IGFsbCAodGhlIGNvbnRleHQgbm9kZSA8Zm9v PiBpcyBub3QgcHJlc2VudCBpbg0KPiB0aGUgaW5zdGFuY2UgZG9jdW1lbnQpLg0KPiANCj4gLS0N Cj4gTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPiBQR1AgS2V5IElEOiBFNzRFOEMwQw0K PiANCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gDQo= From nobody Mon Mar 24 00:54:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828481A0152 for ; Mon, 24 Mar 2014 00:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgm_Wuv8qM57 for ; Mon, 24 Mar 2014 00:54:28 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3096E1A0150 for ; Mon, 24 Mar 2014 00:54:28 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id D8C6313F98A; Mon, 24 Mar 2014 08:54:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395647667; bh=zGqIQs6DOCVuvtKqru6gh6Utc3cDXrqsXOKPbQBCj9A=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=R2isfKi3P1f8zDbFNDIdN0kjB8mCh2W0LGCulMCcIeNnoHRAs0Umrvm+78jK/ag9N WFKik7VhbDR4Q6BIUTii9M7K2ZRPhBIcMFjim0h99RSTSmXTasyv7J6p6GPtzGx9fs X6DSsSGQm3w0T0xpdL2vGBhqwjSDPK5qdnOWc2UQ= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140324.085255.116440426366187599.mbj@tail-f.com> Date: Mon, 24 Mar 2014 08:54:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <54D89C09-7B33-4547-BC4C-17EA12E95589@nic.cz> References: <42BC513A-DCA3-49A4-A7E4-7F6268CD989F@nic.cz> <20140324.085255.116440426366187599.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/innYIBDk0nUberrl_VEldQd-Vkk Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 issue: ill-defined XPath context for 'when' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 07:54:29 -0000 On 24 Mar 2014, at 08:52, Martin Bjorklund wrote: > Hi, >=20 > This is, as far as I can tell, a duplication of issue Y18. Right? Oh yes, I missed that, sorry. Lada >=20 >=20 > /martin >=20 >=20 >=20 > Ladislav Lhotka wrote: >> * ill-defined XPath context for 'when' >>=20 >> ** Description >>=20 >> The context for XPath expressions appearing in the 'when' statement = is >> not properly defined in >> [[http://tools.ietf.org/html/rfc6020#section-7.19.5][Sec. 7.19.5]] >> because the context node needn=92t exist in the data tree. >>=20 >> Here is an example: >>=20 >> container foo { >> when "..."; >> leaf bar { >> mandatory true; >> ... >> } >> } >>=20 >> According to the third bullet in Sec. 7.19.5, the context node for = the >> 'when' expression is the container "foo". >>=20 >> Then, a data tree which doesn't contain must be always >> considered invalid because a mandatory leaf is missing. It is not >> possible to argue that is missing due to the fact that the >> 'when' expression evaluates to false because the XPath expression >> cannot be evaluated at all (the context node is not present in >> the instance document). >>=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 From nobody Mon Mar 24 01:43:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E111A0159 for ; Mon, 24 Mar 2014 01:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tmPlhkhUit5 for ; Mon, 24 Mar 2014 01:42:56 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4F56F1A00FA for ; Mon, 24 Mar 2014 01:42:56 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 1C7F613F908; Mon, 24 Mar 2014 09:42:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395650572; bh=H2PVFhyTHRgziKaAjOycpXaV1RhlaszM8e0Plt4EYlA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=J5TYs+AnqZ3OHu2ypreKfYue873ADlce3WqK6w5xnhMiShPEC9x0PYL+sedS4gNF1 +D8RTbnWYOsA1YoHQ2XEkW2UzDfdBoA20jAxPyHIQxT3BsthA6Dp3y0Z6L61kTiX2G Vsd7u0BVrx+F0NsDzLc5l3NMhtCSskc9Cck6pLEc= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <532FDF7B.8060703@mg-soft.com> Date: Mon, 24 Mar 2014 09:42:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1FADB18A-D3F1-4EA6-A1E4-9EDE8F6BE4CA@nic.cz> References: <532FDF7B.8060703@mg-soft.com> To: Jernej Tuljak X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Lvfe0vlNycmSti-JXQuBM_a_1O8 Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 issue: YIN -> YANG translation breaks text formatting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 08:42:58 -0000 On 24 Mar 2014, at 08:32, Jernej Tuljak = wrote: > Dne 23.3.2014 18:36, pi=9Ae Ladislav Lhotka: >> * YIN -> YANG translation breaks text formatting >>=20 >> ** Description >>=20 >> When using YIN as the source format with the prospect of transforming = it to YANG (e.g. for publishing in an RFC), it is often impossible to = get longer text (in 'description' etc.) properly indented and formatted, = especially if the text consists of multiple paragraphs and/or contains = itemized lists or other structures. >>=20 >> Further details and example use cases can be found = [[https://gitlab.labs.nic.cz/labs/yang-tools/wikis/editing_yang][here]]. >=20 > This is due to the fact that YANG is capable of carrying more meta = information than YIN (like comments between concatenated quoted strings, = and string concatenation itself). But I think that's okay and don't see = it as a problem. >=20 > I find it quite strange that you use YIN as the format in which you = write YANG code. I understand why (read the link you provided), but = still...I don't think YIN was ever meant for that purpose. You will = never be=20 Strange? I am an Emacs user, and schema-supported editing = (auto-completion, on-the-fly validation etc.) provided by its nXML mode = gives me far more comfort compared to the yang mode. Of course, the = pre-requisite is that the pointy XML stuff doesn=92t make me feel sick. = :-) > able to write YIN with the same "precision" as YANG. I don=92t agree. Why not? >=20 > Note that you could probably avoid most formatting issues if you = abandon the idea of pretty printing your YIN text values, since all = whitespace within them should be considered as significant. A simpler = solution than mixed content. This is how I started and, believe me, it was a pain. The indentation in = YIN source is generally different from YANG and every change in the = module structure or moving definitions around required manual = adjustments of descriptions. So I am now using limited HTML-like markup = in YIN, and I wrote an XSLT stylesheet for YIN->YANG translation that = supports this markup (and also preserves most comments). It works like = charm, the translation is now fully reliable, and I have been using it = for preparation of my I-Ds in the past couple of years. Another use case for this extension would be multi-lingual descriptions = that are quite easy to implement using XML markup and off-the-shelf = tools. A specialized translator can then generate the YANG module with = descriptions in a selected language. I am not saying it is a critical feature, and I can certainly live = without it. On the other hand, solid XML parsers should be able to deal = with it quite easily. Lada >=20 > Jernej >=20 >>=20 >> ** Solution >>=20 >> IN YIN, permit mixed content inside the element that is a = child of 'contact', 'description', 'organization' and 'reference' = statements. That is, the contents of may contain text nodes as = well as XML elements from foreign namespaces (any namespace other than = the YIN namespace, current module namespace and namespaces of all = imported modules). >>=20 >> The default YIN->YANG translation of such a mixed content is similar = to XSLT: ignore all XML elements and concatenate the text nodes. = However, translators can make use of these elements. >>=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 From nobody Mon Mar 24 02:13:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54751A0170 for ; Mon, 24 Mar 2014 02:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.339 X-Spam-Level: X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jotJIetw_SLQ for ; Mon, 24 Mar 2014 02:13:26 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5B13B1A016B for ; Mon, 24 Mar 2014 02:13:26 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6B1A310E0; Mon, 24 Mar 2014 10:13:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 8oKU4xreistq; Mon, 24 Mar 2014 10:13:24 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 24 Mar 2014 10:13:24 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2CF92002F; Mon, 24 Mar 2014 10:13:24 +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 zZB3rsvzx2hk; Mon, 24 Mar 2014 10:13:24 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 02E1A2002C; Mon, 24 Mar 2014 10:13:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 070BF2C0B364; Mon, 24 Mar 2014 10:13:21 +0100 (CET) Date: Mon, 24 Mar 2014 10:13:21 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140324091321.GA44796@elstar.local> Mail-Followup-To: Ladislav Lhotka , Jernej Tuljak , netmod@ietf.org References: <532FDF7B.8060703@mg-soft.com> <1FADB18A-D3F1-4EA6-A1E4-9EDE8F6BE4CA@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1FADB18A-D3F1-4EA6-A1E4-9EDE8F6BE4CA@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rrlcN4rIdqOBwFbsaRmfuRDgu5w Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 issue: YIN -> YANG translation breaks text formatting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 24 Mar 2014 09:13:27 -0000 On Mon, Mar 24, 2014 at 09:42:51AM +0100, Ladislav Lhotka wrote: > > I am not saying it is a critical feature, and I can certainly live without it. On the other hand, solid XML parsers should be able to deal with it quite easily. > Lada, can this perhaps be done by an extension of the YIN format or does it have to be part of YANG 1.1? Or should YIN perhaps become a separate document and moved out of YANG 1.1? I am just asking questions to explore the possible solution space. /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 Mar 24 03:05:36 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D151A0190 for ; Mon, 24 Mar 2014 03:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jt2HBR-mMP6z for ; Mon, 24 Mar 2014 03:05:29 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C38591A018F for ; Mon, 24 Mar 2014 03:05:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 0217A54035E for ; Mon, 24 Mar 2014 11:05:27 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbTmiQ19Uzf4 for ; Mon, 24 Mar 2014 11:05:23 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 87BF05400E0 for ; Mon, 24 Mar 2014 11:05:23 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Mon, 24 Mar 2014 11:05:22 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/HHDn99M3sb6ixGZTebf_8gYcrJg Subject: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 10:05:31 -0000 Hi, I think the solution Y18-01 is just hand-waving that raises other questions: If the context node is tentatively added to the instance document, then with what content? Are mandatory descendants supposed to be added as well, do contained defaults apply? This can lead to nasty race conditions, for example: leaf foo { when "../bar/baz" = 42"; type uint8; } container bar { when "not(../foo = 1)"; leaf baz { type uint8; default 42; } } Then, is the data tree fragment 1 valid or not? The thing is, XPath evaluation needs a fixed XML document that has to be properly defined (as it is done, e.g., for "must"). Without it, standard XPath tools will never work. My example also shows that it is not sufficient to forbid "when" expressions to refer to nodes below the context node - similar pathological situations can arise if two nodes or subtrees refer to each other in their "when" expressions. Here is an alternative solution: ==== ** Solution Y18-02 For validation purposes, treat when ""; as equivalent to must " or not(.)"; This is essentially how RFC 6110 translates "when" to Schematron, because there is no other possibility. What this means is that "when" expressions would not apply in any way if the context node is missing (after all defaults "in use" have been added). ==== Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 24 03:08:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8931A0192 for ; Mon, 24 Mar 2014 03:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1-v-hPCJZD0 for ; Mon, 24 Mar 2014 03:08:24 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 86C9A1A0194 for ; Mon, 24 Mar 2014 03:08:24 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 4E71437C30E; Mon, 24 Mar 2014 11:08:23 +0100 (CET) Date: Mon, 24 Mar 2014 11:08:23 +0100 (CET) Message-Id: <20140324.110823.696141374614674300.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xmhB-upMMsO633NP7SbvPaAofJg Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 issue: YIN -> YANG translation breaks text formatting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 10:08:27 -0000 Hi, I have added this to the issues list as Y24, status NEW. I agree with Andy and Jernej that this should not be done. I have two concerns: 1. The translation is not losslee. 2. Unless we specify which XML elements are allowed, and their meaning, their usage will be implementation specific. Translation from YIN to YANG would no longer produce the same result by different implementations. /martin Ladislav Lhotka wrote: > * YIN -> YANG translation breaks text formatting > > ** Description > > When using YIN as the source format with the prospect of transforming > it to YANG (e.g. for publishing in an RFC), it is often impossible to > get longer text (in 'description' etc.) properly indented and > formatted, especially if the text consists of multiple paragraphs > and/or contains itemized lists or other structures. > > Further details and example use cases can be found > [[https://gitlab.labs.nic.cz/labs/yang-tools/wikis/editing_yang][here]]. > > ** Solution > > IN YIN, permit mixed content inside the element that is a child > of 'contact', 'description', 'organization' and 'reference' > statements. That is, the contents of may contain text nodes as > well as XML elements from foreign namespaces (any namespace other than > the YIN namespace, current module namespace and namespaces of all > imported modules). > > The default YIN->YANG translation of such a mixed content is similar > to XSLT: ignore all XML elements and concatenate the text > nodes. However, translators can make use of these elements. > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Mon Mar 24 03:09:57 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57261A0192 for ; Mon, 24 Mar 2014 03:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTD7k8hLaWuQ for ; Mon, 24 Mar 2014 03:09:51 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id C8A091A0197 for ; Mon, 24 Mar 2014 03:09:46 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id s2OA9jNZ009386; Mon, 24 Mar 2014 11:09:45 +0100 Message-ID: <53300468.2040803@mg-soft.com> Date: Mon, 24 Mar 2014 11:09:44 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ladislav Lhotka References: <532FDF7B.8060703@mg-soft.com> <1FADB18A-D3F1-4EA6-A1E4-9EDE8F6BE4CA@nic.cz> In-Reply-To: <1FADB18A-D3F1-4EA6-A1E4-9EDE8F6BE4CA@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cd0OH_4YW1z8zqYFKXV9aqERvDk Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 issue: YIN -> YANG translation breaks text formatting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 10:09:54 -0000 Dne 24.3.2014 9:42, piše Ladislav Lhotka: > On 24 Mar 2014, at 08:32, Jernej Tuljak wrote: > >> Dne 23.3.2014 18:36, piše Ladislav Lhotka: >>> * YIN -> YANG translation breaks text formatting >>> >>> ** Description >>> >>> When using YIN as the source format with the prospect of transforming it to YANG (e.g. for publishing in an RFC), it is often impossible to get longer text (in 'description' etc.) properly indented and formatted, especially if the text consists of multiple paragraphs and/or contains itemized lists or other structures. >>> >>> Further details and example use cases can be found [[https://gitlab.labs.nic.cz/labs/yang-tools/wikis/editing_yang][here]]. >> This is due to the fact that YANG is capable of carrying more meta information than YIN (like comments between concatenated quoted strings, and string concatenation itself). But I think that's okay and don't see it as a problem. >> >> I find it quite strange that you use YIN as the format in which you write YANG code. I understand why (read the link you provided), but still...I don't think YIN was ever meant for that purpose. You will never be > Strange? I am an Emacs user, and schema-supported editing (auto-completion, on-the-fly validation etc.) provided by its nXML mode gives me far more comfort compared to the yang mode. Of course, the pre-requisite is that the pointy XML stuff doesn’t make me feel sick. :-) I agree it's a personal preference, but a major selling point of YANG is supposedly human readability. XML or any other form of markup can be hard to read by humans. And it's definitely harder to edit, IMO. >> able to write YIN with the same "precision" as YANG. > I don’t agree. Why not? Try to express the following with YIN. I'm an annoying tool user and the type of last comment is significant to me (I'd like the last comment to be an EOL comment instead of a multi-line comment when YANG gets generated from your YIN). The whitespace around them comments is also significant as is the position of the concatenation. description /* comment after keyword */ "A mess" + /* inline comment */ " of a description." /* after argument */ ; // trailing single line comment This is an example of a valid YANG statement with very specific formatting. I don't know why anyone would write YANG like this, but you could if you wanted to. Hence "precision". Like I said. The level of meta information between the two formats is different. > >> Note that you could probably avoid most formatting issues if you abandon the idea of pretty printing your YIN text values, since all whitespace within them should be considered as significant. A simpler solution than mixed content. > This is how I started and, believe me, it was a pain. The indentation in YIN source is generally different from YANG and every change in the module structure or moving definitions around required manual adjustments of descriptions. Why? Descriptions are in element values. If these are not pretty printed, they can be moved around without losing formatting. Or am I missing something? I agree that it must look like a mess though. > So I am now using limited HTML-like markup in YIN, and I wrote an XSLT stylesheet for YIN->YANG translation that supports this markup (and also preserves most comments). It works like charm, the translation is now fully reliable, and I have been using it for preparation of my I-Ds in the past couple of years. > > Another use case for this extension would be multi-lingual descriptions that are quite easy to implement using XML markup and off-the-shelf tools. A specialized translator can then generate the YANG module with descriptions in a selected language. > > I am not saying it is a critical feature, and I can certainly live without it. On the other hand, solid XML parsers should be able to deal with it quite easily. Would your proposal also affect YANG-->YIN conversion? Jernej > > Lada > >> Jernej >> >>> ** Solution >>> >>> IN YIN, permit mixed content inside the element that is a child of 'contact', 'description', 'organization' and 'reference' statements. That is, the contents of may contain text nodes as well as XML elements from foreign namespaces (any namespace other than the YIN namespace, current module namespace and namespaces of all imported modules). >>> >>> The default YIN->YANG translation of such a mixed content is similar to XSLT: ignore all XML elements and concatenate the text nodes. However, translators can make use of these elements. >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Mon Mar 24 03:15:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C7E1A019A for ; Mon, 24 Mar 2014 03:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cguz2LaWKgdz for ; Mon, 24 Mar 2014 03:15:44 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id AD8761A0197 for ; Mon, 24 Mar 2014 03:15:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 8E13A54035E; Mon, 24 Mar 2014 11:15:43 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvyPIsLSQkTI; Mon, 24 Mar 2014 11:15:39 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id E7AC05400E0; Mon, 24 Mar 2014 11:15:38 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20140324091321.GA44796@elstar.local> References: <532FDF7B.8060703@mg-soft.com> <1FADB18A-D3F1-4EA6-A1E4-9EDE8F6BE4CA@nic.cz> <20140324091321.GA44796@elstar.local> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Mon, 24 Mar 2014 11:15:38 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9t_aA7WeN8SoKb-kQ5hIlWa8_Ao Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 issue: YIN -> YANG translation breaks text formatting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 10:15:46 -0000 Juergen Schoenwaelder writes: > On Mon, Mar 24, 2014 at 09:42:51AM +0100, Ladislav Lhotka wrote: >> >> I am not saying it is a critical feature, and I can certainly live without it. On the other hand, solid XML parsers should be able to deal with it quite easily. >> > > Lada, > > can this perhaps be done by an extension of the YIN format or does it > have to be part of YANG 1.1? Or should YIN perhaps become a separate > document and moved out of YANG 1.1? I am just asking questions to > explore the possible solution space. As long as it is a non-standard extension, YANG compilers reject such modules. I don't know how to make it possible unless YIN spec says it is allowed. Lada > > /js > > -- > 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 Mar 24 03:18:04 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227841A019A for ; Mon, 24 Mar 2014 03:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWSqQXFbx_8u for ; Mon, 24 Mar 2014 03:17:59 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 248E11A0190 for ; Mon, 24 Mar 2014 03:17:59 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1891337C30E; Mon, 24 Mar 2014 11:17:58 +0100 (CET) Date: Mon, 24 Mar 2014 11:17:57 +0100 (CET) Message-Id: <20140324.111757.1429730801819634445.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2_iXjySG9NUi_pt5FO4WerKXDaQ Cc: netmod@ietf.org Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 10:18:01 -0000 Ladislav Lhotka wrote: > Hi, > > I think the solution Y18-01 is just hand-waving that raises other > questions: If the context node is tentatively added to the instance > document, then with what content? Are mandatory descendants supposed > to be added as well, do contained defaults apply? Y18-01 says: This node has no value and no children. It is only added in order to have a context node. > This can lead to nasty race conditions, for example: > > leaf foo { > when "../bar/baz" = 42"; > type uint8; > } > container bar { > when "not(../foo = 1)"; > leaf baz { > type uint8; > default 42; > } > } > > Then, is the data tree fragment > > 1 > > valid or not? > > The thing is, XPath evaluation needs a fixed XML document that has to > be properly defined (as it is done, e.g., for "must"). Without it, > standard XPath tools will never work. > > My example also shows that it is not sufficient to forbid "when" > expressions to refer to nodes below the context node - similar > pathological situations can arise if two nodes or subtrees refer to > each other in their "when" expressions. > > Here is an alternative solution: > > ==== > > ** Solution Y18-02 > > For validation purposes, treat > > when ""; > > as equivalent to > > must " or not(.)"; But must expressions are only evaluated if the node exists, so "not(.)" will always evaluate to false. This means that there would be no difference between must and when. > This is essentially how RFC 6110 translates "when" to Schematron, > because there is no other possibility. > > What this means is that "when" expressions would not apply in any way > if the context node is missing (after all defaults "in use" have been > added). This is not the intention of when! Your example above is a good use case of when: container foo { when ../enabled; leaf bar { mandatory true; ... } } /martin From nobody Mon Mar 24 03:43:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A742B1A01A9 for ; Mon, 24 Mar 2014 03:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32RXrgTRPPhl for ; Mon, 24 Mar 2014 03:43:07 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id AFBDA1A0195 for ; Mon, 24 Mar 2014 03:43:07 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id B8891140075; Mon, 24 Mar 2014 11:43:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395657783; bh=xVKlCAGoGf930RZoAAN2CDHj9NH0RKJh1TyA5ITI+2c=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=MJflgI8eEdmUuPehu1bsH0mUPrU6hzMeIRr+et5OmWVBKOcswMPwNWa/RZaO6A+3c 7fPH+Ycd6hDkCUQpDJ5nuBxbEtVNjEgIC4VGqLowlysNIEB1R1sQE4htuVJkxv251J jz2oiutdakiGdxCjaDJ8hZwbwhy+WyOqp6nROi7Q= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140324.110823.696141374614674300.mbj@tail-f.com> Date: Mon, 24 Mar 2014 11:43:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <07F2F7F5-D29C-4A73-AA30-56886CD3FD13@nic.cz> References: <20140324.110823.696141374614674300.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rMKqRLj-SooriIwjVEUlimCiyfk Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 issue: YIN -> YANG translation breaks text formatting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 10:43:09 -0000 On 24 Mar 2014, at 11:08, Martin Bjorklund wrote: > Hi, >=20 > I have added this to the issues list as Y24, status NEW. >=20 > I agree with Andy and Jernej that this should not be done. I have two > concerns: >=20 > 1. The translation is not losslee. The current translation is not lossless either. >=20 > 2. Unless we specify which XML elements are allowed, and their > meaning, their usage will be implementation specific. But at least YANG compilers won=92t reject it. > Translation from YIN to YANG would no longer produce the same > result by different implementations. Yes, even one implementation may be instructed to produce different = results (plain text, reStructuredText, markdown). I assume that the standard version of any module will always be the one = that is published, e.g. in an RFC (in YANG syntax). This YIN extension = is only intended as an aid for presentation purposes, or for certain = freaks that want to write modules in YIN. Lada >=20 >=20 > /martin >=20 >=20 >=20 > Ladislav Lhotka wrote: >> * YIN -> YANG translation breaks text formatting >>=20 >> ** Description >>=20 >> When using YIN as the source format with the prospect of transforming >> it to YANG (e.g. for publishing in an RFC), it is often impossible to >> get longer text (in 'description' etc.) properly indented and >> formatted, especially if the text consists of multiple paragraphs >> and/or contains itemized lists or other structures. >>=20 >> Further details and example use cases can be found >> = [[https://gitlab.labs.nic.cz/labs/yang-tools/wikis/editing_yang][here]]. >>=20 >> ** Solution >>=20 >> IN YIN, permit mixed content inside the element that is a = child >> of 'contact', 'description', 'organization' and 'reference' >> statements. That is, the contents of may contain text nodes as >> well as XML elements from foreign namespaces (any namespace other = than >> the YIN namespace, current module namespace and namespaces of all >> imported modules). >>=20 >> The default YIN->YANG translation of such a mixed content is similar >> to XSLT: ignore all XML elements and concatenate the text >> nodes. However, translators can make use of these elements. >>=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 From nobody Mon Mar 24 04:13:19 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85421A01CB for ; Mon, 24 Mar 2014 04:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9VnwxrEF3fG for ; Mon, 24 Mar 2014 04:13:16 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8CD1A0195 for ; Mon, 24 Mar 2014 04:13:15 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 571AE4775CB; Mon, 24 Mar 2014 12:13:14 +0100 (CET) Date: Mon, 24 Mar 2014 12:13:14 +0100 (CET) Message-Id: <20140324.121314.583331316038403460.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/UiTbw4vzbYgTh1v8Wi5EARCfRqo Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 issue: make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 11:13:18 -0000 Added as Y25. /martin Ladislav Lhotka wrote: > * make enum numbering purely informative and optional > > ** Description > > In an enumeration type, each enum has an integer value assigned to it, > either using the 'value' statement or via an automatic numbering > procedure. From the NETCONF/RESTCONF protocol point of view, these > values are irrelevant because they never appear on the wire. RFC 6020 > also says in > [[http://tools.ietf.org/html/rfc6020#section-9.6.4.2][Sec. 9.6.4.2]]: > "The value is unused by YANG and the XML encoding, but is carried as a > convenience to implementors." > > However, RFC 6020 states in > [[http://tools.ietf.org/html/rfc6020#section-10][Sec. 10]]: > > o An "enumeration" type may have new enums added, provided the old > enums's values do not change. > > This rule makes updates of enumerations difficult and/or forces the > data modeller to assign the values explicitly even if they have no > meaning otherwise. The rule also contradicts the statement in > Sec. 9.6.4.2 because the value in fact *is* used by YANG. > > ** Solution > > Remove the auto-numbering procedure and the cited rule from > Sec. 10. Numeric values can be assigned where they have some meaning > outside NETCONF (e.g. protocols with port numbers), but they are > indeed only informative. > > -- > Ladislav Lhotka, CZ.NIC Labs From nobody Mon Mar 24 04:17:18 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DA01A01CB for ; Mon, 24 Mar 2014 04:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pxfv4o6XFsNr for ; Mon, 24 Mar 2014 04:17:16 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 225BA1A01C8 for ; Mon, 24 Mar 2014 04:17:16 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1356439408C; Mon, 24 Mar 2014 12:17:15 +0100 (CET) Date: Mon, 24 Mar 2014 12:17:14 +0100 (CET) Message-Id: <20140324.121714.1861441403913411305.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/3x8mtHBPt6ZoWxRNXxMy3xJ0oVI Cc: netmod@ietf.org Subject: [netmod] Y25: make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 11:17:17 -0000 Hi, We had a discussion about this on the ML, leading up to errata 3871, which clarifies the procedure. Which problem do we solve by removing this? Why isn't the clarification of the procedure good enough? /martin From nobody Mon Mar 24 05:28:16 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97271A01F1 for ; Mon, 24 Mar 2014 05:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1Co2CDHApFj for ; Mon, 24 Mar 2014 05:28:13 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 787851A01EA for ; Mon, 24 Mar 2014 05:28:13 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 3283D140156; Mon, 24 Mar 2014 13:28:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395664091; bh=+L/gFmRzyWJPjD94eTkPfRaur8It69rAnUWybOL/xio=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=WuuwsKnjOJ16BHW1YR6pqLDcyxs+t7fVSrRiva2hEp1KQxhQpYMWyckBQXePJwF6R CxocbViQ0++rQPeGkVv7wNIPt66QHp9PKQBM0ARz0Dq5giAnw1qhCsl2bbXgucnVf3 vWz7VZrYGewNbOF2oc/GbFB3alfwIOyHagnx93eU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140324.121714.1861441403913411305.mbj@tail-f.com> Date: Mon, 24 Mar 2014 13:28:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <40F4939D-C150-4585-938D-4E030E742B77@nic.cz> References: <20140324.121714.1861441403913411305.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5NkN_tOyofXYzOL96la_J5ofk7c Cc: netmod@ietf.org Subject: Re: [netmod] Y25: make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 12:28:15 -0000 On 24 Mar 2014, at 12:17, Martin Bjorklund wrote: > Hi, >=20 > We had a discussion about this on the ML, leading up to errata 3871, > which clarifies the procedure. >=20 > Which problem do we solve by removing this? Why isn't the > clarification of the procedure good enough? I think I explained it in the description: - Enumerations that don=92t have explicit =93value=94 statements are = difficult to update, except for appending new enums at the end. - Putting =93value=94 statements everywhere is a nuisance for both = writers and readers, especially with long enumerations. - Sec. 9.6.4.2 states the values are unused by YANG, which is not true. - =46rom the interoperability point of view, the values are irrelevant, = so it is no clear what problem is solved by having the rule in Sec. 10. - Removing the auto-numbering procedure simplifies the YANG spec (tiny = bit, but still=85) Lada=20 =20 >=20 >=20 > /martin >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 24 05:47:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F68E1A0203 for ; Mon, 24 Mar 2014 05:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPUC_n9S-UNJ for ; Mon, 24 Mar 2014 05:47:39 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 866BA1A01EA for ; Mon, 24 Mar 2014 05:47:39 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id CFD93140075; Mon, 24 Mar 2014 13:47:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395665256; bh=Xpy8tR7QsoAuzeAeqhmXLjlwwFhnvQ4G8vvejpHLyd8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Qdl6V7/XuNfw+qfUIrL1ak9tcvJmdeYpAODmu8b7a3cIBYuH+LkBFsTHgjgaFKk30 bE30MvFReg4Ixa0usQvtDlEsHjBgZDEW0AMcsffBTNqZPWvvsU31/VCPraPAjcUnK0 +UuXtsvD958PTrnrxrTWMmvydppvkCthC8QgFGBg= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <53300468.2040803@mg-soft.com> Date: Mon, 24 Mar 2014 13:47:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <16006AB9-BBA1-4E3D-8A14-E206D85CCB30@nic.cz> References: <532FDF7B.8060703@mg-soft.com> <1FADB18A-D3F1-4EA6-A1E4-9EDE8F6BE4CA@nic.cz> <53300468.2040803@mg-soft.com> To: Jernej Tuljak X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jmd7vLoeBK1LQJ-_ZYaoxEo122E Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 issue: YIN -> YANG translation breaks text formatting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 12:47:41 -0000 On 24 Mar 2014, at 11:09, Jernej Tuljak = wrote: > Dne 24.3.2014 9:42, pi=9Ae Ladislav Lhotka: >> On 24 Mar 2014, at 08:32, Jernej Tuljak = wrote: >>=20 >>> Dne 23.3.2014 18:36, pi=9Ae Ladislav Lhotka: >>>> * YIN -> YANG translation breaks text formatting >>>>=20 >>>> ** Description >>>>=20 >>>> When using YIN as the source format with the prospect of = transforming it to YANG (e.g. for publishing in an RFC), it is often = impossible to get longer text (in 'description' etc.) properly indented = and formatted, especially if the text consists of multiple paragraphs = and/or contains itemized lists or other structures. >>>>=20 >>>> Further details and example use cases can be found = [[https://gitlab.labs.nic.cz/labs/yang-tools/wikis/editing_yang][here]]. >>> This is due to the fact that YANG is capable of carrying more meta = information than YIN (like comments between concatenated quoted strings, = and string concatenation itself). But I think that's okay and don't see = it as a problem. >>>=20 >>> I find it quite strange that you use YIN as the format in which you = write YANG code. I understand why (read the link you provided), but = still...I don't think YIN was ever meant for that purpose. You will = never be >> Strange? I am an Emacs user, and schema-supported editing = (auto-completion, on-the-fly validation etc.) provided by its nXML mode = gives me far more comfort compared to the yang mode. Of course, the = pre-requisite is that the pointy XML stuff doesn=92t make me feel sick. = :-) >=20 > I agree it's a personal preference, but a major selling point of YANG = is supposedly human readability. XML or any other form of markup can be = hard to read by humans. And it's definitely harder to edit, IMO. That=92s why I always translate YIN to YANG before publishing a module. = Yes, all things being equal, YIN is harder to edit than YANG but, as I = wrote, nXML is superior to yang mode, so unless somebody adds = auto-completion, validation etc. to the yang mode, I will probably stick = to nXML.=20 >=20 >>> able to write YIN with the same "precision" as YANG. >> I don=92t agree. Why not? >=20 > Try to express the following with YIN. I'm an annoying tool user and = the type of last comment is significant to me (I'd like the last comment = to be an EOL comment instead of a multi-line comment when YANG gets = generated from your YIN). The whitespace around them comments is also = significant as is the position of the concatenation. >=20 > description /* comment after keyword */ "A mess" + /* inline comment = */ " of a description." /* after argument */ ; // trailing single line = comment >=20 > This is an example of a valid YANG statement with very specific = formatting. I don't know why anyone would write YANG like this, but you = could if you wanted to. Hence "precision=94. Comments do not carry any info relevant for the data model, and they can = be handled in most real-life cases. >=20 > Like I said. The level of meta information between the two formats is = different. >=20 >>=20 >>> Note that you could probably avoid most formatting issues if you = abandon the idea of pretty printing your YIN text values, since all = whitespace within them should be considered as significant. A simpler = solution than mixed content. >> This is how I started and, believe me, it was a pain. The indentation = in YIN source is generally different from YANG and every change in the = module structure or moving definitions around required manual = adjustments of descriptions. >=20 > Why? Descriptions are in element values. If these are not pretty = printed, they can be moved around without losing formatting. Or am I = missing something? I agree that it must look like a mess though. If I want to publish a module in the YANG form, then the descriptions, = references etc. have to be pretty-printed, and it is difficult to format = them automatically if there is no markup. >=20 >> So I am now using limited HTML-like markup in YIN, and I wrote an = XSLT stylesheet for YIN->YANG translation that supports this markup (and = also preserves most comments). It works like charm, the translation is = now fully reliable, and I have been using it for preparation of my I-Ds = in the past couple of years. >>=20 >> Another use case for this extension would be multi-lingual = descriptions that are quite easy to implement using XML markup and = off-the-shelf tools. A specialized translator can then generate the YANG = module with descriptions in a selected language. >>=20 >> I am not saying it is a critical feature, and I can certainly live = without it. On the other hand, solid XML parsers should be able to deal = with it quite easily. >=20 > Would your proposal also affect YANG-->YIN conversion? No, unless somebody wants to use some kind of markup in YANG syntax, = too. Lada >=20 > Jernej >=20 >>=20 >> Lada >>=20 >>> Jernej >>>=20 >>>> ** Solution >>>>=20 >>>> IN YIN, permit mixed content inside the element that is a = child of 'contact', 'description', 'organization' and 'reference' = statements. That is, the contents of may contain text nodes as = well as XML elements from foreign namespaces (any namespace other than = the YIN namespace, current module namespace and namespaces of all = imported modules). >>>>=20 >>>> The default YIN->YANG translation of such a mixed content is = similar to XSLT: ignore all XML elements and concatenate the text nodes. = However, translators can make use of these elements. >>>>=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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 24 06:13:39 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCBE31A01AE for ; Mon, 24 Mar 2014 06:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.339 X-Spam-Level: X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0vTrlEeIASW for ; Mon, 24 Mar 2014 06:13:34 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 744471A0245 for ; Mon, 24 Mar 2014 06:10:32 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 34868F85; Mon, 24 Mar 2014 14:10:31 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Cak5lt9W5-5t; Mon, 24 Mar 2014 14:10:30 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 24 Mar 2014 14:10:30 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 99A5E2002F; Mon, 24 Mar 2014 14:10: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 S_GL_IwJ9rJm; Mon, 24 Mar 2014 14:10:30 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE11E2002C; Mon, 24 Mar 2014 14:10:29 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D0CD32C0BE34; Mon, 24 Mar 2014 14:10:27 +0100 (CET) Date: Mon, 24 Mar 2014 14:10:27 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140324131027.GA45208@elstar.local> Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org References: <20140324.121714.1861441403913411305.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140324.121714.1861441403913411305.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-X_v-tbJUpZNVWZYKZfNfoS8bO8 Cc: netmod@ietf.org Subject: Re: [netmod] Y25: make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 24 Mar 2014 13:13:37 -0000 On Mon, Mar 24, 2014 at 12:17:14PM +0100, Martin Bjorklund wrote: > Hi, > > We had a discussion about this on the ML, leading up to errata 3871, > which clarifies the procedure. > > Which problem do we solve by removing this? Why isn't the > clarification of the procedure good enough? > As technical contributor, I tend to agree with Lada that this auto-numbering feature serves no clear value and has caused problems. I would not mind getting rid of it in 1.1. /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 Mar 24 06:19:52 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23D21A01B4 for ; Mon, 24 Mar 2014 06:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4bPSrrMl8zI for ; Mon, 24 Mar 2014 06:19:44 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5121A01AE for ; Mon, 24 Mar 2014 06:19:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 36E69FA6; Mon, 24 Mar 2014 14:19:43 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id oMqLDrwuv_b4; Mon, 24 Mar 2014 14:19:42 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 24 Mar 2014 14:19:42 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AA30A20035; Mon, 24 Mar 2014 14:19:42 +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 IzkWK-hJ7AoO; Mon, 24 Mar 2014 14:19:42 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DFD9920033; Mon, 24 Mar 2014 14:19:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F222F2C0C026; Mon, 24 Mar 2014 14:19:40 +0100 (CET) Date: Mon, 24 Mar 2014 14:19:40 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140324131940.GA45438@elstar.local> Mail-Followup-To: Ladislav Lhotka , Jernej Tuljak , netmod@ietf.org References: <532FDF7B.8060703@mg-soft.com> <1FADB18A-D3F1-4EA6-A1E4-9EDE8F6BE4CA@nic.cz> <20140324091321.GA44796@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/lGghPsLAPXMpbKU5EDGyyB0g9bM Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 issue: YIN -> YANG translation breaks text formatting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 24 Mar 2014 13:19:48 -0000 On Mon, Mar 24, 2014 at 11:15:38AM +0100, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > On Mon, Mar 24, 2014 at 09:42:51AM +0100, Ladislav Lhotka wrote: > >> > >> I am not saying it is a critical feature, and I can certainly live without it. On the other hand, solid XML parsers should be able to deal with it quite easily. > >> > > > > Lada, > > > > can this perhaps be done by an extension of the YIN format or does it > > have to be part of YANG 1.1? Or should YIN perhaps become a separate > > document and moved out of YANG 1.1? I am just asking questions to > > explore the possible solution space. > > As long as it is a non-standard extension, YANG compilers reject such modules. I don't know how to make it possible unless YIN spec says it is allowed. > I am confused - a YANG compiler parses YANG not YIN. Or is the assumption here that a YANG compiler also has to accept YIN? /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 Mar 24 06:30:50 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D271A01F6 for ; Mon, 24 Mar 2014 06:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oRmrQDIaucs for ; Mon, 24 Mar 2014 06:30:47 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6B86E1A01AE for ; Mon, 24 Mar 2014 06:30:47 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id DFF1E140075; Mon, 24 Mar 2014 14:30:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395667832; bh=3JeOM0FKmal2PLJQ1eMAla4nAGIPxBAc7cCKCahg44o=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=U+DZ4B5uFXmGP+danF8hbuWM5eUV3Q2F2jH8y8MQsTLdF5WZqAGqDWCBVd8Gwn56x lvS7xzpa17XUoHCG1oWkASiDFZ2Y/N5h9t8PSNB2woEL2/tcP+JskNX8srzWgzuEHf 6eWh9rFrWKpGzpdrkfU6gxMYTlJIjgq4W61O/kGc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140324131940.GA45438@elstar.local> Date: Mon, 24 Mar 2014 14:30:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <47833A6F-E5EE-457A-97C6-09F38A5056F0@nic.cz> References: <532FDF7B.8060703@mg-soft.com> <1FADB18A-D3F1-4EA6-A1E4-9EDE8F6BE4CA@nic.cz> <20140324091321.GA44796@elstar.local> <20140324131940.GA45438@elstar.local> To: =?iso-8859-1?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/NT0Z-hm8iAkS_kWp47u-wSRvJEU Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 issue: YIN -> YANG translation breaks text formatting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 13:30:49 -0000 On 24 Mar 2014, at 14:19, Juergen Schoenwaelder = wrote: > On Mon, Mar 24, 2014 at 11:15:38AM +0100, Ladislav Lhotka wrote: >> Juergen Schoenwaelder writes: >>=20 >>> On Mon, Mar 24, 2014 at 09:42:51AM +0100, Ladislav Lhotka wrote: >>>>=20 >>>> I am not saying it is a critical feature, and I can certainly live = without it. On the other hand, solid XML parsers should be able to deal = with it quite easily. >>>>=20 >>>=20 >>> Lada, >>>=20 >>> can this perhaps be done by an extension of the YIN format or does = it >>> have to be part of YANG 1.1? Or should YIN perhaps become a separate >>> document and moved out of YANG 1.1? I am just asking questions to >>> explore the possible solution space. >>=20 >> As long as it is a non-standard extension, YANG compilers reject such = modules. I don't know how to make it possible unless YIN spec says it is = allowed. >>=20 >=20 > I am confused - a YANG compiler parses YANG not YIN. Or is the > assumption here that a YANG compiler also has to accept YIN? =46rom the text in Sec. 11, it is unclear whether the YIN syntax is = mandatory to implement. At any rate, this would be relevant only to = those that do implement YIN. 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 24 07:14:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46631A0247 for ; Mon, 24 Mar 2014 07:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkAk7PYOs0pI for ; Mon, 24 Mar 2014 07:14:01 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id AF3A41A023F for ; Mon, 24 Mar 2014 07:14:01 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 8F92637C311; Mon, 24 Mar 2014 15:14:00 +0100 (CET) Date: Mon, 24 Mar 2014 15:14:00 +0100 (CET) Message-Id: <20140324.151400.143715794437617571.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140324131027.GA45208@elstar.local> References: <20140324.121714.1861441403913411305.mbj@tail-f.com> <20140324131027.GA45208@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/aNaBRtgn3S9Z0RThmzm5G-eaY00 Cc: netmod@ietf.org Subject: Re: [netmod] Y25: make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 14:14:03 -0000 Juergen Schoenwaelder wrote: > On Mon, Mar 24, 2014 at 12:17:14PM +0100, Martin Bjorklund wrote: > > Hi, > > > > We had a discussion about this on the ML, leading up to errata 3871, > > which clarifies the procedure. > > > > Which problem do we solve by removing this? Why isn't the > > clarification of the procedure good enough? > > > > As technical contributor, I tend to agree with Lada that this > auto-numbering feature serves no clear value and has caused > problems. I would not mind getting rid of it in 1.1. I think this would be problematic. It is there in 1.0 for implementations to use, and implementations use it. Yes, it may put some additional burden on the module writer if a module is updated, but I think we can live with that. Also note that the "bits" type ("position" statement) behaves in a similar way. /martin From nobody Mon Mar 24 07:37:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EB91A01FE for ; Mon, 24 Mar 2014 07:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gb6WqY3Wtgc0 for ; Mon, 24 Mar 2014 07:37:38 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id 85F341A01D5 for ; Mon, 24 Mar 2014 07:37:38 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id w8so5298555qac.26 for ; Mon, 24 Mar 2014 07:37:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zX37T2KBnW0PH+7VpT27vI4evN/3TTZOLO42GJ0WAEs=; b=FfXWGze+V3v9cGAufT2iS72br+A5y95+lCe1/E0PZm8rD4608NToqlt4r5k0VPRtbJ AuYE7WqZpvUpUtSoM7Dob3g0uyXR8rzpuuHOrORwqComGkNEXvzwcJJuTQ4qJJtZjf/c RMi+BYoTunutRdI5Peu1G0auu0xv9KZ8TKGsYo3/J1f4yYnlsusAr/Po8LAe4k1qh66I UQtWAhiz9I/dr5BjBo1WS+UEZgHtUmOP5AydDMqc5TzAtvfzGpCkSR3Mw+r8AUm1/YL6 6hoxnciHZ9f6FDZfuzIiMGEyph1Xc9DedNoHdBVego9ttzcoGwQw4VZImXQLXlyfo0yR NAzQ== X-Gm-Message-State: ALoCoQnQh/W9+IEoZigyhDEQs/b1O8Hqwa0aiIPeqM2laM7zjwp4z4K99iHbdY7WB4g5ytWpeuAA MIME-Version: 1.0 X-Received: by 10.224.130.8 with SMTP id q8mr2314617qas.99.1395671857380; Mon, 24 Mar 2014 07:37:37 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Mon, 24 Mar 2014 07:37:37 -0700 (PDT) In-Reply-To: <40F4939D-C150-4585-938D-4E030E742B77@nic.cz> References: <20140324.121714.1861441403913411305.mbj@tail-f.com> <40F4939D-C150-4585-938D-4E030E742B77@nic.cz> Date: Mon, 24 Mar 2014 07:37:37 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c2b34e486b5d04f55b2dca Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9FU2JeAgJ4AgZnJLr8T6mEQ6JD0 Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25: make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 14:37:43 -0000 --001a11c2b34e486b5d04f55b2dca Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 24, 2014 at 5:28 AM, Ladislav Lhotka wrote: > > On 24 Mar 2014, at 12:17, Martin Bjorklund wrote: > > > Hi, > > > > We had a discussion about this on the ML, leading up to errata 3871, > > which clarifies the procedure. > > > > Which problem do we solve by removing this? Why isn't the > > clarification of the procedure good enough? > > I think I explained it in the description: > > - Enumerations that don't have explicit "value" statements are difficult > to update, except for appending new enums at the end. > > - Putting "value" statements everywhere is a nuisance for both writers and > readers, especially with long enumerations. > > - Sec. 9.6.4.2 states the values are unused by YANG, which is not true. > > - From the interoperability point of view, the values are irrelevant, so > it is no clear what problem is solved by having the rule in Sec. 10. > > - Removing the auto-numbering procedure simplifies the YANG spec (tiny > bit, but still...) > > We went through this before. The rules in section 10 do not allow a value-stmt or position-stmt value to change. There is no problem updating enums. The RFC says how to do this. Removing the value for some enums does not solve any problem. > Lada > > > > > > > /martin > > > > Andy > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c2b34e486b5d04f55b2dca Content-Type: text/html; charset=ISO-8859-1



On Mon, Mar 24, 2014 at 5:28 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

On 24 Mar 2014, at 12:17, Martin Bjorklund <mbj@tail-f.com> wrote:

> Hi,
>
> We had a discussion about this on the ML, leading up to errata 3871,
> which clarifies the procedure.
>
> Which problem do we solve by removing this?  Why isn't the
> clarification of the procedure good enough?

I think I explained it in the description:

- Enumerations that don’t have explicit “value” statements are difficult to update, except for appending new enums at the end.

- Putting “value” statements everywhere is a nuisance for both writers and readers, especially with long enumerations.

- Sec. 9.6.4.2 states the values are unused by YANG, which is not true.

- From the interoperability point of view, the values are irrelevant, so it is no clear what problem is solved by having the rule in Sec. 10.

- Removing the auto-numbering procedure simplifies the YANG spec (tiny bit, but still…)


We went through this before.
The rules in section 10 do not allow a value-stmt or position-stmt value to change.
There is no problem updating enums. The RFC says how to do this.
Removing the value for some enums does not solve any problem.
  
Lada

>
>
> /martin
>


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




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

--001a11c2b34e486b5d04f55b2dca-- From nobody Mon Mar 24 07:39:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877171A023F for ; Mon, 24 Mar 2014 07:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMPG_FiIAWtc for ; Mon, 24 Mar 2014 07:39:07 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 814371A021E for ; Mon, 24 Mar 2014 07:39:05 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id A7850140075; Mon, 24 Mar 2014 15:39:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395671943; bh=b5W+sJDHxY/MluF3cs1GGkeXnuXMwCO8i3jsV3oZdEs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=FEfvBOG78JLm42gt+uy4hEINDOuQYrZbaQc7Vi+dAHh/UXYT3HxNuCAilswBJR+/u RPuEI0WbXHJ6EU6klR9Zdg7sXkY5Wz9sShuHLLgTmj2U2f3VmLx4XaD/RTTf9nPUSC eqt9Vck1VKjVzelXP9yejZcNm5A8StywhCvjAa0Y= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140324.151400.143715794437617571.mbj@tail-f.com> Date: Mon, 24 Mar 2014 15:39:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3B06297B-C878-4E20-9F42-02114E300F7E@nic.cz> References: <20140324.121714.1861441403913411305.mbj@tail-f.com> <20140324131027.GA45208@elstar.local> <20140324.151400.143715794437617571.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hZoUoLcWfUx8-D6-kJBEs0q0R-o Cc: netmod@ietf.org Subject: Re: [netmod] Y25: make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 14:39:09 -0000 On 24 Mar 2014, at 15:14, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Mon, Mar 24, 2014 at 12:17:14PM +0100, Martin Bjorklund wrote: >>> Hi, >>>=20 >>> We had a discussion about this on the ML, leading up to errata 3871, >>> which clarifies the procedure. >>>=20 >>> Which problem do we solve by removing this? Why isn't the >>> clarification of the procedure good enough? >>>=20 >>=20 >> As technical contributor, I tend to agree with Lada that this >> auto-numbering feature serves no clear value and has caused >> problems. I would not mind getting rid of it in 1.1. >=20 > I think this would be problematic. It is there in 1.0 for > implementations to use, and implementations use it. Yes, it may put I don=92t see any risk of interoperability problems because the client = and server only talk to each other in terms of enum names. They cannot = even tell whether they use the same assignment of values. If an enumeration doesn=92t have the =93value=94 statements and an enum = is deleted somewhere in the middle, an implementation can use the = original assignment - there is no need for the renumbering that is = mandated in 6020. =20 > some additional burden on the module writer if a module is updated, > but I think we can live with that. The burden is also on the module reader side - an enum without a value = statement is a one-liner, with it it is three lines. >=20 > Also note that the "bits" type ("position" statement) behaves in a > similar way. The bit positions are important for the canonical value, so it is = different. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 24 07:43:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D541A021C for ; Mon, 24 Mar 2014 07:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQT_NX269225 for ; Mon, 24 Mar 2014 07:43:41 -0700 (PDT) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7A23B1A01FE for ; Mon, 24 Mar 2014 07:43:41 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id i13so5335111qae.19 for ; Mon, 24 Mar 2014 07:43:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Riy2x7d+pY4mxSc2i3rnYaWWjevuEiFtxY1WWnAr5HU=; b=SJ7znglhVgabSRojMDAK8D/yKa7LSr0Cc7UrIwI1gY+kH7I+ioyxnutzoR46uRoF5g AAt+ikQ1flDGwA2piYPwssP85/sT+uwwQPE7PY6GXHmm0PP5Tdvxuf4/VuZgi4p7tE/T 8SvAkYll7gNj1V8mYomG1B64Wqr+q5DFi6vu6Va7N1eiZkR3tN/ALX+h6yXQtJSC939O ahR1CF7MLDOGqHVU4mJ+/lCyDzBq1WeX6MGZ5eeUNfBPTaMdATA4b77lFSjY2Wlpaz86 Fy/ggqb9wEc3j4d7Rl+AMxqScUwNORLSwbQGIbUmgJaUSGhiD4t0zWrabISQHaGBx+oh JKFA== X-Gm-Message-State: ALoCoQn0IUx426yK2qrK9Ag/owOembxJZB2jE80xj91w48my9oKlXpi37Of1Sh1Ngez/UAJhbGYn MIME-Version: 1.0 X-Received: by 10.224.130.8 with SMTP id q8mr2352797qas.99.1395672220567; Mon, 24 Mar 2014 07:43:40 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Mon, 24 Mar 2014 07:43:40 -0700 (PDT) In-Reply-To: <20140324091321.GA44796@elstar.local> References: <532FDF7B.8060703@mg-soft.com> <1FADB18A-D3F1-4EA6-A1E4-9EDE8F6BE4CA@nic.cz> <20140324091321.GA44796@elstar.local> Date: Mon, 24 Mar 2014 07:43:40 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Ladislav Lhotka , Jernej Tuljak , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2b34eee0c8004f55b4204 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KcWe7NKHObQILKhZjefg6bpJRFE Subject: Re: [netmod] YANG 1.1 issue: YIN -> YANG translation breaks text formatting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 14:43:43 -0000 --001a11c2b34eee0c8004f55b4204 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 24, 2014 at 2:13 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Mar 24, 2014 at 09:42:51AM +0100, Ladislav Lhotka wrote: > > > > I am not saying it is a critical feature, and I can certainly live > without it. On the other hand, solid XML parsers should be able to deal > with it quite easily. > > > > Lada, > > can this perhaps be done by an extension of the YIN format or does it > have to be part of YANG 1.1? Or should YIN perhaps become a separate > document and moved out of YANG 1.1? I am just asking questions to > explore the possible solution space. > > Indentation is preserved for 1 statement, not across multiple statements. XML preserves whitespace. A tool can figure out how to format the YIN text so it looks like YANG formatting for double quoted strings. Fancy string concatenation done for formatting is not very important. I don't want tool developers (like me) to be required to support "round trip pretty printing". IMO the YIN format should go away. I never thought it was useful. > /js > > Andy --001a11c2b34eee0c8004f55b4204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 24, 2014 at 2:13 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Mar 24, 2014 at 09:42:51AM +0100, La= dislav Lhotka wrote:
>
> I am not saying it is a critical feature, and I can certainly live wit= hout it. On the other hand, solid XML parsers should be able to deal with i= t quite easily.
>

Lada,

can this perhaps be done by an extension of the YIN format or does it
have to be part of YANG 1.1? Or should YIN perhaps become a separate
document and moved out of YANG 1.1? I am just asking questions to
explore the possible solution space.


Indentation is preserved for 1 statement, not across= multiple statements.
XML preserves whitespace. =A0A tool can fig= ure out how to format the YIN
text so it looks like YANG formatting for double quoted strings.
=

Fancy string concatenation done for formatting is not v= ery important.
I don't want tool developers (like me) to be r= equired to support "round trip
pretty printing". =A0IMO the YIN format should go away. I never t= hought
it was useful.


=A0
/js


Andy
=A0
=
--001a11c2b34eee0c8004f55b4204-- From nobody Mon Mar 24 07:50:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268CF1A023F for ; Mon, 24 Mar 2014 07:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoryMZ8YF4ij for ; Mon, 24 Mar 2014 07:50:33 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id EE2901A0227 for ; Mon, 24 Mar 2014 07:50:32 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 7E78C140075; Mon, 24 Mar 2014 15:50:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395672631; bh=ZEsYKLt3lHJpJTAWQiTTHcKXwbDE8owsNjp7fExTplU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nEm+XCACLAHWSF5xCziuBkpJwGtyIn02qquH6emeS9Nu4zW3O837bhJKfPcR2uVru DP2lrdm/rsyfbzeNFtZ97MkPeSgnGYZ/WiOvYTQ2j0qGOpvtnCQvzqNNavFmI1cCby 2r5sHghwpl3tZ6ZYV9YUaxyy5RbV/KZV9NkeLVKA= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 24 Mar 2014 15:50:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140324.121714.1861441403913411305.mbj@tail-f.com> <40F4939D-C150-4585-938D-4E030E742B77@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/GpLPwFpVAPuWxRingAHE6fW8PEc Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25: make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 14:50:34 -0000 On 24 Mar 2014, at 15:37, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Mar 24, 2014 at 5:28 AM, Ladislav Lhotka = wrote: >=20 > On 24 Mar 2014, at 12:17, Martin Bjorklund wrote: >=20 > > Hi, > > > > We had a discussion about this on the ML, leading up to errata 3871, > > which clarifies the procedure. > > > > Which problem do we solve by removing this? Why isn't the > > clarification of the procedure good enough? >=20 > I think I explained it in the description: >=20 > - Enumerations that don=92t have explicit =93value=94 statements are = difficult to update, except for appending new enums at the end. >=20 > - Putting =93value=94 statements everywhere is a nuisance for both = writers and readers, especially with long enumerations. >=20 > - Sec. 9.6.4.2 states the values are unused by YANG, which is not = true. >=20 > - =46rom the interoperability point of view, the values are = irrelevant, so it is no clear what problem is solved by having the rule = in Sec. 10. >=20 > - Removing the auto-numbering procedure simplifies the YANG spec (tiny = bit, but still=85) >=20 >=20 > We went through this before. > The rules in section 10 do not allow a value-stmt or position-stmt = value to change. > There is no problem updating enums. The RFC says how to do this. Not true for enums that don=92t have the value statement. > Removing the value for some enums does not solve any problem. There is no need to remove anything, only writers of new enums will not = have to bother with the values where they make no sense. Lada > =20 > Lada >=20 > > > > > > /martin > > >=20 >=20 > Andy > =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 From nobody Mon Mar 24 07:51:36 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88541A019A for ; Mon, 24 Mar 2014 07:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPtD83AWWTmP for ; Mon, 24 Mar 2014 07:51:32 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 848551A0249 for ; Mon, 24 Mar 2014 07:51:30 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 08393140AC4; Mon, 24 Mar 2014 15:51:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395672689; bh=/2EbXiINAVoVSppTe5SU4gtFBwHu6Vm5bLuaHndv7/I=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=EEueVI70nBnOZT48CMn3A/TQtZA7Bq/ZpM50hTmSo1I9t8Ab4FcddJOlQUF/hAMIp SsLj5fTnAgTpYLFM39GW1IWqNW1krTQQvEidUS32kUcQRw+MIJkWR6CtRbyoSjLVN9 hZhOYYsG/9OwKjPH/WOPlzXR50TszHmKQ92ybYds= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 24 Mar 2014 15:51:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <532FDF7B.8060703@mg-soft.com> <1FADB18A-D3F1-4EA6-A1E4-9EDE8F6BE4CA@nic.cz> <20140324091321.GA44796@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/o2IBTa81gaWelpNCdAMyEX5VZmQ Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 issue: YIN -> YANG translation breaks text formatting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 14:51:33 -0000 On 24 Mar 2014, at 15:43, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Mar 24, 2014 at 2:13 AM, Juergen Schoenwaelder = wrote: > On Mon, Mar 24, 2014 at 09:42:51AM +0100, Ladislav Lhotka wrote: > > > > I am not saying it is a critical feature, and I can certainly live = without it. On the other hand, solid XML parsers should be able to deal = with it quite easily. > > >=20 > Lada, >=20 > can this perhaps be done by an extension of the YIN format or does it > have to be part of YANG 1.1? Or should YIN perhaps become a separate > document and moved out of YANG 1.1? I am just asking questions to > explore the possible solution space. >=20 >=20 > Indentation is preserved for 1 statement, not across multiple = statements. > XML preserves whitespace. A tool can figure out how to format the YIN > text so it looks like YANG formatting for double quoted strings. >=20 > Fancy string concatenation done for formatting is not very important. > I don't want tool developers (like me) to be required to support = "round trip > pretty printing". IMO the YIN format should go away. I never thought > it was useful. Fine with me. Lada >=20 >=20 >=20 > =20 > /js >=20 >=20 > Andy > =20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 24 07:53:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A530D1A024C for ; Mon, 24 Mar 2014 07:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNrIBrfbNg9t for ; Mon, 24 Mar 2014 07:53:41 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id 611821A023F for ; Mon, 24 Mar 2014 07:53:41 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id j15so5399507qaq.2 for ; Mon, 24 Mar 2014 07:53:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1mQIskAUTDCc4jaE2oh6qouIqDdPZlwYTtFSpPEpu0s=; b=ZdAwWetlMnQV7PYQntokiZk1H1uiF9oyJS8gLiH7tXkaBM3Lj0+duS/R45fTyTwEoj WgnxKT292XMI2j5JLNDk6TIoF+ybJQFtWzlQEkwNc64Kd7RKJIVs2PzdxUYUvriWRscx QPcL7vSArBZp9J2aqMoR1GR9Y5CvXAcCiYG2QuBjA6JFVTmEWa1B1Fz/eVUIt1Bn/J9y npz211auZOGJPt+3/E53BaXideyZqWMHgSJGIPfMTGr+jANdMX4FQlDMNIuWH+fPczIK 2SQpWSdqTw4F3MlP2iPyi5gQ27QIxZzPwTRcTYF1IL7zbiHdRVjcGVJX8VDjEoF7ezjt C2eQ== X-Gm-Message-State: ALoCoQl3DZRnBLJhkKANxCvIQBQY4ydZLeqRzOxHGcYLSSu0/qdAmbjkh1SGZrqMYfVF7Z6yEhd7 MIME-Version: 1.0 X-Received: by 10.140.104.103 with SMTP id z94mr2831530qge.91.1395672820534; Mon, 24 Mar 2014 07:53:40 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Mon, 24 Mar 2014 07:53:40 -0700 (PDT) In-Reply-To: <20140324.151400.143715794437617571.mbj@tail-f.com> References: <20140324.121714.1861441403913411305.mbj@tail-f.com> <20140324131027.GA45208@elstar.local> <20140324.151400.143715794437617571.mbj@tail-f.com> Date: Mon, 24 Mar 2014 07:53:40 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a1134f2beb0fdad04f55b66ec Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/e4pXDsK1MXP2rB375TFFqCYpxD0 Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25: make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 14:53:43 -0000 --001a1134f2beb0fdad04f55b66ec Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 24, 2014 at 7:14 AM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Mon, Mar 24, 2014 at 12:17:14PM +0100, Martin Bjorklund wrote: > > > Hi, > > > > > > We had a discussion about this on the ML, leading up to errata 3871, > > > which clarifies the procedure. > > > > > > Which problem do we solve by removing this? Why isn't the > > > clarification of the procedure good enough? > > > > > > > As technical contributor, I tend to agree with Lada that this > > auto-numbering feature serves no clear value and has caused > > problems. I would not mind getting rid of it in 1.1. > > I think this would be problematic. It is there in 1.0 for > implementations to use, and implementations use it. Yes, it may put > some additional burden on the module writer if a module is updated, > but I think we can live with that. > > Also note that the "bits" type ("position" statement) behaves in a > similar way. > > I strongly agree. I think we need to follow some design principles. #1 is "Do not break YANG 1.0 clients, except as a last resort" There is no way this "confusing" enum auto-numbering is breaking the network. Errata has been written to clarify the procedure. Sec 10 says the values are not allowed to change. IMO this problem has already been solved and breaking YANG 1.0 apps for no reason is really bad engineering. > /martin > > Andy --001a1134f2beb0fdad04f55b66ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 24, 2014 at 7:14 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<= /a>> wrote:
> On Mon, Mar 24, 2014 at 12:17:14PM +0100, Martin Bjorklund wrote:
> > Hi,
> >
> > We had a discussion about this on the ML, leading up to errata 38= 71,
> > which clarifies the procedure.
> >
> > Which problem do we solve by removing this? =A0Why isn't the<= br> > > clarification of the procedure good enough?
> >
>
> As technical contributor, I tend to agree with Lada that this
> auto-numbering feature serves no clear value and has caused
> problems. I would not mind getting rid of it in 1.1.

I think this would be problematic. =A0It is there in 1.0 for
implementations to use, and implementations use it. =A0Yes, it may put
some additional burden on the module writer if a module is updated,
but I think we can live with that.

Also note that the "bits" type ("position" statement) b= ehaves in a
similar way.



=
I think we need to follow some design principles.

=
#1 is "Do not break YANG 1.0 clients, except as a last resort&quo= t;

There is no way this "confusing" enum auto-nu= mbering is breaking the
network. =A0Errata has been written to cl= arify the procedure.
Sec 10 says the values are not allowed to ch= ange.

IMO this problem has already been solved and breaking Y= ANG 1.0 apps
for no reason is really bad engineering.
<= br>

/martin


Andy


--001a1134f2beb0fdad04f55b66ec-- From nobody Mon Mar 24 08:03:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6129B1A01AF for ; Mon, 24 Mar 2014 08:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQdfd5M-l_6Y for ; Mon, 24 Mar 2014 08:03:33 -0700 (PDT) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id 0802B1A01C7 for ; Mon, 24 Mar 2014 08:03:32 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id i17so6155925qcy.28 for ; Mon, 24 Mar 2014 08:03:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uw0XukWJc9UPsj4adWNJhFQxwIP2/4ZzaJz9koZT6d4=; b=OAY7HvcJu73+Ey6iS25S6aJHgEqKI7eAH9XMua0GJvO8ixnhSOlBV9taik3BleW0LL QPggdn09OyRpCmUm+MbVwwZvUJdxrBDBXnpELyQhw2C4N9X56vxNuG4z69PDEL3VZun1 NPrxqGVAeyvQFHOnsS/ta9SsMe7a3PP7Y+OwlJ0Ppw9XP2HLhntCv6e+OGFzoi6+5e/m 5Y3cDqF6o0f+vtUC/xlh1RTdzoFN+vNTpzgTmrJBM6+IbmZEq/CAT3PR87yV+uYSb9qE LfmTCqbekxadW6SZvdfGkgqNpp3P22lRPvdDHSKO7fPX01qU4GA6OmHAjt3GG2Z/Tu0J w/zA== X-Gm-Message-State: ALoCoQkAvAHCU/v+zhS5GLmkaA0+1jqLYBTlfEqTt61wsbNLG09zDD5tYNc2h8iC9mBPhOlfTvLK MIME-Version: 1.0 X-Received: by 10.140.92.6 with SMTP id a6mr70709310qge.34.1395673411986; Mon, 24 Mar 2014 08:03:31 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Mon, 24 Mar 2014 08:03:31 -0700 (PDT) In-Reply-To: References: <20140324.121714.1861441403913411305.mbj@tail-f.com> <40F4939D-C150-4585-938D-4E030E742B77@nic.cz> Date: Mon, 24 Mar 2014 08:03:31 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1139a970f1bb8804f55b89f8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/sXqLUhJf3tKC__nSmJWWpb_BJ6o Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25: make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 15:03:38 -0000 --001a1139a970f1bb8804f55b89f8 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 24, 2014 at 7:50 AM, Ladislav Lhotka wrote: > > On 24 Mar 2014, at 15:37, Andy Bierman wrote: > > > > > > > > > On Mon, Mar 24, 2014 at 5:28 AM, Ladislav Lhotka wrote: > > > > On 24 Mar 2014, at 12:17, Martin Bjorklund wrote: > > > > > Hi, > > > > > > We had a discussion about this on the ML, leading up to errata 3871, > > > which clarifies the procedure. > > > > > > Which problem do we solve by removing this? Why isn't the > > > clarification of the procedure good enough? > > > > I think I explained it in the description: > > > > - Enumerations that don't have explicit "value" statements are difficult > to update, except for appending new enums at the end. > > > > - Putting "value" statements everywhere is a nuisance for both writers > and readers, especially with long enumerations. > > > > - Sec. 9.6.4.2 states the values are unused by YANG, which is not true. > > > > - From the interoperability point of view, the values are irrelevant, so > it is no clear what problem is solved by having the rule in Sec. 10. > > > > - Removing the auto-numbering procedure simplifies the YANG spec (tiny > bit, but still...) > > > > > > We went through this before. > > The rules in section 10 do not allow a value-stmt or position-stmt value > to change. > > There is no problem updating enums. The RFC says how to do this. > > Not true for enums that don't have the value statement. > > Are you saying the clarified auto-numbering procedure is broken? You need to add new enums at the end of the list or the auto-numbering changes. Same as it has been for C code forever. Even if you had explicit value-smts (e.g., 11, 12, 13, 14) you still cannot add enums in the middle of the list, unless you plan the numbering in advance to allow it. > > Removing the value for some enums does not solve any problem. > > There is no need to remove anything, only writers of new enums will not > have to bother with the values where they make no sense. > > You seem to be saying that the ability to add enums to the middle of the list is more important than having numbers at all. If so, then the enum and position statements should be removed completely. IMO they are very confusing precisely because they are not used in NETCONF or RESTCONF at all. For binary encoding, a tool could easily auto-assign all the values. The binary to string mapping just needs to be unique. Letting the user specify explicit values for properties that do not actually exist in any protocol seems pointless. > Lada > > Andy > > > > Lada > > > > > > > > > > > /martin > > > > > > > > > Andy > > > > -- > > 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 > > > > > --001a1139a970f1bb8804f55b89f8 Content-Type: text/html; charset=ISO-8859-1



On Mon, Mar 24, 2014 at 7:50 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

On 24 Mar 2014, at 15:37, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Mon, Mar 24, 2014 at 5:28 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On 24 Mar 2014, at 12:17, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Hi,
> >
> > We had a discussion about this on the ML, leading up to errata 3871,
> > which clarifies the procedure.
> >
> > Which problem do we solve by removing this?  Why isn't the
> > clarification of the procedure good enough?
>
> I think I explained it in the description:
>
> - Enumerations that don’t have explicit “value” statements are difficult to update, except for appending new enums at the end.
>
> - Putting “value” statements everywhere is a nuisance for both writers and readers, especially with long enumerations.
>
> - Sec. 9.6.4.2 states the values are unused by YANG, which is not true.
>
> - From the interoperability point of view, the values are irrelevant, so it is no clear what problem is solved by having the rule in Sec. 10.
>
> - Removing the auto-numbering procedure simplifies the YANG spec (tiny bit, but still…)
>
>
> We went through this before.
> The rules in section 10 do not allow a value-stmt or position-stmt value to change.
> There is no problem updating enums. The RFC says how to do this.

Not true for enums that don’t have the value statement.


Are you saying the clarified auto-numbering procedure is broken?
You need to add new enums at the end of the list or the auto-numbering changes.
Same as it has been for C code forever.

Even if you had explicit value-smts (e.g., 11, 12, 13, 14)
you still cannot add enums in the middle of the list, unless
you plan the numbering in advance to allow it.

 
> Removing the value for some enums does not solve any problem.

There is no need to remove anything, only writers of new enums will not have to bother with the values where they make no sense.



You seem to be saying that the ability to add enums to the middle of the list
is more important than having numbers at all.  If so, then the enum and position
statements should be removed completely.

IMO they are very confusing precisely because they are not used in NETCONF
or RESTCONF at all.  For binary encoding, a tool could easily auto-assign
all the values.  The binary to string mapping just needs to be unique.
Letting the user specify explicit values for properties that do not actually
exist in any protocol seems pointless.



 
Lada


Andy
 
>
> Lada
>
> >
> >
> > /martin
> >
>
>
> Andy
>
> --
> 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





--001a1139a970f1bb8804f55b89f8-- From nobody Mon Mar 24 08:37:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554D61A024B for ; Mon, 24 Mar 2014 08:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYcQIkm3B0yY for ; Mon, 24 Mar 2014 08:37:22 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 627F41A024D for ; Mon, 24 Mar 2014 08:37:18 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 20875140156; Mon, 24 Mar 2014 16:37:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395675437; bh=DFCpVCq9RVzyqZHOJbdI/RjfoKIWgBwPIbi2Kju8Mhs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=KRUqqz9LgpMF5ACe86pPZfr8ki7BXhNDSWtWV2ne9EPpHD/xx0pkrZlyvZrwYiyGj 0BtJyPD5wHID+gws9srTBukqRGdRInKL1MI+r6nUzef35tW+7nZ0tEQHvNgpfrMkEA 1pXdqCno1TCq2PwWtdUG4akeHPcvxGbSb7ZDRumQ= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 24 Mar 2014 16:37:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140324.121714.1861441403913411305.mbj@tail-f.com> <40F4939D-C150-4585-938D-4E030E742B77@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LLoQ5IifGZdVSpZqi93OXARObhU Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25: make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 15:37:29 -0000 On 24 Mar 2014, at 16:03, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Mar 24, 2014 at 7:50 AM, Ladislav Lhotka = wrote: >=20 > On 24 Mar 2014, at 15:37, Andy Bierman wrote: >=20 > > > > > > > > On Mon, Mar 24, 2014 at 5:28 AM, Ladislav Lhotka = wrote: > > > > On 24 Mar 2014, at 12:17, Martin Bjorklund wrote: > > > > > Hi, > > > > > > We had a discussion about this on the ML, leading up to errata = 3871, > > > which clarifies the procedure. > > > > > > Which problem do we solve by removing this? Why isn't the > > > clarification of the procedure good enough? > > > > I think I explained it in the description: > > > > - Enumerations that don=92t have explicit =93value=94 statements are = difficult to update, except for appending new enums at the end. > > > > - Putting =93value=94 statements everywhere is a nuisance for both = writers and readers, especially with long enumerations. > > > > - Sec. 9.6.4.2 states the values are unused by YANG, which is not = true. > > > > - =46rom the interoperability point of view, the values are = irrelevant, so it is no clear what problem is solved by having the rule = in Sec. 10. > > > > - Removing the auto-numbering procedure simplifies the YANG spec = (tiny bit, but still=85) > > > > > > We went through this before. > > The rules in section 10 do not allow a value-stmt or position-stmt = value to change. > > There is no problem updating enums. The RFC says how to do this. >=20 > Not true for enums that don=92t have the value statement. >=20 >=20 > Are you saying the clarified auto-numbering procedure is broken? > You need to add new enums at the end of the list or the auto-numbering = changes. But you cannot delete an enum, which is sometimes needed. > Same as it has been for C code forever. Some languages (even older than C) define enumerations without numeric = values. >=20 > Even if you had explicit value-smts (e.g., 11, 12, 13, 14) > you still cannot add enums in the middle of the list, unless > you plan the numbering in advance to allow it. Why not? There is no requirement that the values must be increasing. >=20 > =20 > > Removing the value for some enums does not solve any problem. >=20 > There is no need to remove anything, only writers of new enums will = not have to bother with the values where they make no sense. >=20 >=20 >=20 > You seem to be saying that the ability to add enums to the middle of = the list > is more important than having numbers at all. If so, then the enum = and position > statements should be removed completely. Do you mean =93=85 value and position statements =85=94? We cannot = remove them because that could break existing modules. Also, the bit = positions are different because their relative order determines the = canonical value that appears on the wire. >=20 > IMO they are very confusing precisely because they are not used in = NETCONF > or RESTCONF at all. For binary encoding, a tool could easily = auto-assign > all the values. The binary to string mapping just needs to be unique. > Letting the user specify explicit values for properties that do not = actually > exist in any protocol seems pointless. Agreed, and since we cannot remove the statement due to backward = compatibility requirement, my proposal just tries to make it harmless. Lada >=20 >=20 >=20 > =20 > Lada >=20 >=20 > Andy > =20 > > > > Lada > > > > > > > > > > > /martin > > > > > > > > > Andy > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > _______________________________________________ > > 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 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 24 09:12:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A081A0250 for ; Mon, 24 Mar 2014 09:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJ1RwLxpksbO for ; Mon, 24 Mar 2014 09:11:54 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC8B1A01B9 for ; Mon, 24 Mar 2014 09:11:54 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id e9so6142215qcy.40 for ; Mon, 24 Mar 2014 09:11:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NrzZueum2O75gLqXNflj/dpCrl2z/0SfUNcivxfHKvs=; b=AccW8cg3yqrEWuMZbJH+RK0SBcD38QYfvAtAA969WG1TCaxTPhat5CxEXZZFMoa7V4 HncLd7TT5RTWj9qs6eTRep8/iGZZTrrx2ndUjl0iQGEY1/47Xo7ZT3jy2pKvKqLVaht6 losp5aoDlvQhTpSaN7Dz0/Eb3qANuUUBXtiGdz1+T+TuUyBvtMYif8LPXw4sytThQqIc WPjPghxds7LqVRyXiOGQRtdTmRKw6BfFx8T04zgLugG2bXq6ZjeM5/DoutzZhHBz1YiK 28AB+dE14iT6ynTFpE6xTLZvsG0gJyVKNjJgQBa6cWki02bmPmtF2RdH2uqQJhZY9Fr2 Attg== X-Gm-Message-State: ALoCoQkwRnXJA+/v46d5o7WS/3bReBVIEWqySylE5+GgZRBaOeVTlmY0NJuwcwDNRxpTThfPJh1N MIME-Version: 1.0 X-Received: by 10.140.27.193 with SMTP id 59mr71886045qgx.18.1395677513316; Mon, 24 Mar 2014 09:11:53 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Mon, 24 Mar 2014 09:11:53 -0700 (PDT) In-Reply-To: References: <20140324.121714.1861441403913411305.mbj@tail-f.com> <40F4939D-C150-4585-938D-4E030E742B77@nic.cz> Date: Mon, 24 Mar 2014 09:11:53 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c1233a67180b04f55c7e23 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/578ZezeeOZfv_ibsweV_Wa4nV3k Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25: make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 16:11:58 -0000 --001a11c1233a67180b04f55c7e23 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 24, 2014 at 8:37 AM, Ladislav Lhotka wrote: > > On 24 Mar 2014, at 16:03, Andy Bierman wrote: > > > > > > > > > On Mon, Mar 24, 2014 at 7:50 AM, Ladislav Lhotka wrote: > > > > On 24 Mar 2014, at 15:37, Andy Bierman wrote: > > > > > > > > > > > > > > On Mon, Mar 24, 2014 at 5:28 AM, Ladislav Lhotka > wrote: > > > > > > On 24 Mar 2014, at 12:17, Martin Bjorklund wrote: > > > > > > > Hi, > > > > > > > > We had a discussion about this on the ML, leading up to errata 3871, > > > > which clarifies the procedure. > > > > > > > > Which problem do we solve by removing this? Why isn't the > > > > clarification of the procedure good enough? > > > > > > I think I explained it in the description: > > > > > > - Enumerations that don't have explicit "value" statements are > difficult to update, except for appending new enums at the end. > > > > > > - Putting "value" statements everywhere is a nuisance for both writers > and readers, especially with long enumerations. > > > > > > - Sec. 9.6.4.2 states the values are unused by YANG, which is not true. > > > > > > - From the interoperability point of view, the values are irrelevant, > so it is no clear what problem is solved by having the rule in Sec. 10. > > > > > > - Removing the auto-numbering procedure simplifies the YANG spec (tiny > bit, but still...) > > > > > > > > > We went through this before. > > > The rules in section 10 do not allow a value-stmt or position-stmt > value to change. > > > There is no problem updating enums. The RFC says how to do this. > > > > Not true for enums that don't have the value statement. > > > > > > Are you saying the clarified auto-numbering procedure is broken? > > You need to add new enums at the end of the list or the auto-numbering > changes. > > But you cannot delete an enum, which is sometimes needed. > You cannot delete an enum, with or without explicit value-stmts. It would break old clients (by taking away a value that used to work) and violate sec. 10 rules. The only change allowed is to deprecate or obsolete the definition and create a new one. > > > Same as it has been for C code forever. > > Some languages (even older than C) define enumerations without numeric > values. > > > > > Even if you had explicit value-smts (e.g., 11, 12, 13, 14) > > you still cannot add enums in the middle of the list, unless > > you plan the numbering in advance to allow it. > > Why not? There is no requirement that the values must be increasing. > > true -- if you want to do this, you could add explicit value-stmts to the auto-numbered enums that follow the new enum. So there is a way in YANG to add enums to the middle of a list if you want. I've run into enum additions many times over the years in MIB modules, and adding new enums at the end was never seen as a problem. Why is it a problem for YANG? > > > > > > > Removing the value for some enums does not solve any problem. > > > > There is no need to remove anything, only writers of new enums will not > have to bother with the values where they make no sense. > > > > > > > > You seem to be saying that the ability to add enums to the middle of the > list > > is more important than having numbers at all. If so, then the enum and > position > > statements should be removed completely. > > Do you mean "... value and position statements ..."? We cannot remove them > because that could break existing modules. Also, the bit positions are > different because their relative order determines the canonical value that > appears on the wire. > > > > > IMO they are very confusing precisely because they are not used in > NETCONF > > or RESTCONF at all. For binary encoding, a tool could easily auto-assign > > all the values. The binary to string mapping just needs to be unique. > > Letting the user specify explicit values for properties that do not > actually > > exist in any protocol seems pointless. > > Agreed, and since we cannot remove the statement due to backward > compatibility requirement, my proposal just tries to make it harmless. > > I think they are already harmless. They are carried over from SMIv2, where the values actually mattered. The current scheme provides 1 mandatory-to-implement auto-numbering scheme. I don't see how I would get the same behavior from every YANG tool if this was made optional. Lada > > Andy --001a11c1233a67180b04f55c7e23 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 24, 2014 at 8:37 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 24 Mar 2014, at 16:03, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Mon, Mar 24, 2014 at 7:50 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On 24 Mar 2014, at 15:37, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Mon, Mar 24, 2014 at 5:28 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > On 24 Mar 2014, at 12:17, Martin Bjorklund <mbj@tail-f.com> wrote:
> >
> > > Hi,
> > >
> > > We had a discussion about this on the ML, leading up to erra= ta 3871,
> > > which clarifies the procedure.
> > >
> > > Which problem do we solve by removing this?  Why isn= 9;t the
> > > clarification of the procedure good enough?
> >
> > I think I explained it in the description:
> >
> > - Enumerations that don’t have explicit “value”= statements are difficult to update, except for appending new enums at the = end.
> >
> > - Putting “value” statements everywhere is a nuisance= for both writers and readers, especially with long enumerations.
> >
> > - Sec. 9.6.4.2 states the values are unused by YANG, which is not= true.
> >
> > - From the interoperability point of view, the values are irrelev= ant, so it is no clear what problem is solved by having the rule in Sec. 10= .
> >
> > - Removing the auto-numbering procedure simplifies the YANG spec = (tiny bit, but still…)
> >
> >
> > We went through this before.
> > The rules in section 10 do not allow a value-stmt or position-stm= t value to change.
> > There is no problem updating enums. The RFC says how to do this.<= br> >
> Not true for enums that don’t have the value statement.
>
>
> Are you saying the clarified auto-numbering procedure is broken?
> You need to add new enums at the end of the list or the auto-numbering= changes.

But you cannot delete an enum, which is sometimes needed.
<= div>

You cannot delete an enum, with or withou= t explicit value-stmts.
It would break old clients (by taking awa= y a value that used to work)
and violate sec. 10 rules.  The only change allowed
is = to deprecate or obsolete the definition and create a new one.
 

> Same as it has been for C code forever.

Some languages (even older than C) define enumerations without numeric valu= es.

>
> Even if you had explicit value-smts (e.g., 11, 12, 13, 14)
> you still cannot add enums in the middle of the list, unless
> you plan the numbering in advance to allow it.

Why not? There is no requirement that the values must be increasing.



true -- if you want to = do this, you could add explicit value-stmts to
the auto-numbered = enums that follow the new enum.  So there is
a way in YANG t= o add enums to the middle of a list if you want.

I've run into enum additions many times over the ye= ars in MIB modules,
and adding new enums at the end was never see= n as a problem.
Why is it a problem for YANG?

 
>
>
> > Removing the value for some enums does not solve any problem.
>
> There is no need to remove anything, only writers of new enums will no= t have to bother with the values where they make no sense.
>
>
>
> You seem to be saying that the ability to add enums to the middle of t= he list
> is more important than having numbers at all.  If so, then the en= um and position
> statements should be removed completely.

Do you mean “… value and position statements …”? = We cannot remove them because that could break existing modules. Also, the = bit positions are different because their relative order determines the can= onical value that appears on the wire.

>
> IMO they are very confusing precisely because they are not used in NET= CONF
> or RESTCONF at all.  For binary encoding, a tool could easily aut= o-assign
> all the values.  The binary to string mapping just needs to be un= ique.
> Letting the user specify explicit values for properties that do not ac= tually
> exist in any protocol seems pointless.

Agreed, and since we cannot remove the statement due to backward compatibil= ity requirement, my proposal just tries to make it harmless.



I think they are alread= y harmless.
They are carried over from SMIv2, where the values ac= tually mattered.

The current scheme provides 1 man= datory-to-implement auto-numbering
scheme.  I don't see how I would get the same behavior from e= very YANG tool
if this was made optional.


Lada


Andy


--001a11c1233a67180b04f55c7e23-- From nobody Mon Mar 24 09:44:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415971A0256 for ; Mon, 24 Mar 2014 09:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcOl-U_nwG1r for ; Mon, 24 Mar 2014 09:44:28 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A5D741A0236 for ; Mon, 24 Mar 2014 09:44:27 -0700 (PDT) Received: from [172.20.26.113] (unknown [172.20.20.35]) by mail.nic.cz (Postfix) with ESMTPSA id B22751400E1; Mon, 24 Mar 2014 17:44:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395679458; bh=yMSKnTayCjLFTnAY9mlt2aAGO/vTDMQw8g2WxSyjUow=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=WfcV60Vo6bmSgbWDc4IvYChGz9qtQb5dici8dn3S36yrbM3Uge+JtFtFG/RZoGjUz rPwKOLu6psfvjUtd7+aADmHIrpAOHXCYdbcZwiSHBVjvWzFzXr5O/PogU+Nj7yV/ET ut5g2/1dxZjsEfip82DFY5YVP+AW4jyr7gS/KPsQ= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 24 Mar 2014 17:44:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140324.121714.1861441403913411305.mbj@tail-f.com> <40F4939D-C150-4585-938D-4E030E742B77@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZKIPF5199UKARUMyKINN0EwQ8Wc Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25: make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 16:44:30 -0000 On 24 Mar 2014, at 17:11, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Mar 24, 2014 at 8:37 AM, Ladislav Lhotka = wrote: >=20 > On 24 Mar 2014, at 16:03, Andy Bierman wrote: >=20 > > > > > > > > On Mon, Mar 24, 2014 at 7:50 AM, Ladislav Lhotka = wrote: > > > > On 24 Mar 2014, at 15:37, Andy Bierman wrote: > > > > > > > > > > > > > > On Mon, Mar 24, 2014 at 5:28 AM, Ladislav Lhotka = wrote: > > > > > > On 24 Mar 2014, at 12:17, Martin Bjorklund wrote: > > > > > > > Hi, > > > > > > > > We had a discussion about this on the ML, leading up to errata = 3871, > > > > which clarifies the procedure. > > > > > > > > Which problem do we solve by removing this? Why isn't the > > > > clarification of the procedure good enough? > > > > > > I think I explained it in the description: > > > > > > - Enumerations that don=92t have explicit =93value=94 statements = are difficult to update, except for appending new enums at the end. > > > > > > - Putting =93value=94 statements everywhere is a nuisance for both = writers and readers, especially with long enumerations. > > > > > > - Sec. 9.6.4.2 states the values are unused by YANG, which is not = true. > > > > > > - =46rom the interoperability point of view, the values are = irrelevant, so it is no clear what problem is solved by having the rule = in Sec. 10. > > > > > > - Removing the auto-numbering procedure simplifies the YANG spec = (tiny bit, but still=85) > > > > > > > > > We went through this before. > > > The rules in section 10 do not allow a value-stmt or position-stmt = value to change. > > > There is no problem updating enums. The RFC says how to do this. > > > > Not true for enums that don=92t have the value statement. > > > > > > Are you saying the clarified auto-numbering procedure is broken? > > You need to add new enums at the end of the list or the = auto-numbering changes. >=20 > But you cannot delete an enum, which is sometimes needed. >=20 >=20 > You cannot delete an enum, with or without explicit value-stmts. > It would break old clients (by taking away a value that used to work) I don=92t think this is much different from the case when a new enum is = added that used to be illegal. Without intelligent conformance statements, a mismatch in module = versions is IMO always risky. > and violate sec. 10 rules. The only change allowed > is to deprecate or obsolete the definition and create a new one. >=20 > =20 >=20 > > Same as it has been for C code forever. >=20 > Some languages (even older than C) define enumerations without numeric = values. >=20 > > > > Even if you had explicit value-smts (e.g., 11, 12, 13, 14) > > you still cannot add enums in the middle of the list, unless > > you plan the numbering in advance to allow it. >=20 > Why not? There is no requirement that the values must be increasing. >=20 >=20 >=20 > true -- if you want to do this, you could add explicit value-stmts to > the auto-numbered enums that follow the new enum. So there is > a way in YANG to add enums to the middle of a list if you want. >=20 > I've run into enum additions many times over the years in MIB modules, > and adding new enums at the end was never seen as a problem. > Why is it a problem for YANG? I understood it was a problem for the timezone enumeration. >=20 > =20 > > > > > > > Removing the value for some enums does not solve any problem. > > > > There is no need to remove anything, only writers of new enums will = not have to bother with the values where they make no sense. > > > > > > > > You seem to be saying that the ability to add enums to the middle of = the list > > is more important than having numbers at all. If so, then the enum = and position > > statements should be removed completely. >=20 > Do you mean =93=85 value and position statements =85=94? We cannot = remove them because that could break existing modules. Also, the bit = positions are different because their relative order determines the = canonical value that appears on the wire. >=20 > > > > IMO they are very confusing precisely because they are not used in = NETCONF > > or RESTCONF at all. For binary encoding, a tool could easily = auto-assign > > all the values. The binary to string mapping just needs to be = unique. > > Letting the user specify explicit values for properties that do not = actually > > exist in any protocol seems pointless. >=20 > Agreed, and since we cannot remove the statement due to backward = compatibility requirement, my proposal just tries to make it harmless. >=20 >=20 >=20 > I think they are already harmless. > They are carried over from SMIv2, where the values actually mattered. >=20 > The current scheme provides 1 mandatory-to-implement auto-numbering > scheme. I don't see how I would get the same behavior from every YANG = tool > if this was made optional. Why do you need a universal numbering scheme if the numeric values have = only local meaning and are never exchanged between the server and = client? Lada >=20 >=20 > Lada >=20 >=20 > Andy >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 24 10:03:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D84B1A0260 for ; Mon, 24 Mar 2014 10:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z578--nfWDLQ for ; Mon, 24 Mar 2014 10:03:05 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 34E171A020F for ; Mon, 24 Mar 2014 10:03:05 -0700 (PDT) Received: from [172.20.26.113] (unknown [172.20.20.35]) by mail.nic.cz (Postfix) with ESMTPSA id C2CC41400E1 for ; Mon, 24 Mar 2014 18:03:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395680583; bh=gbQpzs9hgw/W9UUO2AE1Yn74bfMOoINz42n6BeWdxOs=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id: Date:To:Mime-Version; b=qAkPYY8pVuYAvzgy/ZfJwQ4QP82EtmONb6jwN5Mw7lpuPuKYlS/Bz4tALH2JtFN42 OBEQkeFL9PXKnmJPib5H0rmaAmkSoFZj+yGdrVIfpgaKHX2tnuLYutx8PraOLol47g g5WxzOXmN4ImwVeAT6MoDQPZjehfnBwRkpqTubVM= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 24 Mar 2014 18:03:03 +0100 To: netmod@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4vPpnAcqsCzPDcVz75ThTDD8I0M Subject: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 17:03:07 -0000 * allow mandatory nodes in augments ** Description RFC 6020 states in = [[http://tools.ietf.org/html/rfc6020#section-7.15][Sec. 7.15]]: If the target node is in another module, then nodes added by the augmentation MUST NOT be mandatory nodes (see Section 3.1). This rule was probably based on the assumption that augments will be = used for really optional data that can be safely ignored. However, as it = turned out, augments have become an essential tool for modular = development of YANG data models. In some cases, the inability to define = mandatory nodes in augments prevents the data modeller from specifying = desired schema constraints. For instance, = [[http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-16#appendix-= A][Appendix A]] in "interfaces-cfg" shows how an Ethernet module can be = written that augments "if:interface". However, the container "ethernet" = cannot define any child leafs as mandatory even though it may be = necessary and would be normally done if the "ethernet" container was = defined directly in the "ietf-interfaces" module. ** Solution Remove the rule cited above.=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 24 10:25:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B337E1A025D for ; Mon, 24 Mar 2014 10:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6R4nIknlZGVf for ; Mon, 24 Mar 2014 10:25:39 -0700 (PDT) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) by ietfa.amsl.com (Postfix) with ESMTP id DF94B1A0254 for ; Mon, 24 Mar 2014 10:25:38 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id i50so17528843qgf.0 for ; Mon, 24 Mar 2014 10:25:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=naPQFh++yhQSNzg6yMyxHYX/IMFcXuznQdzcYCDBiMk=; b=LF+0RnAhnnowHIDHbZqmuIHPNe/4WlgXXWY4C48itVvt5HQr9Z4LvnaA7Q6YCMMdNS q0sjIBfxpZU3j9+dcEMejcFrB9cLQHhOQBwkTUK+yRQ7iE2TknwDDWNFhMXDoazKrGgF jS+brVB2bEYAzGeoXM9PpQAB8vyhgLMupzrmcyBu1yklUOtWaSnxmsjwtSSWB5rnrkUW 3EVN2xpP8fqzq87L6wSlnASKB8Ux+x/P9MYyKLtnRk2ZFUcvWKTYERcR/5wx0/35tJxY WQz/ZiQbJHF3N3jjvkkIUk0qWlcSQjPpMSGe7u1AzXtGgt5/azVAswAJvHZsIcLA9d0f S0cg== X-Gm-Message-State: ALoCoQmj/tDN3Xo9Lq4Vuzthsvdt0kBzhykyFSSDmgtIZxDkRWAQ1O9NKf8ISJ+Au6izBzRLbbho MIME-Version: 1.0 X-Received: by 10.140.104.103 with SMTP id z94mr3804587qge.91.1395681937808; Mon, 24 Mar 2014 10:25:37 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Mon, 24 Mar 2014 10:25:37 -0700 (PDT) In-Reply-To: References: <20140324.121714.1861441403913411305.mbj@tail-f.com> <40F4939D-C150-4585-938D-4E030E742B77@nic.cz> Date: Mon, 24 Mar 2014 10:25:37 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1134f2be1f8f2704f55d869f Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/vpHq7pN_m35aVfG2pbOIJqmVXSc Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25: make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 17:25:44 -0000 --001a1134f2be1f8f2704f55d869f Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 24, 2014 at 9:44 AM, Ladislav Lhotka wrote: > > On 24 Mar 2014, at 17:11, Andy Bierman wrote: > > > > > > > > > On Mon, Mar 24, 2014 at 8:37 AM, Ladislav Lhotka wrote: > > > > On 24 Mar 2014, at 16:03, Andy Bierman wrote: > > > > > > > > > > > > > > On Mon, Mar 24, 2014 at 7:50 AM, Ladislav Lhotka > wrote: > > > > > > On 24 Mar 2014, at 15:37, Andy Bierman wrote: > > > > > > > > > > > > > > > > > > > On Mon, Mar 24, 2014 at 5:28 AM, Ladislav Lhotka > wrote: > > > > > > > > On 24 Mar 2014, at 12:17, Martin Bjorklund wrote: > > > > > > > > > Hi, > > > > > > > > > > We had a discussion about this on the ML, leading up to errata > 3871, > > > > > which clarifies the procedure. > > > > > > > > > > Which problem do we solve by removing this? Why isn't the > > > > > clarification of the procedure good enough? > > > > > > > > I think I explained it in the description: > > > > > > > > - Enumerations that don't have explicit "value" statements are > difficult to update, except for appending new enums at the end. > > > > > > > > - Putting "value" statements everywhere is a nuisance for both > writers and readers, especially with long enumerations. > > > > > > > > - Sec. 9.6.4.2 states the values are unused by YANG, which is not > true. > > > > > > > > - From the interoperability point of view, the values are > irrelevant, so it is no clear what problem is solved by having the rule in > Sec. 10. > > > > > > > > - Removing the auto-numbering procedure simplifies the YANG spec > (tiny bit, but still...) > > > > > > > > > > > > We went through this before. > > > > The rules in section 10 do not allow a value-stmt or position-stmt > value to change. > > > > There is no problem updating enums. The RFC says how to do this. > > > > > > Not true for enums that don't have the value statement. > > > > > > > > > Are you saying the clarified auto-numbering procedure is broken? > > > You need to add new enums at the end of the list or the auto-numbering > changes. > > > > But you cannot delete an enum, which is sometimes needed. > > > > > > You cannot delete an enum, with or without explicit value-stmts. > > It would break old clients (by taking away a value that used to work) > > I don't think this is much different from the case when a new enum is > added that used to be illegal. > > It is much different. We even have a name for it -- the Bonica Principle (since it was described by Ron at an early YANG interim meeting). Basically, you can expand the value set over time but you cannot contract it. This is core old-manager/new-agent stuff. An old manager will not use the new values it does not know about. As long as the old values don't change, new values can be added at any time. > Without intelligent conformance statements, a mismatch in module versions > is IMO always risky. > > Not if sec. 10 rules are followed. > > and violate sec. 10 rules. The only change allowed > > is to deprecate or obsolete the definition and create a new one. > > > > > > > > > Same as it has been for C code forever. > > > > Some languages (even older than C) define enumerations without numeric > values. > > > > > > > > Even if you had explicit value-smts (e.g., 11, 12, 13, 14) > > > you still cannot add enums in the middle of the list, unless > > > you plan the numbering in advance to allow it. > > > > Why not? There is no requirement that the values must be increasing. > > > > > > > > true -- if you want to do this, you could add explicit value-stmts to > > the auto-numbered enums that follow the new enum. So there is > > a way in YANG to add enums to the middle of a list if you want. > > > > I've run into enum additions many times over the years in MIB modules, > > and adding new enums at the end was never seen as a problem. > > Why is it a problem for YANG? > > I understood it was a problem for the timezone enumeration. > Now that it is gone -- problem solved ;-) I agree keeping enums in some sorted order is more reader-friendly. Maybe we are forgetting that an old YANG 1.0 tool will never read a YANG 1.1 module. What if we eliminate auto-numbering in YANG 1.1? Only explicit value/position statements declare any value. There are no auto-assigned numbers at all. (Not optional). IMO, the value/position stmts are misleading unless they have some correlation value to the operational network. They should be explicit when they have meaning and they should be absent if they have no meaning (other than arbitrary numbering). > > > > > > > > > > > > > > Removing the value for some enums does not solve any problem. > > > > > > There is no need to remove anything, only writers of new enums will > not have to bother with the values where they make no sense. > > > > > > > > > > > > You seem to be saying that the ability to add enums to the middle of > the list > > > is more important than having numbers at all. If so, then the enum > and position > > > statements should be removed completely. > > > > Do you mean "... value and position statements ..."? We cannot remove them > because that could break existing modules. Also, the bit positions are > different because their relative order determines the canonical value that > appears on the wire. > > > > > > > > IMO they are very confusing precisely because they are not used in > NETCONF > > > or RESTCONF at all. For binary encoding, a tool could easily > auto-assign > > > all the values. The binary to string mapping just needs to be unique. > > > Letting the user specify explicit values for properties that do not > actually > > > exist in any protocol seems pointless. > > > > Agreed, and since we cannot remove the statement due to backward > compatibility requirement, my proposal just tries to make it harmless. > > > > > > > > I think they are already harmless. > > They are carried over from SMIv2, where the values actually mattered. > > > > The current scheme provides 1 mandatory-to-implement auto-numbering > > scheme. I don't see how I would get the same behavior from every YANG > tool > > if this was made optional. > > Why do you need a universal numbering scheme if the numeric values have > only local meaning and are never exchanged between the server and client? > > Because automation tools use YANG in protocol implementations? (IMO, they could auto-generate code-point values, and the YANG module does not need to provide them). If they have explicit values (especially bits) then I can see how this info could directly map to binary implementations. Lada > > > > > > > Lada > > > > > > Andy > > > > > > Andy --001a1134f2be1f8f2704f55d869f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 24, 2014 at 9:44 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 24 Mar 2014, at 17:11, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Mon, Mar 24, 2014 at 8:37 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On 24 Mar 2014, at 16:03, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Mon, Mar 24, 2014 at 7:50 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > On 24 Mar 2014, at 15:37, Andy Bierman <andy@yumaworks.com> wrote:
> >
> > >
> > >
> > >
> > > On Mon, Mar 24, 2014 at 5:28 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > >
> > > On 24 Mar 2014, at 12:17, Martin Bjorklund <mbj@tail-f.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > We had a discussion about this on the ML, leading up to= errata 3871,
> > > > which clarifies the procedure.
> > > >
> > > > Which problem do we solve by removing this?  Why i= sn't the
> > > > clarification of the procedure good enough?
> > >
> > > I think I explained it in the description:
> > >
> > > - Enumerations that don’t have explicit “value&r= dquo; statements are difficult to update, except for appending new enums at= the end.
> > >
> > > - Putting “value” statements everywhere is a nui= sance for both writers and readers, especially with long enumerations.
> > >
> > > - Sec. 9.6.4.2 states the values are unused by YANG, which i= s not true.
> > >
> > > - From the interoperability point of view, the values are ir= relevant, so it is no clear what problem is solved by having the rule in Se= c. 10.
> > >
> > > - Removing the auto-numbering procedure simplifies the YANG = spec (tiny bit, but still…)
> > >
> > >
> > > We went through this before.
> > > The rules in section 10 do not allow a value-stmt or positio= n-stmt value to change.
> > > There is no problem updating enums. The RFC says how to do t= his.
> >
> > Not true for enums that don’t have the value statement.
> >
> >
> > Are you saying the clarified auto-numbering procedure is broken?<= br> > > You need to add new enums at the end of the list or the auto-numb= ering changes.
>
> But you cannot delete an enum, which is sometimes needed.
>
>
> You cannot delete an enum, with or without explicit value-stmts.
> It would break old clients (by taking away a value that used to work)<= br>
I don’t think this is much different from the case when a new enum is= added that used to be illegal.



It is much different. &= nbsp;We even have a name for it -- the Bonica Principle
(since it= was described by Ron at an early YANG interim meeting).

Basically, you can expand the value set over time but you cannot contr= act it.
This is core old-manager/new-agent stuff. An old manager = will not use the new values
it does not know about.  As long= as the old values don't change, new values
can be added at any time.

 
Without intelligent conformance statements, a mismatch in module versions i= s IMO always risky.


Not if sec. 10 rules are followed.

 
> and violate sec. 10 rules.  The only change allowed
> is to deprecate or obsolete the definition and create a new one.
>
>
>
> > Same as it has been for C code forever.
>
> Some languages (even older than C) define enumerations without numeric= values.
>
> >
> > Even if you had explicit value-smts (e.g., 11, 12, 13, 14)
> > you still cannot add enums in the middle of the list, unless
> > you plan the numbering in advance to allow it.
>
> Why not? There is no requirement that the values must be increasing. >
>
>
> true -- if you want to do this, you could add explicit value-stmts to<= br> > the auto-numbered enums that follow the new enum.  So there is > a way in YANG to add enums to the middle of a list if you want.
>
> I've run into enum additions many times over the years in MIB modu= les,
> and adding new enums at the end was never seen as a problem.
> Why is it a problem for YANG?

I understood it was a problem for the timezone enumeration.


Now that it is gone -- problem solved ;= -)

I agree keeping enums in some sorted order is m= ore reader-friendly.

Maybe we are forgetting that an old YANG 1.0 tool will = never read a YANG 1.1 module.

What if we eliminate= auto-numbering in YANG 1.1?
Only explicit value/position stateme= nts declare any value.
There are no auto-assigned numbers at all. (Not optional).
<= br>
IMO, the value/position stmts are misleading unless they have= some correlation value
to the operational network.  They sh= ould be explicit when they have meaning
and they should be absent if they have no meaning (other than arbitrar= y numbering).



>
>
> >
> >
> > > Removing the value for some enums does not solve any problem= .
> >
> > There is no need to remove anything, only writers of new enums wi= ll not have to bother with the values where they make no sense.
> >
> >
> >
> > You seem to be saying that the ability to add enums to the middle= of the list
> > is more important than having numbers at all.  If so, then t= he enum and position
> > statements should be removed completely.
>
> Do you mean “… value and position statements …&rdq= uo;? We cannot remove them because that could break existing modules. Also,= the bit positions are different because their relative order determines th= e canonical value that appears on the wire.
>
> >
> > IMO they are very confusing precisely because they are not used i= n NETCONF
> > or RESTCONF at all.  For binary encoding, a tool could easil= y auto-assign
> > all the values.  The binary to string mapping just needs to = be unique.
> > Letting the user specify explicit values for properties that do n= ot actually
> > exist in any protocol seems pointless.
>
> Agreed, and since we cannot remove the statement due to backward compa= tibility requirement, my proposal just tries to make it harmless.
>
>
>
> I think they are already harmless.
> They are carried over from SMIv2, where the values actually mattered.<= br> >
> The current scheme provides 1 mandatory-to-implement auto-numbering > scheme.  I don't see how I would get the same behavior from e= very YANG tool
> if this was made optional.

Why do you need a universal numbering scheme if the numeric values have onl= y local meaning and are never exchanged between the server and client?


Because automation tools use YANG in p= rotocol implementations?
(IMO, they could auto-generate code-poin= t values, and the YANG module
does not need to provide them).

If they have explicit values (especially bits) then I c= an see how this info
could directly map to binary implementations= .



Lada

>
>
> Lada
>
>
> Andy
>
>


Andy

<= /div> --001a1134f2be1f8f2704f55d869f-- From nobody Mon Mar 24 10:34:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28661A0245 for ; Mon, 24 Mar 2014 10:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCOSCOORpRho for ; Mon, 24 Mar 2014 10:33:59 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id 798931A0244 for ; Mon, 24 Mar 2014 10:33:59 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id e9so6266897qcy.26 for ; Mon, 24 Mar 2014 10:33:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wirUjRhHefhgOjsCfM4B80qBFe2BelIRuPqz4I+b9aQ=; b=ac5x5HIILRJs8+qEibFUIcyS4yZY9W3UEM6inLgDTuZyIrg9IDMfD+ika7Yh4EqC1J WiWLj4fA93/oGsy2SgdLk41/rlvWmo8fUE7vNe0DxwYlEtsx30Hqu9fLIjS3ok0hkQcZ KoKbtxoIdOujANrUKOIHcKNL5a3tv4t4OuQKU+pY0d468Vwqim8iaVdGlmX6ug4BKdxO X14RfTKGYyYjM+P+eF6RIOqprwqtEQf9kx7ZDOhLH6gUFvn7O2wa3lNOaenwNeA3+cPP 4E3PmKSFpKtJ7JRm18j4o17cE3AtYzbvYqGRLLsvvVP4mN2MyBw/MEz+x/4XErLgShsQ t0Kg== X-Gm-Message-State: ALoCoQmzFAG/aNYBh+QRqtsh89zxilq8wvvPn1q1mAoqUlZ7khtb2dZiG93sfMsfDX0Rj2LoEAIa MIME-Version: 1.0 X-Received: by 10.224.36.129 with SMTP id t1mr3852448qad.88.1395682438445; Mon, 24 Mar 2014 10:33:58 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Mon, 24 Mar 2014 10:33:58 -0700 (PDT) In-Reply-To: References: Date: Mon, 24 Mar 2014 10:33:58 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=089e0158a9e4f6af0c04f55da376 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jIeKNulf_Pv0cShv61-eqGW-tBA Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 17:34:01 -0000 --089e0158a9e4f6af0c04f55da376 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 24, 2014 at 10:03 AM, Ladislav Lhotka wrote: > * allow mandatory nodes in augments > > ** Description > > RFC 6020 states in [[http://tools.ietf.org/html/rfc6020#section-7.15][Sec. > 7.15]]: > > If the target node is in another module, then nodes added by the > augmentation MUST NOT be mandatory nodes (see Section 3.1). > > This rule was probably based on the assumption that augments will be used > for really optional data that can be safely ignored. However, as it turned > out, augments have become an essential tool for modular development of YANG > data models. In some cases, the inability to define mandatory nodes in > augments prevents the data modeller from specifying desired schema > constraints. > > For instance, [[ > http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-16#appendix-A][AppendixA]] in "interfaces-cfg" shows how an Ethernet module can be written that > augments "if:interface". However, the container "ethernet" cannot define > any child leafs as mandatory even though it may be necessary and would be > normally done if the "ethernet" container was defined directly in the > "ietf-interfaces" module. > > ** Solution > > Remove the rule cited above. > > In the examples of this sort of augment usage, the augments are in different modules. There is no requirement that a server implement all-or-none of these modules, just because they happen to be published in 1 RFC. The reason this rule exists is so a server implementation of the augmenting module does not break old clients that do not know about this module. They will not provide the mandatory values and edits will fail. (Bonica Principle again). -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > Andy --089e0158a9e4f6af0c04f55da376 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 24, 2014 at 10:03 AM, Ladislav Lhotka <lhotka@nic.cz&g= t; wrote:
* allow mandatory nodes in augments

** Description

RFC 6020 states in [[http://tools.ietf.org/html/rfc6020#section-7.1= 5][Sec. 7.15]]:

=A0 =A0If the target node is in another module, then nodes added by the
=A0 =A0augmentation MUST NOT be mandatory nodes (see Section 3.1).

This rule was probably based on the assumption that augments will be used f= or really optional data that can be safely ignored. However, as it turned o= ut, augments have become an essential tool for modular development of YANG = data models. In some cases, the inability to define mandatory nodes in augm= ents prevents the data modeller from specifying desired schema constraints.=

For instance, [[http://tools.ietf.or= g/html/draft-ietf-netmod-interfaces-cfg-16#appendix-A][Appendix A]] in = "interfaces-cfg" shows how an Ethernet module can be written that= augments "if:interface". However, the container "ethernet&q= uot; cannot define any child leafs as mandatory even though it may be neces= sary and would be normally done if the "ethernet" container was d= efined directly in the "ietf-interfaces" module.

** Solution

Remove the rule cited above.



In the examples of this= sort of augment usage, the augments are in different
modules. = =A0There is no requirement that a server implement all-or-none of
these modules, just because they happen to be published in 1 RFC.

The reason this rule exists is so a server implementation o= f the augmenting module
does not break old clients that do not kn= ow about this module. =A0They will not provide
the mandatory values and edits will fail. (Bonica Principle again).




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



Andy

--089e0158a9e4f6af0c04f55da376-- From nobody Mon Mar 24 12:11:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78D51A02D0 for ; Mon, 24 Mar 2014 12:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYQ62nqsbksF for ; Mon, 24 Mar 2014 12:11:42 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A5BEA1A02B9 for ; Mon, 24 Mar 2014 12:11:42 -0700 (PDT) Received: from [172.20.26.113] (unknown [172.20.20.35]) by mail.nic.cz (Postfix) with ESMTPSA id C5CBB13F908; Mon, 24 Mar 2014 20:11:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395688300; bh=KQDvDnYWZsvG2SH7btmEvcETasQVUGHmRArtR0ajqJo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nqFeTri1SLt+c08M4Udnnzkj7o74DJxLC2nHU2drIn3qEOIwMJtXTZ/5+JXViR1Ju j35SaISg2i9/ivfkeBcp+ZFEAbzyT0uMRVhGBTM3NHqAKh6G8uv0O9enKiP0+Q2ISu rl4opBx3adAsBFVYR6GAJqhkrw+L/791wgnorrRo= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 24 Mar 2014 20:11:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <69BF499A-DD00-450B-AE41-07F937866103@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/XYQUQb0BKW38fhIx5tqgvqeTMZk Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 19:11:44 -0000 On 24 Mar 2014, at 18:33, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Mar 24, 2014 at 10:03 AM, Ladislav Lhotka = wrote: > * allow mandatory nodes in augments >=20 > ** Description >=20 > RFC 6020 states in = [[http://tools.ietf.org/html/rfc6020#section-7.15][Sec. 7.15]]: >=20 > If the target node is in another module, then nodes added by the > augmentation MUST NOT be mandatory nodes (see Section 3.1). >=20 > This rule was probably based on the assumption that augments will be = used for really optional data that can be safely ignored. However, as it = turned out, augments have become an essential tool for modular = development of YANG data models. In some cases, the inability to define = mandatory nodes in augments prevents the data modeller from specifying = desired schema constraints. >=20 > For instance, = [[http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-16#appendix-= A][Appendix A]] in "interfaces-cfg" shows how an Ethernet module can be = written that augments "if:interface". However, the container "ethernet" = cannot define any child leafs as mandatory even though it may be = necessary and would be normally done if the "ethernet" container was = defined directly in the "ietf-interfaces" module. >=20 > ** Solution >=20 > Remove the rule cited above. >=20 >=20 >=20 > In the examples of this sort of augment usage, the augments are in = different > modules. There is no requirement that a server implement all-or-none = of > these modules, just because they happen to be published in 1 RFC. This is not what I am saying. >=20 > The reason this rule exists is so a server implementation of the = augmenting module > does not break old clients that do not know about this module. They = will not provide > the mandatory values and edits will fail. (Bonica Principle again). I don=92t buy this principle. I have already argued that new = non-mandatory data in server=92s model can lead to unexpected = consequences if the client isn=92t aware of them, see http://www.ietf.org/mail-archive/web/netmod/current/msg09296.html Lada >=20 >=20 >=20 >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 > Andy >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 24 12:32:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B991A02C3 for ; Mon, 24 Mar 2014 12:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1FzIEUX38cG for ; Mon, 24 Mar 2014 12:32:42 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 607D21A0293 for ; Mon, 24 Mar 2014 12:32:42 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id D54AC37C316; Mon, 24 Mar 2014 20:32:40 +0100 (CET) Date: Mon, 24 Mar 2014 20:32:40 +0100 (CET) Message-Id: <20140324.203240.140236698.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/In5c60PjK06OgQIymABjzP2YafA Cc: netmod@ietf.org Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 19:32:44 -0000 Hi, Added as issue Y26. /martin Ladislav Lhotka wrote: > * allow mandatory nodes in augments > > ** Description > > RFC 6020 states in > [[http://tools.ietf.org/html/rfc6020#section-7.15][Sec. 7.15]]: > > If the target node is in another module, then nodes added by the > augmentation MUST NOT be mandatory nodes (see Section 3.1). > > This rule was probably based on the assumption that augments will be used for > really optional data that can be safely ignored. However, as it turned out, > augments have become an essential tool for modular development of YANG data > models. In some cases, the inability to define mandatory nodes in augments > prevents the data modeller from specifying desired schema constraints. > > For instance, > [[http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-16#appendix-A][Appendix > A]] in "interfaces-cfg" shows how an Ethernet module can be written that > augments "if:interface". However, the container "ethernet" cannot define any > child leafs as mandatory even though it may be necessary and would be normally > done if the "ethernet" container was defined directly in the "ietf-interfaces" > module. > > ** Solution > > Remove the rule cited above. > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Mon Mar 24 12:50:35 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00821A02D6 for ; Mon, 24 Mar 2014 12:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYAdsXyefUcI for ; Mon, 24 Mar 2014 12:50:27 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1461B1A02D4 for ; Mon, 24 Mar 2014 12:50:26 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id j7so5768162qaq.8 for ; Mon, 24 Mar 2014 12:50:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CLlOaWkV7oEKkK7sOIqqPlwE2tSNdrzoso1eU/qFEOs=; b=Pece40KTZdfPVpVeKB2c92NQ5Wdg8HPoGf96Zc6wDggeI0qIJH1Xp7+t9KICPfpe6G NpNrM0GgcuM1gv4hk6Js11CHzoI217quTI793uLYi2E+HMTAFZEaD8b8n1kmUwqeDBFk agQqtGnxgWm52SbkbhaZmWo703mtCS5J18FCMJDIoVIjqwNB8xoiizuX0G4Tz4wlwVUB 2QTrJdNDJISpQ6A0qbf5XYnBtvPk4qWH4SAJPKwxZnVEh8p3Xh044KyuTkKddB8tPnTI 7A/k/XN/SKRcQS+guGQX1dY5RPkgecPCjvmUss5iRj2q9lQi3g66ml8X5br0aTgSipGJ algg== X-Gm-Message-State: ALoCoQnHwZRrKyHlDcF1+fOFHS5woVcDjOYZf+gU2WKCrWrCCbc61eBtjrMLtMADX0Vb/IlE5yhu MIME-Version: 1.0 X-Received: by 10.140.36.77 with SMTP id o71mr73223636qgo.25.1395690625974; Mon, 24 Mar 2014 12:50:25 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Mon, 24 Mar 2014 12:50:25 -0700 (PDT) In-Reply-To: <69BF499A-DD00-450B-AE41-07F937866103@nic.cz> References: <69BF499A-DD00-450B-AE41-07F937866103@nic.cz> Date: Mon, 24 Mar 2014 12:50:25 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c15fa6fa73e204f55f8b49 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kyuajRf3lGdK-yGlaGk3--s6PCI Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 19:50:32 -0000 --001a11c15fa6fa73e204f55f8b49 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 24, 2014 at 12:11 PM, Ladislav Lhotka wrote: > > On 24 Mar 2014, at 18:33, Andy Bierman wrote: > > > > > > > > > On Mon, Mar 24, 2014 at 10:03 AM, Ladislav Lhotka wrote: > > * allow mandatory nodes in augments > > > > ** Description > > > > RFC 6020 states in [[ > http://tools.ietf.org/html/rfc6020#section-7.15][Sec. 7.15]]: > > > > If the target node is in another module, then nodes added by the > > augmentation MUST NOT be mandatory nodes (see Section 3.1). > > > > This rule was probably based on the assumption that augments will be > used for really optional data that can be safely ignored. However, as it > turned out, augments have become an essential tool for modular development > of YANG data models. In some cases, the inability to define mandatory nodes > in augments prevents the data modeller from specifying desired schema > constraints. > > > > For instance, [[ > http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-16#appendix-A][AppendixA]] in "interfaces-cfg" shows how an Ethernet module can be written that > augments "if:interface". However, the container "ethernet" cannot define > any child leafs as mandatory even though it may be necessary and would be > normally done if the "ethernet" container was defined directly in the > "ietf-interfaces" module. > > > > ** Solution > > > > Remove the rule cited above. > > > > > > > > In the examples of this sort of augment usage, the augments are in > different > > modules. There is no requirement that a server implement all-or-none of > > these modules, just because they happen to be published in 1 RFC. > > This is not what I am saying. > > > > > The reason this rule exists is so a server implementation of the > augmenting module > > does not break old clients that do not know about this module. They > will not provide > > the mandatory values and edits will fail. (Bonica Principle again). > > I don't buy this principle. I have already argued that new non-mandatory > data in server's model can lead to unexpected consequences if the client > isn't aware of them, see > > http://www.ietf.org/mail-archive/web/netmod/current/msg09296.html > > If a new YANG object is defined such that it changes the way an existing YANG object works, then the new object is broken. An old client should be able to configure the objects it already knows and the request should not be rejected because of missing mandatory nodes. The server can pick reasonable defaults for the new objects without an old client needing to be re-coded. A client can use merge instead of replace to make sure that new objects do not get deleted. The new objects can be ignored for editing purposes. This is not true if the merge is rejected because of missing mandatory nodes. Lada > > Andy > > > > > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > Andy > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c15fa6fa73e204f55f8b49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 24, 2014 at 12:11 PM, Ladislav Lhotka <lhotka@nic.cz&g= t; wrote:

On 24 Mar 2014, at 18:33, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Mon, Mar 24, 2014 at 10:03 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> * allow mandatory nodes in augments
>
> ** Description
>
> RFC 6020 states in [[http://tools.ietf.org/html/rfc6020#sectio= n-7.15][Sec. 7.15]]:
>
>    If the target node is in another module, then nodes added= by the
>    augmentation MUST NOT be mandatory nodes (see Section 3.1= ).
>
> This rule was probably based on the assumption that augments will be u= sed for really optional data that can be safely ignored. However, as it tur= ned out, augments have become an essential tool for modular development of = YANG data models. In some cases, the inability to define mandatory nodes in= augments prevents the data modeller from specifying desired schema constra= ints.
>
> For instance, [[http://tools.ie= tf.org/html/draft-ietf-netmod-interfaces-cfg-16#appendix-A][Appendix A]= ] in "interfaces-cfg" shows how an Ethernet module can be written= that augments "if:interface". However, the container "ether= net" cannot define any child leafs as mandatory even though it may be = necessary and would be normally done if the "ethernet" container = was defined directly in the "ietf-interfaces" module.
>
> ** Solution
>
> Remove the rule cited above.
>
>
>
> In the examples of this sort of augment usage, the augments are in dif= ferent
> modules.  There is no requirement that a server implement all-or-= none of
> these modules, just because they happen to be published in 1 RFC.

This is not what I am saying.

>
> The reason this rule exists is so a server implementation of the augme= nting module
> does not break old clients that do not know about this module.  T= hey will not provide
> the mandatory values and edits will fail. (Bonica Principle again).
I don’t buy this principle. I have already argued that new non-mandat= ory data in server’s model can lead to unexpected consequences if the= client isn’t aware of them, see

http://www.ietf.org/mail-archive/web/netmod/current/ms= g09296.html



If a new YANG object is= defined such that it changes the way an existing
YANG object wor= ks, then the new object is broken.

An old client s= hould be able to configure the objects it already knows
and the request should not be rejected because of missing mandatory no= des.

The server can pick reasonable defaults for t= he new objects without
an old client needing to be re-coded. &nbs= p;A client can use merge instead of replace to
make sure that new objects do not get deleted. The new objects can be = ignored
for editing purposes.  This is not true if the merge= is rejected because of missing
mandatory nodes.


Lada



Andy
 

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

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





--001a11c15fa6fa73e204f55f8b49-- From nobody Mon Mar 24 13:48:25 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4A61A028B for ; Mon, 24 Mar 2014 13:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOwIaLMJoqPC for ; Mon, 24 Mar 2014 13:48:19 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6431A0271 for ; Mon, 24 Mar 2014 13:48:18 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 8CA9213F908; Mon, 24 Mar 2014 21:48:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395694095; bh=QAV4WWR2UqEJpvNecHNCUMnXiWlSJsbR/l0Uv1/Vaas=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=sxZN/5YDQ8WIyJOtPDuAVOW8IEt06YyxJrAh+MXCML3Y8guiZfzprRCR3GtTV99W6 j3cyGBZzoeLDRIWXLCPq+AwnMdh2Q7+8s4YFUZhQT0iv2wrkEGul8Nz0EN4WKX7fcW VnScuzouqiw13a30tE8JLUMjLDm+XKfPqGrnoSkk= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 24 Mar 2014 21:48:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <69BF499A-DD00-450B-AE41-07F937866103@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mnJpJlnayzcFYEBvwhm4ZUXoYIo Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 20:48:21 -0000 On 24 Mar 2014, at 20:50, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Mar 24, 2014 at 12:11 PM, Ladislav Lhotka = wrote: >=20 > On 24 Mar 2014, at 18:33, Andy Bierman wrote: >=20 > > > > > > > > On Mon, Mar 24, 2014 at 10:03 AM, Ladislav Lhotka = wrote: > > * allow mandatory nodes in augments > > > > ** Description > > > > RFC 6020 states in = [[http://tools.ietf.org/html/rfc6020#section-7.15][Sec. 7.15]]: > > > > If the target node is in another module, then nodes added by the > > augmentation MUST NOT be mandatory nodes (see Section 3.1). > > > > This rule was probably based on the assumption that augments will be = used for really optional data that can be safely ignored. However, as it = turned out, augments have become an essential tool for modular = development of YANG data models. In some cases, the inability to define = mandatory nodes in augments prevents the data modeller from specifying = desired schema constraints. > > > > For instance, = [[http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-16#appendix-= A][Appendix A]] in "interfaces-cfg" shows how an Ethernet module can be = written that augments "if:interface". However, the container "ethernet" = cannot define any child leafs as mandatory even though it may be = necessary and would be normally done if the "ethernet" container was = defined directly in the "ietf-interfaces" module. > > > > ** Solution > > > > Remove the rule cited above. > > > > > > > > In the examples of this sort of augment usage, the augments are in = different > > modules. There is no requirement that a server implement = all-or-none of > > these modules, just because they happen to be published in 1 RFC. >=20 > This is not what I am saying. >=20 > > > > The reason this rule exists is so a server implementation of the = augmenting module > > does not break old clients that do not know about this module. They = will not provide > > the mandatory values and edits will fail. (Bonica Principle again). >=20 > I don=92t buy this principle. I have already argued that new = non-mandatory data in server=92s model can lead to unexpected = consequences if the client isn=92t aware of them, see >=20 > http://www.ietf.org/mail-archive/web/netmod/current/msg09296.html >=20 >=20 >=20 > If a new YANG object is defined such that it changes the way an = existing > YANG object works, then the new object is broken. >=20 > An old client should be able to configure the objects it already knows > and the request should not be rejected because of missing mandatory = nodes. >=20 > The server can pick reasonable defaults for the new objects without > an old client needing to be re-coded. A client can use merge instead = of replace to > make sure that new objects do not get deleted. The new objects can be = ignored > for editing purposes. This is not true if the merge is rejected = because of missing > mandatory nodes. Let me rephrase the main point of this issue: Significant parts of our = core models are defined inside augments, with more to come (e.g., = modules for all interface type). These parts cannot have mandatory = contents due to that rule from sec. 7.15, which can be a serious = limitation because some parameters simply have no reasonable defaults = and have to be configured. The possibility of supporting old clients = (IMO dubious) does not outweigh this limitation. Lada >=20 >=20 > Lada >=20 >=20 >=20 > Andy > =20 >=20 > > > > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > Andy > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 24 14:14:21 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A7A1A02A0 for ; Mon, 24 Mar 2014 14:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6_keSh_DuJnp for ; Mon, 24 Mar 2014 14:14:15 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 519DF1A028D for ; Mon, 24 Mar 2014 14:14:15 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id A9F6337C316; Mon, 24 Mar 2014 22:14:13 +0100 (CET) Date: Mon, 24 Mar 2014 22:14:13 +0100 (CET) Message-Id: <20140324.221413.405598704.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <69BF499A-DD00-450B-AE41-07F937866103@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_lq36mdaXFFGuPkV2KGbVK3G0SE Cc: netmod@ietf.org Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 21:14:18 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+IE9uIDI0IE1hciAy MDE0LCBhdCAyMDo1MCwgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0K PiANCj4gPiANCj4gPiANCj4gPiANCj4gPiBPbiBNb24sIE1hciAyNCwgMjAxNCBhdCAxMjoxMSBQ TSwgTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gPiANCj4gPiBPbiAy NCBNYXIgMjAxNCwgYXQgMTg6MzMsIEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiB3 cm90ZToNCj4gPiANCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IE9uIE1vbiwgTWFyIDI0LCAy MDE0IGF0IDEwOjAzIEFNLCBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0K PiA+ID4gKiBhbGxvdyBtYW5kYXRvcnkgbm9kZXMgaW4gYXVnbWVudHMNCj4gPiA+DQo+ID4gPiAq KiBEZXNjcmlwdGlvbg0KPiA+ID4NCj4gPiA+IFJGQyA2MDIwIHN0YXRlcyBpbg0KPiA+ID4gW1to dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MDIwI3NlY3Rpb24tNy4xNV1bU2VjLiA3LjE1 XV06DQo+ID4gPg0KPiA+ID4gICAgSWYgdGhlIHRhcmdldCBub2RlIGlzIGluIGFub3RoZXIgbW9k dWxlLCB0aGVuIG5vZGVzIGFkZGVkIGJ5IHRoZQ0KPiA+ID4gICAgYXVnbWVudGF0aW9uIE1VU1Qg Tk9UIGJlIG1hbmRhdG9yeSBub2RlcyAoc2VlIFNlY3Rpb24gMy4xKS4NCj4gPiA+DQo+ID4gPiBU aGlzIHJ1bGUgd2FzIHByb2JhYmx5IGJhc2VkIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgYXVnbWVu dHMgd2lsbCBiZSB1c2VkDQo+ID4gPiBmb3IgcmVhbGx5IG9wdGlvbmFsIGRhdGEgdGhhdCBjYW4g YmUgc2FmZWx5IGlnbm9yZWQuIEhvd2V2ZXIsIGFzIGl0IHR1cm5lZA0KPiA+ID4gb3V0LCBhdWdt ZW50cyBoYXZlIGJlY29tZSBhbiBlc3NlbnRpYWwgdG9vbCBmb3IgbW9kdWxhciBkZXZlbG9wbWVu dCBvZiBZQU5HDQo+ID4gPiBkYXRhIG1vZGVscy4gSW4gc29tZSBjYXNlcywgdGhlIGluYWJpbGl0 eSB0byBkZWZpbmUgbWFuZGF0b3J5IG5vZGVzIGluDQo+ID4gPiBhdWdtZW50cyBwcmV2ZW50cyB0 aGUgZGF0YSBtb2RlbGxlciBmcm9tIHNwZWNpZnlpbmcgZGVzaXJlZCBzY2hlbWENCj4gPiA+IGNv bnN0cmFpbnRzLg0KPiA+ID4NCj4gPiA+IEZvciBpbnN0YW5jZSwNCj4gPiA+IFtbaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2QtaW50ZXJmYWNlcy1jZmctMTYjYXBw ZW5kaXgtQV1bQXBwZW5kaXgNCj4gPiA+IEFdXSBpbiAiaW50ZXJmYWNlcy1jZmciIHNob3dzIGhv dyBhbiBFdGhlcm5ldCBtb2R1bGUgY2FuIGJlIHdyaXR0ZW4gdGhhdA0KPiA+ID4gYXVnbWVudHMg ImlmOmludGVyZmFjZSIuIEhvd2V2ZXIsIHRoZSBjb250YWluZXIgImV0aGVybmV0IiBjYW5ub3Qg ZGVmaW5lDQo+ID4gPiBhbnkgY2hpbGQgbGVhZnMgYXMgbWFuZGF0b3J5IGV2ZW4gdGhvdWdoIGl0 IG1heSBiZSBuZWNlc3NhcnkgYW5kIHdvdWxkIGJlDQo+ID4gPiBub3JtYWxseSBkb25lIGlmIHRo ZSAiZXRoZXJuZXQiIGNvbnRhaW5lciB3YXMgZGVmaW5lZCBkaXJlY3RseSBpbiB0aGUNCj4gPiA+ ICJpZXRmLWludGVyZmFjZXMiIG1vZHVsZS4NCj4gPiA+DQo+ID4gPiAqKiBTb2x1dGlvbg0KPiA+ ID4NCj4gPiA+IFJlbW92ZSB0aGUgcnVsZSBjaXRlZCBhYm92ZS4NCj4gPiA+DQo+ID4gPg0KPiA+ ID4NCj4gPiA+IEluIHRoZSBleGFtcGxlcyBvZiB0aGlzIHNvcnQgb2YgYXVnbWVudCB1c2FnZSwg dGhlIGF1Z21lbnRzIGFyZSBpbg0KPiA+ID4gZGlmZmVyZW50DQo+ID4gPiBtb2R1bGVzLiAgVGhl cmUgaXMgbm8gcmVxdWlyZW1lbnQgdGhhdCBhIHNlcnZlciBpbXBsZW1lbnQgYWxsLW9yLW5vbmUg b2YNCj4gPiA+IHRoZXNlIG1vZHVsZXMsIGp1c3QgYmVjYXVzZSB0aGV5IGhhcHBlbiB0byBiZSBw dWJsaXNoZWQgaW4gMSBSRkMuDQo+ID4gDQo+ID4gVGhpcyBpcyBub3Qgd2hhdCBJIGFtIHNheWlu Zy4NCj4gPiANCj4gPiA+DQo+ID4gPiBUaGUgcmVhc29uIHRoaXMgcnVsZSBleGlzdHMgaXMgc28g YSBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gb2YgdGhlIGF1Z21lbnRpbmcNCj4gPiA+IG1vZHVsZQ0K PiA+ID4gZG9lcyBub3QgYnJlYWsgb2xkIGNsaWVudHMgdGhhdCBkbyBub3Qga25vdyBhYm91dCB0 aGlzIG1vZHVsZS4gIFRoZXkgd2lsbA0KPiA+ID4gbm90IHByb3ZpZGUNCj4gPiA+IHRoZSBtYW5k YXRvcnkgdmFsdWVzIGFuZCBlZGl0cyB3aWxsIGZhaWwuIChCb25pY2EgUHJpbmNpcGxlIGFnYWlu KS4NCj4gPiANCj4gPiBJIGRvbuKAmXQgYnV5IHRoaXMgcHJpbmNpcGxlLiBJIGhhdmUgYWxyZWFk eSBhcmd1ZWQgdGhhdCBuZXcgbm9uLW1hbmRhdG9yeSBkYXRhDQo+ID4gaW4gc2VydmVy4oCZcyBt b2RlbCBjYW4gbGVhZCB0byB1bmV4cGVjdGVkIGNvbnNlcXVlbmNlcyBpZiB0aGUgY2xpZW50IGlz buKAmXQNCj4gPiBhd2FyZSBvZiB0aGVtLCBzZWUNCj4gPiANCj4gPiBodHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNnMDkyOTYuaHRtbA0KPiA+IA0K PiA+IA0KPiA+IA0KPiA+IElmIGEgbmV3IFlBTkcgb2JqZWN0IGlzIGRlZmluZWQgc3VjaCB0aGF0 IGl0IGNoYW5nZXMgdGhlIHdheSBhbiBleGlzdGluZw0KPiA+IFlBTkcgb2JqZWN0IHdvcmtzLCB0 aGVuIHRoZSBuZXcgb2JqZWN0IGlzIGJyb2tlbi4NCj4gPiANCj4gPiBBbiBvbGQgY2xpZW50IHNo b3VsZCBiZSBhYmxlIHRvIGNvbmZpZ3VyZSB0aGUgb2JqZWN0cyBpdCBhbHJlYWR5IGtub3dzDQo+ ID4gYW5kIHRoZSByZXF1ZXN0IHNob3VsZCBub3QgYmUgcmVqZWN0ZWQgYmVjYXVzZSBvZiBtaXNz aW5nIG1hbmRhdG9yeSBub2Rlcy4NCj4gPiANCj4gPiBUaGUgc2VydmVyIGNhbiBwaWNrIHJlYXNv bmFibGUgZGVmYXVsdHMgZm9yIHRoZSBuZXcgb2JqZWN0cyB3aXRob3V0DQo+ID4gYW4gb2xkIGNs aWVudCBuZWVkaW5nIHRvIGJlIHJlLWNvZGVkLiAgQSBjbGllbnQgY2FuIHVzZSBtZXJnZSBpbnN0 ZWFkIG9mDQo+ID4gcmVwbGFjZSB0bw0KPiA+IG1ha2Ugc3VyZSB0aGF0IG5ldyBvYmplY3RzIGRv IG5vdCBnZXQgZGVsZXRlZC4gVGhlIG5ldyBvYmplY3RzIGNhbiBiZSBpZ25vcmVkDQo+ID4gZm9y IGVkaXRpbmcgcHVycG9zZXMuICBUaGlzIGlzIG5vdCB0cnVlIGlmIHRoZSBtZXJnZSBpcyByZWpl Y3RlZCBiZWNhdXNlIG9mDQo+ID4gbWlzc2luZw0KPiA+IG1hbmRhdG9yeSBub2Rlcy4NCj4gDQo+ IExldCBtZSByZXBocmFzZSB0aGUgbWFpbiBwb2ludCBvZiB0aGlzIGlzc3VlOiBTaWduaWZpY2Fu dCBwYXJ0cyBvZiBvdXIgY29yZQ0KPiBtb2RlbHMgYXJlIGRlZmluZWQgaW5zaWRlIGF1Z21lbnRz LCB3aXRoIG1vcmUgdG8gY29tZSAoZS5nLiwgbW9kdWxlcyBmb3IgYWxsDQo+IGludGVyZmFjZSB0 eXBlKS4gVGhlc2UgcGFydHMgY2Fubm90IGhhdmUgbWFuZGF0b3J5IGNvbnRlbnRzIGR1ZSB0byB0 aGF0IHJ1bGUNCj4gZnJvbSBzZWMuIDcuMTUsIHdoaWNoIGNhbiBiZSBhIHNlcmlvdXMgbGltaXRh dGlvbiBiZWNhdXNlIHNvbWUgcGFyYW1ldGVycw0KPiBzaW1wbHkgaGF2ZSBubyByZWFzb25hYmxl IGRlZmF1bHRzIGFuZCBoYXZlIHRvIGJlIGNvbmZpZ3VyZWQuIFRoZSBwb3NzaWJpbGl0eQ0KPiBv ZiBzdXBwb3J0aW5nIG9sZCBjbGllbnRzIChJTU8gZHViaW91cykgZG9lcyBub3Qgb3V0d2VpZ2gg dGhpcyBsaW1pdGF0aW9uLg0KDQpJIGFncmVlIHRoYXQgdGhlIGN1cnJlbnQgcnVsZSBpcyB0b28g bGltaXRpbmcgLSB0aGVyZSBhcmUgY2FzZXMgd2hlcmUNCm1hbmRhdG9yeSBub2RlcyBjYW4gYmUg YWRkZWQgaW4gYSBzYWZlIHdheSwgZS5nLiwgaWYgYSBtb2R1bGUgZm9yDQpldGhlcm5ldCBwYXJh bWV0ZXJzIGRlZmluZXMgYm90aCB0aGUgZXRoZXJuZXQgaWRlbnRpdHksIGFuZCBhdWdtZW50DQpu b2RlcyBiYXNlZCBvbiB0aGlzIGV0aGVybmV0IGlkZW50aXR5Lg0KDQpJZiB3ZSBjYW4gY2FwdHVy ZSB0aGlzLCBJIGFtIGFsbCBmb3IgcmVsYXhpbmcgdGhlIHJ1bGUuICBJIGRvbid0IHRoaW5rDQpq dXN0IHJlbW92aW5nIHRoZSBydWxlIGlzIGEgZ29vZCBpZGVhLg0KDQoNCi9tYXJ0aW4NCg0K From nobody Mon Mar 24 14:30:19 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D08D1A02AF for ; Mon, 24 Mar 2014 14:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXDWgLoA4K0r for ; Mon, 24 Mar 2014 14:30:17 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B7EF81A01CD for ; Mon, 24 Mar 2014 14:30:16 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 5E7A8140075; Mon, 24 Mar 2014 22:30:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395696612; bh=KgX9iDuaPZsDTwlZC2hECtvF5bt1XdqbV9s3/l95lkA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=OtKgwR4jIk88EAjHcElqxRQuRDTL8ig+6VN0yfIG+532OCjh05/IKhvNieRig56ZC MC550NfSNg2/Opsb7Hdb7//ym9edi+Dx6FD/S3AvTJcL2mpkiCsSyvnFCvrbS+WAVZ OZmvXJHw5jgmzpWjPwty9ii9TqQeMtIPbwYdr9bU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140324.221413.405598704.mbj@tail-f.com> Date: Mon, 24 Mar 2014 22:30:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <69BF499A-DD00-450B-AE41-07F937866103@nic.cz> <20140324.221413.405598704.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wiE9j1tco6DjlNUP_UKqOx9q7WE Cc: netmod@ietf.org Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 21:30:19 -0000 On 24 Mar 2014, at 22:14, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On 24 Mar 2014, at 20:50, Andy Bierman wrote: >>=20 >>>=20 >>>=20 >>>=20 >>> On Mon, Mar 24, 2014 at 12:11 PM, Ladislav Lhotka = wrote: >>>=20 >>> On 24 Mar 2014, at 18:33, Andy Bierman wrote: >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Mon, Mar 24, 2014 at 10:03 AM, Ladislav Lhotka = wrote: >>>> * allow mandatory nodes in augments >>>>=20 >>>> ** Description >>>>=20 >>>> RFC 6020 states in >>>> [[http://tools.ietf.org/html/rfc6020#section-7.15][Sec. 7.15]]: >>>>=20 >>>> If the target node is in another module, then nodes added by the >>>> augmentation MUST NOT be mandatory nodes (see Section 3.1). >>>>=20 >>>> This rule was probably based on the assumption that augments will = be used >>>> for really optional data that can be safely ignored. However, as it = turned >>>> out, augments have become an essential tool for modular development = of YANG >>>> data models. In some cases, the inability to define mandatory nodes = in >>>> augments prevents the data modeller from specifying desired schema >>>> constraints. >>>>=20 >>>> For instance, >>>> = [[http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-16#appendix-= A][Appendix >>>> A]] in "interfaces-cfg" shows how an Ethernet module can be written = that >>>> augments "if:interface". However, the container "ethernet" cannot = define >>>> any child leafs as mandatory even though it may be necessary and = would be >>>> normally done if the "ethernet" container was defined directly in = the >>>> "ietf-interfaces" module. >>>>=20 >>>> ** Solution >>>>=20 >>>> Remove the rule cited above. >>>>=20 >>>>=20 >>>>=20 >>>> In the examples of this sort of augment usage, the augments are in >>>> different >>>> modules. There is no requirement that a server implement = all-or-none of >>>> these modules, just because they happen to be published in 1 RFC. >>>=20 >>> This is not what I am saying. >>>=20 >>>>=20 >>>> The reason this rule exists is so a server implementation of the = augmenting >>>> module >>>> does not break old clients that do not know about this module. = They will >>>> not provide >>>> the mandatory values and edits will fail. (Bonica Principle again). >>>=20 >>> I don=92t buy this principle. I have already argued that new = non-mandatory data >>> in server=92s model can lead to unexpected consequences if the = client isn=92t >>> aware of them, see >>>=20 >>> http://www.ietf.org/mail-archive/web/netmod/current/msg09296.html >>>=20 >>>=20 >>>=20 >>> If a new YANG object is defined such that it changes the way an = existing >>> YANG object works, then the new object is broken. >>>=20 >>> An old client should be able to configure the objects it already = knows >>> and the request should not be rejected because of missing mandatory = nodes. >>>=20 >>> The server can pick reasonable defaults for the new objects without >>> an old client needing to be re-coded. A client can use merge = instead of >>> replace to >>> make sure that new objects do not get deleted. The new objects can = be ignored >>> for editing purposes. This is not true if the merge is rejected = because of >>> missing >>> mandatory nodes. >>=20 >> Let me rephrase the main point of this issue: Significant parts of = our core >> models are defined inside augments, with more to come (e.g., modules = for all >> interface type). These parts cannot have mandatory contents due to = that rule >> from sec. 7.15, which can be a serious limitation because some = parameters >> simply have no reasonable defaults and have to be configured. The = possibility >> of supporting old clients (IMO dubious) does not outweigh this = limitation. >=20 > I agree that the current rule is too limiting - there are cases where > mandatory nodes can be added in a safe way, e.g., if a module for > ethernet parameters defines both the ethernet identity, and augment > nodes based on this ethernet identity. Yes, this could be sufficient, though it is not easy to determine what = can be considered safe in general. Lada >=20 > If we can capture this, I am all for relaxing the rule. I don't think > just removing the rule is a good idea. >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 24 14:30:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CAA1A02DD for ; Mon, 24 Mar 2014 14:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHiwrPTU6edK for ; Mon, 24 Mar 2014 14:30:22 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id 403171A01CD for ; Mon, 24 Mar 2014 14:30:22 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id i8so6741574qcq.37 for ; Mon, 24 Mar 2014 14:30:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uMjEun4OX0VYa5Qtu5xEEnr2Twn5/RJB/+yCwdqUSj4=; b=CrVi8YY0fa+U2fIj1D5NtAa53R3ISCPrBpqSRqM5+rSAMYfSB4e+MHjuGNwvZbWSQY jDfxP304ChmTEfTnYSHDWAzM30rPy4bVduU9nswBFlTwSUa5tY9mJj8sAhl2BjTa498A wF1y6ZGjqbqCpkaDodpWE2U8gmwVknffsGutyb0zmeUYqJRHCvf30usdTvdK233mw1S6 s4rWsPeF/S6px7lghbQ3tLZXBALLVETPoC7tFEEkm/pDRsJ8JfQs1LFbfEvwlSrQJxxz 8nxRr1UnIt0ggn7G3fHSb9TSHdg7cHyoqb1mcSD4R40yvkIfgssUKIc2BtOnkqdNUgFG QYoA== X-Gm-Message-State: ALoCoQl7xkLznd9VajHzCBlUphULwIQNM8T4bLD/QjwBqS+EdZOMV4QLVshpSbb5Y3lQRtWfyXtK MIME-Version: 1.0 X-Received: by 10.140.104.103 with SMTP id z94mr5100854qge.91.1395696620732; Mon, 24 Mar 2014 14:30:20 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Mon, 24 Mar 2014 14:30:20 -0700 (PDT) In-Reply-To: References: <69BF499A-DD00-450B-AE41-07F937866103@nic.cz> Date: Mon, 24 Mar 2014 14:30:20 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1134f2be4b1a1d04f560f1aa Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/H4LQxxhL4AiJ1pl-m1ed1ACN6BU Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 21:30:27 -0000 --001a1134f2be4b1a1d04f560f1aa Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 24, 2014 at 1:48 PM, Ladislav Lhotka wrote: > > On 24 Mar 2014, at 20:50, Andy Bierman wrote: > > > > > > > > > On Mon, Mar 24, 2014 at 12:11 PM, Ladislav Lhotka wrote: > > > > On 24 Mar 2014, at 18:33, Andy Bierman wrote: > > > > > > > > > > > > > > On Mon, Mar 24, 2014 at 10:03 AM, Ladislav Lhotka > wrote: > > > * allow mandatory nodes in augments > > > > > > ** Description > > > > > > RFC 6020 states in [[ > http://tools.ietf.org/html/rfc6020#section-7.15][Sec. 7.15]]: > > > > > > If the target node is in another module, then nodes added by the > > > augmentation MUST NOT be mandatory nodes (see Section 3.1). > > > > > > This rule was probably based on the assumption that augments will be > used for really optional data that can be safely ignored. However, as it > turned out, augments have become an essential tool for modular development > of YANG data models. In some cases, the inability to define mandatory nodes > in augments prevents the data modeller from specifying desired schema > constraints. > > > > > > For instance, [[ > http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-16#appendix-A][AppendixA]] in "interfaces-cfg" shows how an Ethernet module can be written that > augments "if:interface". However, the container "ethernet" cannot define > any child leafs as mandatory even though it may be necessary and would be > normally done if the "ethernet" container was defined directly in the > "ietf-interfaces" module. > > > > > > ** Solution > > > > > > Remove the rule cited above. > > > > > > > > > > > > In the examples of this sort of augment usage, the augments are in > different > > > modules. There is no requirement that a server implement all-or-none > of > > > these modules, just because they happen to be published in 1 RFC. > > > > This is not what I am saying. > > > > > > > > The reason this rule exists is so a server implementation of the > augmenting module > > > does not break old clients that do not know about this module. They > will not provide > > > the mandatory values and edits will fail. (Bonica Principle again). > > > > I don't buy this principle. I have already argued that new non-mandatory > data in server's model can lead to unexpected consequences if the client > isn't aware of them, see > > > > http://www.ietf.org/mail-archive/web/netmod/current/msg09296.html > > > > > > > > If a new YANG object is defined such that it changes the way an existing > > YANG object works, then the new object is broken. > > > > An old client should be able to configure the objects it already knows > > and the request should not be rejected because of missing mandatory > nodes. > > > > The server can pick reasonable defaults for the new objects without > > an old client needing to be re-coded. A client can use merge instead of > replace to > > make sure that new objects do not get deleted. The new objects can be > ignored > > for editing purposes. This is not true if the merge is rejected because > of missing > > mandatory nodes. > > Let me rephrase the main point of this issue: Significant parts of our > core models are defined inside augments, with more to come (e.g., modules > for all interface type). These parts cannot have mandatory contents due to > that rule from sec. 7.15, which can be a serious limitation because some > parameters simply have no reasonable defaults and have to be configured. > The possibility of supporting old clients (IMO dubious) does not outweigh > this limitation. > > If all these augments are in the same YANG module then the augment-stmt is not really needed and inline definitions should be used instead. If they are in different modules, then a server vendor may choose to implement the augmenting module in a later release than the base module. It doesn't matter that a bunch of modules are published around the same time. The likely case is that the augmenting module is over a year later. It has nothing to do with YANG 1.0 vs. 1.1. It is a bad idea to break old clients that don't know about the new module. Note that it is possible to add new nodes, such that the sibling/child nodes to the augmented nodes are optional, but their descendant nodes are mandatory. This should be OK. An old client that provides just the base objects in a create or merge will not break if the new mandatory objects are "protected" via an extra layer: container top { leaf old-1 { type string; } } NOT OK: augment /top { leaf from-augment-1 { type string; mandatory true; } } OK: augment /top { container pcon { presence "must exist to make the leaf mandatory"; leaf from-augment-1 { type string; mandatory true; } } } Lada > > > > Andy --001a1134f2be4b1a1d04f560f1aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 24, 2014 at 1:48 PM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 24 Mar 2014, at 20:50, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Mon, Mar 24, 2014 at 12:11 PM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On 24 Mar 2014, at 18:33, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Mon, Mar 24, 2014 at 10:03 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > * allow mandatory nodes in augments
> >
> > ** Description
> >
> > RFC 6020 states in [[http://tools.ietf.org/html/rfc6020#s= ection-7.15][Sec. 7.15]]:
> >
> >    If the target node is in another module, then nodes = added by the
> >    augmentation MUST NOT be mandatory nodes (see Sectio= n 3.1).
> >
> > This rule was probably based on the assumption that augments will= be used for really optional data that can be safely ignored. However, as i= t turned out, augments have become an essential tool for modular developmen= t of YANG data models. In some cases, the inability to define mandatory nod= es in augments prevents the data modeller from specifying desired schema co= nstraints.
> >
> > For instance, [[http://too= ls.ietf.org/html/draft-ietf-netmod-interfaces-cfg-16#appendix-A][Appendix A]] in "interfaces-cfg" shows how an Ethernet module can be wr= itten that augments "if:interface". However, the container "= ethernet" cannot define any child leafs as mandatory even though it ma= y be necessary and would be normally done if the "ethernet" conta= iner was defined directly in the "ietf-interfaces" module.
> >
> > ** Solution
> >
> > Remove the rule cited above.
> >
> >
> >
> > In the examples of this sort of augment usage, the augments are i= n different
> > modules.  There is no requirement that a server implement al= l-or-none of
> > these modules, just because they happen to be published in 1 RFC.=
>
> This is not what I am saying.
>
> >
> > The reason this rule exists is so a server implementation of the = augmenting module
> > does not break old clients that do not know about this module. &n= bsp;They will not provide
> > the mandatory values and edits will fail. (Bonica Principle again= ).
>
> I don’t buy this principle. I have already argued that new non-m= andatory data in server’s model can lead to unexpected consequences i= f the client isn’t aware of them, see
>
> http://www.ietf.org/mail-archive/web/netmod/curre= nt/msg09296.html
>
>
>
> If a new YANG object is defined such that it changes the way an existi= ng
> YANG object works, then the new object is broken.
>
> An old client should be able to configure the objects it already knows=
> and the request should not be rejected because of missing mandatory no= des.
>
> The server can pick reasonable defaults for the new objects without > an old client needing to be re-coded.  A client can use merge ins= tead of replace to
> make sure that new objects do not get deleted. The new objects can be = ignored
> for editing purposes.  This is not true if the merge is rejected = because of missing
> mandatory nodes.

Let me rephrase the main point of this issue: Significant parts of our core= models are defined inside augments, with more to come (e.g., modules for a= ll interface type). These parts cannot have mandatory contents due to that = rule from sec. 7.15, which can be a serious limitation because some paramet= ers simply have no reasonable defaults and have to be configured. The possi= bility of supporting old clients (IMO dubious) does not outweigh this limit= ation.



If all these augments a= re in the same YANG module then the augment-stmt is not
really ne= eded and inline definitions should be used instead.

If they are in different modules, then a server vendor may choose to i= mplement the augmenting
module in a later release than the base m= odule. It doesn't matter that a bunch of modules are
publishe= d around the same time.  The likely case is that the augmenting module= is over a year later.

It has nothing to do with YANG 1.0 vs. 1.1.
I= t is a bad idea to break old clients that don't know about the new modu= le.

Note that it is possible to add new nodes, suc= h that the sibling/child nodes
to the augmented nodes are optional, but their descendant nodes are ma= ndatory.
This should be OK.  An old client that provides jus= t the base objects in a
create or merge will not break if the new= mandatory objects are "protected"
via an extra layer:


  &nb= sp;container top {
      leaf old-1 { type string;= }
   }


NO= T OK:

   augment /top {
       leaf = from-augment-1 {
         type string;
         mandatory true;
 =      }
   }

<= /div>


OK:

   augment /top {
       container pcon {
     = ;      presence "must exist to make the leaf mandatory&= quot;;
 
          l= eaf from-augment-1 {
             type string;
             mandatory true;
=            }
    &n= bsp;   }
    }


=

Lada

>


Andy
&nbs= p;
--001a1134f2be4b1a1d04f560f1aa-- From nobody Tue Mar 25 02:03:53 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF43E1A038C for ; Tue, 25 Mar 2014 02:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RuGJbaRcY4e for ; Tue, 25 Mar 2014 02:03:49 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 325D71A038A for ; Tue, 25 Mar 2014 02:03:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 42162540645; Tue, 25 Mar 2014 10:03:45 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKM0tRxMeZUQ; Tue, 25 Mar 2014 10:03:40 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 705FA540010; Tue, 25 Mar 2014 10:03:38 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20140324.111757.1429730801819634445.mbj@tail-f.com> References: <20140324.111757.1429730801819634445.mbj@tail-f.com> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 25 Mar 2014 10:03:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2-XpVP4HG-0-G7E7o3ZgrZ9iXuk Cc: netmod@ietf.org Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 09:03:52 -0000 Hi, I think the problem of "when" definition is that it is inherently circular: it tries to decide about including a conditional node in the schema by evaluating an XPath expression whose context node is that conditional node. Perhaps the correct solution would be to define the context node to be the closest ancestor data node. And I'd also add another rule that the XPath expression must not involve any node that is directly or indirectly conditional (this also excludes the subtree of the conditional node that is being tested). While this might solve the problem, it would break existing modules - the leading double-dot would have to be removed from all "when" expressions. On the other hand, it would be a correction of an error in the spec. Lada Martin Bjorklund writes: > Ladislav Lhotka wrote: >> Hi, >> >> I think the solution Y18-01 is just hand-waving that raises other >> questions: If the context node is tentatively added to the instance >> document, then with what content? Are mandatory descendants supposed >> to be added as well, do contained defaults apply? > > Y18-01 says: > > This node has no value and no children. > > It is only added in order to have a context node. > >> This can lead to nasty race conditions, for example: >> >> leaf foo { >> when "../bar/baz" = 42"; >> type uint8; >> } >> container bar { >> when "not(../foo = 1)"; >> leaf baz { >> type uint8; >> default 42; >> } >> } >> >> Then, is the data tree fragment >> >> 1 >> >> valid or not? >> >> The thing is, XPath evaluation needs a fixed XML document that has to >> be properly defined (as it is done, e.g., for "must"). Without it, >> standard XPath tools will never work. >> >> My example also shows that it is not sufficient to forbid "when" >> expressions to refer to nodes below the context node - similar >> pathological situations can arise if two nodes or subtrees refer to >> each other in their "when" expressions. >> >> Here is an alternative solution: >> >> ==== >> >> ** Solution Y18-02 >> >> For validation purposes, treat >> >> when ""; >> >> as equivalent to >> >> must " or not(.)"; > > But must expressions are only evaluated if the node exists, so > "not(.)" will always evaluate to false. > > This means that there would be no difference between must and when. > >> This is essentially how RFC 6110 translates "when" to Schematron, >> because there is no other possibility. >> >> What this means is that "when" expressions would not apply in any way >> if the context node is missing (after all defaults "in use" have been >> added). > > This is not the intention of when! Your example above is a good use > case of when: > > container foo { > when ../enabled; > leaf bar { > mandatory true; > ... > } > } > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Mar 25 05:30:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC96B1A00D1 for ; Tue, 25 Mar 2014 05:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cqj0QnbyoUP8 for ; Tue, 25 Mar 2014 05:29:21 -0700 (PDT) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id ABB251A00CA for ; Tue, 25 Mar 2014 05:29:21 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id i13so344746qae.19 for ; Tue, 25 Mar 2014 05:29:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0AmQI5n+LREXUFFd+NnfgBYYZna61o07CJ0wCMnaNGk=; b=VccrI5el8a60x4cn6PQs0WvXslS3y72wzQ7CBKo5vpq3USP/1HUeQ1ZdfGLvjxB3Y5 BCuCVa+iEk0aW++HUPHBdEx8WzOYEfxGBCkOXOZLQeTbzskJBT3qaEVqgoVbbcSnOSWY GZzegcIDocZoPoXbR9mdjYPPf60LRzKcqwe3aQu0ZovPP3XML/GHAPlvgn7/yRoFGJ8Q J+2jMN+UI3hhOkN37LHTd4aIyaoGEpopgHBl4dIifQkoP4FKSN5n1lgq1xi4z3CCLkTj 2zJJT3geZ0k/AtN9gEAn+yzgnInVsJvcpWBwOsPmW/+FrpM2GZyjIFIhPgzf/ArWxqbe dSHg== X-Gm-Message-State: ALoCoQmf2RjW5D0oIuj+b1tyUnYwxGmNWfhR4CSXFTtHIKTYak7t+2hmKvsAX6EOEHD2ybwfb7D6 MIME-Version: 1.0 X-Received: by 10.224.130.8 with SMTP id q8mr1525139qas.99.1395750559984; Tue, 25 Mar 2014 05:29:19 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Tue, 25 Mar 2014 05:29:19 -0700 (PDT) In-Reply-To: References: <20140324.111757.1429730801819634445.mbj@tail-f.com> Date: Tue, 25 Mar 2014 05:29:19 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c2b34e52bfc204f56d8038 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/dQESFGsKr1VH13hWySF2hBzWUzQ Cc: "netmod@ietf.org" Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 12:29:25 -0000 --001a11c2b34e52bfc204f56d8038 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 25, 2014 at 2:03 AM, Ladislav Lhotka wrote: > Hi, > > I think the problem of "when" definition is that it is inherently > circular: it tries to decide about including a conditional node in the > schema by evaluating an XPath expression whose context node is that > conditional node. > > Perhaps the correct solution would be to define the context node to be the > closest ancestor data node. > And I'd also add another rule that the XPath expression must not involve > any node that is directly or indirectly conditional (this also excludes the > subtree of the conditional node that is being tested). > > While this might solve the problem, it would break existing modules - the > leading double-dot would have to be removed from all "when" expressions. On > the other hand, it would be a correction of an error in the spec. > > I am against breaking all when-stmts and changing the way they work. Implementation of the when-stmt in a real server is difficult. So what's your point? It is not an error in the spec. It's just difficult code. The priority for ease of use is readers, writers and lastly, tool developers. It seems you want to make YANG very difficult to write in order to simplify tool development. The when-stmt is worse than circular. It is nested + circular. Any modification to the datastore might cause a when-stmt to change state. Any deletion of a false when-stmt might cause other nodes when-stmt value to change. It is possible to construct pathological cases that never resolve, no matter how you iterate through the when-stmt tests. Lada > Andy > > Martin Bjorklund writes: > > > Ladislav Lhotka wrote: > >> Hi, > >> > >> I think the solution Y18-01 is just hand-waving that raises other > >> questions: If the context node is tentatively added to the instance > >> document, then with what content? Are mandatory descendants supposed > >> to be added as well, do contained defaults apply? > > > > Y18-01 says: > > > > This node has no value and no children. > > > > It is only added in order to have a context node. > > > >> This can lead to nasty race conditions, for example: > >> > >> leaf foo { > >> when "../bar/baz" = 42"; > >> type uint8; > >> } > >> container bar { > >> when "not(../foo = 1)"; > >> leaf baz { > >> type uint8; > >> default 42; > >> } > >> } > >> > >> Then, is the data tree fragment > >> > >> 1 > >> > >> valid or not? > >> > >> The thing is, XPath evaluation needs a fixed XML document that has to > >> be properly defined (as it is done, e.g., for "must"). Without it, > >> standard XPath tools will never work. > >> > >> My example also shows that it is not sufficient to forbid "when" > >> expressions to refer to nodes below the context node - similar > >> pathological situations can arise if two nodes or subtrees refer to > >> each other in their "when" expressions. > >> > >> Here is an alternative solution: > >> > >> ==== > >> > >> ** Solution Y18-02 > >> > >> For validation purposes, treat > >> > >> when ""; > >> > >> as equivalent to > >> > >> must " or not(.)"; > > > > But must expressions are only evaluated if the node exists, so > > "not(.)" will always evaluate to false. > > > > This means that there would be no difference between must and when. > > > >> This is essentially how RFC 6110 translates "when" to Schematron, > >> because there is no other possibility. > >> > >> What this means is that "when" expressions would not apply in any way > >> if the context node is missing (after all defaults "in use" have been > >> added). > > > > This is not the intention of when! Your example above is a good use > > case of when: > > > > container foo { > > when ../enabled; > > leaf bar { > > mandatory true; > > ... > > } > > } > > > > > > /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c2b34e52bfc204f56d8038 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Mar 25, 2014 at 2:03 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:
Hi,

I think the problem of "when" definition is that it is inherently= circular: it tries to decide about including a conditional node in the sch= ema by evaluating an XPath expression whose context node is that conditiona= l node.

Perhaps the correct solution would be to define the context node to be the = closest ancestor data node.
And I'd also add another rule that the XPath expression must not involv= e any node that is directly or indirectly conditional (this also excludes t= he subtree of the conditional node that is being tested).

While this might solve the problem, it would break existing modules - the l= eading double-dot would have to be removed from all "when" expres= sions. On the other hand, it would be a correction of an error in the spec.=


I am against breaking all when-stmts a= nd changing the way they work.
Implementation of the when-stmt in= a real server is difficult. =A0So what's your point?
It is n= ot an error in the spec. It's just difficult code.

The priority for ease of use is readers, writers and la= stly, tool developers.
It seems you want to make YANG very diffic= ult to write in order to
simplify tool development. =A0

The when-stmt is worse than circular. =A0It is nested + circ= ular.
Any modification to the datastore might cause a when-stmt t= o
change state. =A0Any deletion of a false when-stmt might cause<= /div>
other nodes when-stmt value to change. =A0It is possible to construct<= /div>
pathological cases that never resolve, no matter how you iterate<= /div>
through the when-stmt tests.


Lada


Andy

=
=A0

Martin Bjorklund <mbj@tail-f.com&g= t; writes:

> Ladislav Lhotka <lhotka@nic.cz= > wrote:
>> Hi,
>>
>> I think the solution Y18-01 is just hand-waving that raises other<= br> >> questions: If the context node is tentatively added to the instanc= e
>> document, then with what content? Are mandatory descendants suppos= ed
>> to be added as well, do contained defaults apply?
>
> Y18-01 says:
>
> =A0 This node has no value and no children.
>
> It is only added in order to have a context node.
>
>> This can lead to nasty race conditions, for example:
>>
>> leaf foo {
>> =A0 =A0 when "../bar/baz" =3D 42";
>> =A0 =A0 type uint8;
>> }
>> container bar {
>> =A0 =A0 when "not(../foo =3D 1)";
>> =A0 =A0 leaf baz {
>> =A0 =A0 =A0 =A0 type uint8;
>> =A0 =A0 =A0 =A0 default 42;
>> =A0 =A0 }
>> }
>>
>> Then, is the data tree fragment
>>
>> <foo>1</foo>
>>
>> valid or not?
>>
>> The thing is, XPath evaluation needs a fixed XML document that has= to
>> be properly defined (as it is done, e.g., for "must"). W= ithout it,
>> standard XPath tools will never work.
>>
>> My example also shows that it is not sufficient to forbid "wh= en"
>> expressions to refer to nodes below the context node - similar
>> pathological situations can arise if two nodes or subtrees refer t= o
>> each other in their "when" expressions.
>>
>> Here is an alternative solution:
>>
>> =3D=3D=3D=3D
>>
>> ** Solution Y18-02
>>
>> For validation purposes, treat
>>
>> when "<expression>";
>>
>> as equivalent to
>>
>> must "<expression> or not(.)";
>
> But must expressions are only evaluated if the node exists, so
> "not(.)" will always evaluate to false.
>
> This means that there would be no difference between must and when. >
>> This is essentially how RFC 6110 translates "when" to Sc= hematron,
>> because there is no other possibility.
>>
>> What this means is that "when" expressions would not app= ly in any way
>> if the context node is missing (after all defaults "in use&qu= ot; have been
>> added).
>
> This is not the intention of when! =A0Your example above is a good use=
> case of when:
>
> =A0 container foo {
> =A0 =A0 when ../enabled;
> =A0 =A0 leaf bar {
> =A0 =A0 =A0 mandatory true;
> =A0 =A0 =A0 ...
> =A0 =A0 }
> =A0 }
>
>
> /martin

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

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

--001a11c2b34e52bfc204f56d8038-- From nobody Tue Mar 25 07:14:30 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759E21A0153 for ; Tue, 25 Mar 2014 07:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1Y06qnHg4G1 for ; Tue, 25 Mar 2014 07:14:26 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id F14C81A014D for ; Tue, 25 Mar 2014 07:14:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id AEB5E540645; Tue, 25 Mar 2014 15:14:23 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0V5t5j-HeA5; Tue, 25 Mar 2014 15:14:17 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 1BBC55400BA; Tue, 25 Mar 2014 15:14:16 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <20140324.111757.1429730801819634445.mbj@tail-f.com> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 25 Mar 2014 15:14:15 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/V-PHfIacEHOWkiNJ1CK6epaDs3Y Cc: "netmod@ietf.org" Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 14:14:29 -0000 Andy Bierman writes: > On Tue, Mar 25, 2014 at 2:03 AM, Ladislav Lhotka wrote: > >> Hi, >> >> I think the problem of "when" definition is that it is inherently >> circular: it tries to decide about including a conditional node in the >> schema by evaluating an XPath expression whose context node is that >> conditional node. >> >> Perhaps the correct solution would be to define the context node to be the >> closest ancestor data node. >> And I'd also add another rule that the XPath expression must not involve >> any node that is directly or indirectly conditional (this also excludes the >> subtree of the conditional node that is being tested). >> >> While this might solve the problem, it would break existing modules - the >> leading double-dot would have to be removed from all "when" expressions. On >> the other hand, it would be a correction of an error in the spec. >> >> > I am against breaking all when-stmts and changing the way they work. > Implementation of the when-stmt in a real server is difficult. So what's > your point? > It is not an error in the spec. It's just difficult code. I disagree, of course. Issue Y18 is real, and it describes an error in the spec. > > The priority for ease of use is readers, writers and lastly, tool > developers. > It seems you want to make YANG very difficult to write in order to > simplify tool development. I want a precise specification that leaves no doubts about how tools are supposed to behave. We have seen already several times that vague formulations led to different results. Moreover, my proposal would actually simplify the spec because the closest ancestor data node would now be the context node for all uses of "when" - in data nodes, choice, uses and augment. > > The when-stmt is worse than circular. It is nested + circular. > Any modification to the datastore might cause a when-stmt to > change state. Any deletion of a false when-stmt might cause > other nodes when-stmt value to change. It is possible to construct > pathological cases that never resolve, no matter how you iterate > through the when-stmt tests. That's why I also proposed that XPath expressions in "when" must not refer to any conditional nodes (that may or may not exist depending on another "when"). This should eliminate such ripple efects. Lada > > > Lada >> > > > Andy > > > >> >> Martin Bjorklund writes: >> >> > Ladislav Lhotka wrote: >> >> Hi, >> >> >> >> I think the solution Y18-01 is just hand-waving that raises other >> >> questions: If the context node is tentatively added to the instance >> >> document, then with what content? Are mandatory descendants supposed >> >> to be added as well, do contained defaults apply? >> > >> > Y18-01 says: >> > >> > This node has no value and no children. >> > >> > It is only added in order to have a context node. >> > >> >> This can lead to nasty race conditions, for example: >> >> >> >> leaf foo { >> >> when "../bar/baz" = 42"; >> >> type uint8; >> >> } >> >> container bar { >> >> when "not(../foo = 1)"; >> >> leaf baz { >> >> type uint8; >> >> default 42; >> >> } >> >> } >> >> >> >> Then, is the data tree fragment >> >> >> >> 1 >> >> >> >> valid or not? >> >> >> >> The thing is, XPath evaluation needs a fixed XML document that has to >> >> be properly defined (as it is done, e.g., for "must"). Without it, >> >> standard XPath tools will never work. >> >> >> >> My example also shows that it is not sufficient to forbid "when" >> >> expressions to refer to nodes below the context node - similar >> >> pathological situations can arise if two nodes or subtrees refer to >> >> each other in their "when" expressions. >> >> >> >> Here is an alternative solution: >> >> >> >> ==== >> >> >> >> ** Solution Y18-02 >> >> >> >> For validation purposes, treat >> >> >> >> when ""; >> >> >> >> as equivalent to >> >> >> >> must " or not(.)"; >> > >> > But must expressions are only evaluated if the node exists, so >> > "not(.)" will always evaluate to false. >> > >> > This means that there would be no difference between must and when. >> > >> >> This is essentially how RFC 6110 translates "when" to Schematron, >> >> because there is no other possibility. >> >> >> >> What this means is that "when" expressions would not apply in any way >> >> if the context node is missing (after all defaults "in use" have been >> >> added). >> > >> > This is not the intention of when! Your example above is a good use >> > case of when: >> > >> > container foo { >> > when ../enabled; >> > leaf bar { >> > mandatory true; >> > ... >> > } >> > } >> > >> > >> > /martin >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Mar 25 07:41:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9085B1A0150 for ; Tue, 25 Mar 2014 07:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ_b1CccHcsC for ; Tue, 25 Mar 2014 07:41:29 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id 281891A014B for ; Tue, 25 Mar 2014 07:41:29 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id j15so577483qaq.30 for ; Tue, 25 Mar 2014 07:41:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=umpb5ZSE3hke4TVRoGGfrsi4tlnUNW5Buh6NXo6zZgw=; b=hFKFIVhrh10nijAALPSzOBnHLAYsVULbdT0+g3Ip0ayXs2WW48c+XY0k8GzctsLV7K ikHn2b99kUsuPf/LBzraUnPxfhmzsdvpunR2MpgR39L7M9YNy0pUCCVbsHErRfq80Njb U8CrXHQ8odv9dvhE/pW0NCRUiBOxLEJKB46e8vX6LEkAcFy6SH9xm0JodnfyJtK0nFyG zNcG9ZnXgfgWqxnZCWG0B/sXKmIf7CrXKpsdDmbyskgxrIyfc009tHkTNRt/s142wAbe oSYWctrBBDf5jeIWvOesA83hswfSppheBqKneTYFp9rGeQoYxBBePaZIPIQgK4FAUKQI LH7Q== X-Gm-Message-State: ALoCoQm7psI2Zk9vkpStveQ8TQw8VBtxWQZ+qPrYSIDLTRVJsFojAUzJAFrgaBCYZSAGBw9t1gZY MIME-Version: 1.0 X-Received: by 10.140.27.193 with SMTP id 59mr78080858qgx.18.1395758487807; Tue, 25 Mar 2014 07:41:27 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Tue, 25 Mar 2014 07:41:27 -0700 (PDT) In-Reply-To: References: <20140324.111757.1429730801819634445.mbj@tail-f.com> Date: Tue, 25 Mar 2014 07:41:27 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c1233adc568504f56f5886 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qhsBaDJEfyHJ2fR-o-v54UlE6Ts Cc: "netmod@ietf.org" Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 14:41:32 -0000 --001a11c1233adc568504f56f5886 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 25, 2014 at 7:14 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Tue, Mar 25, 2014 at 2:03 AM, Ladislav Lhotka wrote: > > > >> Hi, > >> > >> I think the problem of "when" definition is that it is inherently > >> circular: it tries to decide about including a conditional node in the > >> schema by evaluating an XPath expression whose context node is that > >> conditional node. > >> > >> Perhaps the correct solution would be to define the context node to be > the > >> closest ancestor data node. > >> And I'd also add another rule that the XPath expression must not involve > >> any node that is directly or indirectly conditional (this also excludes > the > >> subtree of the conditional node that is being tested). > >> > >> While this might solve the problem, it would break existing modules - > the > >> leading double-dot would have to be removed from all "when" > expressions. On > >> the other hand, it would be a correction of an error in the spec. > >> > >> > > I am against breaking all when-stmts and changing the way they work. > > Implementation of the when-stmt in a real server is difficult. So what's > > your point? > > It is not an error in the spec. It's just difficult code. > > I disagree, of course. Issue Y18 is real, and it describes an error in the > spec. > > I think the text is clear. The when expression is obviously processed before the context node exists. It is the test to determine if the node should exist or not. Otherwise it would be identical to the must-stmt. The pathological cases are probably unimplementable. It would require that all the when-stmts be processed simultaneously instead of 1 at a time. Fortunately the pathological loops are not operationally useful, so they do not really show up. > > > > The priority for ease of use is readers, writers and lastly, tool > > developers. > > It seems you want to make YANG very difficult to write in order to > > simplify tool development. > > I want a precise specification that leaves no doubts about how tools are > supposed to behave. We have seen already several times that vague > formulations led to different results. > > I want a data modeling language that is easy to use for readers and writers. Changing the context node would be non-intuitive. It also prevents when-stmt from being used inside groupings where the parent node has not been set. > Moreover, my proposal would actually simplify the spec because the closest > ancestor data node would now be the context node for all uses of "when" - > in data nodes, choice, uses and augment. > > It would make it very difficult to write modular and reusable data definitions. A when-stmt can point at a conditional node. It would be a problem if there were loops, but that is not how when-stmt gets used. > > > The when-stmt is worse than circular. It is nested + circular. > > Any modification to the datastore might cause a when-stmt to > > change state. Any deletion of a false when-stmt might cause > > other nodes when-stmt value to change. It is possible to construct > > pathological cases that never resolve, no matter how you iterate > > through the when-stmt tests. > > That's why I also proposed that XPath expressions in "when" must not refer > to any conditional nodes (that may or may not exist depending on another > "when"). This should eliminate such ripple efects. > It would make YANG too difficult to use. > > Lada > Andy --001a11c1233adc568504f56f5886 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Mar 25, 2014 at 7:14 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:
Andy Bierman <andy@yumaworks.com> writes:

> On Tue, Mar 25, 2014 at 2:03 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
>> Hi,
>>
>> I think the problem of "when" definition is that it is i= nherently
>> circular: it tries to decide about including a conditional node in= the
>> schema by evaluating an XPath expression whose context node is tha= t
>> conditional node.
>>
>> Perhaps the correct solution would be to define the context node t= o be the
>> closest ancestor data node.
>> And I'd also add another rule that the XPath expression must n= ot involve
>> any node that is directly or indirectly conditional (this also exc= ludes the
>> subtree of the conditional node that is being tested).
>>
>> While this might solve the problem, it would break existing module= s - the
>> leading double-dot would have to be removed from all "when&qu= ot; expressions. On
>> the other hand, it would be a correction of an error in the spec.<= br> >>
>>
> I am against breaking all when-stmts and changing the way they work. > Implementation of the when-stmt in a real server is difficult. =A0So w= hat's
> your point?
> It is not an error in the spec. It's just difficult code.

I disagree, of course. Issue Y18 is real, and it describes an error in the = spec.



I think the text is cle= ar. =A0The when expression is obviously processed before
the cont= ext node exists. =A0It is the test to determine if the node should exist or= not.
Otherwise it would be identical to the must-stmt.

=
The pathological cases are probably unimplementable.
It woul= d require that all the when-stmts be processed simultaneously
instead of 1 at a time. =A0Fortunately the pathological loops are not
=
operationally useful, so they do not really show up.

=A0
>
> The priority for ease of use is readers, writers and lastly, tool
> developers.
> It seems you want to make YANG very difficult to write in order to
> simplify tool development.

I want a precise specification that leaves no doubts about how tools are su= pposed to behave. We have seen already several times that vague formulation= s led to different results.


I want a data modeling language that i= s easy to use for readers and writers.
Changing the context node = would be non-intuitive. =A0It also prevents when-stmt
from being = used inside groupings where the parent node has not been set.

=A0
Moreover, my proposal would actually simplify the spec because the closest = ancestor data node would now be the context node for all uses of "when= " - in data nodes, choice, uses and augment.


It would make it very difficult to wri= te modular and reusable data definitions.
A when-stmt can point a= t a conditional node. =A0It would be a problem if there
were loop= s, but that is not how when-stmt gets used.



>
> The when-stmt is worse than circular. =A0It is nested + circular.
> Any modification to the datastore might cause a when-stmt to
> change state. =A0Any deletion of a false when-stmt might cause
> other nodes when-stmt value to change. =A0It is possible to construct<= br> > pathological cases that never resolve, no matter how you iterate
> through the when-stmt tests.

That's why I also proposed that XPath expressions in "when" m= ust not refer to any conditional nodes (that may or may not exist depending= on another "when"). This should eliminate such ripple efects.

It would make YANG too difficult to use.
=A0

Lada

Andy

--001a11c1233adc568504f56f5886-- From nobody Tue Mar 25 07:50:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB901A0160 for ; Tue, 25 Mar 2014 07:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rLs8Yhe8Ec1 for ; Tue, 25 Mar 2014 07:50:08 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id AD2141A0133 for ; Tue, 25 Mar 2014 07:50:07 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C2CF913F7D4; Tue, 25 Mar 2014 15:50:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395759006; bh=Rv4COGco6MXnnFCUcpK05NB+XbeJUaBuNCcELU8LNlE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=U0Q0SDULmGnUhKYpxtz8kIgyG6Lxu/0JDEDzQIf2p+a5ETlyRwMrxEfzC/jLdgL1Z np1wlr5n0HPLY+ui3nh1OV2p1rHJhlMjMYsWreycSkfJUuB8f2WaMfy6KWZH0z5VTi 28NqYlTKUr/i6dOM2WPZ53Bap7TVSFe7lDTfZiq4= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 25 Mar 2014 15:50:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6497C153-01EF-4266-B944-40FACD7052E8@nic.cz> References: <20140324.111757.1429730801819634445.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wD14KGGnM9EJ1bWv_TLfzGoTQPg Cc: "netmod@ietf.org" Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 14:50:10 -0000 On 25 Mar 2014, at 15:41, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Mar 25, 2014 at 7:14 AM, Ladislav Lhotka = wrote: > Andy Bierman writes: >=20 > > On Tue, Mar 25, 2014 at 2:03 AM, Ladislav Lhotka = wrote: > > > >> Hi, > >> > >> I think the problem of "when" definition is that it is inherently > >> circular: it tries to decide about including a conditional node in = the > >> schema by evaluating an XPath expression whose context node is that > >> conditional node. > >> > >> Perhaps the correct solution would be to define the context node to = be the > >> closest ancestor data node. > >> And I'd also add another rule that the XPath expression must not = involve > >> any node that is directly or indirectly conditional (this also = excludes the > >> subtree of the conditional node that is being tested). > >> > >> While this might solve the problem, it would break existing modules = - the > >> leading double-dot would have to be removed from all "when" = expressions. On > >> the other hand, it would be a correction of an error in the spec. > >> > >> > > I am against breaking all when-stmts and changing the way they work. > > Implementation of the when-stmt in a real server is difficult. So = what's > > your point? > > It is not an error in the spec. It's just difficult code. >=20 > I disagree, of course. Issue Y18 is real, and it describes an error in = the spec. >=20 >=20 >=20 > I think the text is clear. The when expression is obviously processed = before > the context node exists. It is the test to determine if the node = should exist or not. Xpath evaluation needs a context node, or else it is ill-defined. > Otherwise it would be identical to the must-stmt. Yes, this is what DSDL validation does - it has to because it relies on = standard XPath processors that cannot juggle with temporarily added = nodes.=20 >=20 > The pathological cases are probably unimplementable. > It would require that all the when-stmts be processed simultaneously > instead of 1 at a time. Fortunately the pathological loops are not > operationally useful, so they do not really show up. >=20 > =20 > > > > The priority for ease of use is readers, writers and lastly, tool > > developers. > > It seems you want to make YANG very difficult to write in order to > > simplify tool development. >=20 > I want a precise specification that leaves no doubts about how tools = are supposed to behave. We have seen already several times that vague = formulations led to different results. >=20 >=20 > I want a data modeling language that is easy to use for readers and = writers. > Changing the context node would be non-intuitive. It also prevents = when-stmt > from being used inside groupings where the parent node has not been = set. >=20 > =20 > Moreover, my proposal would actually simplify the spec because the = closest ancestor data node would now be the context node for all uses of = "when" - in data nodes, choice, uses and augment. >=20 >=20 > It would make it very difficult to write modular and reusable data = definitions. > A when-stmt can point at a conditional node. It would be a problem if = there > were loops, but that is not how when-stmt gets used. >=20 >=20 >=20 > > > > The when-stmt is worse than circular. It is nested + circular. > > Any modification to the datastore might cause a when-stmt to > > change state. Any deletion of a false when-stmt might cause > > other nodes when-stmt value to change. It is possible to construct > > pathological cases that never resolve, no matter how you iterate > > through the when-stmt tests. >=20 > That's why I also proposed that XPath expressions in "when" must not = refer to any conditional nodes (that may or may not exist depending on = another "when"). This should eliminate such ripple efects. >=20 > It would make YANG too difficult to use. Why? I am pretty sure all uses of =93when=94 in our core modules already = follow these rules. Lada=20 > =20 >=20 > Lada >=20 > Andy >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Mar 25 08:10:25 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042121A01A6 for ; Tue, 25 Mar 2014 08:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKA7Gstny2FI for ; Tue, 25 Mar 2014 08:09:53 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 560AD1A0178 for ; Tue, 25 Mar 2014 08:09:42 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id m20so717433qcx.24 for ; Tue, 25 Mar 2014 08:09:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pIsRGLYVPtxqbNADya6o9tuySHSmiU8ZpmeTDE91f6g=; b=ac6YtW5jr0sHI6tDRUlBNDicAsG2AGSUm5T3Wsa8njVQBd/61K8K/RxKxT8YAz2nt5 lN2x04aypWTwzKvQ+CAKiM3QicO0pp7XBpsPIE/ZhqoGPYsaP3KVFQOU5g3cOmzfT414 oHqs+D67QQQK3bwTBrZ/vlRaiHxGRguSRoQB0HqUDNmDSjznNxw6XgusffVVD5AYVYYJ AYv+qDmagvmZ8P7Cb71KYpH/5pzkRFwwBnDkLFhgnmTgVRDCAvcvI5mEy/usxtV+n+t0 HmzzsYKB8fQobCXUnU9I8CqvzDjZO+tVBORhLWsVwid+U/lq+NKhIgJquq3gVcElNSMS V1uQ== X-Gm-Message-State: ALoCoQmpdLky66ykDSvl4KBvmG6RxH09p9EjYX9PRFGM+qf8SEPRtM1SwIYsKQxeuIbw9FQjwRyF MIME-Version: 1.0 X-Received: by 10.140.27.193 with SMTP id 59mr78274804qgx.18.1395760180627; Tue, 25 Mar 2014 08:09:40 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Tue, 25 Mar 2014 08:09:40 -0700 (PDT) In-Reply-To: <6497C153-01EF-4266-B944-40FACD7052E8@nic.cz> References: <20140324.111757.1429730801819634445.mbj@tail-f.com> <6497C153-01EF-4266-B944-40FACD7052E8@nic.cz> Date: Tue, 25 Mar 2014 08:09:40 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c1233ac2196f04f56fbdaa Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hpRa0GOhgeItxQ7nEZiEa07F2T4 Cc: "netmod@ietf.org" Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 15:10:12 -0000 --001a11c1233ac2196f04f56fbdaa Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 25, 2014 at 7:50 AM, Ladislav Lhotka wrote: > > On 25 Mar 2014, at 15:41, Andy Bierman wrote: > > > > > > > > > On Tue, Mar 25, 2014 at 7:14 AM, Ladislav Lhotka wrote: > > Andy Bierman writes: > > > > > On Tue, Mar 25, 2014 at 2:03 AM, Ladislav Lhotka > wrote: > > > > > >> Hi, > > >> > > >> I think the problem of "when" definition is that it is inherently > > >> circular: it tries to decide about including a conditional node in the > > >> schema by evaluating an XPath expression whose context node is that > > >> conditional node. > > >> > > >> Perhaps the correct solution would be to define the context node to > be the > > >> closest ancestor data node. > > >> And I'd also add another rule that the XPath expression must not > involve > > >> any node that is directly or indirectly conditional (this also > excludes the > > >> subtree of the conditional node that is being tested). > > >> > > >> While this might solve the problem, it would break existing modules - > the > > >> leading double-dot would have to be removed from all "when" > expressions. On > > >> the other hand, it would be a correction of an error in the spec. > > >> > > >> > > > I am against breaking all when-stmts and changing the way they work. > > > Implementation of the when-stmt in a real server is difficult. So > what's > > > your point? > > > It is not an error in the spec. It's just difficult code. > > > > I disagree, of course. Issue Y18 is real, and it describes an error in > the spec. > > > > > > > > I think the text is clear. The when expression is obviously processed > before > > the context node exists. It is the test to determine if the node should > exist or not. > > Xpath evaluation needs a context node, or else it is ill-defined. > > It is defined. > > Otherwise it would be identical to the must-stmt. > > Yes, this is what DSDL validation does - it has to because it relies on > standard XPath processors that cannot juggle with temporarily added nodes. > > This is not correct though. It is just an implementation detail to construct a new document with the context node in that document. Then process the new document with the standard XPath tool. > > > > The pathological cases are probably unimplementable. > > It would require that all the when-stmts be processed simultaneously > > instead of 1 at a time. Fortunately the pathological loops are not > > operationally useful, so they do not really show up. > > > > > > > > > > The priority for ease of use is readers, writers and lastly, tool > > > developers. > > > It seems you want to make YANG very difficult to write in order to > > > simplify tool development. > > > > I want a precise specification that leaves no doubts about how tools are > supposed to behave. We have seen already several times that vague > formulations led to different results. > > > > > > I want a data modeling language that is easy to use for readers and > writers. > > Changing the context node would be non-intuitive. It also prevents > when-stmt > > from being used inside groupings where the parent node has not been set. > > > > > > Moreover, my proposal would actually simplify the spec because the > closest ancestor data node would now be the context node for all uses of > "when" - in data nodes, choice, uses and augment. > > > > > > It would make it very difficult to write modular and reusable data > definitions. > > A when-stmt can point at a conditional node. It would be a problem if > there > > were loops, but that is not how when-stmt gets used. > > > > > > > > > > > > The when-stmt is worse than circular. It is nested + circular. > > > Any modification to the datastore might cause a when-stmt to > > > change state. Any deletion of a false when-stmt might cause > > > other nodes when-stmt value to change. It is possible to construct > > > pathological cases that never resolve, no matter how you iterate > > > through the when-stmt tests. > > > > That's why I also proposed that XPath expressions in "when" must not > refer to any conditional nodes (that may or may not exist depending on > another "when"). This should eliminate such ripple efects. > > > > It would make YANG too difficult to use. > > Why? I am pretty sure all uses of "when" in our core modules already > follow these rules. > > There is no implementation problem unless there are loops (A --> B --> C --> A). The normal case (A --> B --> C) is not a problem. It can happen quite easily. Changing the context node to the ancestor breaks when-stmt for groupings: grouping foo { leaf X { when "../Y = 10"; type string; } leaf Y { type int32; } } This type of construct shows up often. The context node cannot be changed to the parent or relative path expressions would break. > Lada > > Andy --001a11c1233ac2196f04f56fbdaa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Mar 25, 2014 at 7:50 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 25 Mar 2014, at 15:41, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Tue, Mar 25, 2014 at 7:14 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> Andy Bierman <andy@yumaworks.= com> writes:
>
> > On Tue, Mar 25, 2014 at 2:03 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> >> Hi,
> >>
> >> I think the problem of "when" definition is that it= is inherently
> >> circular: it tries to decide about including a conditional no= de in the
> >> schema by evaluating an XPath expression whose context node i= s that
> >> conditional node.
> >>
> >> Perhaps the correct solution would be to define the context n= ode to be the
> >> closest ancestor data node.
> >> And I'd also add another rule that the XPath expression m= ust not involve
> >> any node that is directly or indirectly conditional (this als= o excludes the
> >> subtree of the conditional node that is being tested).
> >>
> >> While this might solve the problem, it would break existing m= odules - the
> >> leading double-dot would have to be removed from all "wh= en" expressions. On
> >> the other hand, it would be a correction of an error in the s= pec.
> >>
> >>
> > I am against breaking all when-stmts and changing the way they wo= rk.
> > Implementation of the when-stmt in a real server is difficult. &n= bsp;So what's
> > your point?
> > It is not an error in the spec. It's just difficult code.
>
> I disagree, of course. Issue Y18 is real, and it describes an error in= the spec.
>
>
>
> I think the text is clear.  The when expression is obviously proc= essed before
> the context node exists.  It is the test to determine if the node= should exist or not.

Xpath evaluation needs a context node, or else it is ill-defined.



It is defined.

 
> Otherwise it would be identical to the must-stmt.

Yes, this is what DSDL validation does - it has to because it relies on sta= ndard XPath processors that cannot juggle with temporarily added nodes.


This is not correct though.
= It is just an implementation detail to construct a new document with
<= div>the context node in that document. Then process the new document with
the standard XPath tool.



<= /div>
 
>
> The pathological cases are probably unimplementable.
> It would require that all the when-stmts be processed simultaneously > instead of 1 at a time.  Fortunately the pathological loops are n= ot
> operationally useful, so they do not really show up.
>
>
> >
> > The priority for ease of use is readers, writers and lastly, tool=
> > developers.
> > It seems you want to make YANG very difficult to write in order t= o
> > simplify tool development.
>
> I want a precise specification that leaves no doubts about how tools a= re supposed to behave. We have seen already several times that vague formul= ations led to different results.
>
>
> I want a data modeling language that is easy to use for readers and wr= iters.
> Changing the context node would be non-intuitive.  It also preven= ts when-stmt
> from being used inside groupings where the parent node has not been se= t.
>
>
> Moreover, my proposal would actually simplify the spec because the clo= sest ancestor data node would now be the context node for all uses of "= ;when" - in data nodes, choice, uses and augment.
>
>
> It would make it very difficult to write modular and reusable data def= initions.
> A when-stmt can point at a conditional node.  It would be a probl= em if there
> were loops, but that is not how when-stmt gets used.
>
>
>
> >
> > The when-stmt is worse than circular.  It is nested + circul= ar.
> > Any modification to the datastore might cause a when-stmt to
> > change state.  Any deletion of a false when-stmt might cause=
> > other nodes when-stmt value to change.  It is possible to co= nstruct
> > pathological cases that never resolve, no matter how you iterate<= br> > > through the when-stmt tests.
>
> That's why I also proposed that XPath expressions in "when&qu= ot; must not refer to any conditional nodes (that may or may not exist depe= nding on another "when"). This should eliminate such ripple efect= s.
>
> It would make YANG too difficult to use.

Why? I am pretty sure all uses of “when” in our core modules al= ready follow these rules.



There is no implementat= ion problem unless there are loops (A --> B --> C --> A).
The normal case (A --> B --> C) is not a problem.  It can happ= en quite easily.

Changing the context node to the ancestor breaks when-s= tmt for groupings:

   grouping foo {
       leaf X {
      &= nbsp;   when "../Y =3D 10";
          type string;
    &nb= sp;  }
       leaf Y {
  =         type int32;
      &nbs= p;}
   }

This type of construc= t shows up often.
The context node cannot be changed to the paren= t or relative path expressions would break.

 
Lada


Andy

<= /div> --001a11c1233ac2196f04f56fbdaa-- From nobody Tue Mar 25 08:28:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02EAF1A016F for ; Tue, 25 Mar 2014 08:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQCftEYoVOEM for ; Tue, 25 Mar 2014 08:28:14 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5981A00D9 for ; Tue, 25 Mar 2014 08:28:14 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id AF63713F7D4; Tue, 25 Mar 2014 16:28:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395761292; bh=DjOQOWB7tQttgzFlWDG8WKHOncghvZnzNVITyXLF0Dc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=WhRCVJmur8kk1kmaNYcDHbUY1MoetIBIx3Y68VcoH8vkUs6bphefMDL8NjA+l3uEm ao0Si7uXQXBfsDczSeARHnWJkTMeBrF8yw7YE4BAqeYphiyj3RHBlMRQoj7lghydZr iBTrJzZt59+DuxWJtvac3k5DNQsQsRm7xG7rVrHI= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 25 Mar 2014 16:28:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <39BF58F5-2078-42FA-86D5-DD46960E5FC3@nic.cz> References: <20140324.111757.1429730801819634445.mbj@tail-f.com> <6497C153-01EF-4266-B944-40FACD7052E8@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Ur-4yRX-UT6ZwpkZGmHa1k_OTrs Cc: "netmod@ietf.org" Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 15:28:17 -0000 On 25 Mar 2014, at 16:09, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Mar 25, 2014 at 7:50 AM, Ladislav Lhotka = wrote: >=20 > On 25 Mar 2014, at 15:41, Andy Bierman wrote: >=20 > > > > > > > > On Tue, Mar 25, 2014 at 7:14 AM, Ladislav Lhotka = wrote: > > Andy Bierman writes: > > > > > On Tue, Mar 25, 2014 at 2:03 AM, Ladislav Lhotka = wrote: > > > > > >> Hi, > > >> > > >> I think the problem of "when" definition is that it is inherently > > >> circular: it tries to decide about including a conditional node = in the > > >> schema by evaluating an XPath expression whose context node is = that > > >> conditional node. > > >> > > >> Perhaps the correct solution would be to define the context node = to be the > > >> closest ancestor data node. > > >> And I'd also add another rule that the XPath expression must not = involve > > >> any node that is directly or indirectly conditional (this also = excludes the > > >> subtree of the conditional node that is being tested). > > >> > > >> While this might solve the problem, it would break existing = modules - the > > >> leading double-dot would have to be removed from all "when" = expressions. On > > >> the other hand, it would be a correction of an error in the spec. > > >> > > >> > > > I am against breaking all when-stmts and changing the way they = work. > > > Implementation of the when-stmt in a real server is difficult. So = what's > > > your point? > > > It is not an error in the spec. It's just difficult code. > > > > I disagree, of course. Issue Y18 is real, and it describes an error = in the spec. > > > > > > > > I think the text is clear. The when expression is obviously = processed before > > the context node exists. It is the test to determine if the node = should exist or not. >=20 > Xpath evaluation needs a context node, or else it is ill-defined. >=20 >=20 >=20 > It is defined. >=20 > =20 > > Otherwise it would be identical to the must-stmt. >=20 > Yes, this is what DSDL validation does - it has to because it relies = on standard XPath processors that cannot juggle with temporarily added = nodes. >=20 >=20 > This is not correct though. > It is just an implementation detail to construct a new document with > the context node in that document. Then process the new document with > the standard XPath tool. If there are multiple nodes that have to be temporarily added in this = way, do you add them all at once, and then start evaluating the XPath = expressions? Or do you handle them one by one, and then in which order? = Implementors may apply different answers to these questions, and arrive = to different results. I don=92t call this an implementation detail. >=20 >=20 >=20 > =20 > > > > The pathological cases are probably unimplementable. > > It would require that all the when-stmts be processed simultaneously > > instead of 1 at a time. Fortunately the pathological loops are not > > operationally useful, so they do not really show up. > > > > > > > > > > The priority for ease of use is readers, writers and lastly, tool > > > developers. > > > It seems you want to make YANG very difficult to write in order to > > > simplify tool development. > > > > I want a precise specification that leaves no doubts about how tools = are supposed to behave. We have seen already several times that vague = formulations led to different results. > > > > > > I want a data modeling language that is easy to use for readers and = writers. > > Changing the context node would be non-intuitive. It also prevents = when-stmt > > from being used inside groupings where the parent node has not been = set. > > > > > > Moreover, my proposal would actually simplify the spec because the = closest ancestor data node would now be the context node for all uses of = "when" - in data nodes, choice, uses and augment. > > > > > > It would make it very difficult to write modular and reusable data = definitions. > > A when-stmt can point at a conditional node. It would be a problem = if there > > were loops, but that is not how when-stmt gets used. > > > > > > > > > > > > The when-stmt is worse than circular. It is nested + circular. > > > Any modification to the datastore might cause a when-stmt to > > > change state. Any deletion of a false when-stmt might cause > > > other nodes when-stmt value to change. It is possible to = construct > > > pathological cases that never resolve, no matter how you iterate > > > through the when-stmt tests. > > > > That's why I also proposed that XPath expressions in "when" must not = refer to any conditional nodes (that may or may not exist depending on = another "when"). This should eliminate such ripple efects. > > > > It would make YANG too difficult to use. >=20 > Why? I am pretty sure all uses of =93when=94 in our core modules = already follow these rules. >=20 >=20 >=20 > There is no implementation problem unless there are loops (A --> B --> = C --> A). > The normal case (A --> B --> C) is not a problem. It can happen quite = easily. >=20 > Changing the context node to the ancestor breaks when-stmt for = groupings: >=20 > grouping foo { > leaf X { > when "../Y =3D 10"; > type string; > } > leaf Y { > type int32; > } > } >=20 Why should it break? Every time this grouping is used, X and Y will have = a common parent node that is the context node for the =93when=94 = expression. So only the when statement has to be changed to when "Y =3D 10"; and everything will work as expected. Lada > This type of construct shows up often. > The context node cannot be changed to the parent or relative path = expressions would break. >=20 > =20 > Lada >=20 >=20 > Andy >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Mar 25 08:38:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4051A016D for ; Tue, 25 Mar 2014 08:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mY7yZpaiJzr for ; Tue, 25 Mar 2014 08:38:07 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id 675AD1A0144 for ; Tue, 25 Mar 2014 08:38:07 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id w8so667454qac.40 for ; Tue, 25 Mar 2014 08:38:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tQhnjElKJyKRcX/EX3usKrDzsdeddGIjXU0eDlfR2jY=; b=jdYc2sK3eRbVnY03t1QQBoAf0hswCvbU/oEDgm7WoPnAjt2Lcvo9LqYpgYFOl4ifsK x24BE5ZAd6EaSknxol9xmS1cCRcPZup6vxoyPD/UBnbIs+ZHVAs6OYKrvk4Jbd50rARO H/3D02hy4oU4Nza+lD3M0FqeJHLVIFQENQNoPZ/J6xFewrDHLKHrv4XzNwBcO4BAAIQo idS3az5JVZ9JFfe3OZcS6GuZPnhHcRzbvhq//uI+bKm0qz83IRpiS0m6nN8+jfH5B+iQ il4Mi5NBn+2OadWKqqT32HUhoZvdfFv/LpNdkk1msWANCgrVfAPFzuhvVnUAS8e/2yi3 W+nw== X-Gm-Message-State: ALoCoQlSwOl4AeW8xTioOf4fPZ0n5d+WAtjouUH83bNnQT5guWHBERt/LF/S/NOUvBE5EZ7/cyCs MIME-Version: 1.0 X-Received: by 10.140.92.6 with SMTP id a6mr77645823qge.34.1395761886107; Tue, 25 Mar 2014 08:38:06 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Tue, 25 Mar 2014 08:38:06 -0700 (PDT) In-Reply-To: <39BF58F5-2078-42FA-86D5-DD46960E5FC3@nic.cz> References: <20140324.111757.1429730801819634445.mbj@tail-f.com> <6497C153-01EF-4266-B944-40FACD7052E8@nic.cz> <39BF58F5-2078-42FA-86D5-DD46960E5FC3@nic.cz> Date: Tue, 25 Mar 2014 08:38:06 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1139a97069ed8c04f570230b Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/T259u56dBskAViYgzjyIyWZ6R_4 Cc: "netmod@ietf.org" Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 15:38:09 -0000 --001a1139a97069ed8c04f570230b Content-Type: text/plain; charset=ISO-8859-1 .... > > Changing the context node to the ancestor breaks when-stmt for groupings: > > > > grouping foo { > > leaf X { > > when "../Y = 10"; > > type string; > > } > > leaf Y { > > type int32; > > } > > } > > > > Why should it break? Every time this grouping is used, X and Y will have a > common parent node that is the context node for the "when" expression. So > only the when statement has to be changed to > > when "Y = 10"; > > and everything will work as expected. > > This is a massive change to YANG. Not only that, the charter says that all YANG 1.0 modules MUST be valid in YANG 1.1. This change would not meet that constraint. > Lada > Andy --001a1139a97069ed8c04f570230b Content-Type: text/html; charset=ISO-8859-1


....
> Changing the context node to the ancestor breaks when-stmt for groupings:
>
>    grouping foo {
>        leaf X {
>           when "../Y = 10";
>           type string;
>        }
>        leaf Y {
>           type int32;
>        }
>    }
>

Why should it break? Every time this grouping is used, X and Y will have a common parent node that is the context node for the “when” expression. So only the when statement has to be changed to

    when "Y = 10";

and everything will work as expected.



This is a massive change to YANG.
Not only that, the charter says that all YANG 1.0 modules MUST be
valid in YANG 1.1.  This change would not meet that constraint.


 
Lada


Andy

--001a1139a97069ed8c04f570230b-- From nobody Tue Mar 25 08:42:28 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC901A01DC for ; Tue, 25 Mar 2014 08:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HfpFEmgkfAM for ; Tue, 25 Mar 2014 08:42:03 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D6C131A0199 for ; Tue, 25 Mar 2014 08:42:02 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 3C34D13F7D4; Tue, 25 Mar 2014 16:42:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395762121; bh=5DCTCdBz35tfohzq+gtrdAzRomAgR+CCDnVrXpGjNEs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=InElYbI1jdzcCkwpJoWuQOPoVE2UsanrNkR57gTbjECQD04xBogyPIjkOKIf0YdPi GtBx8rMACqDE8sssBLF5HnL0+D7LMI32/a0yvlkyKzKFqosiPlNN/Pb9QKRK+tsFht cUkLL1QytsUGEFHWmH34DbOB54xZMEHTOl8jjmV8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 25 Mar 2014 16:42:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140324.111757.1429730801819634445.mbj@tail-f.com> <6497C153-01EF-4266-B944-40FACD7052E8@nic.cz> <39BF58F5-2078-42FA-86D5-DD46960E5FC3@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/tf1FyA_vXVO-TmTFJ-oB_BwPIpM Cc: "netmod@ietf.org" Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 15:42:05 -0000 On 25 Mar 2014, at 16:38, Andy Bierman wrote: >=20 >=20 > .... > > Changing the context node to the ancestor breaks when-stmt for = groupings: > > > > grouping foo { > > leaf X { > > when "../Y =3D 10"; > > type string; > > } > > leaf Y { > > type int32; > > } > > } > > >=20 > Why should it break? Every time this grouping is used, X and Y will = have a common parent node that is the context node for the =93when=94 = expression. So only the when statement has to be changed to >=20 > when "Y =3D 10"; >=20 > and everything will work as expected. >=20 >=20 >=20 > This is a massive change to YANG. > Not only that, the charter says that all YANG 1.0 modules MUST be > valid in YANG 1.1. This change would not meet that constraint. That=92s what I said. However, there is an error in YANG 1.0 and I = seriously doubt the circular definition can be rectified. Lada >=20 >=20 > =20 > Lada >=20 >=20 > Andy >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Mar 25 11:04:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0301A01DF for ; Tue, 25 Mar 2014 11:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCY-8HWyafTO for ; Tue, 25 Mar 2014 11:04:19 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2DE1A0157 for ; Tue, 25 Mar 2014 11:04:19 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id r5so1100290qcx.4 for ; Tue, 25 Mar 2014 11:04:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=k2SvomwiIFf+Sc0BKVWSLMi/1UnZG9XXzRyzsdGDE08=; b=HjSXbwhKXtgsv0aDI5vSlfDkSjG2cf1FPIrqcwYs/EAvAlLrfPEOToh+//LieChz5C 4Ij3efqcP7Ci/y8/Vpvsq7M+x4yKsPtrbbNjqtnvik8yOi+vZj4Sy8+9lUJpA+acVVw0 nHu+D39vMRAl6spccbcyltPD0mSfzrKjuBFhjeL5rUEIKnNBhzyO/jkX42QBdFz5tWAh E8TPB1LDE7o+Vq1nk1Hs3EwPaEvJlc+ibwwzMqEFyRU0b4fqujRNCScMUA8uwB3dCp2D lX9tOc3A5as9ZRT459+h0d0GlHDX2dZ1dQv5ED+8MCX5XZBRDm5/zQpRYpfXyVzJ+sRq YkJQ== X-Gm-Message-State: ALoCoQmZg+70RnmjcPjHrf2kXwKKA0WQSN/gkY8E8dItWR5BjdY2Us0aoj/gJ2rbkB27VIQ8G6sv MIME-Version: 1.0 X-Received: by 10.224.112.6 with SMTP id u6mr11586848qap.78.1395770657833; Tue, 25 Mar 2014 11:04:17 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Tue, 25 Mar 2014 11:04:17 -0700 (PDT) In-Reply-To: References: <20140324.111757.1429730801819634445.mbj@tail-f.com> <6497C153-01EF-4266-B944-40FACD7052E8@nic.cz> <39BF58F5-2078-42FA-86D5-DD46960E5FC3@nic.cz> Date: Tue, 25 Mar 2014 11:04:17 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c2e8483fb3c604f5722e93 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/8sEG7FTNYWdqxsO7NFMX7meSs9E Cc: "netmod@ietf.org" Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 18:04:21 -0000 --001a11c2e8483fb3c604f5722e93 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 25, 2014 at 8:42 AM, Ladislav Lhotka wrote: > > On 25 Mar 2014, at 16:38, Andy Bierman wrote: > > > > > > > .... > > > Changing the context node to the ancestor breaks when-stmt for > groupings: > > > > > > grouping foo { > > > leaf X { > > > when "../Y = 10"; > > > type string; > > > } > > > leaf Y { > > > type int32; > > > } > > > } > > > > > > > Why should it break? Every time this grouping is used, X and Y will have > a common parent node that is the context node for the "when" expression. So > only the when statement has to be changed to > > > > when "Y = 10"; > > > > and everything will work as expected. > > > > > > > > This is a massive change to YANG. > > Not only that, the charter says that all YANG 1.0 modules MUST be > > valid in YANG 1.1. This change would not meet that constraint. > > That's what I said. However, there is an error in YANG 1.0 and I seriously > doubt the circular definition can be rectified. > > I do not see the error. Are you saying all the when-stmts that are in YANG 1.0 modules now are broken? Are you saying they are unimplementable? YANG 1.0 when-stmts need to be unchanged in YANG 1.1. The issue of evaluating a when-expr as if there was a context node inserted is a completely different issue than the order that multiple when-stmts are evaluated. Changing the context node to the parent does not alter the evaluation order problem. The rules for what nodes can be accessed (directly or indirectly via XPath mechanisms) cannot be changed because that would break YANG 1.0 when statements. > Lada > > Andy --001a11c2e8483fb3c604f5722e93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Mar 25, 2014 at 8:42 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 25 Mar 2014, at 16:38, Andy Bierman <andy@yumaworks.com> wrote:

>
>
> ....
> > Changing the context node to the ancestor breaks when-stmt for gr= oupings:
> >
> >    grouping foo {
> >        leaf X {
> >           when "../Y =3D 10";<= br> > >           type string;
> >        }
> >        leaf Y {
> >           type int32;
> >        }
> >    }
> >
>
> Why should it break? Every time this grouping is used, X and Y will ha= ve a common parent node that is the context node for the “when”= expression. So only the when statement has to be changed to
>
>     when "Y =3D 10";
>
> and everything will work as expected.
>
>
>
> This is a massive change to YANG.
> Not only that, the charter says that all YANG 1.0 modules MUST be
> valid in YANG 1.1.  This change would not meet that constraint.
That’s what I said. However, there is an error in YANG 1.0 and I seri= ously doubt the circular definition can be rectified.


I do not see the error.  Are you = saying all the when-stmts that are in YANG 1.0
modules now are br= oken? Are you saying they are unimplementable?

YAN= G 1.0 when-stmts need to be unchanged in YANG 1.1.
The issue of evaluating a when-expr as if there was a context
node inserted is a completely different issue than the order that
multiple when-stmts are evaluated.  Changing the context node
=
to the parent does not alter the evaluation order problem.

The rules for what nodes can be accessed (directly or indirectly
via XPath mechanisms) cannot be changed because that would break
YANG 1.0 when statements.  


 
Lada



Andy

--001a11c2e8483fb3c604f5722e93-- From nobody Tue Mar 25 13:46:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F751A0239 for ; Tue, 25 Mar 2014 13:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQB9x4mDkl0x for ; Tue, 25 Mar 2014 13:46:16 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 857EB1A0215 for ; Tue, 25 Mar 2014 13:46:16 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id DB48937C320; Tue, 25 Mar 2014 21:46:13 +0100 (CET) Date: Tue, 25 Mar 2014 21:46:13 +0100 (CET) Message-Id: <20140325.214613.446044730.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/iziJYhMGaqoBgoCXBHfH1bfQ3Kg Cc: netmod@ietf.org Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 20:46:19 -0000 Hi, I fully agree with Andy. I don't mind clarifying things, or make the pathological circular cases illegal, if that can be done. But in all real use cases, current "when" works just fine, and it is being used and implemented all the time. /martin Andy Bierman wrote: > On Tue, Mar 25, 2014 at 8:42 AM, Ladislav Lhotka wrote: > > > > > On 25 Mar 2014, at 16:38, Andy Bierman wrote: > > > > > > > > > > > .... > > > > Changing the context node to the ancestor breaks when-stmt for > > groupings: > > > > > > > > grouping foo { > > > > leaf X { > > > > when "../Y = 10"; > > > > type string; > > > > } > > > > leaf Y { > > > > type int32; > > > > } > > > > } > > > > > > > > > > Why should it break? Every time this grouping is used, X and Y will have > > a common parent node that is the context node for the "when" expression. So > > only the when statement has to be changed to > > > > > > when "Y = 10"; > > > > > > and everything will work as expected. > > > > > > > > > > > > This is a massive change to YANG. > > > Not only that, the charter says that all YANG 1.0 modules MUST be > > > valid in YANG 1.1. This change would not meet that constraint. > > > > That's what I said. However, there is an error in YANG 1.0 and I seriously > > doubt the circular definition can be rectified. > > > > > I do not see the error. Are you saying all the when-stmts that are in YANG > 1.0 > modules now are broken? Are you saying they are unimplementable? > > YANG 1.0 when-stmts need to be unchanged in YANG 1.1. > The issue of evaluating a when-expr as if there was a context > node inserted is a completely different issue than the order that > multiple when-stmts are evaluated. Changing the context node > to the parent does not alter the evaluation order problem. > > The rules for what nodes can be accessed (directly or indirectly > via XPath mechanisms) cannot be changed because that would break > YANG 1.0 when statements. > > > > > > Lada > > > > > > Andy From nobody Tue Mar 25 14:40:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CC71A0236 for ; Tue, 25 Mar 2014 14:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6koEQQfM0QGv for ; Tue, 25 Mar 2014 14:40:46 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 240E01A020A for ; Tue, 25 Mar 2014 14:40:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id D8BC2540645; Tue, 25 Mar 2014 22:40:43 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gI025U8il20J; Tue, 25 Mar 2014 22:40:39 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 48862540233; Tue, 25 Mar 2014 22:40:37 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <20140324.111757.1429730801819634445.mbj@tail-f.com> <6497C153-01EF-4266-B944-40FACD7052E8@nic.cz> <39BF58F5-2078-42FA-86D5-DD46960E5FC3@nic.cz> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 25 Mar 2014 22:40:36 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/3Ns4FL8Ga7Q2yJZLuAT9fvpjWZ8 Cc: "netmod@ietf.org" Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 21:40:48 -0000 Andy Bierman writes: >> >> > I do not see the error. Are you saying all the when-stmts that are in YANG > 1.0 > modules now are broken? Are you saying they are unimplementable? What I am saying is that data model fragments like container foo { when "1 = 0"; leaf bar { mandatory true; ... } } don't have a satisfactory interpretation. It is fully defensible if a validation tool flags datastore content as invalid if it doesn't contain the "foo" container and the mandatory "bar" leaf. > > YANG 1.0 when-stmts need to be unchanged in YANG 1.1. > The issue of evaluating a when-expr as if there was a context > node inserted is a completely different issue than the order that > multiple when-stmts are evaluated. Changing the context node > to the parent does not alter the evaluation order problem. That's true, but it does make a difference whether you insert all the temporary context nodes at once or one by one. > > The rules for what nodes can be accessed (directly or indirectly > via XPath mechanisms) cannot be changed because that would break > YANG 1.0 when statements. > If you develop YANG modules for your customers, you can certainly make sure that everything works as expected because you are aware of the dark corners. But if the plan is to offer YANG for general use, then the spec IMO must be rock solid. The idea that I can write a valid YANG module that will most likely blow up almost any tool around makes me nervous. Lada > > > >> Lada >> >> > > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Mar 25 16:03:56 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5931A0256 for ; Tue, 25 Mar 2014 16:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Uq2gOHueV4o for ; Tue, 25 Mar 2014 16:03:45 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id BE8FC1A0254 for ; Tue, 25 Mar 2014 16:03:44 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id e9so1696682qcy.1 for ; Tue, 25 Mar 2014 16:03:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MdUi9k2p7vmK18zBnGNtXEG9FhB+dfS4GwuhCR3v5WE=; b=RSRlt1Zu8memnqpfgh0+ur3z0vWEjQ5MYbp3m8XyfSGzLaKL9neFYbSX+BsImsY+Da tYF7LEBzj4G4zRvJdoIEY4q8lN93hyJAXD70BTTxunG8iDX8fUlkTRlL/Um+zwY9CnMc 1AzNNWwtv4Fq1FKtKsCbo1cNMqgX7/DKorAyKwsqy7fKYeop6YFxNs6IydlB5ypHKIUb m/QGcO5uR4QTZOoynOJzoDTd0UbjyhLPOJeOjqNhtB9l7t5/wwrX2xVf7hcj/nR1A/J/ DFu/LI/l3KMAub0/HsKpRHGgGfUBWNcLejvsJCWhqC7VSNBdnKQ0PRv1MXe6fcH6IpcH VlYQ== X-Gm-Message-State: ALoCoQntPF5xL27Yf0PxFShQWGCLXHr1h69Wo7frDY56VLdo9SKDyWgIOgvx6jei9wOQrnGdSh8t MIME-Version: 1.0 X-Received: by 10.224.36.129 with SMTP id t1mr5871788qad.88.1395788623336; Tue, 25 Mar 2014 16:03:43 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Tue, 25 Mar 2014 16:03:43 -0700 (PDT) In-Reply-To: References: <20140324.111757.1429730801819634445.mbj@tail-f.com> <6497C153-01EF-4266-B944-40FACD7052E8@nic.cz> <39BF58F5-2078-42FA-86D5-DD46960E5FC3@nic.cz> Date: Tue, 25 Mar 2014 16:03:43 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=089e0158a9e413cb6704f5765d16 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/T6j62OspLTc2btythCqd1cDslHU Cc: "netmod@ietf.org" Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 23:03:53 -0000 --089e0158a9e413cb6704f5765d16 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 25, 2014 at 2:40 PM, Ladislav Lhotka wrote: > Andy Bierman writes: > > >> > >> > > I do not see the error. Are you saying all the when-stmts that are in > YANG > > 1.0 > > modules now are broken? Are you saying they are unimplementable? > > What I am saying is that data model fragments like > > container foo { > when "1 = 0"; > leaf bar { > mandatory true; > ... > } > } > > don't have a satisfactory interpretation. It is fully defensible if a > validation tool flags datastore content as invalid if it doesn't contain > the "foo" container and the mandatory "bar" leaf. > > Like I said, the pathological cases are operationally useless. Nobody would ever write "when 1 = 0". We should avoid adding CLRs to YANG that are intended from preventing people from doing things they would not even try to do. It is just busy work for compiler writers. > > > > YANG 1.0 when-stmts need to be unchanged in YANG 1.1. > > The issue of evaluating a when-expr as if there was a context > > node inserted is a completely different issue than the order that > > multiple when-stmts are evaluated. Changing the context node > > to the parent does not alter the evaluation order problem. > > That's true, but it does make a difference whether you insert all the > temporary context nodes at once or one by one. > > To be honest -- it doesn't. Setting all the context nodes to random values is just as arbitrarily incorrect as leaving them all out. Truth is, if there are dependency arcs then they have to be resolved in the correct order. Our client code does not do that (yet). If you are trying to test when-stmts on the client side in order to prevent showing the user false-when-nodes, then it might be either order-dependent or impossible. Unlike AJAX menus where the conditional arcs are usually downward, the XPath arcs can go anywhere. Unlike "import" resolution, resolving arbitrary XPath could be impossible. Any XPath expert could construct pathological expressions like "not(.)" where the outcome makes YANG validation implementation-dependent or impossible. > > > The rules for what nodes can be accessed (directly or indirectly > > via XPath mechanisms) cannot be changed because that would break > > YANG 1.0 when statements. > > > > If you develop YANG modules for your customers, you can certainly make > sure that everything works as expected because you are aware of the dark > corners. > > But if the plan is to offer YANG for general use, then the spec IMO must > be rock solid. The idea that I can write a valid YANG module that will most > likely blow up almost any tool around makes me nervous. > > We can do something like mandatory top-level node -- write guidelines. They are allowed in YANG but not in IETF modules. The statement "while (1);" is allowed is C but it usually is not a good thing to do. Lada > > Andy > > > > > > > >> Lada > >> > >> > > > > Andy > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --089e0158a9e413cb6704f5765d16 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Mar 25, 2014 at 2:40 PM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:
Andy Bierman <andy@yumaworks.com> writes:

>>
>>
> I do not see the error. =A0Are you saying all the when-stmts that are = in YANG
> 1.0
> modules now are broken? Are you saying they are unimplementable?

What I am saying is that data model fragments like

container foo {
=A0 =A0 when "1 =3D 0";
=A0 =A0 leaf bar {
=A0 =A0 =A0 =A0 mandatory true;
=A0 =A0 =A0 =A0 ...
=A0 =A0 }
}

don't have a satisfactory interpretation. It is fully defensible if a v= alidation tool flags datastore content as invalid if it doesn't contain= the "foo" container and the mandatory "bar" leaf.



Like I said, the pathol= ogical cases are operationally useless.
Nobody would ever write &= quot;when 1 =3D 0". We should avoid adding
CLRs to YANG that= are intended from preventing people from doing things
they would not even try to do. =A0It is just busy work for compiler wr= iters.


=A0
>
> YANG 1.0 when-stmts need to be unchanged in YANG 1.1.
> The issue of evaluating a when-expr as if there was a context
> node inserted is a completely different issue than the order that
> multiple when-stmts are evaluated. =A0Changing the context node
> to the parent does not alter the evaluation order problem.

That's true, but it does make a difference whether you insert all the t= emporary context nodes at once or one by one.


To be honest -- it doesn't. =A0Set= ting all the context nodes to random values
is just as arbitraril= y incorrect as leaving them all out. Truth is, if there are
depen= dency arcs then they have to be resolved in the correct order.

Our client code does not do that (yet). =A0If you are t= rying to test when-stmts on
the client side in order to prevent s= howing the user false-when-nodes,
then it might be either order-d= ependent or impossible. =A0Unlike AJAX menus
where the conditional arcs are usually downward, the XPath arcs can go= anywhere.

Unlike "import" resolution, r= esolving arbitrary XPath could be impossible.
Any XPath expert co= uld construct pathological expressions like "not(.)"
where the outcome makes YANG validation implementation-dependent or im= possible.


>
> The rules for what nodes can be accessed (directly or indirectly
> via XPath mechanisms) cannot be changed because that would break
> YANG 1.0 when statements.
>

If you develop YANG modules for your customers, you can certainly make sure= that everything works as expected because you are aware of the dark corner= s.

But if the plan is to offer YANG for general use, then the spec IMO must be= rock solid. The idea that I can write a valid YANG module that will most l= ikely blow up almost any tool around makes me nervous.



We can do something lik= e mandatory top-level node -- write guidelines.
They are allowed = in YANG but not in IETF modules.
The statement "while (1);&q= uot; is allowed is C but it usually
is not a good thing to do.


Lada



Andy

=A0
>
>
>
>> Lada
>>
>>
>
> Andy

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

--089e0158a9e413cb6704f5765d16-- From nobody Tue Mar 25 19:10:02 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE421A0032 for ; Tue, 25 Mar 2014 19:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-NCrdxL5k5C for ; Tue, 25 Mar 2014 19:09:56 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 436991A001B for ; Tue, 25 Mar 2014 19:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9772; q=dns/txt; s=iport; t=1395799795; x=1397009395; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Kz8A3joi8yypHSgllp4rjS7WdzBACbWCiqMxpLiTQ7c=; b=PEP0HCwzxh9GAzG8+hRRoRhih1ST6E74quD30ps0StD27dZHWODCsKwu /sVeEJAU4NFo9Lq3o7vvI34/HM2HjpfB0Zn/6nEZ6B0tb09NRbwJV1Zde UK8sTyAfbdm/yOkOGMohfMrtO28eec2HhFgWIyA578zehV6cc8lbRDQ1G M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAL02MlOtJV2a/2dsb2JhbABZgwY7UQaDC7g6hmRRGYEBFnSCJQEBAQQBAQEgETcDCxACAQgYAgImAgICJQsVEAIEAQ0FCYdwCAWtLqIeF4EpjRIzB4JvgUkEmE2BMpEAgy6CKw X-IronPort-AV: E=Sophos;i="4.97,732,1389744000"; d="scan'208";a="312696314" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 26 Mar 2014 02:09:54 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2Q29sxX021603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Mar 2014 02:09:54 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.219]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Tue, 25 Mar 2014 21:09:53 -0500 From: "Yi Yang (yiya)" To: Ladislav Lhotka , "Derek Man-Kit Yeung (myeung)" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt Thread-Index: AQHPDgglsV7ZhSMgp02l6cqKlZJTf5rW54cAgAAKUQCACr4yAIAABNeAgAZ/kACAAJNSgIAKXeIA Date: Wed, 26 Mar 2014 02:09:53 +0000 Message-ID: References: <20140110133016.24678.42711.idtracker@ietfa.amsl.com> <9C81158E-5B4C-4479-AEA5-23CBCC020ADD@nic.cz> <0ED855DA-51BE-4DE6-AB22-E1A9E04C0E5F@nic.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.116.75.13] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7OyV8ugGdxcyfMDDgLBE3VRSZ5k Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 02:09:59 -0000 SGkgTGFkYSwNCg0KSW4gdGhlIGN1cnJlbnQgbW9kZWwsIGRlZmF1bHQtcmlicyB3aWxsIGV4aXN0 IG9ubHkgd2hlbiBmZWF0dXJlDQptdWx0aXBsZS1yaWJzIGV4aXN0cy4gVGhpcyBpcyBjb250cmFk aWN0b3J5IHRvIHdoYXQgcGVvcGxlIGFyZSBmYW1pbGlhciBpbg0KdGhlIHJlYWwgd29ybGQgZGVw bG95bWVudCAgLS0gZGVmYXVsdC1yaWJzIGFsd2F5cyBleGlzdC4NCg0KVG8gcmVmbGVjdCBzdWNo IGFuIGV4cGVjdGF0aW9uLCBJIHN1Z2dlc3QgdG8ga2VlcCBkZWZhdWx0LXJpYnMNCnVuY29uZGl0 aW9uYWxseS4gSW5zdGVhZCwgbW92ZSB0aGUgY29uZGl0aW9ucyB0byB0aGUgcmlicyAtLSBpZiBm ZWF0dXJlDQptdWx0aXBsZS1yaWJzIGRvZXNuJ3QgZXhpc3QsIG9ubHkgb25lIHJpYiBpcyBhbGxv d2VkIHBlciBhZGRyZXNzIGZhbWlseS4NCg0KWWkNCg0KDQpPbiAzLzE5LzE0IDM6NTEgQU0sICJM YWRpc2xhdiBMaG90a2EiIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCg0KPiJEZXJlayBNYW4tS2l0 IFlldW5nIChteWV1bmcpIiA8bXlldW5nQGNpc2NvLmNvbT4gd3JpdGVzOg0KPg0KPj4gT24gMy8x NC8xNCAxMjo0OSBQTSwgIkxhZGlzbGF2IExob3RrYSIgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0K Pj4NCj4+Pg0KPj4+T24gMTQgTWFyIDIwMTQsIGF0IDIwOjMyLCBEZXJlayBNYW4tS2l0IFlldW5n IChteWV1bmcpDQo+Pj48bXlldW5nQGNpc2NvLmNvbT4NCj4+Pndyb3RlOg0KPj4+DQo+Pj4+IA0K Pj4+PiANCj4+Pj4gT24gMy83LzE0IDI6MjkgUE0sICJMYWRpc2xhdiBMaG90a2EiIDxsaG90a2FA bmljLmN6PiB3cm90ZToNCj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IE9uIDA3IE1hciAyMDE0LCBhdCAy Mjo1MiwgWWkgWWFuZyAoeWl5YSkgPHlpeWFAY2lzY28uY29tPiB3cm90ZToNCj4+Pj4+IA0KPj4+ Pj4+IE9uZSB0aGluZyBpcyBtaXNzaW5nIGZyb20gdGhlIGRhdGEgbW9kZWwgaXMgYXNzb2NpYXRp b24gd2l0aCB2cmYuDQo+Pj4+PiANCj4+Pj4+IEkgYWdyZWUgd2l0aCB3aGF0IE1hcnRpbiB3cm90 ZSBpbiBhIHBhcmFsbGVsIHRocmVhZC4gSSBiZWxpZXZlIHRoZQ0KPj4+Pj4gcm91dGluZyBtb2R1 bGUgKGFuZCBZQU5HIGF1Z21lbnQgc3RhdGVtZW50KSBwcm92aWRlIHN1ZmZpY2llbnQgaG9va3MN Cj4+Pj4+Zm9yDQo+Pj4+PiBpbXBsZW1lbnRpbmcgVlJGIGFzIGEgc3BlY2lmaWMgdHlwZSBvZiBy b3V0aW5nLWluc3RhbmNlLg0KPj4+PiANCj4+Pj4gDQo+Pj4+IFRoZSBkcmFmdCBtZW50aW9uZWQg dGhlIHJvdXRpbmctaW5zdGFuY2UgY291bGQgYmUgdXNlZCB0byByZXByZXNlbnRzIGENCj4+Pj4g bG9naWNhbCByb3V0ZXIuDQo+Pj4+IA0KPj4+PiBUaGUgdGVybSAibG9naWNhbCByb3V0ZXIiIGlu IG9uZSBvciBtb3JlIHZlbmRvcnMgbWVhbiBhIHBhcnRpdGlvbiBvZg0KPj4+PnRoZQ0KPj4+PiBw aHlzaWNhbCByb3V0ZXIgaW50byBtdWx0aXBsZSBsb2dpY2FsIHVuaXRzLCBlYWNoIGNvdWxkIGhh dmUgbXVsdGlwbGUNCj4+Pj5WUkZzLg0KPj4+PiANCj4+Pj4gRG9lcyB0aGUgZHJhZnQgaW50ZW5k IHRvIG1hbmFnZSAibG9naWNhbCByb3V0ZXIiIGluIHRoZSBhYm92ZQ0KPj4+PmRlZmluaXRpb24/ DQo+Pj4+IFNvbWUgY2xhcmlmaWNhdGlvbiB3aWxsIGJlIHVzZWZ1bC4NCj4+Pg0KPj4+T25lIHdh eSB0byBpbXBsZW1lbnQgdGhpcyBpcyB0byBpbnRyb2R1Y2UgdHdvIHR5cGVzIG9mIHJvdXRpbmcN Cj4+Pmluc3RhbmNlcywNCj4+PnNheSAnbG9naWNhbC1yb3V0ZXLCuSBhbmQgxZJ2cmbCuS4gVGhl IMWSdnJmwrkgdHlwZSB0aGVuIHdvdWxkIGhhdmUgYW5vdGhlcg0KPj4+bGVhZiBsaW5raW5nIGl0 IHRvIGEgbG9naWNhbCByb3V0ZXIuIFRoaXMgaXMgcXVpdGUgbGlrZSB0aGUgdmFyaW91cw0KPj4+ bWV0aG9kcyBvZiBpbnRlcmZhY2Ugc3RhY2tpbmcsIHNlZSB0aGUgZXhhbXBsZXMgaW4NCj4+PmRy YWZ0LWlldGYtbmV0bW9kLWludGVyZmFjZXMtY2ZnLTE2Lg0KPj4+DQo+Pj5MYWRhDQo+Pg0KPj4N Cj4+IEl0IGlzIG9uZSB3YXkuIA0KPj4gSG93ZXZlciwgZ2l2ZW4gdGhhdCBjdXJyZW50IG1vZGVs IHRoYXQgZXZlcnl0aGluZyBpcyBwdXQgaW5zaWRlIGENCj4+IHJvdXRpbmctaW5zdGFuY2UsIHRo aW5ncyBsaWtlIFJJQiwgcm91dGluZy1wcm90b2NvbHMgZXRjIGFyZSBubyBsb25nZXINCj4+IG5l ZWRlZCBkaXJlY3RseSB1bmRlciB0aGUgJ2xvZ2ljYWwtcm91dGVyJy4NCj4NCj5Ob3RlIHRoYXQg UklCcyBhcmUgbm90IGluc2lkZSAicm91dGluZy1pbnN0YW5jZSIsIGFsdGhvdWdoIGFuDQo+aW1w bGVtZW50YXRpb24gbWF5IGRlZmluZSBzb21lIFJJQnMgdG8gYmUgcm91dGluZy1pbnN0YW5jZS1z cGVjaWZpYy4NCj4NCj4+IFdoYXQgbmVlZGVkIGluIHRoZSAnbG9naWNhbCByb3V0ZXInIGFyZSBy ZXNvdXJjZXMgYWxsb2NhdGlvbiBsaWtlDQo+PiBpbnRlcmZhY2VzLCBDUFUgZXRjLg0KPg0KPiJp bnRlcmZhY2VzIiBpcyBhIGNvbnRhaW5lciBpbnNpZGUgInJvdXRpbmctaW5zdGFuY2UiLCBhbmQg ImNwdSIgY2FuIGJlDQo+ZWFzaWx5IGFkZGVkIGJ5IGFub3RoZXIgbW9kdWxlIHZpYSBhdWdtZW50 YXRpb24uDQo+DQo+PiBUaG91Z2ggcm91dGluZy1pbnN0YW5jZSBjb3VsZCBiZSBhdWdtZW50ZWQg dG8gaW5jbHVkZSAnbG9naWNhbCByb3V0ZXInDQo+PiBzcGVjaWZpYyBmaWVsZCBhbmQgYWRkIG5l dyBjb25kaXRpb24gdG8gcmVzdHJpY3QgZXhpc3RpbmcgbGVhZiB0aGF0IG5vDQo+PiBsb25nIGFw cGx5LCBJIHRoaW5rIGEgbmV3IGNvbnRhaW5lciBhYm92ZSByb3V0aW5nLWluc3RhbmNlIGlzIGNs ZWFuZXIuDQo+Pkl0DQo+PiBjb3VsZCBiZSBhIG5ldyBkYXRhIG1vZGVsIHRoYXQgcmVmZXJlbmNl IHRoZSBkZWZpbml0aW9uIGluIHRoZSBjdXJyZW50DQo+PiBkcmFmdC4NCj4NCj5JIGd1ZXNzIHBh cnQgb2YgdGhlIGNvbmZ1c2lvbiBzdGVtcyBmcm9tIHRoZSBuYW1lICJyb3V0aW5nLWluc3RhbmNl Ig0KPndoaWNoIGFscmVhZHkgbWVhbnMgYSBwYXJ0aWN1bGFyIChwbGF0Zm9ybS1zcGVjaWZpYykg c3R5bGUgb2Ygcm91dGVyDQo+dmlydHVhbGl6YXRpb24uIEVhcmxpZXIgcmV2aXNpb25zIG9mIHRo ZSBkcmFmdCB1c2VkICJyb3V0ZXIiIGxpc3QgaW4gdGhpcw0KPnBsYWNlIGJ1dCBpdCB3YXMgYW4g c3BlY2lmaWMgcmVxdWlyZW1lbnQgb2YgSTJSUyBmb2xrcyB0byBjaGFuZ2UgdGhpcw0KPm5hbWUg dG8gInJvdXRpbmctaW5zdGFuY2UiLiBPaCB3ZWxsIC4uLg0KPg0KPlNvIHBsZWFzZSBrZWVwIGlu IG1pbmQgdGhhdCAicm91dGluZy1pbnN0YW5jZSIgY2FuIHJlYWxseSBtZWFuIGRpZmZlcmVudA0K PnRoaW5ncyBkZXBlbmRpbmcgb24gaXRzIHR5cGUgKGFuZCBjYW4gYmUgYXVnbWVudGVkIGluIGRp ZmZlcmVudCB3YXlzDQo+ZGVwZW5kaW5nIG9uIHRoZSB0eXBlKS4gQWdhaW4sIHRoaXMgYXBwcm9h Y2ggaXMgdmVyeSBzaW1pbGFyIHRvIHRoZSBvbmUNCj5hZG9wdGVkIGZvciB0aGUgImludGVyZmFj ZSIgbGlzdCBpbiAiaWV0Zi1pbnRlcmZhY2VzIiBtb2R1bGUuDQo+DQo+TGFkYQ0KPg0KPj4NCj4+ IC0gRGVyZWsNCj4+DQo+Pj4NCj4+Pj4gDQo+Pj4+IC0gRGVyZWsNCj4+Pj4gDQo+Pj4+PiANCj4+ Pj4+IEkgdGhpbmsgdGhvdWdoIHRoYXQgb3RoZXIgd29yayBleHRlbmRpbmcgdGhlIHJvdXRpbmcg bW9kdWxlIGlzIG11Y2gNCj4+Pj4+bW9yZQ0KPj4+Pj4gbmVlZGVkLCBuYW1lbHkgdmVuZG9yLW5l dXRyYWwgZGF0YSBtb2RlbHMgZm9yIHJvdXRpbmcgcHJvdG9jb2xzLg0KPj4+Pj4gDQo+Pj4+PiBU aGUgY29uc2Vuc3VzIG9mIHRoZSBORVRNT0QgV0cgd2FzIHRoYXQgdGhlc2UgbmV3IG1vZHVsZXMg c2hvdWxkIGJlDQo+Pj4+PiBkZXZlbG9wZWQgYnkgZXhwZXJ0cyBpbiB0aGUgUm91dGluZyBBcmVh IChWUkYgaW4gdGhlIE1QTFMgV0c/KS4gVGhlDQo+Pj4+PiBORVRNT0QgV0cgYW5kIFlBTkcgRG9j dG9ycyB3aWxsIGNlcnRhaW5seSBoZWxwIGJ1dCB0aGUgYnVsayBvZiB0aGlzDQo+Pj4+PndvcmsN Cj4+Pj4+IHNob3VsZCBiZSBkb25lIGJ5IGRvbWFpbiBleHBlcnRzLg0KPj4+Pj4gDQo+Pj4+PiBM YWRhDQo+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBBbm90aGVyIGNvbmNlcm4gSSBoYXZlIGlzIGFi b3V0IGFkZHJlc3MgZmFtaWx5LiBUbyBmYWNpbGl0YXRlIGENCj4+Pj4+PnF1ZXJ5DQo+Pj4+Pj4g YmFzZWQgb24gQUZJIG9ubHksIG9yIFNBRkkgb25seSwgaXQgc2VlbXMgbW9yZSBjb252ZW5pZW50 IHRvIHVzZSB0d28NCj4+Pj4+PiBsZWFmcw0KPj4+Pj4+IChBRkkgYW5kIFNBRkkpIGluc3RlYWQg b2Ygb25lIChBRkktU0FGSSkuDQo+Pj4+Pj4gDQo+Pj4+Pj4gWWkNCj4+Pj4+PiANCj4+Pj4+PiAN Cj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBPbiAxLzEwLzE0IDg6MzAgQU0sICJpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmciDQo+Pj4+Pj4gPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCj4+Pj4+ PiB3cm90ZToNCj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0 IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPj4+Pj4+PiBk aXJlY3Rvcmllcy4NCj4+Pj4+Pj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTkVU Q09ORiBEYXRhIE1vZGVsaW5nIExhbmd1YWdlDQo+Pj4+Pj4+V29ya2luZw0KPj4+Pj4+PiBHcm91 cCBvZiB0aGUgSUVURi4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+ICAgICAgVGl0bGUgICAgICAgICAgIDog QSBZQU5HIERhdGEgTW9kZWwgZm9yIFJvdXRpbmcgTWFuYWdlbWVudA0KPj4+Pj4+PiAgICAgIEF1 dGhvciAgICAgICAgICA6IExhZGlzbGF2IExob3RrYQ0KPj4+Pj4+PiAJRmlsZW5hbWUgICAgICAg IDogZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmctMTMudHh0DQo+Pj4+Pj4+IAlQYWdlcyAg ICAgICAgICAgOiA5NQ0KPj4+Pj4+PiAJRGF0ZSAgICAgICAgICAgIDogMjAxNC0wMS0xMA0KPj4+ Pj4+PiANCj4+Pj4+Pj4gQWJzdHJhY3Q6DQo+Pj4+Pj4+IFRoaXMgZG9jdW1lbnQgY29udGFpbnMg YSBzcGVjaWZpY2F0aW9uIG9mIHRocmVlIFlBTkcgbW9kdWxlcy4NCj4+Pj4+Pj4gVG9nZXRoZXIg dGhleSBmb3JtIHRoZSBjb3JlIHJvdXRpbmcgZGF0YSBtb2RlbCB3aGljaCBzZXJ2ZXMgYXMgYQ0K Pj4+Pj4+PiBmcmFtZXdvcmsgZm9yIGNvbmZpZ3VyaW5nIGFuZCBtYW5hZ2luZyBhIHJvdXRpbmcg c3Vic3lzdGVtLiAgSXQgaXMNCj4+Pj4+Pj4gZXhwZWN0ZWQgdGhhdCB0aGVzZSBtb2R1bGVzIHdp bGwgYmUgYXVnbWVudGVkIGJ5IGFkZGl0aW9uYWwgWUFORw0KPj4+Pj4+PiBtb2R1bGVzIGRlZmlu aW5nIGRhdGEgbW9kZWxzIGZvciBpbmRpdmlkdWFsIHJvdXRpbmcgcHJvdG9jb2xzIGFuZA0KPj4+ Pj4+PiBvdGhlciByZWxhdGVkIGZ1bmN0aW9ucy4gIFRoZSBjb3JlIHJvdXRpbmcgZGF0YSBtb2Rl bCBwcm92aWRlcw0KPj4+Pj4+PmNvbW1vbg0KPj4+Pj4+PiBidWlsZGluZyBibG9ja3MgZm9yIHN1 Y2ggZXh0ZW5zaW9ucyAtIHJvdXRpbmcgaW5zdGFuY2VzLCByb3V0ZXMsDQo+Pj4+Pj4+IHJvdXRp bmcgaW5mb3JtYXRpb24gYmFzZXMgKFJJQiksIHJvdXRpbmcgcHJvdG9jb2xzIGFuZCByb3V0ZQ0K Pj4+Pj4+PmZpbHRlcnMuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gVGhlIElFVEYgZGF0 YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+Pj4+Pj4+IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLXJvdXRpbmctY2ZnLw0K Pj4+Pj4+PiANCj4+Pj4+Pj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFi bGUgYXQ6DQo+Pj4+Pj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0 bW9kLXJvdXRpbmctY2ZnLTEzDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBBIGRpZmYgZnJvbSB0aGUgcHJl dmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+Pj4+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbmV0bW9kLXJvdXRpbmctY2ZnLTEzDQo+Pj4+Pj4+ IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4+Pj4+Pj4gc3VibWlzc2lvbg0KPj4+Pj4+ PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+ Pj4+Pj4+dG9vbHMuaWV0Zi5vcmcuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBJbnRlcm5ldC1EcmFmdHMg YXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+Pj4+Pj4+IGZ0cDovL2Z0 cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+PiBuZXRtb2QgbWFp bGluZyBsaXN0DQo+Pj4+Pj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4+Pj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPj4+Pj4+IA0KPj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gbmV0bW9kIG1h aWxpbmcgbGlzdA0KPj4+Pj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+Pj4+PiANCj4+Pj4+IC0tDQo+Pj4+PiBM YWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+Pj4+PiBQR1AgS2V5IElEOiBFNzRFOEMwQw0K Pj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0K Pj4+Pj4gbmV0bW9kQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldG1vZA0KPj4+PiANCj4+Pg0KPj4+LS0NCj4+PkxhZGlzbGF2IExob3RrYSwg Q1ouTklDIExhYnMNCj4+PlBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4N Cj4+DQo+DQo+LS0gDQo+TGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPlBHUCBLZXkgSUQ6 IEU3NEU4QzBDDQoNCg== From nobody Wed Mar 26 01:03:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071171A02D8 for ; Wed, 26 Mar 2014 01:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8KHZrWn0fPV for ; Wed, 26 Mar 2014 01:03:30 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 79DD61A00B0 for ; Wed, 26 Mar 2014 01:03:30 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id CB48437C326; Wed, 26 Mar 2014 09:03:27 +0100 (CET) Date: Wed, 26 Mar 2014 09:03:27 +0100 (CET) Message-Id: <20140326.090327.376919656025274702.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/3HGqDlM9al3NMnehZlLJLfZH16w Cc: netmod@ietf.org Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 08:03:32 -0000 Ladislav Lhotka wrote: > Andy Bierman writes: > > >> > >> > > I do not see the error. Are you saying all the when-stmts that are in > > YANG > > 1.0 > > modules now are broken? Are you saying they are unimplementable? > > What I am saying is that data model fragments like > > container foo { > when "1 = 0"; > leaf bar { > mandatory true; > ... > } > } > > don't have a satisfactory interpretation. I think it is very clear. The when expression is false, which means that container foo can never exist, and thus bar can never exist. > It is fully defensible if a > validation tool flags datastore content as invalid if it doesn't > contain the "foo" container and the mandatory "bar" leaf. No. /martin From nobody Wed Mar 26 01:39:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF3C1A0254 for ; Wed, 26 Mar 2014 01:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sKZ2juhl3Xf for ; Wed, 26 Mar 2014 01:39:42 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3C63B1A0090 for ; Wed, 26 Mar 2014 01:39:41 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id s2Q8ddAc007298; Wed, 26 Mar 2014 09:39:39 +0100 Message-ID: <5332924A.2080708@mg-soft.com> Date: Wed, 26 Mar 2014 09:39:38 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Martin Bjorklund References: <20140326.090327.376919656025274702.mbj@tail-f.com> In-Reply-To: <20140326.090327.376919656025274702.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/X725mMAbHe_EmYPG6-Vxm05E2H0 Cc: netmod@ietf.org Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 08:39:45 -0000 Dne 26.3.2014 9:03, piše Martin Bjorklund: > Ladislav Lhotka wrote: >> Andy Bierman writes: >> >>>> >>> I do not see the error. Are you saying all the when-stmts that are in >>> YANG >>> 1.0 >>> modules now are broken? Are you saying they are unimplementable? >> What I am saying is that data model fragments like >> >> container foo { >> when "1 = 0"; >> leaf bar { >> mandatory true; >> ... >> } >> } >> >> don't have a satisfactory interpretation. > I think it is very clear. The when expression is false, which means > that container foo can never exist, and thus bar can never exist. I agree. This particular case is covered in section 8.2. Conditions on parent nodes affect constraints on child nodes as a natural consequence of the hierarchy of nodes. "must", "mandatory", "min-elements", and "max-elements" constraints are not enforced if the parent node has a "when" or "if-feature" property that is not satisfied on the current device. > >> It is fully defensible if a >> validation tool flags datastore content as invalid if it doesn't >> contain the "foo" container and the mandatory "bar" leaf. > No. A smart compiler would flag this as a warning, since the module defines a data node subtree that is not instantiable. It could also prune this branch so it is never part of the schema tree and thus never a problem when validating content. Jernej > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Mar 26 05:03:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C121A0067 for ; Wed, 26 Mar 2014 05:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvyjohC4-fSJ for ; Wed, 26 Mar 2014 05:03:01 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id D42871A0055 for ; Wed, 26 Mar 2014 05:02:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id CB84754037F; Wed, 26 Mar 2014 13:02:56 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiZn4bxvVgfm; Wed, 26 Mar 2014 13:02:46 +0100 (CET) Received: from localhost (ip-94-113-93-24.net.upcbroadband.cz [94.113.93.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 2582E540087; Wed, 26 Mar 2014 13:02:43 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20140326.090327.376919656025274702.mbj@tail-f.com> References: <20140326.090327.376919656025274702.mbj@tail-f.com> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Wed, 26 Mar 2014 13:02:42 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kjhNcK1CMsUurrGagN4eQw0Jcr0 Cc: netmod@ietf.org Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 12:03:03 -0000 Martin Bjorklund writes: > Ladislav Lhotka wrote: >> Andy Bierman writes: >> >> >> >> >> >> > I do not see the error. Are you saying all the when-stmts that are in >> > YANG >> > 1.0 >> > modules now are broken? Are you saying they are unimplementable? >> >> What I am saying is that data model fragments like >> >> container foo { >> when "1 = 0"; >> leaf bar { >> mandatory true; >> ... >> } >> } >> >> don't have a satisfactory interpretation. > > I think it is very clear. The when expression is false, which means You cannot tell because you cannot evaluate the XPath expression, if you follow XPath rules. I guess it is why you put Y18 into the issue list, right? It is irrelevant what the XPath expression is, I used this trivial one to make my point. And I also believe your proposed solution fails short. If you want something closer to "real use cases", here is one: container dhcp { when "not(../bootp)"; leaf enabled { type boolean; default "true"; } ... } container bootp { when "not(../dhcp)"; leaf enabled { type boolean; default "true"; } ... } If neither bootp nor dhcp is explicitly configured, what is the device supposed to do? Run dhcp, bootp or neither? Cases like this are bound to happen, especially if modules are developed in a distributed way. Lada > that container foo can never exist, and thus bar can never exist. > >> It is fully defensible if a >> validation tool flags datastore content as invalid if it doesn't >> contain the "foo" container and the mandatory "bar" leaf. > > No. > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 26 05:10:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF471A0055 for ; Wed, 26 Mar 2014 05:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJVEfWOelZeP for ; Wed, 26 Mar 2014 05:10:44 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7561A0039 for ; Wed, 26 Mar 2014 05:10:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id B669854037F; Wed, 26 Mar 2014 13:10:42 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sw1p4bQNY1ze; Wed, 26 Mar 2014 13:10:37 +0100 (CET) Received: from localhost (ip-94-113-93-24.net.upcbroadband.cz [94.113.93.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id A5EDE540087; Wed, 26 Mar 2014 13:10:36 +0100 (CET) From: Ladislav Lhotka To: Jernej Tuljak , Martin Bjorklund In-Reply-To: <5332924A.2080708@mg-soft.com> References: <20140326.090327.376919656025274702.mbj@tail-f.com> <5332924A.2080708@mg-soft.com> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Wed, 26 Mar 2014 13:10:35 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/V78pnNCPi8dhfwTJuXt0oaWOpCU Cc: netmod@ietf.org Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 12:10:47 -0000 Jernej Tuljak writes: > Dne 26.3.2014 9:03, pi=C5=A1e Martin Bjorklund: >> Ladislav Lhotka wrote: >>> Andy Bierman writes: >>> >>>>> >>>> I do not see the error. Are you saying all the when-stmts that are in >>>> YANG >>>> 1.0 >>>> modules now are broken? Are you saying they are unimplementable? >>> What I am saying is that data model fragments like >>> >>> container foo { >>> when "1 =3D 0"; >>> leaf bar { >>> mandatory true; >>> ... >>> } >>> } >>> >>> don't have a satisfactory interpretation. >> I think it is very clear. The when expression is false, which means >> that container foo can never exist, and thus bar can never exist. > > I agree. This particular case is covered in section 8.2. > > Conditions on parent nodes affect constraints on child nodes as a > natural consequence of the hierarchy of nodes. "must", "mandatory", > "min-elements", and "max-elements" constraints are not enforced if > the parent node has a "when" or "if-feature" property that is not > satisfied on the current device. This is all fine but the point of this issue is that "when" expression cann= ot be evaluated without having a context node - and the context node must b= e in the data tree (in the instance document, in XML terms). So it is not p= ossible to determine whether it is satisfied or not.=20 > > >> >>> It is fully defensible if a >>> validation tool flags datastore content as invalid if it doesn't >>> contain the "foo" container and the mandatory "bar" leaf. >> No. > > A smart compiler would flag this as a warning, since the module defines=20 > a data node subtree that is not instantiable. It could also prune this=20 > branch so it is never part of the schema tree and thus never a problem=20 > when validating content. I wonder what a smart compiler would do with the example I just sent in my = response to Martin. Lada > > Jernej > >> >> /martin >> >> _______________________________________________ >> 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 Wed Mar 26 05:21:02 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24EF1A032A for ; Wed, 26 Mar 2014 05:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bdo_4JKUlFjf for ; Wed, 26 Mar 2014 05:20:58 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id BE9661A0326 for ; Wed, 26 Mar 2014 05:20:57 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id s2QCKtd7010354; Wed, 26 Mar 2014 13:20:55 +0100 Message-ID: <5332C626.9050808@mg-soft.com> Date: Wed, 26 Mar 2014 13:20:54 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Martin Bjorklund References: <20140324.111757.1429730801819634445.mbj@tail-f.com> In-Reply-To: <20140324.111757.1429730801819634445.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qiHaR3zmK8ONhYFNt-U8q0NpKMM Cc: netmod@ietf.org Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 12:21:01 -0000 Dne 24.3.2014 11:17, piše Martin Bjorklund: > Ladislav Lhotka wrote: >> Hi, >> >> I think the solution Y18-01 is just hand-waving that raises other >> questions: If the context node is tentatively added to the instance >> document, then with what content? Are mandatory descendants supposed >> to be added as well, do contained defaults apply? > Y18-01 says: > > This node has no value and no children. > > It is only added in order to have a context node. I don't see any solution in Y18 for the following problem? http://www.ietf.org/mail-archive/web/netmod/current/msg08917.html Is this a separate issue? Jernej >> This can lead to nasty race conditions, for example: >> >> leaf foo { >> when "../bar/baz" = 42"; >> type uint8; >> } >> container bar { >> when "not(../foo = 1)"; >> leaf baz { >> type uint8; >> default 42; >> } >> } >> >> Then, is the data tree fragment >> >> 1 >> >> valid or not? >> >> The thing is, XPath evaluation needs a fixed XML document that has to >> be properly defined (as it is done, e.g., for "must"). Without it, >> standard XPath tools will never work. >> >> My example also shows that it is not sufficient to forbid "when" >> expressions to refer to nodes below the context node - similar >> pathological situations can arise if two nodes or subtrees refer to >> each other in their "when" expressions. >> >> Here is an alternative solution: >> >> ==== >> >> ** Solution Y18-02 >> >> For validation purposes, treat >> >> when ""; >> >> as equivalent to >> >> must " or not(.)"; > But must expressions are only evaluated if the node exists, so > "not(.)" will always evaluate to false. > > This means that there would be no difference between must and when. > >> This is essentially how RFC 6110 translates "when" to Schematron, >> because there is no other possibility. >> >> What this means is that "when" expressions would not apply in any way >> if the context node is missing (after all defaults "in use" have been >> added). > This is not the intention of when! Your example above is a good use > case of when: > > container foo { > when ../enabled; > leaf bar { > mandatory true; > ... > } > } > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Mar 26 05:29:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F7A1A031F for ; Wed, 26 Mar 2014 05:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgzEG-Auupvf for ; Wed, 26 Mar 2014 05:29:43 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB091A02FB for ; Wed, 26 Mar 2014 05:29:29 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id CA4B13940EF; Wed, 26 Mar 2014 13:29:26 +0100 (CET) Date: Wed, 26 Mar 2014 13:29:26 +0100 (CET) Message-Id: <20140326.132926.2151450329400157840.mbj@tail-f.com> To: jernej.tuljak@mg-soft.si From: Martin Bjorklund In-Reply-To: <5332C626.9050808@mg-soft.com> References: <20140324.111757.1429730801819634445.mbj@tail-f.com> <5332C626.9050808@mg-soft.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/q3q0cbWM4JPbrA_9HEe3E5Lr-gs Cc: netmod@ietf.org Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 12:29:44 -0000 Jernej Tuljak wrote: > Dne 24.3.2014 11:17, pi=A8e Martin Bjorklund: > > Ladislav Lhotka wrote: > >> Hi, > >> > >> I think the solution Y18-01 is just hand-waving that raises other > >> questions: If the context node is tentatively added to the instanc= e > >> document, then with what content? Are mandatory descendants suppos= ed > >> to be added as well, do contained defaults apply? > > Y18-01 says: > > > > This node has no value and no children. > > > > It is only added in order to have a context node. > = > I don't see any solution in Y18 for the following problem? > http://www.ietf.org/mail-archive/web/netmod/current/msg08917.html > Is this a separate issue? No I think it can be handled in the same issue. Now fixed. /martin From nobody Wed Mar 26 05:30:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7494E1A02A9 for ; Wed, 26 Mar 2014 05:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXvFnI7Tguxx for ; Wed, 26 Mar 2014 05:30:03 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A19281A00B4 for ; Wed, 26 Mar 2014 05:30:02 -0700 (PDT) Received: from ladislavs-air-2.lan (ip-94-113-93-24.net.upcbroadband.cz [94.113.93.24]) by mail.nic.cz (Postfix) with ESMTPSA id 324DB13F811; Wed, 26 Mar 2014 13:30:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395837000; bh=yghJHipnDmkk1jMA+FmYudpSo9h1gJwG6Qo/X5ubvr8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=cczzNADXCmDGk827xpMFlSYd9yXQVQ5uDQo75xJAZhGx0a/60mdz4RmZquCnF/hwl yRT3y3do6TURkUJnGPZaznNkFjhl9E0ipUYX1dSKpV/Pmw7BReqzwaxj7BF/BwvUTS 8IZijnIMbIHoldwdneiAxZZIIuEbozRUTScaUE80= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <5332C626.9050808@mg-soft.com> Date: Wed, 26 Mar 2014 13:29:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140324.111757.1429730801819634445.mbj@tail-f.com> <5332C626.9050808@mg-soft.com> To: Jernej Tuljak X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/MCs97xcBR77wI7AUZ7tPRUfOxlM Cc: netmod@ietf.org Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 12:30:04 -0000 On 26 Mar 2014, at 13:20, Jernej Tuljak = wrote: > Dne 24.3.2014 11:17, pi=9Ae Martin Bjorklund: >> Ladislav Lhotka wrote: >>> Hi, >>>=20 >>> I think the solution Y18-01 is just hand-waving that raises other >>> questions: If the context node is tentatively added to the instance >>> document, then with what content? Are mandatory descendants supposed >>> to be added as well, do contained defaults apply? >> Y18-01 says: >>=20 >> This node has no value and no children. >>=20 >> It is only added in order to have a context node. >=20 > I don't see any solution in Y18 for the following problem? > http://www.ietf.org/mail-archive/web/netmod/current/msg08917.html > Is this a separate issue? It is a separate issue, and my understanding is the closest ancestor in = this case is the Operations layer element, such as or = . But you are right, it should be clarified. Lada =20 >=20 > Jernej >=20 >>> This can lead to nasty race conditions, for example: >>>=20 >>> leaf foo { >>> when "../bar/baz" =3D 42"; >>> type uint8; >>> } >>> container bar { >>> when "not(../foo =3D 1)"; >>> leaf baz { >>> type uint8; >>> default 42; >>> } >>> } >>>=20 >>> Then, is the data tree fragment >>>=20 >>> 1 >>>=20 >>> valid or not? >>>=20 >>> The thing is, XPath evaluation needs a fixed XML document that has = to >>> be properly defined (as it is done, e.g., for "must"). Without it, >>> standard XPath tools will never work. >>>=20 >>> My example also shows that it is not sufficient to forbid "when" >>> expressions to refer to nodes below the context node - similar >>> pathological situations can arise if two nodes or subtrees refer to >>> each other in their "when" expressions. >>>=20 >>> Here is an alternative solution: >>>=20 >>> =3D=3D=3D=3D >>>=20 >>> ** Solution Y18-02 >>>=20 >>> For validation purposes, treat >>>=20 >>> when ""; >>>=20 >>> as equivalent to >>>=20 >>> must " or not(.)"; >> But must expressions are only evaluated if the node exists, so >> "not(.)" will always evaluate to false. >>=20 >> This means that there would be no difference between must and when. >>=20 >>> This is essentially how RFC 6110 translates "when" to Schematron, >>> because there is no other possibility. >>>=20 >>> What this means is that "when" expressions would not apply in any = way >>> if the context node is missing (after all defaults "in use" have = been >>> added). >> This is not the intention of when! Your example above is a good use >> case of when: >>=20 >> container foo { >> when ../enabled; >> leaf bar { >> mandatory true; >> ... >> } >> } >>=20 >>=20 >> /martin >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 26 05:40:53 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232981A032C for ; Wed, 26 Mar 2014 05:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evaHfniUXE-u for ; Wed, 26 Mar 2014 05:40:47 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id E89B01A032A for ; Wed, 26 Mar 2014 05:40:46 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id s2QCei8L010561; Wed, 26 Mar 2014 13:40:44 +0100 Message-ID: <5332CACB.8040308@mg-soft.com> Date: Wed, 26 Mar 2014 13:40:43 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ladislav Lhotka References: <20140326.090327.376919656025274702.mbj@tail-f.com> <5332924A.2080708@mg-soft.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mKogfGcQkt5kl03z92gdx-huc0Y Cc: netmod@ietf.org Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 12:40:49 -0000 Dne 26.3.2014 13:10, piÅ¡e Ladislav Lhotka: > Jernej Tuljak writes: > >> Dne 26.3.2014 9:03, piÅ¡e Martin Bjorklund: >>> Ladislav Lhotka wrote: >>>> Andy Bierman writes: >>>> >>>>> I do not see the error. Are you saying all the when-stmts that are in >>>>> YANG >>>>> 1.0 >>>>> modules now are broken? Are you saying they are unimplementable? >>>> What I am saying is that data model fragments like >>>> >>>> container foo { >>>> when "1 = 0"; >>>> leaf bar { >>>> mandatory true; >>>> ... >>>> } >>>> } >>>> >>>> don't have a satisfactory interpretation. >>> I think it is very clear. The when expression is false, which means >>> that container foo can never exist, and thus bar can never exist. >> I agree. This particular case is covered in section 8.2. >> >> Conditions on parent nodes affect constraints on child nodes as a >> natural consequence of the hierarchy of nodes. "must", "mandatory", >> "min-elements", and "max-elements" constraints are not enforced if >> the parent node has a "when" or "if-feature" property that is not >> satisfied on the current device. > This is all fine but the point of this issue is that "when" expression cannot be evaluated without having a context node - and the context node must be in the data tree (in the instance document, in XML terms). So it is not possible to determine whether it is satisfied or not. > >> >>>> It is fully defensible if a >>>> validation tool flags datastore content as invalid if it doesn't >>>> contain the "foo" container and the mandatory "bar" leaf. >>> No. >> A smart compiler would flag this as a warning, since the module defines >> a data node subtree that is not instantiable. It could also prune this >> branch so it is never part of the schema tree and thus never a problem >> when validating content. > I wonder what a smart compiler would do with the example I just sent in my response to Martin. The optimization I hinted at would only work for your previous example (literals or if the compiler realizes that the equality expression is comparing the exact same node sets or anything else that does not require runtime expression evaluation). It's not applicable to your other example, since that requires "full" expression evaluation, and therefore an instance document. Jernej > > Lada > >> Jernej >> >>> /martin >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Mar 26 05:40:56 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CBD1A032A for ; Wed, 26 Mar 2014 05:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gc0m1ECbCop for ; Wed, 26 Mar 2014 05:40:46 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBB71A0322 for ; Wed, 26 Mar 2014 05:40:46 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 6125B37C31C; Wed, 26 Mar 2014 13:34:59 +0100 (CET) Date: Wed, 26 Mar 2014 13:34:59 +0100 (CET) Message-Id: <20140326.133459.706535214012413932.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20140324.111757.1429730801819634445.mbj@tail-f.com> <5332C626.9050808@mg-soft.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9qclLqoCanqGWZRi8VtMEoP7aXc Cc: netmod@ietf.org Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 12:40:51 -0000 Ladislav Lhotka wrote: > = > On 26 Mar 2014, at 13:20, Jernej Tuljak > wrote: > = > > Dne 24.3.2014 11:17, pi=A8e Martin Bjorklund: > >> Ladislav Lhotka wrote: > >>> Hi, > >>> = > >>> I think the solution Y18-01 is just hand-waving that raises other= > >>> questions: If the context node is tentatively added to the instan= ce > >>> document, then with what content? Are mandatory descendants suppo= sed > >>> to be added as well, do contained defaults apply? > >> Y18-01 says: > >> = > >> This node has no value and no children. > >> = > >> It is only added in order to have a context node. > > = > > I don't see any solution in Y18 for the following problem? > > http://www.ietf.org/mail-archive/web/netmod/current/msg08917.html > > Is this a separate issue? > = > It is a separate issue, and my understanding is the closest ancestor > in this case is the Operations layer element, such as or > . But you are right, it should be clarified. No, it doesn't make any sense to add the NETCONF message XML into the mix. As Jernej suggested in his original email, the context node should be the root. /martin From nobody Wed Mar 26 05:43:15 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE191A0089 for ; Wed, 26 Mar 2014 05:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6tb8n9VYiXQ for ; Wed, 26 Mar 2014 05:43:11 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D76D01A00FD for ; Wed, 26 Mar 2014 05:43:10 -0700 (PDT) Received: from ladislavs-air-2.lan (ip-94-113-93-24.net.upcbroadband.cz [94.113.93.24]) by mail.nic.cz (Postfix) with ESMTPSA id 8A40813F811; Wed, 26 Mar 2014 13:43:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395837787; bh=O+xJf3updLNs7elzkl5w246KyF8pGAGyXlsjS1/f4Go=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=lrxE/Fsjm0eee/wpQr0Ww1EaO4a7s48TRERCeQI0dVNCusTgTGW1Xj7cM55gmkfzl C3JqlptikNw8JEhhKsEiZudOvdOdw3sx6w5LrDmPdrNIVFFGYk8OTIg7C8grpuTitV M3PYKh9YU7F4M6d0MOjOczujcOsUidBmaFO6ELck= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <5332CACB.8040308@mg-soft.com> Date: Wed, 26 Mar 2014 13:43:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140326.090327.376919656025274702.mbj@tail-f.com> <5332924A.2080708@mg-soft.com> <5332CACB.8040308@mg-soft.com> To: Jernej Tuljak X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/WOPPjxaU5rxt3qGoE3fTEOxkS_s Cc: netmod@ietf.org Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 12:43:12 -0000 On 26 Mar 2014, at 13:40, Jernej Tuljak = wrote: > Dne 26.3.2014 13:10, pi=9Ae Ladislav Lhotka: >> Jernej Tuljak writes: >>=20 >>> Dne 26.3.2014 9:03, pi=9Ae Martin Bjorklund: >>>> Ladislav Lhotka wrote: >>>>> Andy Bierman writes: >>>>>=20 >>>>>> I do not see the error. Are you saying all the when-stmts that = are in >>>>>> YANG >>>>>> 1.0 >>>>>> modules now are broken? Are you saying they are unimplementable? >>>>> What I am saying is that data model fragments like >>>>>=20 >>>>> container foo { >>>>> when "1 =3D 0"; >>>>> leaf bar { >>>>> mandatory true; >>>>> ... >>>>> } >>>>> } >>>>>=20 >>>>> don't have a satisfactory interpretation. >>>> I think it is very clear. The when expression is false, which = means >>>> that container foo can never exist, and thus bar can never exist. >>> I agree. This particular case is covered in section 8.2. >>>=20 >>> Conditions on parent nodes affect constraints on child nodes as = a >>> natural consequence of the hierarchy of nodes. "must", = "mandatory", >>> "min-elements", and "max-elements" constraints are not enforced = if >>> the parent node has a "when" or "if-feature" property that is = not >>> satisfied on the current device. >> This is all fine but the point of this issue is that "when" = expression cannot be evaluated without having a context node - and the = context node must be in the data tree (in the instance document, in XML = terms). So it is not possible to determine whether it is satisfied or = not. >>=20 >>>=20 >>>>> It is fully defensible if a >>>>> validation tool flags datastore content as invalid if it doesn't >>>>> contain the "foo" container and the mandatory "bar" leaf. >>>> No. >>> A smart compiler would flag this as a warning, since the module = defines >>> a data node subtree that is not instantiable. It could also prune = this >>> branch so it is never part of the schema tree and thus never a = problem >>> when validating content. >> I wonder what a smart compiler would do with the example I just sent = in my response to Martin. >=20 > The optimization I hinted at would only work for your previous example = (literals or if the compiler realizes that the equality expression is = comparing the exact same node sets or anything else that does not = require runtime expression evaluation). It's not applicable to your = other example, since that requires "full" expression evaluation, and = therefore an instance document. The instance document is such that neither =93dhcp=94 nor =93bootp=94 = container is present. Lada >=20 > Jernej >=20 >>=20 >> Lada >>=20 >>> Jernej >>>=20 >>>> /martin >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 26 06:25:57 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F1E1A0327 for ; Wed, 26 Mar 2014 06:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mj9wS-dlWlRe for ; Wed, 26 Mar 2014 06:25:53 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 090B31A00DC for ; Wed, 26 Mar 2014 06:25:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 4CCDD54037F; Wed, 26 Mar 2014 14:25:50 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGotMtj03vQT; Wed, 26 Mar 2014 14:25:44 +0100 (CET) Received: from localhost (ip-94-113-93-24.net.upcbroadband.cz [94.113.93.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id DF36B540010; Wed, 26 Mar 2014 14:25:42 +0100 (CET) From: Ladislav Lhotka To: "Yi Yang \(yiya\)" , "Derek Man-Kit Yeung \(myeung\)" In-Reply-To: References: <20140110133016.24678.42711.idtracker@ietfa.amsl.com> <9C81158E-5B4C-4479-AEA5-23CBCC020ADD@nic.cz> <0ED855DA-51BE-4DE6-AB22-E1A9E04C0E5F@nic.cz> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Wed, 26 Mar 2014 14:25:40 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/MI5zMMuamkdKR5c46SY_XAc86o0 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 13:25:56 -0000 Hi Yi, "Yi Yang (yiya)" writes: > Hi Lada, > > In the current model, default-ribs will exist only when feature > multiple-ribs exists. This is contradictory to what people are familiar in > the real world deployment -- default-ribs always exist. Note that default-ribs depends on that feature only in configuration but no= t in operational state data. So, the idea is that the system puts the name(= s) of default RIB(s) into the default-rib list in operational state, so the= client is able to learn easily what the default (and only) RIB is for each= address family. But whenever the server doesn't support multiple RIBs per = address family, there is no point to have default-ribs as a configuration o= ption. Does it make sense? Thanks, Lada > > To reflect such an expectation, I suggest to keep default-ribs > unconditionally. Instead, move the conditions to the ribs -- if feature > multiple-ribs doesn't exist, only one rib is allowed per address family. > > Yi > > > On 3/19/14 3:51 AM, "Ladislav Lhotka" wrote: > >>"Derek Man-Kit Yeung (myeung)" writes: >> >>> On 3/14/14 12:49 PM, "Ladislav Lhotka" wrote: >>> >>>> >>>>On 14 Mar 2014, at 20:32, Derek Man-Kit Yeung (myeung) >>>> >>>>wrote: >>>> >>>>>=20 >>>>>=20 >>>>> On 3/7/14 2:29 PM, "Ladislav Lhotka" wrote: >>>>>=20 >>>>>>=20 >>>>>> On 07 Mar 2014, at 22:52, Yi Yang (yiya) wrote: >>>>>>=20 >>>>>>> One thing is missing from the data model is association with vrf. >>>>>>=20 >>>>>> I agree with what Martin wrote in a parallel thread. I believe the >>>>>> routing module (and YANG augment statement) provide sufficient hooks >>>>>>for >>>>>> implementing VRF as a specific type of routing-instance. >>>>>=20 >>>>>=20 >>>>> The draft mentioned the routing-instance could be used to represents a >>>>> logical router. >>>>>=20 >>>>> The term "logical router" in one or more vendors mean a partition of >>>>>the >>>>> physical router into multiple logical units, each could have multiple >>>>>VRFs. >>>>>=20 >>>>> Does the draft intend to manage "logical router" in the above >>>>>definition? >>>>> Some clarification will be useful. >>>> >>>>One way to implement this is to introduce two types of routing >>>>instances, >>>>say 'logical-router=C2=B9 and =C5=92vrf=C2=B9. The =C5=92vrf=C2=B9 type= then would have another >>>>leaf linking it to a logical router. This is quite like the various >>>>methods of interface stacking, see the examples in >>>>draft-ietf-netmod-interfaces-cfg-16. >>>> >>>>Lada >>> >>> >>> It is one way.=20 >>> However, given that current model that everything is put inside a >>> routing-instance, things like RIB, routing-protocols etc are no longer >>> needed directly under the 'logical-router'. >> >>Note that RIBs are not inside "routing-instance", although an >>implementation may define some RIBs to be routing-instance-specific. >> >>> What needed in the 'logical router' are resources allocation like >>> interfaces, CPU etc. >> >>"interfaces" is a container inside "routing-instance", and "cpu" can be >>easily added by another module via augmentation. >> >>> Though routing-instance could be augmented to include 'logical router' >>> specific field and add new condition to restrict existing leaf that no >>> long apply, I think a new container above routing-instance is cleaner. >>>It >>> could be a new data model that reference the definition in the current >>> draft. >> >>I guess part of the confusion stems from the name "routing-instance" >>which already means a particular (platform-specific) style of router >>virtualization. Earlier revisions of the draft used "router" list in this >>place but it was an specific requirement of I2RS folks to change this >>name to "routing-instance". Oh well ... >> >>So please keep in mind that "routing-instance" can really mean different >>things depending on its type (and can be augmented in different ways >>depending on the type). Again, this approach is very similar to the one >>adopted for the "interface" list in "ietf-interfaces" module. >> >>Lada >> >>> >>> - Derek >>> >>>> >>>>>=20 >>>>> - Derek >>>>>=20 >>>>>>=20 >>>>>> I think though that other work extending the routing module is much >>>>>>more >>>>>> needed, namely vendor-neutral data models for routing protocols. >>>>>>=20 >>>>>> The consensus of the NETMOD WG was that these new modules should be >>>>>> developed by experts in the Routing Area (VRF in the MPLS WG?). The >>>>>> NETMOD WG and YANG Doctors will certainly help but the bulk of this >>>>>>work >>>>>> should be done by domain experts. >>>>>>=20 >>>>>> Lada >>>>>>=20 >>>>>>>=20 >>>>>>> Another concern I have is about address family. To facilitate a >>>>>>>query >>>>>>> based on AFI only, or SAFI only, it seems more convenient to use two >>>>>>> leafs >>>>>>> (AFI and SAFI) instead of one (AFI-SAFI). >>>>>>>=20 >>>>>>> Yi >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 1/10/14 8:30 AM, "internet-drafts@ietf.org" >>>>>>> >>>>>>> wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> 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 >>>>>>>>Working >>>>>>>> Group of the IETF. >>>>>>>>=20 >>>>>>>> Title : A YANG Data Model for Routing Management >>>>>>>> Author : Ladislav Lhotka >>>>>>>> Filename : draft-ietf-netmod-routing-cfg-13.txt >>>>>>>> Pages : 95 >>>>>>>> Date : 2014-01-10 >>>>>>>>=20 >>>>>>>> Abstract: >>>>>>>> This document contains a specification of three YANG modules. >>>>>>>> Together they form the core routing data model which serves as a >>>>>>>> framework for configuring and managing a routing subsystem. It is >>>>>>>> expected that these modules will be augmented by additional YANG >>>>>>>> modules defining data models for individual routing protocols and >>>>>>>> other related functions. The core routing data model provides >>>>>>>>common >>>>>>>> building blocks for such extensions - routing instances, routes, >>>>>>>> routing information bases (RIB), routing protocols and route >>>>>>>>filters. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ >>>>>>>>=20 >>>>>>>> There's also a htmlized version available at: >>>>>>>> http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13 >>>>>>>>=20 >>>>>>>> A diff from the previous version is available at: >>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg-13 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> netmod mailing list >>>>>>>> netmod@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>>>=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 >>>> >>>>-- >>>>Ladislav Lhotka, CZ.NIC Labs >>>>PGP Key ID: E74E8C0C >>>> >>>> >>>> >>>> >>> >> >>--=20 >>Ladislav Lhotka, CZ.NIC Labs >>PGP Key ID: E74E8C0C > --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 26 06:34:44 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3F91A0339 for ; Wed, 26 Mar 2014 06:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wu5dwjnmuDY6 for ; Wed, 26 Mar 2014 06:34:42 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 43A061A0334 for ; Wed, 26 Mar 2014 06:34:42 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 3C01137C320; Wed, 26 Mar 2014 14:34:40 +0100 (CET) Date: Wed, 26 Mar 2014 14:34:40 +0100 (CET) Message-Id: <20140326.143440.588668936751872922.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_bBZe_vJO8w89pfRdsSzob63z7c Cc: netmod@ietf.org Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 13:34:43 -0000 Hi, Here's yet another attempt to handle attributes in JSON, without changing the encoding for the case that there are no attributes present. In all examples, the attributes "inactive" and "etag" are present. Attributes are encoded differently depending on the type of object: leaf ---- Encode the attributes as a sibling to the leaf. leaf foo { type string; } "foo": "some value"; "@foo": { "inactive": true, "etag": "..."; } list instance ------------- Encode the attributes within the list instance. list bar { key name; leaf name { type string; } ... } "bar": [ { "@bar": { "inactive": true, "etag": "..." } "name": "instance name"; }] container --------- Encode the attributes within the container. container baz; "baz": { "@baz": { "inactive": true, "etag": "..." } } leaf-list --------- Encode the attributes as a sibling to the leaf-list, with an array of same length as the leaf-list itself. leaf-list buzz { type string; } "buzz": [ "val1", "val2", "val3" ], "@buzz: [ null, { "inactive": true, "etag": "..." } null] /martin From nobody Wed Mar 26 06:35:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82F31A0339 for ; Wed, 26 Mar 2014 06:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6p0KULy2ok8 for ; Wed, 26 Mar 2014 06:35:24 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 371E91A0333 for ; Wed, 26 Mar 2014 06:35:22 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id s2QDZJ30011338; Wed, 26 Mar 2014 14:35:19 +0100 Message-ID: <5332D796.8070702@mg-soft.com> Date: Wed, 26 Mar 2014 14:35:18 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Martin Bjorklund References: <20140324.111757.1429730801819634445.mbj@tail-f.com> <5332C626.9050808@mg-soft.com> <20140326.132926.2151450329400157840.mbj@tail-f.com> In-Reply-To: <20140326.132926.2151450329400157840.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ilNMIeqoeBPBkblyIsv5lrsFFGo Cc: netmod@ietf.org Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 13:35:31 -0000 Hi, in Y18-01: o If the "when" statement is a child of any other data definition statement, the context node is a node with the same name as the data definition node would have if it existed. This node has no value and no children. Doesn't "data definition node" sound wrong? This term is used in section 10 already and seems to refer to data definition statements/schema nodes. o Any set of data definition nodes may be replaced with another set of syntactically and semantically equivalent nodes. For example, a set of leafs may be replaced by a uses of a grouping with the same leafs. A schema node always exists... What may not exist is an instance of a data node in the data tree. Jernej Dne 26.3.2014 13:29, pi¨e Martin Bjorklund: > Jernej Tuljak wrote: >> Dne 24.3.2014 11:17, pi¨e Martin Bjorklund: >>> Ladislav Lhotka wrote: >>>> Hi, >>>> >>>> I think the solution Y18-01 is just hand-waving that raises other >>>> questions: If the context node is tentatively added to the instance >>>> document, then with what content? Are mandatory descendants supposed >>>> to be added as well, do contained defaults apply? >>> Y18-01 says: >>> >>> This node has no value and no children. >>> >>> It is only added in order to have a context node. >> I don't see any solution in Y18 for the following problem? >> http://www.ietf.org/mail-archive/web/netmod/current/msg08917.html >> Is this a separate issue? > No I think it can be handled in the same issue. > > Now fixed. > > > /martin From nobody Wed Mar 26 06:41:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FF91A0348 for ; Wed, 26 Mar 2014 06:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SQAd4omHqS9 for ; Wed, 26 Mar 2014 06:40:54 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 1040C1A0340 for ; Wed, 26 Mar 2014 06:40:54 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 437AB37C320; Wed, 26 Mar 2014 14:40:52 +0100 (CET) Date: Wed, 26 Mar 2014 14:40:52 +0100 (CET) Message-Id: <20140326.144052.571820635017153121.mbj@tail-f.com> To: jernej.tuljak@mg-soft.si From: Martin Bjorklund In-Reply-To: <5332D796.8070702@mg-soft.com> References: <5332C626.9050808@mg-soft.com> <20140326.132926.2151450329400157840.mbj@tail-f.com> <5332D796.8070702@mg-soft.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/QBLiQQqYuTAmUVu_a0ZSe_JKPLk Cc: netmod@ietf.org Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 13:40:56 -0000 Jernej Tuljak wrote: > Hi, > > in Y18-01: > > o If the "when" statement is a child of any other data definition > statement, the context node is a node with the same name as the data > definition node would have if it existed. This node has no value and > no children. > > Doesn't "data definition node" sound wrong? Yes, it should be "data definition's node". NEW2: o If the "when" statement is a child of any other data definition statement, the context node is a node with the same name as the data definition's node would have if it existed in the tree. This node has no value and no children. /martin From nobody Wed Mar 26 06:41:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88FEC1A0348 for ; Wed, 26 Mar 2014 06:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKSnAdH8YEK1 for ; Wed, 26 Mar 2014 06:41:04 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 351B31A0340 for ; Wed, 26 Mar 2014 06:41:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 52C9254037F; Wed, 26 Mar 2014 14:41:02 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBHULXcpug-E; Wed, 26 Mar 2014 14:40:57 +0100 (CET) Received: from localhost (ip-94-113-93-24.net.upcbroadband.cz [94.113.93.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id B0F82540087; Wed, 26 Mar 2014 14:40:56 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <20140324.111757.1429730801819634445.mbj@tail-f.com> <6497C153-01EF-4266-B944-40FACD7052E8@nic.cz> <39BF58F5-2078-42FA-86D5-DD46960E5FC3@nic.cz> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Wed, 26 Mar 2014 14:40:55 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/XS0OsAVNS3yc_bfdu_AJs4Woj14 Cc: "netmod@ietf.org" Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 13:41:07 -0000 Andy Bierman writes: > On Tue, Mar 25, 2014 at 2:40 PM, Ladislav Lhotka wrote: > >> Andy Bierman writes: >> >> >> >> >> >> > I do not see the error. Are you saying all the when-stmts that are in >> YANG >> > 1.0 >> > modules now are broken? Are you saying they are unimplementable? >> >> What I am saying is that data model fragments like >> >> container foo { >> when "1 = 0"; >> leaf bar { >> mandatory true; >> ... >> } >> } >> >> don't have a satisfactory interpretation. It is fully defensible if a >> validation tool flags datastore content as invalid if it doesn't contain >> the "foo" container and the mandatory "bar" leaf. >> >> > > Like I said, the pathological cases are operationally useless. > Nobody would ever write "when 1 = 0". We should avoid adding The XPath expression doesn't matter, the problem is the same whatever the expression is. > CLRs to YANG that are intended from preventing people from doing things > they would not even try to do. It is just busy work for compiler writers. > > > > >> > >> > YANG 1.0 when-stmts need to be unchanged in YANG 1.1. >> > The issue of evaluating a when-expr as if there was a context >> > node inserted is a completely different issue than the order that >> > multiple when-stmts are evaluated. Changing the context node >> > to the parent does not alter the evaluation order problem. >> >> That's true, but it does make a difference whether you insert all the >> temporary context nodes at once or one by one. >> >> > To be honest -- it doesn't. Setting all the context nodes to random values It doesn't? So how do you proceed with inserting these dummy nodes in my recent dhcp/bootp example? > is just as arbitrarily incorrect as leaving them all out. Truth is, if > there are > dependency arcs then they have to be resolved in the correct order. > > Our client code does not do that (yet). If you are trying to test > when-stmts on > the client side in order to prevent showing the user false-when-nodes, > then it might be either order-dependent or impossible. Unlike AJAX menus > where the conditional arcs are usually downward, the XPath arcs can go > anywhere. > > Unlike "import" resolution, resolving arbitrary XPath could be impossible. > Any XPath expert could construct pathological expressions like "not(.)" > where the outcome makes YANG validation implementation-dependent or > impossible. > > >> >> > The rules for what nodes can be accessed (directly or indirectly >> > via XPath mechanisms) cannot be changed because that would break >> > YANG 1.0 when statements. >> > >> >> If you develop YANG modules for your customers, you can certainly make >> sure that everything works as expected because you are aware of the dark >> corners. >> >> But if the plan is to offer YANG for general use, then the spec IMO must >> be rock solid. The idea that I can write a valid YANG module that will most >> likely blow up almost any tool around makes me nervous. >> >> > > We can do something like mandatory top-level node -- write guidelines. > They are allowed in YANG but not in IETF modules. > The statement "while (1);" is allowed is C but it usually > is not a good thing to do. YANG is not a programming language. If you have a valid XSD schema and an XML instance document, you probably don't expect an XSD validator to dump core. Lada > > > Lada >> >> > > Andy > > > >> > >> > >> > >> >> Lada >> >> >> >> >> > >> > Andy >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 26 06:52:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8219B1A0351 for ; Wed, 26 Mar 2014 06:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y81Hx_qAq3YD for ; Wed, 26 Mar 2014 06:52:01 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B94E51A0348 for ; Wed, 26 Mar 2014 06:52:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id DDFFD54037F; Wed, 26 Mar 2014 14:51:58 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiIvBG1P59O7; Wed, 26 Mar 2014 14:51:54 +0100 (CET) Received: from localhost (ip-94-113-93-24.net.upcbroadband.cz [94.113.93.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 55A9C540087; Wed, 26 Mar 2014 14:51:54 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund , andy@yumaworks.com In-Reply-To: <20140326.143440.588668936751872922.mbj@tail-f.com> References: <20140326.143440.588668936751872922.mbj@tail-f.com> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Wed, 26 Mar 2014 14:51:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jgh9ryzg_VTcNvEP8wyoTYg1caw Cc: netmod@ietf.org Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 13:52:02 -0000 Martin Bjorklund writes: > Hi, > > Here's yet another attempt to handle attributes in JSON, without > changing the encoding for the case that there are no attributes > present. > > In all examples, the attributes "inactive" and "etag" are present. > > Attributes are encoded differently depending on the type of object: > > > leaf > ---- > > Encode the attributes as a sibling to the leaf. > > > leaf foo { > type string; > } > > "foo": "some value"; > "@foo": { > "inactive": true, > "etag": "..."; > } > > > list instance > ------------- > > Encode the attributes within the list instance. > > > list bar { > key name; > leaf name { > type string; > } > ... > } > > "bar": [ > { > "@bar": { > "inactive": true, > "etag": "..." > } > "name": "instance name"; > }] > This could be ambiguous: list bar { key name; leaf name { ... } leaf bar { ... } } Then you don't know whether the attributes belong to the list entry or to the contained leaf. Lada > > container > --------- > > Encode the attributes within the container. > > > container baz; > > "baz": { > "@baz": { > "inactive": true, > "etag": "..." > } > } > > > leaf-list > --------- > > Encode the attributes as a sibling to the leaf-list, with an array of > same length as the leaf-list itself. > > > leaf-list buzz { > type string; > } > > "buzz": [ "val1", "val2", "val3" ], > "@buzz: [ null, > { "inactive": true, > "etag": "..." > } > null] > > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 26 06:53:08 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACAA61A00FB for ; Wed, 26 Mar 2014 06:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FW5P32pNXjsd for ; Wed, 26 Mar 2014 06:53:05 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) by ietfa.amsl.com (Postfix) with ESMTP id F32261A00F9 for ; Wed, 26 Mar 2014 06:53:04 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id j107so858071qga.7 for ; Wed, 26 Mar 2014 06:53:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RPVcI2ESZx9X/QxDZwwJsM7e9SndX4sUmBKra2ETxYg=; b=Q9YUfGpBQD5ZNhpzQp5SkMJit2hPBKy/AcpgJf5VFyAqk/aFtlqvbKsgubS5srqHPS SiiOq/sac6ggLKUTcaWTYHYdl1PG55xu3MDChZSQ8UpspahVxYaC5+0g584CuhWhMRGC avfvh3xXZHnZk6M7Qxj9pfcHoOCvVkORfZa9YZX3aAQwSXZnnKUHKVWgeiBUroLs0jjZ p1uvR8dOUscd1ELwLY/nbl3e1BoXYCZF6wXzOMYk2eDU/9mSI5Z9d+rfIBRWVB6uWTTO LHHh5YnDzt2z0ImwxX7rRSjPX1a+vwrlNYwkPt7QeRSj5Lr5oNHd4QWlwLxwv0n+YS9+ HsOg== X-Gm-Message-State: ALoCoQmJGK6yLmmhDdZg1FkA9/Ro//3MatbEruJuDOo2vNNVJYw25YHb3xRT3lPMjjNLvl46OWuZ MIME-Version: 1.0 X-Received: by 10.224.66.8 with SMTP id l8mr89531654qai.16.1395841983300; Wed, 26 Mar 2014 06:53:03 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Wed, 26 Mar 2014 06:53:03 -0700 (PDT) In-Reply-To: References: <20140324.111757.1429730801819634445.mbj@tail-f.com> <6497C153-01EF-4266-B944-40FACD7052E8@nic.cz> <39BF58F5-2078-42FA-86D5-DD46960E5FC3@nic.cz> Date: Wed, 26 Mar 2014 06:53:03 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c2c27a93d8ed04f582c93b Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/GCyB8cf4FCVFq0HJfy4Uh4PROtA Cc: "netmod@ietf.org" Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 13:53:06 -0000 --001a11c2c27a93d8ed04f582c93b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 26, 2014 at 6:40 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Tue, Mar 25, 2014 at 2:40 PM, Ladislav Lhotka wrote: > > > >> Andy Bierman writes: > >> > >> >> > >> >> > >> > I do not see the error. Are you saying all the when-stmts that are in > >> YANG > >> > 1.0 > >> > modules now are broken? Are you saying they are unimplementable? > >> > >> What I am saying is that data model fragments like > >> > >> container foo { > >> when "1 = 0"; > >> leaf bar { > >> mandatory true; > >> ... > >> } > >> } > >> > >> don't have a satisfactory interpretation. It is fully defensible if a > >> validation tool flags datastore content as invalid if it doesn't contain > >> the "foo" container and the mandatory "bar" leaf. > >> > >> > > > > Like I said, the pathological cases are operationally useless. > > Nobody would ever write "when 1 = 0". We should avoid adding > > The XPath expression doesn't matter, the problem is the same whatever the > expression is. > > > CLRs to YANG that are intended from preventing people from doing things > > they would not even try to do. It is just busy work for compiler > writers. > > > > > > > > > >> > > >> > YANG 1.0 when-stmts need to be unchanged in YANG 1.1. > >> > The issue of evaluating a when-expr as if there was a context > >> > node inserted is a completely different issue than the order that > >> > multiple when-stmts are evaluated. Changing the context node > >> > to the parent does not alter the evaluation order problem. > >> > >> That's true, but it does make a difference whether you insert all the > >> temporary context nodes at once or one by one. > >> > >> > > To be honest -- it doesn't. Setting all the context nodes to random > values > > It doesn't? So how do you proceed with inserting these dummy nodes in my > recent dhcp/bootp example? > > I would not allow that module to be published. It would have to be rewritten so there was no dependency loop. > > is just as arbitrarily incorrect as leaving them all out. Truth is, if > > there are > > dependency arcs then they have to be resolved in the correct order. > > > > Our client code does not do that (yet). If you are trying to test > > when-stmts on > > the client side in order to prevent showing the user false-when-nodes, > > then it might be either order-dependent or impossible. Unlike AJAX menus > > where the conditional arcs are usually downward, the XPath arcs can go > > anywhere. > > > > Unlike "import" resolution, resolving arbitrary XPath could be > impossible. > > Any XPath expert could construct pathological expressions like "not(.)" > > where the outcome makes YANG validation implementation-dependent or > > impossible. > > > > > >> > >> > The rules for what nodes can be accessed (directly or indirectly > >> > via XPath mechanisms) cannot be changed because that would break > >> > YANG 1.0 when statements. > >> > > >> > >> If you develop YANG modules for your customers, you can certainly make > >> sure that everything works as expected because you are aware of the dark > >> corners. > >> > >> But if the plan is to offer YANG for general use, then the spec IMO must > >> be rock solid. The idea that I can write a valid YANG module that will > most > >> likely blow up almost any tool around makes me nervous. > >> > >> > > > > We can do something like mandatory top-level node -- write guidelines. > > They are allowed in YANG but not in IETF modules. > > The statement "while (1);" is allowed is C but it usually > > is not a good thing to do. > > YANG is not a programming language. If you have a valid XSD schema and an > XML instance document, you probably don't expect an XSD validator to dump > core. > > Lada > > > > > > > Lada > >> > >> > > > > Andy > > > > > > > >> > > >> > > >> > > >> >> Lada > >> >> > >> >> > >> > > >> > Andy > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --001a11c2c27a93d8ed04f582c93b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Mar 26, 2014 at 6:40 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:
Andy Bierman <andy@yumaworks.com> writes:

> On Tue, Mar 25, 2014 at 2:40 PM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
>> Andy Bierman <andy@yumawo= rks.com> writes:
>>
>> >>
>> >>
>> > I do not see the error. =A0Are you saying all the when-stmts = that are in
>> YANG
>> > 1.0
>> > modules now are broken? Are you saying they are unimplementab= le?
>>
>> What I am saying is that data model fragments like
>>
>> container foo {
>> =A0 =A0 when "1 =3D 0";
>> =A0 =A0 leaf bar {
>> =A0 =A0 =A0 =A0 mandatory true;
>> =A0 =A0 =A0 =A0 ...
>> =A0 =A0 }
>> }
>>
>> don't have a satisfactory interpretation. It is fully defensib= le if a
>> validation tool flags datastore content as invalid if it doesn'= ;t contain
>> the "foo" container and the mandatory "bar" le= af.
>>
>>
>
> Like I said, the pathological cases are operationally useless.
> Nobody would ever write "when 1 =3D 0". We should avoid addi= ng

The XPath expression doesn't matter, the problem is the same whatever t= he expression is.

> CLRs to YANG that are intended from preventing people from doing thing= s
> they would not even try to do. =A0It is just busy work for compiler wr= iters.
>
>
>
>
>> >
>> > YANG 1.0 when-stmts need to be unchanged in YANG 1.1.
>> > The issue of evaluating a when-expr as if there was a context=
>> > node inserted is a completely different issue than the order = that
>> > multiple when-stmts are evaluated. =A0Changing the context no= de
>> > to the parent does not alter the evaluation order problem. >>
>> That's true, but it does make a difference whether you insert = all the
>> temporary context nodes at once or one by one.
>>
>>
> To be honest -- it doesn't. =A0Setting all the context nodes to ra= ndom values

It doesn't? So how do you proceed with inserting these dummy nodes in m= y recent dhcp/bootp example?


I would not allow that module to be pu= blished.
It would have to be rewritten so there was no dependency= loop.

=A0
> is just as arbitrarily incorrect as leaving them all out. Truth is, if=
> there are
> dependency arcs then they have to be resolved in the correct order. >
> Our client code does not do that (yet). =A0If you are trying to test > when-stmts on
> the client side in order to prevent showing the user false-when-nodes,=
> then it might be either order-dependent or impossible. =A0Unlike AJAX = menus
> where the conditional arcs are usually downward, the XPath arcs can go=
> anywhere.
>
> Unlike "import" resolution, resolving arbitrary XPath could = be impossible.
> Any XPath expert could construct pathological expressions like "n= ot(.)"
> where the outcome makes YANG validation implementation-dependent or > impossible.
>
>
>>
>> > The rules for what nodes can be accessed (directly or indirec= tly
>> > via XPath mechanisms) cannot be changed because that would br= eak
>> > YANG 1.0 when statements.
>> >
>>
>> If you develop YANG modules for your customers, you can certainly = make
>> sure that everything works as expected because you are aware of th= e dark
>> corners.
>>
>> But if the plan is to offer YANG for general use, then the spec IM= O must
>> be rock solid. The idea that I can write a valid YANG module that = will most
>> likely blow up almost any tool around makes me nervous.
>>
>>
>
> We can do something like mandatory top-level node -- write guidelines.=
> They are allowed in YANG but not in IETF modules.
> The statement "while (1);" is allowed is C but it usually > is not a good thing to do.

YANG is not a programming language. If you have a valid XSD schema and an X= ML instance document, you probably don't expect an XSD validator to dum= p core.

Lada

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

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

--001a11c2c27a93d8ed04f582c93b-- From nobody Wed Mar 26 06:53:57 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178821A02D8 for ; Wed, 26 Mar 2014 06:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3y8i7adBk8yI for ; Wed, 26 Mar 2014 06:53:42 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF1A1A0113 for ; Wed, 26 Mar 2014 06:53:42 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id s2QDrewn011506; Wed, 26 Mar 2014 14:53:40 +0100 Message-ID: <5332DBE3.7040800@mg-soft.com> Date: Wed, 26 Mar 2014 14:53:39 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ladislav Lhotka References: <20140326.090327.376919656025274702.mbj@tail-f.com> <5332924A.2080708@mg-soft.com> <5332CACB.8040308@mg-soft.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/00wA_fbPHhG-VZNOyxZtXxpyxG0 Cc: netmod@ietf.org Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 13:53:45 -0000 Dne 26.3.2014 13:43, piše Ladislav Lhotka: > On 26 Mar 2014, at 13:40, Jernej Tuljak wrote: > >> Dne 26.3.2014 13:10, piše Ladislav Lhotka: >>> Jernej Tuljak writes: >>> >>>> Dne 26.3.2014 9:03, piše Martin Bjorklund: >>>>> Ladislav Lhotka wrote: >>>>>> Andy Bierman writes: >>>>>> >>>>>>> I do not see the error. Are you saying all the when-stmts that are in >>>>>>> YANG >>>>>>> 1.0 >>>>>>> modules now are broken? Are you saying they are unimplementable? >>>>>> What I am saying is that data model fragments like >>>>>> >>>>>> container foo { >>>>>> when "1 = 0"; >>>>>> leaf bar { >>>>>> mandatory true; >>>>>> ... >>>>>> } >>>>>> } >>>>>> >>>>>> don't have a satisfactory interpretation. >>>>> I think it is very clear. The when expression is false, which means >>>>> that container foo can never exist, and thus bar can never exist. >>>> I agree. This particular case is covered in section 8.2. >>>> >>>> Conditions on parent nodes affect constraints on child nodes as a >>>> natural consequence of the hierarchy of nodes. "must", "mandatory", >>>> "min-elements", and "max-elements" constraints are not enforced if >>>> the parent node has a "when" or "if-feature" property that is not >>>> satisfied on the current device. >>> This is all fine but the point of this issue is that "when" expression cannot be evaluated without having a context node - and the context node must be in the data tree (in the instance document, in XML terms). So it is not possible to determine whether it is satisfied or not. >>> >>>>>> It is fully defensible if a >>>>>> validation tool flags datastore content as invalid if it doesn't >>>>>> contain the "foo" container and the mandatory "bar" leaf. >>>>> No. >>>> A smart compiler would flag this as a warning, since the module defines >>>> a data node subtree that is not instantiable. It could also prune this >>>> branch so it is never part of the schema tree and thus never a problem >>>> when validating content. >>> I wonder what a smart compiler would do with the example I just sent in my response to Martin. >> The optimization I hinted at would only work for your previous example (literals or if the compiler realizes that the equality expression is comparing the exact same node sets or anything else that does not require runtime expression evaluation). It's not applicable to your other example, since that requires "full" expression evaluation, and therefore an instance document. > The instance document is such that neither “dhcp” nor “bootp” container is present. I understand that. What I was talking about was a compile time optimization of the resulting schema tree. Your other example would not be a candidate for this optimization. Jernej > > Lada > >> Jernej >> >>> Lada >>> >>>> Jernej >>>> >>>>> /martin >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Wed Mar 26 06:57:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8C91A030D for ; Wed, 26 Mar 2014 06:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vINH-U8sT9cV for ; Wed, 26 Mar 2014 06:57:39 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4011A1A00FB for ; Wed, 26 Mar 2014 06:57:39 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 443D837C320; Wed, 26 Mar 2014 14:57:37 +0100 (CET) Date: Wed, 26 Mar 2014 14:57:37 +0100 (CET) Message-Id: <20140326.145737.580242632261637255.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20140326.143440.588668936751872922.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OZzxGgQHMfOGL9FLPxzBPjDGe74 Cc: netmod@ietf.org Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 13:57:41 -0000 Ladislav Lhotka wrote: > Martin Bjorklund writes: > > > Hi, > > > > Here's yet another attempt to handle attributes in JSON, without > > changing the encoding for the case that there are no attributes > > present. > > > > In all examples, the attributes "inactive" and "etag" are present. > > > > Attributes are encoded differently depending on the type of object: > > > > > > leaf > > ---- > > > > Encode the attributes as a sibling to the leaf. > > > > > > leaf foo { > > type string; > > } > > > > "foo": "some value"; > > "@foo": { > > "inactive": true, > > "etag": "..."; > > } > > > > > > list instance > > ------------- > > > > Encode the attributes within the list instance. > > > > > > list bar { > > key name; > > leaf name { > > type string; > > } > > ... > > } > > > > "bar": [ > > { > > "@bar": { > > "inactive": true, > > "etag": "..." > > } > > "name": "instance name"; > > }] > > > > This could be ambiguous: > > list bar { > key name; > leaf name { ... } > leaf bar { ... } > } > > Then you don't know whether the attributes belong to the list entry > or to the contained leaf. Right. Then we use "@@bar" for the list / container attributes. /martin > > Lada > > > > > container > > --------- > > > > Encode the attributes within the container. > > > > > > container baz; > > > > "baz": { > > "@baz": { > > "inactive": true, > > "etag": "..." > > } > > } > > > > > > leaf-list > > --------- > > > > Encode the attributes as a sibling to the leaf-list, with an array of > > same length as the leaf-list itself. > > > > > > leaf-list buzz { > > type string; > > } > > > > "buzz": [ "val1", "val2", "val3" ], > > "@buzz: [ null, > > { "inactive": true, > > "etag": "..." > > } > > null] > > > > > > > > /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > From nobody Wed Mar 26 07:06:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FCD1A00F9 for ; Wed, 26 Mar 2014 07:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 437p5oALjXKe for ; Wed, 26 Mar 2014 07:06:21 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6851A00E3 for ; Wed, 26 Mar 2014 07:06:20 -0700 (PDT) Received: from ladislavs-air-2.lan (ip-94-113-93-24.net.upcbroadband.cz [94.113.93.24]) by mail.nic.cz (Postfix) with ESMTPSA id 1964F140259; Wed, 26 Mar 2014 15:06:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395842761; bh=6nNHMb5RIM8md5eaAJTcXn1tiO+q42nYPTrw8MZ+K7E=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nsjJ6NjQJiXhWGeOjAFQNuPML//lJj/cDHSSQi0Bfy0BVu+YM3Nb3O39ZMSU6jjbc zuz1tEtFd8/LA0O6pcJkuykCZJ+jzxti7JZU1d4cQM01U6LCDtbqxMzA3E/cjNhp1G WoFaceBn+JSMwf63UiHalmry/JfHdUnRS6YvRCqE= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 26 Mar 2014 15:05:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5CAA392C-3951-4AA4-AE57-BFC26FE4A3FD@nic.cz> References: <20140324.111757.1429730801819634445.mbj@tail-f.com> <6497C153-01EF-4266-B944-40FACD7052E8@nic.cz> <39BF58F5-2078-42FA-86D5-DD46960E5FC3@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1bwJJW4gyQvRGx9bJZUDyJx2f5k Cc: "netmod@ietf.org" Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 14:06:23 -0000 On 26 Mar 2014, at 14:53, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, Mar 26, 2014 at 6:40 AM, Ladislav Lhotka = wrote: > Andy Bierman writes: >=20 > > On Tue, Mar 25, 2014 at 2:40 PM, Ladislav Lhotka = wrote: > > > >> Andy Bierman writes: > >> > >> >> > >> >> > >> > I do not see the error. Are you saying all the when-stmts that = are in > >> YANG > >> > 1.0 > >> > modules now are broken? Are you saying they are unimplementable? > >> > >> What I am saying is that data model fragments like > >> > >> container foo { > >> when "1 =3D 0"; > >> leaf bar { > >> mandatory true; > >> ... > >> } > >> } > >> > >> don't have a satisfactory interpretation. It is fully defensible if = a > >> validation tool flags datastore content as invalid if it doesn't = contain > >> the "foo" container and the mandatory "bar" leaf. > >> > >> > > > > Like I said, the pathological cases are operationally useless. > > Nobody would ever write "when 1 =3D 0". We should avoid adding >=20 > The XPath expression doesn't matter, the problem is the same whatever = the expression is. >=20 > > CLRs to YANG that are intended from preventing people from doing = things > > they would not even try to do. It is just busy work for compiler = writers. > > > > > > > > > >> > > >> > YANG 1.0 when-stmts need to be unchanged in YANG 1.1. > >> > The issue of evaluating a when-expr as if there was a context > >> > node inserted is a completely different issue than the order that > >> > multiple when-stmts are evaluated. Changing the context node > >> > to the parent does not alter the evaluation order problem. > >> > >> That's true, but it does make a difference whether you insert all = the > >> temporary context nodes at once or one by one. > >> > >> > > To be honest -- it doesn't. Setting all the context nodes to random = values >=20 > It doesn't? So how do you proceed with inserting these dummy nodes in = my recent dhcp/bootp example? >=20 >=20 > I would not allow that module to be published. > It would have to be rewritten so there was no dependency loop. Each container can be in a separate module maintained by a different = party. Also, this is a very simple example - the dependency loop may be = buried somewhere deep and span multiple hops. Alternatively, it can be intentionally crafted by an attacker.=20 IMO it is up to YANG spec to make sure this is not allowed, and = compilers should do their best to eliminate it. Lada >=20 > =20 > > is just as arbitrarily incorrect as leaving them all out. Truth is, = if > > there are > > dependency arcs then they have to be resolved in the correct order. > > > > Our client code does not do that (yet). If you are trying to test > > when-stmts on > > the client side in order to prevent showing the user = false-when-nodes, > > then it might be either order-dependent or impossible. Unlike AJAX = menus > > where the conditional arcs are usually downward, the XPath arcs can = go > > anywhere. > > > > Unlike "import" resolution, resolving arbitrary XPath could be = impossible. > > Any XPath expert could construct pathological expressions like = "not(.)" > > where the outcome makes YANG validation implementation-dependent or > > impossible. > > > > > >> > >> > The rules for what nodes can be accessed (directly or indirectly > >> > via XPath mechanisms) cannot be changed because that would break > >> > YANG 1.0 when statements. > >> > > >> > >> If you develop YANG modules for your customers, you can certainly = make > >> sure that everything works as expected because you are aware of the = dark > >> corners. > >> > >> But if the plan is to offer YANG for general use, then the spec IMO = must > >> be rock solid. The idea that I can write a valid YANG module that = will most > >> likely blow up almost any tool around makes me nervous. > >> > >> > > > > We can do something like mandatory top-level node -- write = guidelines. > > They are allowed in YANG but not in IETF modules. > > The statement "while (1);" is allowed is C but it usually > > is not a good thing to do. >=20 > YANG is not a programming language. If you have a valid XSD schema and = an XML instance document, you probably don't expect an XSD validator to = dump core. >=20 > Lada >=20 > > > > > > Lada > >> > >> > > > > Andy > > > > > > > >> > > >> > > >> > > >> >> Lada > >> >> > >> >> > >> > > >> > Andy > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 26 07:09:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD531A0306 for ; Wed, 26 Mar 2014 07:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnqwKwHKJlFw for ; Wed, 26 Mar 2014 07:09:38 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 0806D1A00E3 for ; Wed, 26 Mar 2014 07:09:38 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 0AB8337C320; Wed, 26 Mar 2014 15:09:36 +0100 (CET) Date: Wed, 26 Mar 2014 15:09:35 +0100 (CET) Message-Id: <20140326.150935.1428873551094973632.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <5CAA392C-3951-4AA4-AE57-BFC26FE4A3FD@nic.cz> References: <5CAA392C-3951-4AA4-AE57-BFC26FE4A3FD@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Mv85F_rXtPMLjMbwdmQmCPeXGC8 Cc: netmod@ietf.org Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 14:09:41 -0000 Ladislav Lhotka wrote: > > On 26 Mar 2014, at 14:53, Andy Bierman wrote: > > > > > > > > > On Wed, Mar 26, 2014 at 6:40 AM, Ladislav Lhotka > > wrote: > > Andy Bierman writes: > > > > > On Tue, Mar 25, 2014 at 2:40 PM, Ladislav Lhotka > > > wrote: > > > > > >> Andy Bierman writes: > > >> > > >> >> > > >> >> > > >> > I do not see the error. Are you saying all the when-stmts that are in > > >> YANG > > >> > 1.0 > > >> > modules now are broken? Are you saying they are unimplementable? > > >> > > >> What I am saying is that data model fragments like > > >> > > >> container foo { > > >> when "1 = 0"; > > >> leaf bar { > > >> mandatory true; > > >> ... > > >> } > > >> } > > >> > > >> don't have a satisfactory interpretation. It is fully defensible if a > > >> validation tool flags datastore content as invalid if it doesn't > > >> contain > > >> the "foo" container and the mandatory "bar" leaf. > > >> > > >> > > > > > > Like I said, the pathological cases are operationally useless. > > > Nobody would ever write "when 1 = 0". We should avoid adding > > > > The XPath expression doesn't matter, the problem is the same whatever > > the expression is. > > > > > CLRs to YANG that are intended from preventing people from doing > > > things > > > they would not even try to do. It is just busy work for compiler > > > writers. > > > > > > > > > > > > > > >> > > > >> > YANG 1.0 when-stmts need to be unchanged in YANG 1.1. > > >> > The issue of evaluating a when-expr as if there was a context > > >> > node inserted is a completely different issue than the order that > > >> > multiple when-stmts are evaluated. Changing the context node > > >> > to the parent does not alter the evaluation order problem. > > >> > > >> That's true, but it does make a difference whether you insert all the > > >> temporary context nodes at once or one by one. > > >> > > >> > > > To be honest -- it doesn't. Setting all the context nodes to random > > > values > > > > It doesn't? So how do you proceed with inserting these dummy nodes in > > my recent dhcp/bootp example? > > > > > > I would not allow that module to be published. > > It would have to be rewritten so there was no dependency loop. > > Each container can be in a separate module maintained by a different > party. If I understand your concern this isn't possible, since you can't refer to nodes from other module w/o importing the other module, and cirular imports are not allowed. > Alternatively, it can be intentionally crafted by an attacker. ? > IMO it is up to YANG spec to make sure this is not allowed, and > compilers should do their best to eliminate it. How can we state that there MUST NOT be any ciruclar references in when expressions? /martin From nobody Wed Mar 26 07:10:21 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E501A00FB for ; Wed, 26 Mar 2014 07:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XlEX5JJSQJ5 for ; Wed, 26 Mar 2014 07:10:12 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 466B91A0119 for ; Wed, 26 Mar 2014 07:10:12 -0700 (PDT) Received: from ladislavs-air-2.lan (ip-94-113-93-24.net.upcbroadband.cz [94.113.93.24]) by mail.nic.cz (Postfix) with ESMTPSA id 4825213F6A4; Wed, 26 Mar 2014 15:10:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395843010; bh=VzKdeG8u729LhWGR48c9SBgYnGbnC0cmkxqn5aFW/KU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=vbBBOg3U0XLYcGkfC979MIv50HFNIFg9sQYZAYnPrnTwAKBnQjvZp3MNQBH+1bDmH D/FwWLvF2P1AaifhcsdPqBNoIWr3F6LvhcWOImvs1SIB/NpCxeamsurt7cMP7LTZVX hXqfjXG40hES5lGIwWqcpxjxmZHtG6RbOUg2lviQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140326.145737.580242632261637255.mbj@tail-f.com> Date: Wed, 26 Mar 2014 15:10:09 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <20140326.143440.588668936751872922.mbj@tail-f.com> <20140326.145737.580242632261637255.mbj@tail-f.com> To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/DuNWkQpCG2FE1V0-mrdbfXm-pWI Cc: netmod@ietf.org Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 14:10:13 -0000 On 26 Mar 2014, at 14:57, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Martin Bjorklund writes: >> >>> Hi, >>> >>> Here's yet another attempt to handle attributes in JSON, without >>> changing the encoding for the case that there are no attributes >>> present. >>> >>> In all examples, the attributes "inactive" and "etag" are present. >>> >>> Attributes are encoded differently depending on the type of object: >>> >>> >>> leaf >>> ---- >>> >>> Encode the attributes as a sibling to the leaf. >>> >>> >>> leaf foo { >>> type string; >>> } >>> >>> "foo": "some value"; >>> "@foo": { >>> "inactive": true, >>> "etag": "..."; >>> } >>> >>> >>> list instance >>> ------------- >>> >>> Encode the attributes within the list instance. >>> >>> >>> list bar { >>> key name; >>> leaf name { >>> type string; >>> } >>> ... >>> } >>> >>> "bar": [ >>> { >>> "@bar": { >>> "inactive": true, >>> "etag": "..." >>> } >>> "name": "instance name"; >>> }] >>> >> >> This could be ambiguous: >> >> list bar { >> key name; >> leaf name { ... } >> leaf bar { ... } >> } >> >> Then you don't know whether the attributes belong to the list entry >> or to the contained leaf. > > Right. Then we use "@@bar" for the list / container attributes. OK, then this scheme is fine with me. Lada > > > /martin > > > >> >> Lada >> >>> >>> container >>> --------- >>> >>> Encode the attributes within the container. >>> >>> >>> container baz; >>> >>> "baz": { >>> "@baz": { >>> "inactive": true, >>> "etag": "..." >>> } >>> } >>> >>> >>> leaf-list >>> --------- >>> >>> Encode the attributes as a sibling to the leaf-list, with an array of >>> same length as the leaf-list itself. >>> >>> >>> leaf-list buzz { >>> type string; >>> } >>> >>> "buzz": [ "val1", "val2", "val3" ], >>> "@buzz: [ null, >>> { "inactive": true, >>> "etag": "..." >>> } >>> null] >>> >>> >>> >>> /martin >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 26 07:16:57 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811BE1A0142 for ; Wed, 26 Mar 2014 07:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNALwUJN9b3o for ; Wed, 26 Mar 2014 07:16:53 -0700 (PDT) Received: from exprod5og118.obsmtp.com (exprod5og118.obsmtp.com [64.18.0.160]) by ietfa.amsl.com (Postfix) with ESMTP id EA8D71A033F for ; Wed, 26 Mar 2014 07:16:48 -0700 (PDT) Received: from alpmlip11.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob118.postini.com ([64.18.4.12]) with SMTP ID DSNKUzLhTx9XHkjc7xXG2GHZ2ocXEU+PzsZi@postini.com; Wed, 26 Mar 2014 07:16:47 PDT Received: from unknown (HELO CINMBHT04.e2k.ad.ge.com) ([3.159.212.197]) by alpmlip11.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 26 Mar 2014 10:12:51 -0400 Received: from CINURAPD08.e2k.ad.ge.com (3.159.212.120) by CINMBHT04.e2k.ad.ge.com (3.159.212.197) with Microsoft SMTP Server (TLS) id 14.3.174.2; Wed, 26 Mar 2014 10:16:45 -0400 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.29]) by CINURAPD08.e2k.ad.ge.com ([169.254.10.32]) with mapi id 14.03.0174.002; Wed, 26 Mar 2014 10:16:45 -0400 From: "Lange, Jeffrey K (GE Energy Management)" To: "netmod@ietf.org" Thread-Topic: Default presence containers Thread-Index: AQHPSP4E5KaMJCtobEOAwOdoa7NJwA== Date: Wed, 26 Mar 2014 14:16:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [3.159.212.181] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/MXHU9B71Gj0L46r7JkKQfsHRmaA Subject: [netmod] Default presence containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 14:16:54 -0000 Is there any way in YANG that one can create a presence container with a default state? 6020 does not list =B3default=B2 as a sub statement to container. If not, perhaps this is a useful feature for YANG 1.1 e.g. (from 6020): container system { description "Contains various system parameters"; container services { description "Configure externally available services"; container "ssh" { presence "Enables SSH"; description "SSH service specific configuration=B2; default present; // or not-present } } } Thanks! -Jeff =20 From nobody Wed Mar 26 07:17:18 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED76C1A033D for ; Wed, 26 Mar 2014 07:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbVQjjnceEKt for ; Wed, 26 Mar 2014 07:17:11 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6BE1A034E for ; Wed, 26 Mar 2014 07:17:11 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id 63so913025qgz.34 for ; Wed, 26 Mar 2014 07:17:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cUrhJGYq8JLEGGQ+GcsxuZi/2ghejb0SDEXDqgHIvHk=; b=CYVjvm9ysyqS6WfyfmXHd6muz8dogUSoWZoUS2KwkhOUN1eAxvZruy2oSyRfh9daVD OSwhGC6SdhGf40CgoVzt2Q9IMDBZlushxa0oT63y+5x3b4PZoNM9imaMnhPVAMgl7I5T FFa09B79E5IkuMIW3MNLQknZSuNfkUs2HsnuA9oXVOBSBKr2hskkxdkIIhpveTTaY9yd O6jAxbDPMc4ytU6oJJL7vLmMLt8WxE/Cf4WetL3cBTd4hizrLUySgMJn7mMjWMaNdMsG iYjEiAE86FdNfCzvR94MipHRpjuu3ry3S+y+2AFpwGQyIFMa+wKXj8uHTUQ4dBbPWWbH zOCQ== X-Gm-Message-State: ALoCoQnbDhhBVih27ubiJSnoXbKGHBLxi8XNO54MzyRXZmmqOhy1uy7Jw9/T2iAWnpsSirMj+mjB MIME-Version: 1.0 X-Received: by 10.224.79.200 with SMTP id q8mr89006222qak.7.1395843429752; Wed, 26 Mar 2014 07:17:09 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Wed, 26 Mar 2014 07:17:09 -0700 (PDT) In-Reply-To: <20140326.150935.1428873551094973632.mbj@tail-f.com> References: <5CAA392C-3951-4AA4-AE57-BFC26FE4A3FD@nic.cz> <20140326.150935.1428873551094973632.mbj@tail-f.com> Date: Wed, 26 Mar 2014 07:17:09 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7bdca59ecd2aee04f5831fc1 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/b2EGYH7Qk6v71E9UFvQqmVdc4yw Cc: "netmod@ietf.org" Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 14:17:14 -0000 --047d7bdca59ecd2aee04f5831fc1 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 26, 2014 at 7:09 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > > > On 26 Mar 2014, at 14:53, Andy Bierman wrote: > > > > > > > > > > > > > > On Wed, Mar 26, 2014 at 6:40 AM, Ladislav Lhotka > > > wrote: > > > Andy Bierman writes: > > > > > > > On Tue, Mar 25, 2014 at 2:40 PM, Ladislav Lhotka > > > > wrote: > > > > > > > >> Andy Bierman writes: > > > >> > > > >> >> > > > >> >> > > > >> > I do not see the error. Are you saying all the when-stmts that > are in > > > >> YANG > > > >> > 1.0 > > > >> > modules now are broken? Are you saying they are unimplementable? > > > >> > > > >> What I am saying is that data model fragments like > > > >> > > > >> container foo { > > > >> when "1 = 0"; > > > >> leaf bar { > > > >> mandatory true; > > > >> ... > > > >> } > > > >> } > > > >> > > > >> don't have a satisfactory interpretation. It is fully defensible if > a > > > >> validation tool flags datastore content as invalid if it doesn't > > > >> contain > > > >> the "foo" container and the mandatory "bar" leaf. > > > >> > > > >> > > > > > > > > Like I said, the pathological cases are operationally useless. > > > > Nobody would ever write "when 1 = 0". We should avoid adding > > > > > > The XPath expression doesn't matter, the problem is the same whatever > > > the expression is. > > > > > > > CLRs to YANG that are intended from preventing people from doing > > > > things > > > > they would not even try to do. It is just busy work for compiler > > > > writers. > > > > > > > > > > > > > > > > > > > >> > > > > >> > YANG 1.0 when-stmts need to be unchanged in YANG 1.1. > > > >> > The issue of evaluating a when-expr as if there was a context > > > >> > node inserted is a completely different issue than the order that > > > >> > multiple when-stmts are evaluated. Changing the context node > > > >> > to the parent does not alter the evaluation order problem. > > > >> > > > >> That's true, but it does make a difference whether you insert all > the > > > >> temporary context nodes at once or one by one. > > > >> > > > >> > > > > To be honest -- it doesn't. Setting all the context nodes to random > > > > values > > > > > > It doesn't? So how do you proceed with inserting these dummy nodes in > > > my recent dhcp/bootp example? > > > > > > > > > I would not allow that module to be published. > > > It would have to be rewritten so there was no dependency loop. > > > > Each container can be in a separate module maintained by a different > > party. > > If I understand your concern this isn't possible, since you can't > refer to nodes from other module w/o importing the other module, and > cirular imports are not allowed. > > > Alternatively, it can be intentionally crafted by an attacker. > > ? > > > IMO it is up to YANG spec to make sure this is not allowed, and > > compilers should do their best to eliminate it. > > How can we state that there MUST NOT be any ciruclar references in > when expressions? > > This is way too difficult for a compiler to detect. It takes somebody (like a YANG doctor) to spot the issue and say "change this to a choice-stmt, or use must-stmt instead". We say say in the draft what bad things can happen if there are circular references. > /martin > Andy --047d7bdca59ecd2aee04f5831fc1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Mar 26, 2014 at 7:09 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On 26 Mar 2014, at 14:53, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Wed, Mar 26, 2014 at 6:40 AM, Ladislav Lhotka <lhotka@nic.cz>
> > wrote:
> > Andy Bierman <andy@yumaw= orks.com> writes:
> >
> > > On Tue, Mar 25, 2014 at 2:40 PM, Ladislav Lhotka <lhotka@nic.cz>
> > > wrote:
> > >
> > >> Andy Bierman <a= ndy@yumaworks.com> writes:
> > >>
> > >> >>
> > >> >>
> > >> > I do not see the error. =A0Are you saying all the w= hen-stmts that are in
> > >> YANG
> > >> > 1.0
> > >> > modules now are broken? Are you saying they are uni= mplementable?
> > >>
> > >> What I am saying is that data model fragments like
> > >>
> > >> container foo {
> > >> =A0 =A0 when "1 =3D 0";
> > >> =A0 =A0 leaf bar {
> > >> =A0 =A0 =A0 =A0 mandatory true;
> > >> =A0 =A0 =A0 =A0 ...
> > >> =A0 =A0 }
> > >> }
> > >>
> > >> don't have a satisfactory interpretation. It is full= y defensible if a
> > >> validation tool flags datastore content as invalid if it= doesn't
> > >> contain
> > >> the "foo" container and the mandatory "ba= r" leaf.
> > >>
> > >>
> > >
> > > Like I said, the pathological cases are operationally useles= s.
> > > Nobody would ever write "when 1 =3D 0". We should = avoid adding
> >
> > The XPath expression doesn't matter, the problem is the same = whatever
> > the expression is.
> >
> > > CLRs to YANG that are intended from preventing people from d= oing
> > > things
> > > they would not even try to do. =A0It is just busy work for c= ompiler
> > > writers.
> > >
> > >
> > >
> > >
> > >> >
> > >> > YANG 1.0 when-stmts need to be unchanged in YANG 1.= 1.
> > >> > The issue of evaluating a when-expr as if there was= a context
> > >> > node inserted is a completely different issue than = the order that
> > >> > multiple when-stmts are evaluated. =A0Changing the = context node
> > >> > to the parent does not alter the evaluation order p= roblem.
> > >>
> > >> That's true, but it does make a difference whether y= ou insert all the
> > >> temporary context nodes at once or one by one.
> > >>
> > >>
> > > To be honest -- it doesn't. =A0Setting all the context n= odes to random
> > > values
> >
> > It doesn't? So how do you proceed with inserting these dummy = nodes in
> > my recent dhcp/bootp example?
> >
> >
> > I would not allow that module to be published.
> > It would have to be rewritten so there was no dependency loop. >
> Each container can be in a separate module maintained by a different > party.

If I understand your concern this isn't possible, since you can't refer to nodes from other module w/o importing the other module, and
cirular imports are not allowed.

> Alternatively, it can be intentionally crafted by an attacker.

?

> IMO it is up to YANG spec to make sure this is not allowed, and
> compilers should do their best to eliminate it.

How can we state that there MUST NOT be any ciruclar references in
when expressions?


This is way too difficult for a compiler to detect.<= /div>
It takes somebody (like a YANG doctor) to spot the issue
and say "change this to a choice-stmt, or use must-stmt instead".=

=A0We say say in the draft what bad things can ha= ppen if there are circular references.



/martin


<= /div>
Andy

--047d7bdca59ecd2aee04f5831fc1-- From nobody Wed Mar 26 07:20:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7061A0343 for ; Wed, 26 Mar 2014 07:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axLNPP4KG6CP for ; Wed, 26 Mar 2014 07:20:01 -0700 (PDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) by ietfa.amsl.com (Postfix) with ESMTP id CF3031A033F for ; Wed, 26 Mar 2014 07:20:00 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id z60so909944qgd.36 for ; Wed, 26 Mar 2014 07:19:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pWr8um2FXtdWpn9B6hCqr2ua8IEEtoNT9BkuyRibPpc=; b=XxTvywvuf68mfxnYXMXeKBPX5Lcfkb8qR+YAwfKkOZ9EhQWa0RyW1SA7wcCkM7kWzw i+q8Glh4L9XRYgBAs+60Rt+/t3rP29XUpsuGKy9X5zonoaVGWhgbpBGItJqP3LXwv1Qw 2crfRfmBTUQeirhrXw5+s4GVXiM3zSqSdyYd7uTvHNA9i+GoY2bYt6D9kkScEX9nlxlM L2QT60PqEqCphfhzbnkKiaLRnb4XkQC94GMOzNE9gnoGXMMwkXM5PlEHM2hnVOmmH2sX KsJjD5X9e4g3muJH76MUGA4ydSx1AoUAfRJSRlfEtiRCSsoHax3kjdh7rKfCYk0kiUUq rdiQ== X-Gm-Message-State: ALoCoQkmkOKf6cI0hqM+37TYTufA/zOwi2rvlOV5XWXYbj8W7Iatq4Hz7cNYVaJvY497cJvJMXg/ MIME-Version: 1.0 X-Received: by 10.140.27.193 with SMTP id 59mr84825274qgx.18.1395843599182; Wed, 26 Mar 2014 07:19:59 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Wed, 26 Mar 2014 07:19:59 -0700 (PDT) In-Reply-To: References: <20140326.143440.588668936751872922.mbj@tail-f.com> <20140326.145737.580242632261637255.mbj@tail-f.com> Date: Wed, 26 Mar 2014 07:19:59 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c1233ae45f6504f5832995 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/32ntos1GlsJYwoV5ggEdC1m-EIY Cc: "netmod@ietf.org" Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 14:20:03 -0000 --001a11c1233ae45f6504f5832995 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 26, 2014 at 7:10 AM, Ladislav Lhotka wrote: > > On 26 Mar 2014, at 14:57, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > >> Martin Bjorklund writes: > >> > >>> Hi, > >>> > >>> Here's yet another attempt to handle attributes in JSON, without > >>> changing the encoding for the case that there are no attributes > >>> present. > >>> > >>> In all examples, the attributes "inactive" and "etag" are present. > >>> > >>> Attributes are encoded differently depending on the type of object: > >>> > >>> > >>> leaf > >>> ---- > >>> > >>> Encode the attributes as a sibling to the leaf. > >>> > >>> > >>> leaf foo { > >>> type string; > >>> } > >>> > >>> "foo": "some value"; > >>> "@foo": { > >>> "inactive": true, > >>> "etag": "..."; > >>> } > >>> > >>> > >>> list instance > >>> ------------- > >>> > >>> Encode the attributes within the list instance. > >>> > >>> > >>> list bar { > >>> key name; > >>> leaf name { > >>> type string; > >>> } > >>> ... > >>> } > >>> > >>> "bar": [ > >>> { > >>> "@bar": { > >>> "inactive": true, > >>> "etag": "..." > >>> } > >>> "name": "instance name"; > >>> }] > >>> > >> > >> This could be ambiguous: > >> > >> list bar { > >> key name; > >> leaf name { ... } > >> leaf bar { ... } > >> } > >> > >> Then you don't know whether the attributes belong to the list entry > >> or to the contained leaf. > > > > Right. Then we use "@@bar" for the list / container attributes. > > OK, then this scheme is fine with me. > > Looks more complicated than other solution proposals. Looks very cumbersome to implement, especially for leaf-lists. Maybe it will take an interim meeting to figure out how to agree on an attribute encoding for JSON. > Lada > > > > > > > /martin > > > Andy --001a11c1233ae45f6504f5832995 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Mar 26, 2014 at 7:10 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 26 Mar 2014, at 14:57, Martin Bjorklund <mbj@tail-f.com> wrote:

> Ladislav Lhotka <lhotka@nic.cz= > wrote:
>> Martin Bjorklund <mbj@tail-f.= com> writes:
>>
>>> Hi,
>>>
>>> Here's yet another attempt to handle attributes in JSON, w= ithout
>>> changing the encoding for the case that there are no attribute= s
>>> present.
>>>
>>> In all examples, the attributes "inactive" and "= ;etag" are present.
>>>
>>> Attributes are encoded differently depending on the type of ob= ject:
>>>
>>>
>>> leaf
>>> ----
>>>
>>> Encode the attributes as a sibling to the leaf.
>>>
>>>
>>> =A0leaf foo {
>>> =A0 =A0type string;
>>> =A0}
>>>
>>> =A0"foo": "some value";
>>> =A0"@foo": {
>>> =A0 =A0 "inactive": true,
>>> =A0 =A0 "etag": "...";
>>> =A0 }
>>>
>>>
>>> list instance
>>> -------------
>>>
>>> Encode the attributes within the list instance.
>>>
>>>
>>> =A0list bar {
>>> =A0 =A0key name;
>>> =A0 =A0leaf name {
>>> =A0 =A0 =A0type string;
>>> =A0 =A0}
>>> =A0 =A0...
>>> =A0}
>>>
>>> =A0"bar": [
>>> =A0 =A0 {
>>> =A0 =A0 =A0 =A0"@bar": {
>>> =A0 =A0 =A0 =A0 =A0 "inactive": true,
>>> =A0 =A0 =A0 =A0 =A0 "etag": "..."
>>> =A0 =A0 =A0 =A0 }
>>> =A0 =A0 =A0 =A0 "name": "instance name"; >>> =A0 =A0 =A0}]
>>>
>>
>> This could be ambiguous:
>>
>> list bar {
>> =A0key name;
>> =A0leaf name { ... }
>> =A0leaf bar { ... }
>> }
>>
>> Then you don't know whether the attributes belong to the list = entry
>> or to the contained leaf.
>
> Right. Then we use "@@bar" for the list / container attribut= es.

OK, then this scheme is fine with me.


Looks more complicated than other solu= tion proposals.
Looks very cumbersome to implement, especially fo= r leaf-lists.
Maybe it will take an interim meeting to figure out= how to agree
on an attribute encoding for JSON.


=
=A0
Lada

>
>
> /martin
>


Andy

=
--001a11c1233ae45f6504f5832995-- From nobody Wed Mar 26 07:27:43 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5641A00FB for ; Wed, 26 Mar 2014 07:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCDxMLGSznZ2 for ; Wed, 26 Mar 2014 07:27:39 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id A6BA21A00E3 for ; Wed, 26 Mar 2014 07:27:39 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 8309637C320; Wed, 26 Mar 2014 15:27:37 +0100 (CET) Date: Wed, 26 Mar 2014 15:27:37 +0100 (CET) Message-Id: <20140326.152737.330538996469661145.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140326.145737.580242632261637255.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kfstj9WgAawWtqRrDlEQhiqsWHY Cc: netmod@ietf.org Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 14:27:41 -0000 Andy Bierman wrote: > On Wed, Mar 26, 2014 at 7:10 AM, Ladislav Lhotka wrote: > > > > > On 26 Mar 2014, at 14:57, Martin Bjorklund wrote: > > > > > Ladislav Lhotka wrote: > > >> Martin Bjorklund writes: > > >> > > >>> Hi, > > >>> > > >>> Here's yet another attempt to handle attributes in JSON, without > > >>> changing the encoding for the case that there are no attributes > > >>> present. > > >>> > > >>> In all examples, the attributes "inactive" and "etag" are present. > > >>> > > >>> Attributes are encoded differently depending on the type of object: > > >>> > > >>> > > >>> leaf > > >>> ---- > > >>> > > >>> Encode the attributes as a sibling to the leaf. > > >>> > > >>> > > >>> leaf foo { > > >>> type string; > > >>> } > > >>> > > >>> "foo": "some value"; > > >>> "@foo": { > > >>> "inactive": true, > > >>> "etag": "..."; > > >>> } > > >>> > > >>> > > >>> list instance > > >>> ------------- > > >>> > > >>> Encode the attributes within the list instance. > > >>> > > >>> > > >>> list bar { > > >>> key name; > > >>> leaf name { > > >>> type string; > > >>> } > > >>> ... > > >>> } > > >>> > > >>> "bar": [ > > >>> { > > >>> "@bar": { > > >>> "inactive": true, > > >>> "etag": "..." > > >>> } > > >>> "name": "instance name"; > > >>> }] > > >>> > > >> > > >> This could be ambiguous: > > >> > > >> list bar { > > >> key name; > > >> leaf name { ... } > > >> leaf bar { ... } > > >> } > > >> > > >> Then you don't know whether the attributes belong to the list entry > > >> or to the contained leaf. > > > > > > Right. Then we use "@@bar" for the list / container attributes. > > > > OK, then this scheme is fine with me. > > > > > Looks more complicated than other solution proposals. Do we agree that we don't want different encodings for values if there are attributes or not? I.e., if my code works when no attributes are present, it should also work if there are attributes? If so, do we have any other proposal? I am all for a simpler solution! /martin From nobody Wed Mar 26 07:35:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E488D1A0306 for ; Wed, 26 Mar 2014 07:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnS7wJitbA47 for ; Wed, 26 Mar 2014 07:35:42 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 595AF1A0147 for ; Wed, 26 Mar 2014 07:35:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=rfg1wIcX1oHq9m3c8VjrRI003RO9XduHW93M5GeooyLmU0F7XTRZBk05E49KVym1; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.34] (helo=elwamui-hound.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WSovc-00025T-9X for netmod@ietf.org; Wed, 26 Mar 2014 10:35:40 -0400 Received: from 203.116.29.210 by webmail.earthlink.net with HTTP; Wed, 26 Mar 2014 10:35:39 -0400 Message-ID: <2107998.1395844540276.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> Date: Wed, 26 Mar 2014 22:35:39 +0800 (GMT+08:00) From: Randy Presuhn To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88891b749bef7332bbcdaac1ee7d4545dcf67b7d76d719b4c71350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.34 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/zAeb2EgXN_58r3ipUInzwW9kKh8 Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 14:35:44 -0000 Hi - >From: Andy Bierman >Sent: Mar 26, 2014 10:17 PM >To: Martin Bjorklund >Cc: "netmod@ietf.org" >Subject: Re: [netmod] Y18: fix "when" expression context node problem ... >> How can we state that there MUST NOT be any ciruclar references in >> when expressions? >> >> >This is way too difficult for a compiler to detect. >It takes somebody (like a YANG doctor) to spot the issue >and say "change this to a choice-stmt, or use must-stmt instead". I don't see why it should be substantially more difficult than, say, detecting indirect circular references in spreadsheet formulas. One would need to apply similar reasoning anyway to unravel ordering dependencies between various bits and pieces of configuration. Do you have a case in mind more pathological than that? Randy From nobody Wed Mar 26 07:44:02 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F091A0332 for ; Wed, 26 Mar 2014 07:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kD_nGjteoWh2 for ; Wed, 26 Mar 2014 07:43:56 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5821A0145 for ; Wed, 26 Mar 2014 07:43:55 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id i8so2617831qcq.23 for ; Wed, 26 Mar 2014 07:43:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+6ojo1flX7VtVsTKRzKHgVy9J2hLwlZo/NGg98HcsGw=; b=OyNxRF7TTSv8BP5aWpcFIvV9TZs+OsRRH9g2u2xWgBtmRnlF02AfpwKuWGiSVsBfIt qMEIBNffiVqgsGPHGjbw176Ey11boies5ti+ytqpZIKhd9GIaGQab36RMV17uNKKE1aQ K5lcMzECibvRWu2c8QCpu/RQV/4mLGZ+m81oJlIi/FPOJ7cU5CfYXT0t/HCGnf2SVwqj H4jsamdkkGB9Toqlw39JM+3RUKm4qdVdRPuXrAU8Lwrx9ZvBIuS2oWLYD6a7Ww/Avm6H gwHo/odHYbBIIzxLTV9Ph6irzs4cI19OMc+OThmwFeFTs8tPPW85QRDrpBcBXY4qJnEu agSw== X-Gm-Message-State: ALoCoQmSsr1dFe+JoOfzONfToWNVDAbUWk8wCfLD5jhhzsKbvuVBtXA+JmCe9n+wCstz6gP8OqX3 MIME-Version: 1.0 X-Received: by 10.229.81.71 with SMTP id w7mr90217504qck.8.1395845033890; Wed, 26 Mar 2014 07:43:53 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Wed, 26 Mar 2014 07:43:53 -0700 (PDT) In-Reply-To: <20140326.152737.330538996469661145.mbj@tail-f.com> References: <20140326.145737.580242632261637255.mbj@tail-f.com> <20140326.152737.330538996469661145.mbj@tail-f.com> Date: Wed, 26 Mar 2014 07:43:53 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a1133b2b06829ac04f5837f32 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/izyplWO-dkVZBda97Q15N56pHas Cc: "netmod@ietf.org" Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 14:44:00 -0000 --001a1133b2b06829ac04f5837f32 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 26, 2014 at 7:27 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Wed, Mar 26, 2014 at 7:10 AM, Ladislav Lhotka wrote: > > > > > > > > On 26 Mar 2014, at 14:57, Martin Bjorklund wrote: > > > > > > > Ladislav Lhotka wrote: > > > >> Martin Bjorklund writes: > > > >> > > > >>> Hi, > > > >>> > > > >>> Here's yet another attempt to handle attributes in JSON, without > > > >>> changing the encoding for the case that there are no attributes > > > >>> present. > > > >>> > > > >>> In all examples, the attributes "inactive" and "etag" are present. > > > >>> > > > >>> Attributes are encoded differently depending on the type of object: > > > >>> > > > >>> > > > >>> leaf > > > >>> ---- > > > >>> > > > >>> Encode the attributes as a sibling to the leaf. > > > >>> > > > >>> > > > >>> leaf foo { > > > >>> type string; > > > >>> } > > > >>> > > > >>> "foo": "some value"; > > > >>> "@foo": { > > > >>> "inactive": true, > > > >>> "etag": "..."; > > > >>> } > > > >>> > > > >>> > > > >>> list instance > > > >>> ------------- > > > >>> > > > >>> Encode the attributes within the list instance. > > > >>> > > > >>> > > > >>> list bar { > > > >>> key name; > > > >>> leaf name { > > > >>> type string; > > > >>> } > > > >>> ... > > > >>> } > > > >>> > > > >>> "bar": [ > > > >>> { > > > >>> "@bar": { > > > >>> "inactive": true, > > > >>> "etag": "..." > > > >>> } > > > >>> "name": "instance name"; > > > >>> }] > > > >>> > > > >> > > > >> This could be ambiguous: > > > >> > > > >> list bar { > > > >> key name; > > > >> leaf name { ... } > > > >> leaf bar { ... } > > > >> } > > > >> > > > >> Then you don't know whether the attributes belong to the list entry > > > >> or to the contained leaf. > > > > > > > > Right. Then we use "@@bar" for the list / container attributes. > > > > > > OK, then this scheme is fine with me. > > > > > > > > Looks more complicated than other solution proposals. > > Do we agree that we don't want different encodings for values if there > are attributes or not? I.e., if my code works when no attributes are > present, it should also work if there are attributes? > > Not if the normal encoding is painful to use. The use attributes is going to be rare. I want the expected "plain" encoding when there are no attributes. Code that generates JSON and does not care about attributes must not be rendered useless because the JSON is specially encoded in RESTCONF. We want to leverage wide knowledge of JSON, not invent our own incompatible version of it. > If so, do we have any other proposal? > > I am all for a simpler solution! > > Putting attributes at the sibling level does not work for leaf-lists. Even for leafs, it is difficult to parse. JSON objects are unordered, so the "@foo" could appear anywhere, even before "foo". The schemes I proposed always keeps the attributes within the node for the attributes (just like XML). One idea I had was to simply disallow attributes for leaf and leaf-list. They can only go in container or list nodes. This is restrictive but then there will not be any dual decoding possibilities. > /martin > Andy --001a1133b2b06829ac04f5837f32 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Mar 26, 2014 at 7:27 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Wed, Mar 26, 2014 at 7:10 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> >
> > On 26 Mar 2014, at 14:57, Martin Bjorklund <mbj@tail-f.com> wrote:
> >
> > > Ladislav Lhotka <lhotka@= nic.cz> wrote:
> > >> Martin Bjorklund <m= bj@tail-f.com> writes:
> > >>
> > >>> Hi,
> > >>>
> > >>> Here's yet another attempt to handle attributes = in JSON, without
> > >>> changing the encoding for the case that there are no= attributes
> > >>> present.
> > >>>
> > >>> In all examples, the attributes "inactive"= and "etag" are present.
> > >>>
> > >>> Attributes are encoded differently depending on the = type of object:
> > >>>
> > >>>
> > >>> leaf
> > >>> ----
> > >>>
> > >>> Encode the attributes as a sibling to the leaf.
> > >>>
> > >>>
> > >>> =A0leaf foo {
> > >>> =A0 =A0type string;
> > >>> =A0}
> > >>>
> > >>> =A0"foo": "some value";
> > >>> =A0"@foo": {
> > >>> =A0 =A0 "inactive": true,
> > >>> =A0 =A0 "etag": "...";
> > >>> =A0 }
> > >>>
> > >>>
> > >>> list instance
> > >>> -------------
> > >>>
> > >>> Encode the attributes within the list instance.
> > >>>
> > >>>
> > >>> =A0list bar {
> > >>> =A0 =A0key name;
> > >>> =A0 =A0leaf name {
> > >>> =A0 =A0 =A0type string;
> > >>> =A0 =A0}
> > >>> =A0 =A0...
> > >>> =A0}
> > >>>
> > >>> =A0"bar": [
> > >>> =A0 =A0 {
> > >>> =A0 =A0 =A0 =A0"@bar": {
> > >>> =A0 =A0 =A0 =A0 =A0 "inactive": true,
> > >>> =A0 =A0 =A0 =A0 =A0 "etag": "..."= ;
> > >>> =A0 =A0 =A0 =A0 }
> > >>> =A0 =A0 =A0 =A0 "name": "instance nam= e";
> > >>> =A0 =A0 =A0}]
> > >>>
> > >>
> > >> This could be ambiguous:
> > >>
> > >> list bar {
> > >> =A0key name;
> > >> =A0leaf name { ... }
> > >> =A0leaf bar { ... }
> > >> }
> > >>
> > >> Then you don't know whether the attributes belong to= the list entry
> > >> or to the contained leaf.
> > >
> > > Right. Then we use "@@bar" for the list / containe= r attributes.
> >
> > OK, then this scheme is fine with me.
> >
> >
> Looks more complicated than other solution proposals.

Do we agree that we don't want different encodings for values if there<= br> are attributes or not? =A0I.e., if my code works when no attributes are
present, it should also work if there are attributes?


Not if the normal encoding is painful = to use.
The use attributes is going to be rare.
I want = the expected "plain" encoding when there are no attributes.
Code that generates JSON and does not care about attributes
= must not be rendered useless because the JSON is specially encoded
in RESTCONF. =A0We want to leverage wide knowledge of JSON,
not= invent our own incompatible version of it.

=A0
If so, do we have any other proposal?

I am all for a simpler solution!



Putting attributes at the sibling lev= el does not work for leaf-lists.
Even for leafs, it is difficult = to parse. =A0JSON objects are unordered,
so the "@foo" could appear anywhere, even before "foo&q= uot;. =A0The schemes
I proposed always keeps the attributes withi= n the node for the attributes
(just like XML).

One idea I had was to simply disallow attributes for leaf and leaf-lis= t.
They can only go in container or list nodes. =A0This is restri= ctive but then there
will not be any dual decoding possibilities.=



/martin

Andy<= /div>

--001a1133b2b06829ac04f5837f32-- From nobody Wed Mar 26 07:48:28 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC121A0346 for ; Wed, 26 Mar 2014 07:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByQZRyTu8UnX for ; Wed, 26 Mar 2014 07:48:22 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 115A31A033D for ; Wed, 26 Mar 2014 07:48:21 -0700 (PDT) Received: from ladislavs-air-2.lan (ip-94-113-93-24.net.upcbroadband.cz [94.113.93.24]) by mail.nic.cz (Postfix) with ESMTPSA id E669213F686; Wed, 26 Mar 2014 15:48:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395845293; bh=jrtt1EBykrTmojAa56h/cPnP8fNhTfkaQANP7UqegK8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=HPfT7asw1Y5r2EztgNUoX5Bw4lEWyXgdz0SrGwC7clhrRhVkuV9xg6PDyQB0Dfyv1 v5ttu9YHKVsvDW1eSxj0PYSeuvA2GS/RXdTevp372ToafjgXYteBwKo/nSGKU4y20u vKSdENBGRIr3W4zx4AxXLanafnHlDS2oPshEdPf4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140326.150935.1428873551094973632.mbj@tail-f.com> Date: Wed, 26 Mar 2014 15:48:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <36E4F7A8-8A0E-4666-B469-6934E6F7802C@nic.cz> References: <5CAA392C-3951-4AA4-AE57-BFC26FE4A3FD@nic.cz> <20140326.150935.1428873551094973632.mbj@tail-f.com> To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/FlN8OxnNWsgNnRwu39l2l58iWuo Cc: netmod@ietf.org Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 14:48:24 -0000 On 26 Mar 2014, at 15:09, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On 26 Mar 2014, at 14:53, Andy Bierman wrote: >>=20 >>>=20 >>>=20 >>>=20 >>> On Wed, Mar 26, 2014 at 6:40 AM, Ladislav Lhotka >>> wrote: >>> Andy Bierman writes: >>>=20 >>>> On Tue, Mar 25, 2014 at 2:40 PM, Ladislav Lhotka >>>> wrote: >>>>=20 >>>>> Andy Bierman writes: >>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>> I do not see the error. Are you saying all the when-stmts that = are in >>>>> YANG >>>>>> 1.0 >>>>>> modules now are broken? Are you saying they are unimplementable? >>>>>=20 >>>>> What I am saying is that data model fragments like >>>>>=20 >>>>> container foo { >>>>> when "1 =3D 0"; >>>>> leaf bar { >>>>> mandatory true; >>>>> ... >>>>> } >>>>> } >>>>>=20 >>>>> don't have a satisfactory interpretation. It is fully defensible = if a >>>>> validation tool flags datastore content as invalid if it doesn't >>>>> contain >>>>> the "foo" container and the mandatory "bar" leaf. >>>>>=20 >>>>>=20 >>>>=20 >>>> Like I said, the pathological cases are operationally useless. >>>> Nobody would ever write "when 1 =3D 0". We should avoid adding >>>=20 >>> The XPath expression doesn't matter, the problem is the same = whatever >>> the expression is. >>>=20 >>>> CLRs to YANG that are intended from preventing people from doing >>>> things >>>> they would not even try to do. It is just busy work for compiler >>>> writers. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>>=20 >>>>>> YANG 1.0 when-stmts need to be unchanged in YANG 1.1. >>>>>> The issue of evaluating a when-expr as if there was a context >>>>>> node inserted is a completely different issue than the order that >>>>>> multiple when-stmts are evaluated. Changing the context node >>>>>> to the parent does not alter the evaluation order problem. >>>>>=20 >>>>> That's true, but it does make a difference whether you insert all = the >>>>> temporary context nodes at once or one by one. >>>>>=20 >>>>>=20 >>>> To be honest -- it doesn't. Setting all the context nodes to = random >>>> values >>>=20 >>> It doesn't? So how do you proceed with inserting these dummy nodes = in >>> my recent dhcp/bootp example? >>>=20 >>>=20 >>> I would not allow that module to be published. >>> It would have to be rewritten so there was no dependency loop. >>=20 >> Each container can be in a separate module maintained by a different >> party. >=20 > If I understand your concern this isn't possible, since you can't > refer to nodes from other module w/o importing the other module, and > cirular imports are not allowed. Yes, you are right, it is not possible in this form (but see below). >=20 >> Alternatively, it can be intentionally crafted by an attacker.=20 >=20 > ? Somebody can write a module that looks innocent and compiles properly = but creates this when loop under some circumstances. >=20 >> IMO it is up to YANG spec to make sure this is not allowed, and >> compilers should do their best to eliminate it. >=20 > How can we state that there MUST NOT be any ciruclar references in > when expressions? I proposed a formulation earlier:=20 "The XPath expression must not involve any node that is directly or = indirectly conditional." Checking it can be tricky, because the XPath expression may contain = things like count(../*) whose result depends on the presence or absence = of the context node. I think XPath is too powerful for this purpose. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 26 07:48:30 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1C91A033D for ; Wed, 26 Mar 2014 07:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpneXuEaKhtT for ; Wed, 26 Mar 2014 07:48:24 -0700 (PDT) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) by ietfa.amsl.com (Postfix) with ESMTP id CE8AC1A0345 for ; Wed, 26 Mar 2014 07:48:23 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id q107so995894qgd.1 for ; Wed, 26 Mar 2014 07:48:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eqaTGcoyLHyDIA5myxnwH3+MxakH/s++morLuJFnls8=; b=S5kH2vTf6pZ+QJQkAjQMnZQwl+XBwWo9CcF7xHKCYCRcdR1EsqkpGMNJrwDJLr2xtO 9JswN4QT622o4UoQ8OgAQIbvnH9GVwDHUuQFTCwyKYjxMq0lu9vDztOIGsd8wo+8l3/I fAqkM7FgVtBn6nRi+cfzJZD6JoV2m2x/+OQSxWljN4ymIca6Ls4VerpwEPXD1W/ZBWuE 8fZnLzYjYGxNAwUscm+xm018GfPU2WQm0oVEgU8g0C+xPtNAYXFtnUoplM0UcZgCZMpD RfrI2wK2WwHI1C9GjO/+wIzEoyKMmNP7prTs+dccTjlvShd+tD5aPC/s//dBvMYm2iY0 xsaQ== X-Gm-Message-State: ALoCoQlAAIfjdRzESoWvOO9guJVqn5HD9GS15E9PrHv6fAkaS3fnCYsEV3NsyqIivhVBomgDdi1V MIME-Version: 1.0 X-Received: by 10.224.125.194 with SMTP id z2mr2756843qar.99.1395845302159; Wed, 26 Mar 2014 07:48:22 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Wed, 26 Mar 2014 07:48:22 -0700 (PDT) In-Reply-To: <2107998.1395844540276.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> References: <2107998.1395844540276.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> Date: Wed, 26 Mar 2014 07:48:22 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: multipart/alternative; boundary=001a11c2068865b98304f5838fa0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OloBIxFQm12ONnc0dJb8b9akm-0 Cc: "netmod@ietf.org" Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 14:48:25 -0000 --001a11c2068865b98304f5838fa0 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 26, 2014 at 7:35 AM, Randy Presuhn wrote: > Hi - > > >From: Andy Bierman > >Sent: Mar 26, 2014 10:17 PM > >To: Martin Bjorklund > >Cc: "netmod@ietf.org" > >Subject: Re: [netmod] Y18: fix "when" expression context node problem > ... > >> How can we state that there MUST NOT be any ciruclar references in > >> when expressions? > >> > >> > >This is way too difficult for a compiler to detect. > >It takes somebody (like a YANG doctor) to spot the issue > >and say "change this to a choice-stmt, or use must-stmt instead". > > I don't see why it should be substantially more difficult > than, say, detecting indirect circular references in > spreadsheet formulas. One would need to apply similar > reasoning anyway to unravel ordering dependencies between > various bits and pieces of configuration. > > Do you have a case in mind more pathological than that? > > XPath can select values by wildcard, axis, partial string match, etc. There are many ways to reference a node without specifying it by name. Even if every node could be identified, it would be complicated to validate every when-stmt against every other when-stmt to isolate the overlaps. > Randy > > Andy --001a11c2068865b98304f5838fa0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Mar 26, 2014 at 7:35 AM, Randy Presuhn &l= t;randy_p= resuhn@mindspring.com> wrote:
Hi -

>From: Andy Bierman <andy@yumaw= orks.com>
>Sent: Mar 26, 2014 10:17 PM
>To: Martin Bjorklund <mbj@tail-f.c= om>
>Cc: "netmod@ietf.org" = <netmod@ietf.org>
>Subject: Re: [netmod] Y18: fix "when" expression context node= problem
...
>> How can we state that there MUST NOT be any ciruclar references in=
>> when expressions?
>>
>>
>This is way too difficult for a compiler to detect.
>It takes somebody (like a YANG doctor) to spot the issue
>and say "change this to a choice-stmt, or use must-stmt instead&qu= ot;.

I don't see why it should be substantially more difficult
than, say, detecting indirect circular references in
spreadsheet formulas. =A0One would need to apply similar
reasoning anyway to unravel ordering dependencies between
various bits and pieces of configuration.

Do you have a case in mind more pathological than that?


XPath can select values by wildcard, a= xis, partial string match, etc.
There are many ways to reference = a node without specifying it by name.
Even if every node could be= identified, it would be complicated to validate
every when-stmt against every other when-stmt to isolate the overlaps.=
=A0
Randy


Andy
=A0
--001a11c2068865b98304f5838fa0-- From nobody Wed Mar 26 07:49:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BB81A0306 for ; Wed, 26 Mar 2014 07:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iTkITg9WOQM for ; Wed, 26 Mar 2014 07:49:41 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9751A0346 for ; Wed, 26 Mar 2014 07:49:40 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id s2QEncs4012421; Wed, 26 Mar 2014 15:49:38 +0100 Message-ID: <5332E901.4020100@mg-soft.com> Date: Wed, 26 Mar 2014 15:49:37 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Randy Presuhn References: <2107998.1395844540276.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> In-Reply-To: <2107998.1395844540276.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Y3DiOdeUFtsQV52Dx5D0uD1wyNc Cc: netmod@ietf.org Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 14:49:42 -0000 Dne 26.3.2014 15:35, piše Randy Presuhn: > Hi - > >> From: Andy Bierman >> Sent: Mar 26, 2014 10:17 PM >> To: Martin Bjorklund >> Cc: "netmod@ietf.org" >> Subject: Re: [netmod] Y18: fix "when" expression context node problem > ... >>> How can we state that there MUST NOT be any ciruclar references in >>> when expressions? >>> >>> >> This is way too difficult for a compiler to detect. >> It takes somebody (like a YANG doctor) to spot the issue >> and say "change this to a choice-stmt, or use must-stmt instead". > I don't see why it should be substantially more difficult > than, say, detecting indirect circular references in > spreadsheet formulas. One would need to apply similar > reasoning anyway to unravel ordering dependencies between > various bits and pieces of configuration. > > Do you have a case in mind more pathological than that? Unknown extension XPath functions that return node-sets come to mind. A compiler that does not support a specific function could not possibly detect a loop since it would not be able to follow certain location paths and match them to the data nodes. Jernej > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Mar 26 07:57:19 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81111A0354 for ; Wed, 26 Mar 2014 07:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id li0qEvQg4qqe for ; Wed, 26 Mar 2014 07:57:14 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id 531271A0351 for ; Wed, 26 Mar 2014 07:57:14 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id j15so2323928qaq.16 for ; Wed, 26 Mar 2014 07:57:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gpYakEQMsPbbTienOURbzkk4OZrFj7CX5mmDOyyYNNc=; b=Syab0613vjaF9nTxsFFejxsJjTADMzK3iBAlxOdgdbZOxJ1w/wKbcF232hQNJBsId4 OIRV6M+WE/pd8DAF6CMfcuKJpckJc+V118XZ6QyI8WL/JQwVDYoF3yaaZiA3f6+yxHQb Ln9A2o5dyHY9etrbTJWw6RG+s+0SrGzWanN+QUSL+zEZoDLv3/dIjNpUHcdqXfEqangJ ja0DsONCahSlrAFBoacAmXYpFhuz5NWbUAySDcJkxhkoeTDFyRCVMSJzaY5pznYmHg/v y8HyJWDNuj8e5v5QOJ/pbfFogpAXIfS3T6N38AZbsdJ8JhG2wLmtFRMBw3AvyLzH5HAl vPtg== X-Gm-Message-State: ALoCoQnxV5HbettrBZDc5wRCzZjaaq2VHh1CpNKMHrfMKKLZ8hgWlesCV8MyzwNcf+lU+Aa9Ankx MIME-Version: 1.0 X-Received: by 10.140.27.193 with SMTP id 59mr85070305qgx.18.1395845832671; Wed, 26 Mar 2014 07:57:12 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Wed, 26 Mar 2014 07:57:12 -0700 (PDT) In-Reply-To: <36E4F7A8-8A0E-4666-B469-6934E6F7802C@nic.cz> References: <5CAA392C-3951-4AA4-AE57-BFC26FE4A3FD@nic.cz> <20140326.150935.1428873551094973632.mbj@tail-f.com> <36E4F7A8-8A0E-4666-B469-6934E6F7802C@nic.cz> Date: Wed, 26 Mar 2014 07:57:12 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c1233a0496e204f583afaf Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jZZzr0OKaw-5IWDZeHNy_pytiQQ Cc: "netmod@ietf.org" Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 14:57:17 -0000 --001a11c1233a0496e204f583afaf Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 26, 2014 at 7:48 AM, Ladislav Lhotka wrote: > > On 26 Mar 2014, at 15:09, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > >> > >> On 26 Mar 2014, at 14:53, Andy Bierman wrote: > >> > >>> > >>> > >>> > >>> On Wed, Mar 26, 2014 at 6:40 AM, Ladislav Lhotka > >>> wrote: > >>> Andy Bierman writes: > >>> > >>>> On Tue, Mar 25, 2014 at 2:40 PM, Ladislav Lhotka > >>>> wrote: > >>>> > >>>>> Andy Bierman writes: > >>>>> > >>>>>>> > >>>>>>> > >>>>>> I do not see the error. Are you saying all the when-stmts that are > in > >>>>> YANG > >>>>>> 1.0 > >>>>>> modules now are broken? Are you saying they are unimplementable? > >>>>> > >>>>> What I am saying is that data model fragments like > >>>>> > >>>>> container foo { > >>>>> when "1 = 0"; > >>>>> leaf bar { > >>>>> mandatory true; > >>>>> ... > >>>>> } > >>>>> } > >>>>> > >>>>> don't have a satisfactory interpretation. It is fully defensible if a > >>>>> validation tool flags datastore content as invalid if it doesn't > >>>>> contain > >>>>> the "foo" container and the mandatory "bar" leaf. > >>>>> > >>>>> > >>>> > >>>> Like I said, the pathological cases are operationally useless. > >>>> Nobody would ever write "when 1 = 0". We should avoid adding > >>> > >>> The XPath expression doesn't matter, the problem is the same whatever > >>> the expression is. > >>> > >>>> CLRs to YANG that are intended from preventing people from doing > >>>> things > >>>> they would not even try to do. It is just busy work for compiler > >>>> writers. > >>>> > >>>> > >>>> > >>>> > >>>>>> > >>>>>> YANG 1.0 when-stmts need to be unchanged in YANG 1.1. > >>>>>> The issue of evaluating a when-expr as if there was a context > >>>>>> node inserted is a completely different issue than the order that > >>>>>> multiple when-stmts are evaluated. Changing the context node > >>>>>> to the parent does not alter the evaluation order problem. > >>>>> > >>>>> That's true, but it does make a difference whether you insert all the > >>>>> temporary context nodes at once or one by one. > >>>>> > >>>>> > >>>> To be honest -- it doesn't. Setting all the context nodes to random > >>>> values > >>> > >>> It doesn't? So how do you proceed with inserting these dummy nodes in > >>> my recent dhcp/bootp example? > >>> > >>> > >>> I would not allow that module to be published. > >>> It would have to be rewritten so there was no dependency loop. > >> > >> Each container can be in a separate module maintained by a different > >> party. > > > > If I understand your concern this isn't possible, since you can't > > refer to nodes from other module w/o importing the other module, and > > cirular imports are not allowed. > > Yes, you are right, it is not possible in this form (but see below). > > > > >> Alternatively, it can be intentionally crafted by an attacker. > > > > ? > > Somebody can write a module that looks innocent and compiles properly but > creates this when loop under some circumstances. > > > > >> IMO it is up to YANG spec to make sure this is not allowed, and > >> compilers should do their best to eliminate it. > > > > How can we state that there MUST NOT be any ciruclar references in > > when expressions? > > I proposed a formulation earlier: > > "The XPath expression must not involve any node that is directly or > indirectly conditional." > > This is far too restrictive and not needed. I strongly object to solutions that make valid YANG 1.0 modules invalid. It violates the charter, so every proposal better meet this requirement. Checking it can be tricky, because the XPath expression may contain things > like count(../*) whose result depends on the presence or absence of the > context node. > > I think XPath is too powerful for this purpose. > > Lada > > > > > > > /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > Andy --001a11c1233a0496e204f583afaf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Mar 26, 2014 at 7:48 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 26 Mar 2014, at 15:09, Martin Bjorklund <mbj@tail-f.com> wrote:

> Ladislav Lhotka <lhotka@nic.cz= > wrote:
>>
>> On 26 Mar 2014, at 14:53, Andy Bierman <andy@yumaworks.com> wrote:
>>
>>>
>>>
>>>
>>> On Wed, Mar 26, 2014 at 6:40 AM, Ladislav Lhotka <lhotka@nic.cz>
>>> wrote:
>>> Andy Bierman <andy@yu= maworks.com> writes:
>>>
>>>> On Tue, Mar 25, 2014 at 2:40 PM, Ladislav Lhotka <lhotka@nic.cz>
>>>> wrote:
>>>>
>>>>> Andy Bierman <andy@yumaworks.com> writes:
>>>>>
>>>>>>>
>>>>>>>
>>>>>> I do not see the error. =A0Are you saying all the = when-stmts that are in
>>>>> YANG
>>>>>> 1.0
>>>>>> modules now are broken? Are you saying they are un= implementable?
>>>>>
>>>>> What I am saying is that data model fragments like
>>>>>
>>>>> container foo {
>>>>> =A0 =A0when "1 =3D 0";
>>>>> =A0 =A0leaf bar {
>>>>> =A0 =A0 =A0 =A0mandatory true;
>>>>> =A0 =A0 =A0 =A0...
>>>>> =A0 =A0}
>>>>> }
>>>>>
>>>>> don't have a satisfactory interpretation. It is fu= lly defensible if a
>>>>> validation tool flags datastore content as invalid if = it doesn't
>>>>> contain
>>>>> the "foo" container and the mandatory "= bar" leaf.
>>>>>
>>>>>
>>>>
>>>> Like I said, the pathological cases are operationally usel= ess.
>>>> Nobody would ever write "when 1 =3D 0". We shoul= d avoid adding
>>>
>>> The XPath expression doesn't matter, the problem is the sa= me whatever
>>> the expression is.
>>>
>>>> CLRs to YANG that are intended from preventing people from= doing
>>>> things
>>>> they would not even try to do. =A0It is just busy work for= compiler
>>>> writers.
>>>>
>>>>
>>>>
>>>>
>>>>>>
>>>>>> YANG 1.0 when-stmts need to be unchanged in YANG 1= .1.
>>>>>> The issue of evaluating a when-expr as if there wa= s a context
>>>>>> node inserted is a completely different issue than= the order that
>>>>>> multiple when-stmts are evaluated. =A0Changing the= context node
>>>>>> to the parent does not alter the evaluation order = problem.
>>>>>
>>>>> That's true, but it does make a difference whether= you insert all the
>>>>> temporary context nodes at once or one by one.
>>>>>
>>>>>
>>>> To be honest -- it doesn't. =A0Setting all the context= nodes to random
>>>> values
>>>
>>> It doesn't? So how do you proceed with inserting these dum= my nodes in
>>> my recent dhcp/bootp example?
>>>
>>>
>>> I would not allow that module to be published.
>>> It would have to be rewritten so there was no dependency loop.=
>>
>> Each container can be in a separate module maintained by a differe= nt
>> party.
>
> If I understand your concern this isn't possible, since you can= 9;t
> refer to nodes from other module w/o importing the other module, and > cirular imports are not allowed.

Yes, you are right, it is not possible in this form (but see below).

>
>> Alternatively, it can be intentionally crafted by an attacker.
>
> ?

Somebody can write a module that looks innocent and compiles properly but c= reates this when loop under some circumstances.

>
>> IMO it is up to YANG spec to make sure this is not allowed, and >> compilers should do their best to eliminate it.
>
> How can we state that there MUST NOT be any ciruclar references in
> when expressions?

I proposed a formulation earlier:

"The XPath expression must not involve any node that is directly or in= directly conditional."


This is far too restrictive and not ne= eded.

I strongly object to solutions that make val= id YANG 1.0 modules invalid.
It violates the charter, so every pr= oposal better meet this requirement.


Checking it can be tricky, because the XPath expression may contain things = like count(../*) whose result depends on the presence or absence of the con= text node.

I think XPath is too powerful for this purpose.

Lada

>
>
> /martin

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



Andy

=A0

--001a11c1233a0496e204f583afaf-- From nobody Wed Mar 26 08:02:36 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A591A0107 for ; Wed, 26 Mar 2014 08:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnW65w0PzCLO for ; Wed, 26 Mar 2014 08:02:29 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 591BD1A00FB for ; Wed, 26 Mar 2014 08:02:29 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id s2QF2Rbb012605; Wed, 26 Mar 2014 16:02:27 +0100 Message-ID: <5332EC02.2020607@mg-soft.com> Date: Wed, 26 Mar 2014 16:02:26 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ladislav Lhotka References: <5CAA392C-3951-4AA4-AE57-BFC26FE4A3FD@nic.cz> <20140326.150935.1428873551094973632.mbj@tail-f.com> <36E4F7A8-8A0E-4666-B469-6934E6F7802C@nic.cz> In-Reply-To: <36E4F7A8-8A0E-4666-B469-6934E6F7802C@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/tf6Cez9yptg1PMTXx4OQM7LhQ-k Cc: netmod@ietf.org Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 15:02:32 -0000 Dne 26.3.2014 15:48, piše Ladislav Lhotka: > On 26 Mar 2014, at 15:09, Martin Bjorklund wrote: > >> Ladislav Lhotka wrote: >>> On 26 Mar 2014, at 14:53, Andy Bierman wrote: >>> >>>> >>>> >>>> On Wed, Mar 26, 2014 at 6:40 AM, Ladislav Lhotka >>>> wrote: >>>> Andy Bierman writes: >>>> >>>>> On Tue, Mar 25, 2014 at 2:40 PM, Ladislav Lhotka >>>>> wrote: >>>>> >>>>>> Andy Bierman writes: >>>>>> >>>>>>>> >>>>>>> I do not see the error. Are you saying all the when-stmts that are in >>>>>> YANG >>>>>>> 1.0 >>>>>>> modules now are broken? Are you saying they are unimplementable? >>>>>> What I am saying is that data model fragments like >>>>>> >>>>>> container foo { >>>>>> when "1 = 0"; >>>>>> leaf bar { >>>>>> mandatory true; >>>>>> ... >>>>>> } >>>>>> } >>>>>> >>>>>> don't have a satisfactory interpretation. It is fully defensible if a >>>>>> validation tool flags datastore content as invalid if it doesn't >>>>>> contain >>>>>> the "foo" container and the mandatory "bar" leaf. >>>>>> >>>>>> >>>>> Like I said, the pathological cases are operationally useless. >>>>> Nobody would ever write "when 1 = 0". We should avoid adding >>>> The XPath expression doesn't matter, the problem is the same whatever >>>> the expression is. >>>> >>>>> CLRs to YANG that are intended from preventing people from doing >>>>> things >>>>> they would not even try to do. It is just busy work for compiler >>>>> writers. >>>>> >>>>> >>>>> >>>>> >>>>>>> YANG 1.0 when-stmts need to be unchanged in YANG 1.1. >>>>>>> The issue of evaluating a when-expr as if there was a context >>>>>>> node inserted is a completely different issue than the order that >>>>>>> multiple when-stmts are evaluated. Changing the context node >>>>>>> to the parent does not alter the evaluation order problem. >>>>>> That's true, but it does make a difference whether you insert all the >>>>>> temporary context nodes at once or one by one. >>>>>> >>>>>> >>>>> To be honest -- it doesn't. Setting all the context nodes to random >>>>> values >>>> It doesn't? So how do you proceed with inserting these dummy nodes in >>>> my recent dhcp/bootp example? >>>> >>>> >>>> I would not allow that module to be published. >>>> It would have to be rewritten so there was no dependency loop. >>> Each container can be in a separate module maintained by a different >>> party. >> If I understand your concern this isn't possible, since you can't >> refer to nodes from other module w/o importing the other module, and >> cirular imports are not allowed. > Yes, you are right, it is not possible in this form (but see below). > >>> Alternatively, it can be intentionally crafted by an attacker. >> ? > Somebody can write a module that looks innocent and compiles properly but creates this when loop under some circumstances. > >>> IMO it is up to YANG spec to make sure this is not allowed, and >>> compilers should do their best to eliminate it. >> How can we state that there MUST NOT be any ciruclar references in >> when expressions? > I proposed a formulation earlier: > > "The XPath expression must not involve any node that is directly or indirectly conditional." > > Checking it can be tricky, because the XPath expression may contain things like count(../*) whose result depends on the presence or absence of the context node. I don't think you need the actual result of the evaluation though. All you need to know is what the expression is referencing; parent, self and siblings of the context node in your case. Is there an example for the A->B->C->A loop case? Jernej > > I think XPath is too powerful for this purpose. > > Lada > >> >> /martin > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Mar 26 08:05:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC81E1A02D8 for ; Wed, 26 Mar 2014 08:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ki0MeKdWDaj for ; Wed, 26 Mar 2014 08:05:21 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id F26851A0147 for ; Wed, 26 Mar 2014 08:05:20 -0700 (PDT) Received: from ladislavs-air-2.lan (ip-94-113-93-24.net.upcbroadband.cz [94.113.93.24]) by mail.nic.cz (Postfix) with ESMTPSA id 808C313F686; Wed, 26 Mar 2014 16:05:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395846318; bh=z3bl2UvZNPzW6KEXo9w5n5dk5I+qzX6+hSqpChA6L6U=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=DucylAv0nQmk2RYpM3psIlVhJu0R8PsssXQNYyBpv9b9xj0kPt8S/CUJh+Vn/iAZD zPvu7QKilBUHjlr+RZ4mD7/FqTD2sQueoiFa22oQWHm0opCUOwZ5iavPY+oBRwEudr ySEKFVsKOg3uZWYn9hOzvz9nd9jXDF/pIKgORNyk= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 26 Mar 2014 16:05:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6F6EF691-5134-4243-B25D-96C54760741C@nic.cz> References: <20140326.145737.580242632261637255.mbj@tail-f.com> <20140326.152737.330538996469661145.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yJwpRlEYy4BH1CsV7f_tTp05mLs Cc: "netmod@ietf.org" Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 15:05:23 -0000 On 26 Mar 2014, at 15:43, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, Mar 26, 2014 at 7:27 AM, Martin Bjorklund = wrote: > Andy Bierman wrote: > > On Wed, Mar 26, 2014 at 7:10 AM, Ladislav Lhotka = wrote: > > > > > > > > On 26 Mar 2014, at 14:57, Martin Bjorklund wrote: > > > > > > > Ladislav Lhotka wrote: > > > >> Martin Bjorklund writes: > > > >> > > > >>> Hi, > > > >>> > > > >>> Here's yet another attempt to handle attributes in JSON, = without > > > >>> changing the encoding for the case that there are no = attributes > > > >>> present. > > > >>> > > > >>> In all examples, the attributes "inactive" and "etag" are = present. > > > >>> > > > >>> Attributes are encoded differently depending on the type of = object: > > > >>> > > > >>> > > > >>> leaf > > > >>> ---- > > > >>> > > > >>> Encode the attributes as a sibling to the leaf. > > > >>> > > > >>> > > > >>> leaf foo { > > > >>> type string; > > > >>> } > > > >>> > > > >>> "foo": "some value"; > > > >>> "@foo": { > > > >>> "inactive": true, > > > >>> "etag": "..."; > > > >>> } > > > >>> > > > >>> > > > >>> list instance > > > >>> ------------- > > > >>> > > > >>> Encode the attributes within the list instance. > > > >>> > > > >>> > > > >>> list bar { > > > >>> key name; > > > >>> leaf name { > > > >>> type string; > > > >>> } > > > >>> ... > > > >>> } > > > >>> > > > >>> "bar": [ > > > >>> { > > > >>> "@bar": { > > > >>> "inactive": true, > > > >>> "etag": "..." > > > >>> } > > > >>> "name": "instance name"; > > > >>> }] > > > >>> > > > >> > > > >> This could be ambiguous: > > > >> > > > >> list bar { > > > >> key name; > > > >> leaf name { ... } > > > >> leaf bar { ... } > > > >> } > > > >> > > > >> Then you don't know whether the attributes belong to the list = entry > > > >> or to the contained leaf. > > > > > > > > Right. Then we use "@@bar" for the list / container attributes. > > > > > > OK, then this scheme is fine with me. > > > > > > > > Looks more complicated than other solution proposals. >=20 > Do we agree that we don't want different encodings for values if there > are attributes or not? I.e., if my code works when no attributes are > present, it should also work if there are attributes? I am not sure even your encoding satisfies this requirement. At least = your code has to be instructed to ignore the attribute stuff. >=20 >=20 > Not if the normal encoding is painful to use. > The use attributes is going to be rare. > I want the expected "plain" encoding when there are no attributes. > Code that generates JSON and does not care about attributes > must not be rendered useless because the JSON is specially encoded > in RESTCONF. We want to leverage wide knowledge of JSON, > not invent our own incompatible version of it. This is my preference, too. >=20 > =20 > If so, do we have any other proposal? Leave it to proponents of every use case to figure out ad hoc how to = encode what=92s needed, or resort to XML. Lada >=20 > I am all for a simpler solution! >=20 >=20 >=20 > Putting attributes at the sibling level does not work for leaf-lists. > Even for leafs, it is difficult to parse. JSON objects are unordered, > so the "@foo" could appear anywhere, even before "foo". The schemes > I proposed always keeps the attributes within the node for the = attributes > (just like XML). >=20 > One idea I had was to simply disallow attributes for leaf and = leaf-list. > They can only go in container or list nodes. This is restrictive but = then there > will not be any dual decoding possibilities. >=20 >=20 >=20 > /martin >=20 > Andy >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 26 08:12:27 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0216C1A0107 for ; Wed, 26 Mar 2014 08:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQM0xD3Ri6cZ for ; Wed, 26 Mar 2014 08:12:23 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id C653A1A00E3 for ; Wed, 26 Mar 2014 08:12:22 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 67BC9477FF3; Wed, 26 Mar 2014 16:12:20 +0100 (CET) Date: Wed, 26 Mar 2014 16:12:20 +0100 (CET) Message-Id: <20140326.161220.1907816882803386580.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <6F6EF691-5134-4243-B25D-96C54760741C@nic.cz> References: <20140326.152737.330538996469661145.mbj@tail-f.com> <6F6EF691-5134-4243-B25D-96C54760741C@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/MhwTJU8jRiqssoiiK6FzT8Yr6W8 Cc: netmod@ietf.org Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 15:12:25 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+IE9uIDI2IE1hciAy MDE0LCBhdCAxNTo0MywgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0K PiANCj4gPiANCj4gPiANCj4gPiANCj4gPiBPbiBXZWQsIE1hciAyNiwgMjAxNCBhdCA3OjI3IEFN LCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4NCj4gPiB3cm90ZToNCj4gPiBBbmR5 IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gd3JvdGU6DQo+ID4gPiBPbiBXZWQsIE1hciAy NiwgMjAxNCBhdCA3OjEwIEFNLCBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+DQo+ID4g PiB3cm90ZToNCj4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IE9uIDI2IE1hciAyMDE0LCBhdCAxNDo1 NywgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+IHdyb3RlOg0KPiA+ID4gPg0KPiA+ ID4gPiA+IExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej4gd3JvdGU6DQo+ID4gPiA+ID4+ IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPiB3cml0ZXM6DQo+ID4gPiA+ID4+DQo+ ID4gPiA+ID4+PiBIaSwNCj4gPiA+ID4gPj4+DQo+ID4gPiA+ID4+PiBIZXJlJ3MgeWV0IGFub3Ro ZXIgYXR0ZW1wdCB0byBoYW5kbGUgYXR0cmlidXRlcyBpbiBKU09OLCB3aXRob3V0DQo+ID4gPiA+ ID4+PiBjaGFuZ2luZyB0aGUgZW5jb2RpbmcgZm9yIHRoZSBjYXNlIHRoYXQgdGhlcmUgYXJlIG5v IGF0dHJpYnV0ZXMNCj4gPiA+ID4gPj4+IHByZXNlbnQuDQo+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+ Pj4gSW4gYWxsIGV4YW1wbGVzLCB0aGUgYXR0cmlidXRlcyAiaW5hY3RpdmUiIGFuZCAiZXRhZyIg YXJlIHByZXNlbnQuDQo+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+Pj4gQXR0cmlidXRlcyBhcmUgZW5j b2RlZCBkaWZmZXJlbnRseSBkZXBlbmRpbmcgb24gdGhlIHR5cGUgb2Ygb2JqZWN0Og0KPiA+ID4g PiA+Pj4NCj4gPiA+ID4gPj4+DQo+ID4gPiA+ID4+PiBsZWFmDQo+ID4gPiA+ID4+PiAtLS0tDQo+ ID4gPiA+ID4+Pg0KPiA+ID4gPiA+Pj4gRW5jb2RlIHRoZSBhdHRyaWJ1dGVzIGFzIGEgc2libGlu ZyB0byB0aGUgbGVhZi4NCj4gPiA+ID4gPj4+DQo+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+Pj4gIGxl YWYgZm9vIHsNCj4gPiA+ID4gPj4+ICAgIHR5cGUgc3RyaW5nOw0KPiA+ID4gPiA+Pj4gIH0NCj4g PiA+ID4gPj4+DQo+ID4gPiA+ID4+PiAgImZvbyI6ICJzb21lIHZhbHVlIjsNCj4gPiA+ID4gPj4+ ICAiQGZvbyI6IHsNCj4gPiA+ID4gPj4+ICAgICAiaW5hY3RpdmUiOiB0cnVlLA0KPiA+ID4gPiA+ Pj4gICAgICJldGFnIjogIi4uLiI7DQo+ID4gPiA+ID4+PiAgIH0NCj4gPiA+ID4gPj4+DQo+ID4g PiA+ID4+Pg0KPiA+ID4gPiA+Pj4gbGlzdCBpbnN0YW5jZQ0KPiA+ID4gPiA+Pj4gLS0tLS0tLS0t LS0tLQ0KPiA+ID4gPiA+Pj4NCj4gPiA+ID4gPj4+IEVuY29kZSB0aGUgYXR0cmlidXRlcyB3aXRo aW4gdGhlIGxpc3QgaW5zdGFuY2UuDQo+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+Pj4NCj4gPiA+ID4g Pj4+ICBsaXN0IGJhciB7DQo+ID4gPiA+ID4+PiAgICBrZXkgbmFtZTsNCj4gPiA+ID4gPj4+ICAg IGxlYWYgbmFtZSB7DQo+ID4gPiA+ID4+PiAgICAgIHR5cGUgc3RyaW5nOw0KPiA+ID4gPiA+Pj4g ICAgfQ0KPiA+ID4gPiA+Pj4gICAgLi4uDQo+ID4gPiA+ID4+PiAgfQ0KPiA+ID4gPiA+Pj4NCj4g PiA+ID4gPj4+ICAiYmFyIjogWw0KPiA+ID4gPiA+Pj4gICAgIHsNCj4gPiA+ID4gPj4+ICAgICAg ICAiQGJhciI6IHsNCj4gPiA+ID4gPj4+ICAgICAgICAgICAiaW5hY3RpdmUiOiB0cnVlLA0KPiA+ ID4gPiA+Pj4gICAgICAgICAgICJldGFnIjogIi4uLiINCj4gPiA+ID4gPj4+ICAgICAgICAgfQ0K PiA+ID4gPiA+Pj4gICAgICAgICAibmFtZSI6ICJpbnN0YW5jZSBuYW1lIjsNCj4gPiA+ID4gPj4+ ICAgICAgfV0NCj4gPiA+ID4gPj4+DQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IFRoaXMgY291bGQg YmUgYW1iaWd1b3VzOg0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiBsaXN0IGJhciB7DQo+ID4gPiA+ ID4+ICBrZXkgbmFtZTsNCj4gPiA+ID4gPj4gIGxlYWYgbmFtZSB7IC4uLiB9DQo+ID4gPiA+ID4+ ICBsZWFmIGJhciB7IC4uLiB9DQo+ID4gPiA+ID4+IH0NCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4g VGhlbiB5b3UgZG9uJ3Qga25vdyB3aGV0aGVyIHRoZSBhdHRyaWJ1dGVzIGJlbG9uZyB0byB0aGUg bGlzdCBlbnRyeQ0KPiA+ID4gPiA+PiBvciB0byB0aGUgY29udGFpbmVkIGxlYWYuDQo+ID4gPiA+ ID4NCj4gPiA+ID4gPiBSaWdodC4gVGhlbiB3ZSB1c2UgIkBAYmFyIiBmb3IgdGhlIGxpc3QgLyBj b250YWluZXIgYXR0cmlidXRlcy4NCj4gPiA+ID4NCj4gPiA+ID4gT0ssIHRoZW4gdGhpcyBzY2hl bWUgaXMgZmluZSB3aXRoIG1lLg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gTG9va3MgbW9yZSBj b21wbGljYXRlZCB0aGFuIG90aGVyIHNvbHV0aW9uIHByb3Bvc2Fscy4NCj4gPiANCj4gPiBEbyB3 ZSBhZ3JlZSB0aGF0IHdlIGRvbid0IHdhbnQgZGlmZmVyZW50IGVuY29kaW5ncyBmb3IgdmFsdWVz IGlmIHRoZXJlDQo+ID4gYXJlIGF0dHJpYnV0ZXMgb3Igbm90PyAgSS5lLiwgaWYgbXkgY29kZSB3 b3JrcyB3aGVuIG5vIGF0dHJpYnV0ZXMgYXJlDQo+ID4gcHJlc2VudCwgaXQgc2hvdWxkIGFsc28g d29yayBpZiB0aGVyZSBhcmUgYXR0cmlidXRlcz8NCj4gDQo+IEkgYW0gbm90IHN1cmUgZXZlbiB5 b3VyIGVuY29kaW5nIHNhdGlzZmllcyB0aGlzIHJlcXVpcmVtZW50LiBBdCBsZWFzdA0KPiB5b3Vy IGNvZGUgaGFzIHRvIGJlIGluc3RydWN0ZWQgdG8gaWdub3JlIHRoZSBhdHRyaWJ1dGUgc3R1ZmYu DQoNCkluIGdlbmVyYWwsIEkgdGhpbmsgcm9idXN0IGNvZGUgd291bGQgaWdub3JlIHVua25vd24g ZmllbGRzLg0KDQo+ID4gTm90IGlmIHRoZSBub3JtYWwgZW5jb2RpbmcgaXMgcGFpbmZ1bCB0byB1 c2UuDQo+ID4gVGhlIHVzZSBhdHRyaWJ1dGVzIGlzIGdvaW5nIHRvIGJlIHJhcmUuDQo+ID4gSSB3 YW50IHRoZSBleHBlY3RlZCAicGxhaW4iIGVuY29kaW5nIHdoZW4gdGhlcmUgYXJlIG5vIGF0dHJp YnV0ZXMuDQo+ID4gQ29kZSB0aGF0IGdlbmVyYXRlcyBKU09OIGFuZCBkb2VzIG5vdCBjYXJlIGFi b3V0IGF0dHJpYnV0ZXMNCj4gPiBtdXN0IG5vdCBiZSByZW5kZXJlZCB1c2VsZXNzIGJlY2F1c2Ug dGhlIEpTT04gaXMgc3BlY2lhbGx5IGVuY29kZWQNCj4gPiBpbiBSRVNUQ09ORi4gIFdlIHdhbnQg dG8gbGV2ZXJhZ2Ugd2lkZSBrbm93bGVkZ2Ugb2YgSlNPTiwNCj4gPiBub3QgaW52ZW50IG91ciBv d24gaW5jb21wYXRpYmxlIHZlcnNpb24gb2YgaXQuDQo+IA0KPiBUaGlzIGlzIG15IHByZWZlcmVu Y2UsIHRvby4NCg0KV2VsbCwgb2YgY291cnNlLiAgQnV0IEkgZG9uJ3QgdGhpbmsgYW55b25lIGhh cyBwcm9wb3NlZCBzb21ldGhpbmcgdGhhdA0KaXMgbm90IHZhbGlkIGpzb24uDQoNCj4gPiBJZiBz bywgZG8gd2UgaGF2ZSBhbnkgb3RoZXIgcHJvcG9zYWw/DQo+IA0KPiBMZWF2ZSBpdCB0byBwcm9w b25lbnRzIG9mIGV2ZXJ5IHVzZSBjYXNlIHRvIGZpZ3VyZSBvdXQgYWQgaG9jIGhvdyB0bw0KPiBl bmNvZGUgd2hhdOKAmXMgbmVlZGVkLCBvciByZXNvcnQgdG8gWE1MLg0KDQpXaGljaCBmb3IgUkVT VENPTkYgd291bGQgbWVhbiB1c2UgWE1MLCBJTU8uDQoNCkkgc3RpbGwgdGhpbmsgYSBjb21tb24g ZGVmaW5pdGlvbiB3b3VsZCBiZSBiZXR0ZXIuDQoNCg0KL21hcnRpbg0K From nobody Wed Mar 26 08:17:52 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2511A0113 for ; Wed, 26 Mar 2014 08:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFPCYtJf9Cyv for ; Wed, 26 Mar 2014 08:17:47 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id E1E9B1A00E3 for ; Wed, 26 Mar 2014 08:17:46 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1A9C43B411D; Wed, 26 Mar 2014 16:17:45 +0100 (CET) Date: Wed, 26 Mar 2014 16:17:44 +0100 (CET) Message-Id: <20140326.161744.477118160786846212.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140326.152737.330538996469661145.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/J9UGW6e8AtOt0_Ho19oga6V8eyc Cc: netmod@ietf.org Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 15:17:50 -0000 Andy Bierman wrote: > On Wed, Mar 26, 2014 at 7:27 AM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > On Wed, Mar 26, 2014 at 7:10 AM, Ladislav Lhotka wrote: > > > > > > > > > > > On 26 Mar 2014, at 14:57, Martin Bjorklund wrote: > > > > > > > > > Ladislav Lhotka wrote: > > > > >> Martin Bjorklund writes: > > > > >> > > > > >>> Hi, > > > > >>> > > > > >>> Here's yet another attempt to handle attributes in JSON, without > > > > >>> changing the encoding for the case that there are no attributes > > > > >>> present. > > > > >>> > > > > >>> In all examples, the attributes "inactive" and "etag" are present. > > > > >>> > > > > >>> Attributes are encoded differently depending on the type of object: > > > > >>> > > > > >>> > > > > >>> leaf > > > > >>> ---- > > > > >>> > > > > >>> Encode the attributes as a sibling to the leaf. > > > > >>> > > > > >>> > > > > >>> leaf foo { > > > > >>> type string; > > > > >>> } > > > > >>> > > > > >>> "foo": "some value"; > > > > >>> "@foo": { > > > > >>> "inactive": true, > > > > >>> "etag": "..."; > > > > >>> } > > > > >>> > > > > >>> > > > > >>> list instance > > > > >>> ------------- > > > > >>> > > > > >>> Encode the attributes within the list instance. > > > > >>> > > > > >>> > > > > >>> list bar { > > > > >>> key name; > > > > >>> leaf name { > > > > >>> type string; > > > > >>> } > > > > >>> ... > > > > >>> } > > > > >>> > > > > >>> "bar": [ > > > > >>> { > > > > >>> "@bar": { > > > > >>> "inactive": true, > > > > >>> "etag": "..." > > > > >>> } > > > > >>> "name": "instance name"; > > > > >>> }] > > > > >>> > > > > >> > > > > >> This could be ambiguous: > > > > >> > > > > >> list bar { > > > > >> key name; > > > > >> leaf name { ... } > > > > >> leaf bar { ... } > > > > >> } > > > > >> > > > > >> Then you don't know whether the attributes belong to the list entry > > > > >> or to the contained leaf. > > > > > > > > > > Right. Then we use "@@bar" for the list / container attributes. > > > > > > > > OK, then this scheme is fine with me. > > > > > > > > > > > Looks more complicated than other solution proposals. > > > > Do we agree that we don't want different encodings for values if there > > are attributes or not? I.e., if my code works when no attributes are > > present, it should also work if there are attributes? > > > > > Not if the normal encoding is painful to use. > The use attributes is going to be rare. > I want the expected "plain" encoding when there are no attributes. > Code that generates JSON and does not care about attributes > must not be rendered useless because the JSON is specially encoded > in RESTCONF. We want to leverage wide knowledge of JSON, > not invent our own incompatible version of it. > > > > > If so, do we have any other proposal? > > > > I am all for a simpler solution! > > > > > > Putting attributes at the sibling level does not work for leaf-lists. See my proposal. > Even for leafs, it is difficult to parse. JSON objects are unordered, > so the "@foo" could appear anywhere, even before "foo". Sure. So what? Since they are unordered, you have to parse everything before starting to process anyway. > The schemes > I proposed always keeps the attributes within the node for the attributes > (just like XML). The proposals I have seen either changes the encoding depending on atribute presence, or are very chatty, which would remove the simplicity of using JSON. > One idea I had was to simply disallow attributes for leaf and leaf-list. > They can only go in container or list nodes. This is restrictive but then > there > will not be any dual decoding possibilities. Yes I think this is a bit too restrictive. (We tried in RESTCONF to let leafs just be fields, but now they are their own resources.) /martin From nobody Wed Mar 26 08:37:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE8471A0306 for ; Wed, 26 Mar 2014 08:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZsagikUGkin for ; Wed, 26 Mar 2014 08:36:56 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id C32DF1A017E for ; Wed, 26 Mar 2014 08:36:55 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id m5so2378384qaj.21 for ; Wed, 26 Mar 2014 08:36:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7xV8vDmocdJsbnacpRYslghPTraBo09+labVloRmU8c=; b=LhHrAr8tdeV+AfxSjQQpwCqY2LqrMQEfwE+9NwJVu0ehNvhT914S3R7Suhhl8g199M Kow8RAqsJrKpApSVfYfZMTygBXu82+MITSrWOdyj8NZvkA4Xk3+DCdc+P2hikpZf5ZO4 /3WmZtpOA/3vkkzxKKtlTWBJr+WqfQNtgz6zpT434lmUlLkL/lQRx/1pIHfh0ybtAZVx 9zNt9tPsHbANkSDOWnoczmrDX26M3rU8Na21NS0jzQX15+vEhntuG60oSQ+zueLvklw9 AbOsL9naetP+1SXQAhaB9aqogqHg77PdfNeLgEjnKjpvSlN/lC6IK0I2iE6FRwzMXHeO x5og== X-Gm-Message-State: ALoCoQkrb1Sf6sRV/ekK3Ki7xp/4JL/QNF93k1RJL+IpAYJX2vzroHeM7t5qQpViYEStzWHb4cDA MIME-Version: 1.0 X-Received: by 10.229.17.69 with SMTP id r5mr9738803qca.7.1395848213641; Wed, 26 Mar 2014 08:36:53 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Wed, 26 Mar 2014 08:36:53 -0700 (PDT) In-Reply-To: <5332EC02.2020607@mg-soft.com> References: <5CAA392C-3951-4AA4-AE57-BFC26FE4A3FD@nic.cz> <20140326.150935.1428873551094973632.mbj@tail-f.com> <36E4F7A8-8A0E-4666-B469-6934E6F7802C@nic.cz> <5332EC02.2020607@mg-soft.com> Date: Wed, 26 Mar 2014 08:36:53 -0700 Message-ID: From: Andy Bierman To: Jernej Tuljak Content-Type: multipart/alternative; boundary=001a1133c938ef780704f5843c8d Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/duCcP6IN6WHx_tlpBm4r3D7fXJc Cc: "netmod@ietf.org" Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 15:36:59 -0000 --001a1133c938ef780704f5843c8d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 26, 2014 at 8:02 AM, Jernej Tuljak wr= ote: > Dne 26.3.2014 15:48, pi=C5=A1e Ladislav Lhotka: > >> On 26 Mar 2014, at 15:09, Martin Bjorklund wrote: >> >> Ladislav Lhotka wrote: >>> >>>> On 26 Mar 2014, at 14:53, Andy Bierman wrote: >>>> >>>> >>>>> >>>>> On Wed, Mar 26, 2014 at 6:40 AM, Ladislav Lhotka >>>>> wrote: >>>>> Andy Bierman writes: >>>>> >>>>> On Tue, Mar 25, 2014 at 2:40 PM, Ladislav Lhotka >>>>>> wrote: >>>>>> >>>>>> Andy Bierman writes: >>>>>>> >>>>>>> >>>>>>>>> I do not see the error. Are you saying all the when-stmts that >>>>>>>> are in >>>>>>>> >>>>>>> YANG >>>>>>> >>>>>>>> 1.0 >>>>>>>> modules now are broken? Are you saying they are unimplementable? >>>>>>>> >>>>>>> What I am saying is that data model fragments like >>>>>>> >>>>>>> container foo { >>>>>>> when "1 =3D 0"; >>>>>>> leaf bar { >>>>>>> mandatory true; >>>>>>> ... >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> don't have a satisfactory interpretation. It is fully defensible if= a >>>>>>> validation tool flags datastore content as invalid if it doesn't >>>>>>> contain >>>>>>> the "foo" container and the mandatory "bar" leaf. >>>>>>> >>>>>>> >>>>>>> Like I said, the pathological cases are operationally useless. >>>>>> Nobody would ever write "when 1 =3D 0". We should avoid adding >>>>>> >>>>> The XPath expression doesn't matter, the problem is the same whatever >>>>> the expression is. >>>>> >>>>> CLRs to YANG that are intended from preventing people from doing >>>>>> things >>>>>> they would not even try to do. It is just busy work for compiler >>>>>> writers. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> YANG 1.0 when-stmts need to be unchanged in YANG 1.1. >>>>>>>> The issue of evaluating a when-expr as if there was a context >>>>>>>> node inserted is a completely different issue than the order that >>>>>>>> multiple when-stmts are evaluated. Changing the context node >>>>>>>> to the parent does not alter the evaluation order problem. >>>>>>>> >>>>>>> That's true, but it does make a difference whether you insert all t= he >>>>>>> temporary context nodes at once or one by one. >>>>>>> >>>>>>> >>>>>>> To be honest -- it doesn't. Setting all the context nodes to rand= om >>>>>> values >>>>>> >>>>> It doesn't? So how do you proceed with inserting these dummy nodes in >>>>> my recent dhcp/bootp example? >>>>> >>>>> >>>>> I would not allow that module to be published. >>>>> It would have to be rewritten so there was no dependency loop. >>>>> >>>> Each container can be in a separate module maintained by a different >>>> party. >>>> >>> If I understand your concern this isn't possible, since you can't >>> refer to nodes from other module w/o importing the other module, and >>> cirular imports are not allowed. >>> >> Yes, you are right, it is not possible in this form (but see below). >> >> Alternatively, it can be intentionally crafted by an attacker. >>>> >>> ? >>> >> Somebody can write a module that looks innocent and compiles properly bu= t >> creates this when loop under some circumstances. >> >> IMO it is up to YANG spec to make sure this is not allowed, and >>>> compilers should do their best to eliminate it. >>>> >>> How can we state that there MUST NOT be any ciruclar references in >>> when expressions? >>> >> I proposed a formulation earlier: >> >> "The XPath expression must not involve any node that is directly or >> indirectly conditional." >> >> Checking it can be tricky, because the XPath expression may contain >> things like count(../*) whose result depends on the presence or absence = of >> the context node. >> > > I don't think you need the actual result of the evaluation though. All yo= u > need to know is what the expression is referencing; parent, self and > siblings of the context node in your case. > > I think all the intermediate and final node-set results of every must/when expression in order to know if any XPath expressions access the same nodes. Examining the schema tree instead of the value tree has some problems, but ignoring that for the moment, it would be possible to detect that some previous when-stmt accessed the same node as another when-stmt. > Is there an example for the A->B->C->A loop case? > > Simple loop: container foo { leaf A { when "../B =3D 10"; type int32; } leaf B { when "../C =3D 10"; type int32; } leaf C { when "../A !=3D 10"; type int32; } } There are no real examples AFAIK. Of course, it is more complicated. Nodes can inherit multiple when-stmts, so even the order that when-stmts are processed for a single node can affect the ability to detect these loops. (You stop at the first false when-stmt). If there are if-feature statements then it gets even more complicated. It's fine to say when-stmt references MUST NOT create circular references, but I doubt compilers will detect these errors very well. > Jernej > Andy > > >> I think XPath is too powerful for this purpose. >> >> Lada >> >> >>> /martin >>> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> _______________________________________________ >> 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 > --001a1133c938ef780704f5843c8d Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable



On Wed, Mar 26, 2014 at 8:02 AM, Jernej Tuljak &l= t;jernej.tulj= ak@mg-soft.si> wrote:
Dne 26.3.2014 15:48, pi=B9e Ladislav Lhotka:
On 26 Mar 2014, at 15:09, Martin Bjorklund <mbj@tail-f.com> wrote:

Ladislav Lhotka <lhot= ka@nic.cz> wrote:
On 26 Mar 2014, at 14:53, Andy Bierman <andy@yumaworks.com> wrote:



On Wed, Mar 26, 2014 at 6:40 AM, Ladislav Lhotka <lhotka@nic.cz>
wrote:
Andy Bierman <an= dy@yumaworks.com> writes:

On Tue, Mar 25, 2014 at 2:40 PM, Ladislav Lhotka <lhotka@nic.cz>
wrote:

Andy Bierman <an= dy@yumaworks.com> writes:


I do not see the error. =A0Are you saying all the when-stmts that are in
YANG
1.0
modules now are broken? Are you saying they are unimplementable?
What I am saying is that data model fragments like

container foo {
=A0 =A0 when "1 =3D 0";
=A0 =A0 leaf bar {
=A0 =A0 =A0 =A0 mandatory true;
=A0 =A0 =A0 =A0 ...
=A0 =A0 }
}

don't have a satisfactory interpretation. It is fully defensible if a validation tool flags datastore content as invalid if it doesn't
contain
the "foo" container and the mandatory "bar" leaf.


Like I said, the pathological cases are operationally useless.
Nobody would ever write "when 1 =3D 0". We should avoid adding
The XPath expression doesn't matter, the problem is the same whatever the expression is.

CLRs to YANG that are intended from preventing people from doing
things
they would not even try to do. =A0It is just busy work for compiler
writers.




YANG 1.0 when-stmts need to be unchanged in YANG 1.1.
The issue of evaluating a when-expr as if there was a context
node inserted is a completely different issue than the order that
multiple when-stmts are evaluated. =A0Changing the context node
to the parent does not alter the evaluation order problem.
That's true, but it does make a difference whether you insert all the temporary context nodes at once or one by one.


To be honest -- it doesn't. =A0Setting all the context nodes to random<= br> values
It doesn't? So how do you proceed with inserting these dummy nodes in my recent dhcp/bootp example?


I would not allow that module to be published.
It would have to be rewritten so there was no dependency loop.
Each container can be in a separate module maintained by a different
party.
If I understand your concern this isn't possible, since you can't refer to nodes from other module w/o importing the other module, and
cirular imports are not allowed.
Yes, you are right, it is not possible in this form (but see below).

Alternatively, it can be intentionally crafted by an attacker.
?
Somebody can write a module that looks innocent and compiles properly but c= reates this when loop under some circumstances.

IMO it is up to YANG spec to make sure this is not allowed, and
compilers should do their best to eliminate it.
How can we state that there MUST NOT be any ciruclar references in
when expressions?
I proposed a formulation earlier:

"The XPath expression must not involve any node that is directly or in= directly conditional."

Checking it can be tricky, because the XPath expression may contain things = like count(../*) whose result depends on the presence or absence of the con= text node.

I don't think you need the actual result of the evaluation though. All = you need to know is what the expression is referencing; parent, self and si= blings of the context node in your case.


I think all the intermediate and final= node-set results of every
must/when expression in order to know = if any XPath expressions
access the same nodes.

Examining the schema tree instead of the value tree has some pro= blems,
but ignoring that for the moment, it would be possible to = detect that some
previous when-stmt accessed the same node as ano= ther when-stmt.

=A0
Is there an example for the A->B->C->A loop case?



Simple loop:
=
=A0 container foo {
=A0 =A0 =A0leaf A {
= =A0 =A0 =A0 =A0 when "../B =3D 10";
=A0 =A0 =A0 =A0 typ= e int32;
=A0 =A0 =A0}
=A0 =A0 =A0leaf B {
=A0 =A0 =A0 =A0 when "../C =3D= 10";
=A0 =A0 =A0 =A0 type int32;
=A0 =A0 =A0}
=A0 =A0 =A0leaf C {
=A0 =A0 =A0 =A0 when "= ../A !=3D 10";
=A0 =A0 =A0 =A0 type int32;
=A0 =A0 =A0}
=A0 }

There are = no real examples AFAIK.

Of course, it is more comp= licated. Nodes can inherit
multiple when-stmts, so even the order= that when-stmts are processed
for a single node can affect the ability to detect these loops.
<= div>(You stop at the first false when-stmt).

If th= ere are if-feature statements then it gets even more complicated.

It's fine to say when-stmt references MUST NOT crea= te circular references,
but I doubt compilers will detect these e= rrors very well.

=A0
Jernej

Andy

= =A0


I think XPath is too powerful for this purpose.

Lada


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




_______________________________________________
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

--001a1133c938ef780704f5843c8d-- From nobody Wed Mar 26 08:48:01 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B901A02D8 for ; Wed, 26 Mar 2014 08:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7EJSVle1Twp for ; Wed, 26 Mar 2014 08:47:57 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id 276E71A0348 for ; Wed, 26 Mar 2014 08:47:49 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id m20so2799291qcx.35 for ; Wed, 26 Mar 2014 08:47:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7AYEW33GLjyAZR1bNv0rMtpYxeozIQQsC1sjx9NO1wA=; b=U4zee495THzU3Ss+egHdsgd/2qYptTfPAyJaiYiNCc44Y7j9U64ly5vBOg7ssVZPc3 6rRdaaZ2ZwENX4pRXK7RAVdNplbnLM1EiAlvyY+zM+aR/Wh4hpduIQ91A/tqZx6lqCk8 oWR7ZxNmxmnxwpv3HJJfgE4Fdpcv9aTrX0sQWJI1D2n2Y5EywzzXoGXbWkKMMqKbPK5u nrP+FsvpDa7ylrUY+DLJQm9vyhv87bf6+oxmC1mFbvw5H1N1CkTM+RymQhi8vYBVMauC 49pT3/nXINAr7sKEPjzCfuS3iwV1CZhTKKuqOXdJq1v2bNExrskmAvy5mks219C5G4ol TT4g== X-Gm-Message-State: ALoCoQmi3/Nxt7b1hO66YsJOhYBTaDwkF/82tnWvnA8SMKwpMyX6/UuBdYJRyN/al3XO6t1bKmX8 MIME-Version: 1.0 X-Received: by 10.224.66.8 with SMTP id l8mr90386645qai.16.1395848867510; Wed, 26 Mar 2014 08:47:47 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Wed, 26 Mar 2014 08:47:47 -0700 (PDT) In-Reply-To: <20140326.161220.1907816882803386580.mbj@tail-f.com> References: <20140326.152737.330538996469661145.mbj@tail-f.com> <6F6EF691-5134-4243-B25D-96C54760741C@nic.cz> <20140326.161220.1907816882803386580.mbj@tail-f.com> Date: Wed, 26 Mar 2014 08:47:47 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c2c27ae88b2c04f58463b0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Qvv-FkrncFDx1-BGRpJhwNvn5vI Cc: "netmod@ietf.org" Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 15:48:00 -0000 --001a11c2c27ae88b2c04f58463b0 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 26, 2014 at 8:12 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > > > On 26 Mar 2014, at 15:43, Andy Bierman wrote: > > > > > > > > > > > > > > On Wed, Mar 26, 2014 at 7:27 AM, Martin Bjorklund > > > wrote: > > > Andy Bierman wrote: > > > > On Wed, Mar 26, 2014 at 7:10 AM, Ladislav Lhotka > > > > wrote: > > > > > > > > > > > > > > On 26 Mar 2014, at 14:57, Martin Bjorklund wrote: > > > > > > > > > > > Ladislav Lhotka wrote: > > > > > >> Martin Bjorklund writes: > > > > > >> > > > > > >>> Hi, > > > > > >>> > > > > > >>> Here's yet another attempt to handle attributes in JSON, > without > > > > > >>> changing the encoding for the case that there are no attributes > > > > > >>> present. > > > > > >>> > > > > > >>> In all examples, the attributes "inactive" and "etag" are > present. > > > > > >>> > > > > > >>> Attributes are encoded differently depending on the type of > object: > > > > > >>> > > > > > >>> > > > > > >>> leaf > > > > > >>> ---- > > > > > >>> > > > > > >>> Encode the attributes as a sibling to the leaf. > > > > > >>> > > > > > >>> > > > > > >>> leaf foo { > > > > > >>> type string; > > > > > >>> } > > > > > >>> > > > > > >>> "foo": "some value"; > > > > > >>> "@foo": { > > > > > >>> "inactive": true, > > > > > >>> "etag": "..."; > > > > > >>> } > > > > > >>> > > > > > >>> > > > > > >>> list instance > > > > > >>> ------------- > > > > > >>> > > > > > >>> Encode the attributes within the list instance. > > > > > >>> > > > > > >>> > > > > > >>> list bar { > > > > > >>> key name; > > > > > >>> leaf name { > > > > > >>> type string; > > > > > >>> } > > > > > >>> ... > > > > > >>> } > > > > > >>> > > > > > >>> "bar": [ > > > > > >>> { > > > > > >>> "@bar": { > > > > > >>> "inactive": true, > > > > > >>> "etag": "..." > > > > > >>> } > > > > > >>> "name": "instance name"; > > > > > >>> }] > > > > > >>> > > > > > >> > > > > > >> This could be ambiguous: > > > > > >> > > > > > >> list bar { > > > > > >> key name; > > > > > >> leaf name { ... } > > > > > >> leaf bar { ... } > > > > > >> } > > > > > >> > > > > > >> Then you don't know whether the attributes belong to the list > entry > > > > > >> or to the contained leaf. > > > > > > > > > > > > Right. Then we use "@@bar" for the list / container attributes. > > > > > > > > > > OK, then this scheme is fine with me. > > > > > > > > > > > > > > Looks more complicated than other solution proposals. > > > > > > Do we agree that we don't want different encodings for values if there > > > are attributes or not? I.e., if my code works when no attributes are > > > present, it should also work if there are attributes? > > > > I am not sure even your encoding satisfies this requirement. At least > > your code has to be instructed to ignore the attribute stuff. > > In general, I think robust code would ignore unknown fields. > > > > Not if the normal encoding is painful to use. > > > The use attributes is going to be rare. > > > I want the expected "plain" encoding when there are no attributes. > > > Code that generates JSON and does not care about attributes > > > must not be rendered useless because the JSON is specially encoded > > > in RESTCONF. We want to leverage wide knowledge of JSON, > > > not invent our own incompatible version of it. > > > > This is my preference, too. > > This is not a preference. It is critical that plain JSON code that knows how to deal with plain data structures does not break. Well, of course. But I don't think anyone has proposed something that > is not valid json. > > That is not the point. A normal JSON tool is going to generate or expect "foo":"bar" for a simple leaf, or "foo":[1, 2, 3] for a simple array, for example. The encoding for the data nodes MUST be exactly the same as the YANG-to-JSON draft now, if no attributes are used. Only a client that knows about attributes will need to associate an attribute with its parent data node. This must be easy to do. Other clients should be able to ignore attributes. A server must reject messages with unknown attributes. I agree that no proposal is satisfactory for leaf or leaf-list nodes. > > If so, do we have any other proposal? > > > > Leave it to proponents of every use case to figure out ad hoc how to > > encode what's needed, or resort to XML. > > Which for RESTCONF would mean use XML, IMO. > > I still think a common definition would be better. > > > /martin > Andy --001a11c2c27ae88b2c04f58463b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Mar 26, 2014 at 8:12 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On 26 Mar 2014, at 15:43, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Wed, Mar 26, 2014 at 7:27 AM, Martin Bjorklund <mbj@tail-f.com>
> > wrote:
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > On Wed, Mar 26, 2014 at 7:10 AM, Ladislav Lhotka <lhotka@nic.cz>
> > > wrote:
> > >
> > > >
> > > > On 26 Mar 2014, at 14:57, Martin Bjorklund <mbj@tail-f.com> wrote:
> > > >
> > > > > Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > > >> Martin Bjorklund <mbj@tail-f.com> writes:
> > > > >>
> > > > >>> Hi,
> > > > >>>
> > > > >>> Here's yet another attempt to handle a= ttributes in JSON, without
> > > > >>> changing the encoding for the case that th= ere are no attributes
> > > > >>> present.
> > > > >>>
> > > > >>> In all examples, the attributes "inac= tive" and "etag" are present.
> > > > >>>
> > > > >>> Attributes are encoded differently dependi= ng on the type of object:
> > > > >>>
> > > > >>>
> > > > >>> leaf
> > > > >>> ----
> > > > >>>
> > > > >>> Encode the attributes as a sibling to the = leaf.
> > > > >>>
> > > > >>>
> > > > >>>  leaf foo {
> > > > >>>    type string;
> > > > >>>  }
> > > > >>>
> > > > >>>  "foo": "some value&qu= ot;;
> > > > >>>  "@foo": {
> > > > >>>     "inactive": true,<= br> > > > > >>>     "etag": "...&= quot;;
> > > > >>>   }
> > > > >>>
> > > > >>>
> > > > >>> list instance
> > > > >>> -------------
> > > > >>>
> > > > >>> Encode the attributes within the list inst= ance.
> > > > >>>
> > > > >>>
> > > > >>>  list bar {
> > > > >>>    key name;
> > > > >>>    leaf name {
> > > > >>>      type string;
> > > > >>>    }
> > > > >>>    ...
> > > > >>>  }
> > > > >>>
> > > > >>>  "bar": [
> > > > >>>     {
> > > > >>>        "@bar"= ;: {
> > > > >>>           "i= nactive": true,
> > > > >>>           "e= tag": "..."
> > > > >>>         }
> > > > >>>         "name&quo= t;: "instance name";
> > > > >>>      }]
> > > > >>>
> > > > >>
> > > > >> This could be ambiguous:
> > > > >>
> > > > >> list bar {
> > > > >>  key name;
> > > > >>  leaf name { ... }
> > > > >>  leaf bar { ... }
> > > > >> }
> > > > >>
> > > > >> Then you don't know whether the attributes= belong to the list entry
> > > > >> or to the contained leaf.
> > > > >
> > > > > Right. Then we use "@@bar" for the list = / container attributes.
> > > >
> > > > OK, then this scheme is fine with me.
> > > >
> > > >
> > > Looks more complicated than other solution proposals.
> >
> > Do we agree that we don't want different encodings for values= if there
> > are attributes or not?  I.e., if my code works when no attri= butes are
> > present, it should also work if there are attributes?
>
> I am not sure even your encoding satisfies this requirement. At least<= br> > your code has to be instructed to ignore the attribute stuff.

In general, I think robust code would ignore unknown fields.

> > Not if the normal encoding is painful to use.
> > The use attributes is going to be rare.
> > I want the expected "plain" encoding when there are no = attributes.
> > Code that generates JSON and does not care about attributes
> > must not be rendered useless because the JSON is specially encode= d
> > in RESTCONF.  We want to leverage wide knowledge of JSON, > > not invent our own incompatible version of it.
>
> This is my preference, too.


This is not a preference. It is critic= al that plain JSON code
that knows how to deal with plain data st= ructures does not break.

Well, of course.  But I don't think anyone has proposed something = that
is not valid json.



That is not the point. =  A normal JSON tool is going to generate or expect
"foo= ":"bar" for a simple leaf, or "foo":[1, 2, 3] &nbs= p;for a simple array, for example.

The encoding for the data nodes MUST be exactly
the same as the YANG-to-JSON draft now, if no attributes are used.
=

Only a client that knows about attributes will need to = associate an attribute
with its parent data node.  This must be easy to do.
Ot= her clients should be able to ignore attributes.
A server must re= ject messages with unknown attributes.

I agree tha= t no proposal is satisfactory for leaf or leaf-list nodes.


> > If so, do we have any other proposal?
>
> Leave it to proponents of every use case to figure out ad hoc how to > encode what’s needed, or resort to XML.

Which for RESTCONF would mean use XML, IMO.

I still think a common definition would be better.


/martin


<= /div>
Andy

--001a11c2c27ae88b2c04f58463b0-- From nobody Wed Mar 26 08:51:19 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C521A02D8 for ; Wed, 26 Mar 2014 08:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKbTZrXAyMp9 for ; Wed, 26 Mar 2014 08:51:15 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5331A018F for ; Wed, 26 Mar 2014 08:51:15 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id AF9183940FD; Wed, 26 Mar 2014 16:51:13 +0100 (CET) Date: Wed, 26 Mar 2014 16:51:13 +0100 (CET) Message-Id: <20140326.165113.591253176749495826.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <6F6EF691-5134-4243-B25D-96C54760741C@nic.cz> <20140326.161220.1907816882803386580.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/XOZTIzONUlq2nnLGFYP1y0sQ2d0 Cc: netmod@ietf.org Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 15:51:18 -0000 Andy Bierman wrote: > On Wed, Mar 26, 2014 at 8:12 AM, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > > > > > > On 26 Mar 2014, at 15:43, Andy Bierman wrote: > > > > > > > > > > > > > > > > > > > On Wed, Mar 26, 2014 at 7:27 AM, Martin Bjorklund > > > > wrote: > > > > Andy Bierman wrote: > > > > > On Wed, Mar 26, 2014 at 7:10 AM, Ladislav Lhotka > > > > > wrote: > > > > > > > > > > > > > > > > > On 26 Mar 2014, at 14:57, Martin Bjorklund wrote: > > > > > > > > > > > > > Ladislav Lhotka wrote: > > > > > > >> Martin Bjorklund writes: > > > > > > >> > > > > > > >>> Hi, > > > > > > >>> > > > > > > >>> Here's yet another attempt to handle attributes in JSON, > > without > > > > > > >>> changing the encoding for the case that there are no attributes > > > > > > >>> present. > > > > > > >>> > > > > > > >>> In all examples, the attributes "inactive" and "etag" are > > present. > > > > > > >>> > > > > > > >>> Attributes are encoded differently depending on the type of > > object: > > > > > > >>> > > > > > > >>> > > > > > > >>> leaf > > > > > > >>> ---- > > > > > > >>> > > > > > > >>> Encode the attributes as a sibling to the leaf. > > > > > > >>> > > > > > > >>> > > > > > > >>> leaf foo { > > > > > > >>> type string; > > > > > > >>> } > > > > > > >>> > > > > > > >>> "foo": "some value"; > > > > > > >>> "@foo": { > > > > > > >>> "inactive": true, > > > > > > >>> "etag": "..."; > > > > > > >>> } > > > > > > >>> > > > > > > >>> > > > > > > >>> list instance > > > > > > >>> ------------- > > > > > > >>> > > > > > > >>> Encode the attributes within the list instance. > > > > > > >>> > > > > > > >>> > > > > > > >>> list bar { > > > > > > >>> key name; > > > > > > >>> leaf name { > > > > > > >>> type string; > > > > > > >>> } > > > > > > >>> ... > > > > > > >>> } > > > > > > >>> > > > > > > >>> "bar": [ > > > > > > >>> { > > > > > > >>> "@bar": { > > > > > > >>> "inactive": true, > > > > > > >>> "etag": "..." > > > > > > >>> } > > > > > > >>> "name": "instance name"; > > > > > > >>> }] > > > > > > >>> > > > > > > >> > > > > > > >> This could be ambiguous: > > > > > > >> > > > > > > >> list bar { > > > > > > >> key name; > > > > > > >> leaf name { ... } > > > > > > >> leaf bar { ... } > > > > > > >> } > > > > > > >> > > > > > > >> Then you don't know whether the attributes belong to the list > > entry > > > > > > >> or to the contained leaf. > > > > > > > > > > > > > > Right. Then we use "@@bar" for the list / container attributes. > > > > > > > > > > > > OK, then this scheme is fine with me. > > > > > > > > > > > > > > > > > Looks more complicated than other solution proposals. > > > > > > > > Do we agree that we don't want different encodings for values if there > > > > are attributes or not? I.e., if my code works when no attributes are > > > > present, it should also work if there are attributes? > > > > > > I am not sure even your encoding satisfies this requirement. At least > > > your code has to be instructed to ignore the attribute stuff. > > > > In general, I think robust code would ignore unknown fields. > > > > > > Not if the normal encoding is painful to use. > > > > The use attributes is going to be rare. > > > > I want the expected "plain" encoding when there are no attributes. > > > > Code that generates JSON and does not care about attributes > > > > must not be rendered useless because the JSON is specially encoded > > > > in RESTCONF. We want to leverage wide knowledge of JSON, > > > > not invent our own incompatible version of it. > > > > > > This is my preference, too. > > > > > This is not a preference. It is critical that plain JSON code > that knows how to deal with plain data structures does not break. > > Well, of course. But I don't think anyone has proposed something that > > is not valid json. > > > > > > That is not the point. A normal JSON tool is going to generate or expect > "foo":"bar" for a simple leaf, or "foo":[1, 2, 3] for a simple array, for > example. > > The encoding for the data nodes MUST be exactly > the same as the YANG-to-JSON draft now, if no attributes are used. This is exactly my point! > Only a client that knows about attributes will need to associate an > attribute > with its parent data node. Yes! > This must be easy to do. As easy as possible. IMO this falls into the category of "possible to do". The normal case must be easy to do. > Other clients should be able to ignore attributes. Yes! > A server must reject messages with unknown attributes. > > I agree that no proposal is satisfactory for leaf or leaf-list nodes. My proposal satifies all these properties, except "easy to do attributes". /martin From nobody Wed Mar 26 09:06:16 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1261A017D for ; Wed, 26 Mar 2014 09:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTfcSMbHoQxr for ; Wed, 26 Mar 2014 09:06:07 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id 89B951A00E3 for ; Wed, 26 Mar 2014 09:06:07 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id e9so2833721qcy.12 for ; Wed, 26 Mar 2014 09:06:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=76wsjWorhDsZjUxXXcwD+cfOchWy7St9AovznXNbdBg=; b=Biifu+bSvla3DzpMzWc1BHsfrtai0+H6LKG/rZM9oTfrsg2BSuvmRnaFZBYM4lIWNZ 6YZccOxZi5FHduCrMlxxBxImBTz/h10ZKq8aE3mi/ZDguG7NtcFnYeoyuP7s4NbLp52e 9jrp36zzZLFZyDDzTo5qHdSFVoIEgJR3eHVlRubboEzWcyWMWslIo+2t3O57ZowmT6Qc kWKpnd+Upxvs66aE+NrIp0gFpPwFgEbqv6UpoQAlPTCa+N9B6X8kGZim6tOkv/xfAjfY V6BelPs6iPWkXI6i6EGJ7T4QapFFbEelk8K/TGBJ0wt4WCxZ1OPLjr+YPdv9fxXA1yXI QJtA== X-Gm-Message-State: ALoCoQlENIYrNuaj5IZa2/2n4nFh9d+ZsGmYoC0UsWoFBK6CNuTxGMODneMRVz68Y/oAv8IcDfrv MIME-Version: 1.0 X-Received: by 10.140.27.193 with SMTP id 59mr85586809qgx.18.1395849965670; Wed, 26 Mar 2014 09:06:05 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Wed, 26 Mar 2014 09:06:05 -0700 (PDT) In-Reply-To: <20140326.165113.591253176749495826.mbj@tail-f.com> References: <6F6EF691-5134-4243-B25D-96C54760741C@nic.cz> <20140326.161220.1907816882803386580.mbj@tail-f.com> <20140326.165113.591253176749495826.mbj@tail-f.com> Date: Wed, 26 Mar 2014 09:06:05 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c1233a5d27db04f584a5d4 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1D1ZbM9i1s_LOdzsc-cWVubNaNU Cc: "netmod@ietf.org" Subject: Re: [netmod] attributes in draft-lhotka-netmod-yang-json X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 16:06:11 -0000 --001a11c1233a5d27db04f584a5d4 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 26, 2014 at 8:51 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Wed, Mar 26, 2014 at 8:12 AM, Martin Bjorklund > wrote: > > > > > Ladislav Lhotka wrote: > > > > > > > > On 26 Mar 2014, at 15:43, Andy Bierman wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 26, 2014 at 7:27 AM, Martin Bjorklund > > > > > wrote: > > > > > Andy Bierman wrote: > > > > > > On Wed, Mar 26, 2014 at 7:10 AM, Ladislav Lhotka > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On 26 Mar 2014, at 14:57, Martin Bjorklund > wrote: > > > > > > > > > > > > > > > Ladislav Lhotka wrote: > > > > > > > >> Martin Bjorklund writes: > > > > > > > >> > > > > > > > >>> Hi, > > > > > > > >>> > > > > > > > >>> Here's yet another attempt to handle attributes in JSON, > > > without > > > > > > > >>> changing the encoding for the case that there are no > attributes > > > > > > > >>> present. > > > > > > > >>> > > > > > > > >>> In all examples, the attributes "inactive" and "etag" are > > > present. > > > > > > > >>> > > > > > > > >>> Attributes are encoded differently depending on the type of > > > object: > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> leaf > > > > > > > >>> ---- > > > > > > > >>> > > > > > > > >>> Encode the attributes as a sibling to the leaf. > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> leaf foo { > > > > > > > >>> type string; > > > > > > > >>> } > > > > > > > >>> > > > > > > > >>> "foo": "some value"; > > > > > > > >>> "@foo": { > > > > > > > >>> "inactive": true, > > > > > > > >>> "etag": "..."; > > > > > > > >>> } > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> list instance > > > > > > > >>> ------------- > > > > > > > >>> > > > > > > > >>> Encode the attributes within the list instance. > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> list bar { > > > > > > > >>> key name; > > > > > > > >>> leaf name { > > > > > > > >>> type string; > > > > > > > >>> } > > > > > > > >>> ... > > > > > > > >>> } > > > > > > > >>> > > > > > > > >>> "bar": [ > > > > > > > >>> { > > > > > > > >>> "@bar": { > > > > > > > >>> "inactive": true, > > > > > > > >>> "etag": "..." > > > > > > > >>> } > > > > > > > >>> "name": "instance name"; > > > > > > > >>> }] > > > > > > > >>> > > > > > > > >> > > > > > > > >> This could be ambiguous: > > > > > > > >> > > > > > > > >> list bar { > > > > > > > >> key name; > > > > > > > >> leaf name { ... } > > > > > > > >> leaf bar { ... } > > > > > > > >> } > > > > > > > >> > > > > > > > >> Then you don't know whether the attributes belong to the > list > > > entry > > > > > > > >> or to the contained leaf. > > > > > > > > > > > > > > > > Right. Then we use "@@bar" for the list / container > attributes. > > > > > > > > > > > > > > OK, then this scheme is fine with me. > > > > > > > > > > > > > > > > > > > > Looks more complicated than other solution proposals. > > > > > > > > > > Do we agree that we don't want different encodings for values if > there > > > > > are attributes or not? I.e., if my code works when no attributes > are > > > > > present, it should also work if there are attributes? > > > > > > > > I am not sure even your encoding satisfies this requirement. At least > > > > your code has to be instructed to ignore the attribute stuff. > > > > > > In general, I think robust code would ignore unknown fields. > > > > > > > > Not if the normal encoding is painful to use. > > > > > The use attributes is going to be rare. > > > > > I want the expected "plain" encoding when there are no attributes. > > > > > Code that generates JSON and does not care about attributes > > > > > must not be rendered useless because the JSON is specially encoded > > > > > in RESTCONF. We want to leverage wide knowledge of JSON, > > > > > not invent our own incompatible version of it. > > > > > > > > This is my preference, too. > > > > > > > > This is not a preference. It is critical that plain JSON code > > that knows how to deal with plain data structures does not break. > > > > Well, of course. But I don't think anyone has proposed something that > > > is not valid json. > > > > > > > > > > That is not the point. A normal JSON tool is going to generate or expect > > "foo":"bar" for a simple leaf, or "foo":[1, 2, 3] for a simple array, > for > > example. > > > > The encoding for the data nodes MUST be exactly > > the same as the YANG-to-JSON draft now, if no attributes are used. > > This is exactly my point! > > > Only a client that knows about attributes will need to associate an > > attribute > > with its parent data node. > > Yes! > > > This must be easy to do. > > As easy as possible. IMO this falls into the category of "possible to > do". The normal case must be easy to do. > > > Other clients should be able to ignore attributes. > > Yes! > > > A server must reject messages with unknown attributes. > > > > I agree that no proposal is satisfactory for leaf or leaf-list nodes. > > My proposal satifies all these properties, except "easy to do > attributes". > > Yes -- there are corner cases to detect (like array given for @foo, but foo is a leaf). The most annoying part is parsing @foo first, and holding onto the data until foo is found (if it exists - another error to detect is @foo but no foo). I guess this is OK. NACM does not provide any control over access to attributes, which is good. We cannot have NACM filter out a leaf-list value but not filter out the attributes for the associated leaf-list instance. > > /martin > Andy --001a11c1233a5d27db04f584a5d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Mar 26, 2014 at 8:51 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Wed, Mar 26, 2014 at 8:12 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Ladislav Lhotka <lhotka@nic.c= z> wrote:
> > >
> > > On 26 Mar 2014, at 15:43, Andy Bierman <andy@yumaworks.com> wrote:
> > >
> > > >
> > > >
> > > >
> > > > On Wed, Mar 26, 2014 at 7:27 AM, Martin Bjorklund <<= a href=3D"mailto:mbj@tail-f.com">mbj@tail-f.com>
> > > > wrote:
> > > > Andy Bierman <= andy@yumaworks.com> wrote:
> > > > > On Wed, Mar 26, 2014 at 7:10 AM, Ladislav Lhotka &= lt;lhotka@nic.cz>
> > > > > wrote:
> > > > >
> > > > > >
> > > > > > On 26 Mar 2014, at 14:57, Martin Bjorklund &l= t;mbj@tail-f.com> wrote:
> > > > > >
> > > > > > > Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > > > > >> Martin Bjorklund <mbj@tail-f.com> writes:
> > > > > > >>
> > > > > > >>> Hi,
> > > > > > >>>
> > > > > > >>> Here's yet another attempt t= o handle attributes in JSON,
> > without
> > > > > > >>> changing the encoding for the ca= se that there are no attributes
> > > > > > >>> present.
> > > > > > >>>
> > > > > > >>> In all examples, the attributes = "inactive" and "etag" are
> > present.
> > > > > > >>>
> > > > > > >>> Attributes are encoded different= ly depending on the type of
> > object:
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> leaf
> > > > > > >>> ----
> > > > > > >>>
> > > > > > >>> Encode the attributes as a sibli= ng to the leaf.
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> =A0leaf foo {
> > > > > > >>> =A0 =A0type string;
> > > > > > >>> =A0}
> > > > > > >>>
> > > > > > >>> =A0"foo": "some v= alue";
> > > > > > >>> =A0"@foo": {
> > > > > > >>> =A0 =A0 "inactive": tr= ue,
> > > > > > >>> =A0 =A0 "etag": "= ...";
> > > > > > >>> =A0 }
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> list instance
> > > > > > >>> -------------
> > > > > > >>>
> > > > > > >>> Encode the attributes within the= list instance.
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> =A0list bar {
> > > > > > >>> =A0 =A0key name;
> > > > > > >>> =A0 =A0leaf name {
> > > > > > >>> =A0 =A0 =A0type string;
> > > > > > >>> =A0 =A0}
> > > > > > >>> =A0 =A0...
> > > > > > >>> =A0}
> > > > > > >>>
> > > > > > >>> =A0"bar": [
> > > > > > >>> =A0 =A0 {
> > > > > > >>> =A0 =A0 =A0 =A0"@bar":= {
> > > > > > >>> =A0 =A0 =A0 =A0 =A0 "inacti= ve": true,
> > > > > > >>> =A0 =A0 =A0 =A0 =A0 "etag&q= uot;: "..."
> > > > > > >>> =A0 =A0 =A0 =A0 }
> > > > > > >>> =A0 =A0 =A0 =A0 "name"= : "instance name";
> > > > > > >>> =A0 =A0 =A0}]
> > > > > > >>>
> > > > > > >>
> > > > > > >> This could be ambiguous:
> > > > > > >>
> > > > > > >> list bar {
> > > > > > >> =A0key name;
> > > > > > >> =A0leaf name { ... }
> > > > > > >> =A0leaf bar { ... }
> > > > > > >> }
> > > > > > >>
> > > > > > >> Then you don't know whether the = attributes belong to the list
> > entry
> > > > > > >> or to the contained leaf.
> > > > > > >
> > > > > > > Right. Then we use "@@bar" for= the list / container attributes.
> > > > > >
> > > > > > OK, then this scheme is fine with me.
> > > > > >
> > > > > >
> > > > > Looks more complicated than other solution proposa= ls.
> > > >
> > > > Do we agree that we don't want different encodings = for values if there
> > > > are attributes or not? =A0I.e., if my code works when n= o attributes are
> > > > present, it should also work if there are attributes? > > >
> > > I am not sure even your encoding satisfies this requirement.= At least
> > > your code has to be instructed to ignore the attribute stuff= .
> >
> > In general, I think robust code would ignore unknown fields.
> >
> > > > Not if the normal encoding is painful to use.
> > > > The use attributes is going to be rare.
> > > > I want the expected "plain" encoding when the= re are no attributes.
> > > > Code that generates JSON and does not care about attrib= utes
> > > > must not be rendered useless because the JSON is specia= lly encoded
> > > > in RESTCONF. =A0We want to leverage wide knowledge of J= SON,
> > > > not invent our own incompatible version of it.
> > >
> > > This is my preference, too.
> >
> >
> This is not a preference. It is critical that plain JSON code
> that knows how to deal with plain data structures does not break.
>
> Well, of course. =A0But I don't think anyone has proposed somethin= g that
> > is not valid json.
> >
> >
>
> That is not the point. =A0A normal JSON tool is going to generate or e= xpect
> "foo":"bar" for a simple leaf, or "foo":= [1, 2, 3] =A0for a simple array, for
> example.
>
> The encoding for the data nodes MUST be exactly
> the same as the YANG-to-JSON draft now, if no attributes are used.

This is exactly my point!

> Only a client that knows about attributes will need to associate an > attribute
> with its parent data node.

Yes!

> This must be easy to do.

As easy as possible. =A0IMO this falls into the category of "possible = to
do". =A0The normal case must be easy to do.

> Other clients should be able to ignore attributes.

Yes!

> A server must reject messages with unknown attributes.
>
> I agree that no proposal is satisfactory for leaf or leaf-list nodes.<= br>
My proposal satifies all these properties, except "easy to do
attributes".


Yes -- there are corner cases to detect (like array = given for @foo,
but foo is a leaf). =A0The most annoying part is = parsing @foo first,
and holding onto the data until foo is found (if it exists - another e= rror
to detect is @foo but no foo).

I gu= ess this is OK.
NACM does not provide any control over access to = attributes,
which is good. =A0We cannot have NACM filter out a leaf-list value
but not filter out the attributes for the associated leaf-list insta= nce.




/martin

Andy<= /div>

--001a11c1233a5d27db04f584a5d4-- From nobody Wed Mar 26 13:53:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49B61A03C6 for ; Wed, 26 Mar 2014 13:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RO7ZmM7NCbhD for ; Wed, 26 Mar 2014 13:53:31 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 89DD11A01F7 for ; Wed, 26 Mar 2014 13:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11742; q=dns/txt; s=iport; t=1395867210; x=1397076810; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2N4AprKdqN0KPE6d84mWLpCWvGyN+95d8WojsjqaBXQ=; b=RRc/EiCyf1O09u2hlo2q3YJDrRyN5zGEi0D4fzzgqfAYcjxO+gvpbkKi cPKUg3zmlF4Dt/4+rcrzg/HI3ws3ibHxbkHS80cR3z0iAnBfeUbwh4JQK yPwMr8+hHai1tq5dryj5Z0GhqIpr2KV/eMYv4ZkSN2EIlhS99PXmENu2W k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQFAHQ9M1OtJXHB/2dsb2JhbABZgwY7UQaDC7gzhmRRGYEFFnSCJQEBAQQBAQEgETcDCxACAQgYAgImAgICJQsVEAIEAQ0FCYdwCAWubqJNF4EpjRUzB4JvgUkEmE2BM5EAgy6CKw X-IronPort-AV: E=Sophos;i="4.97,737,1389744000"; d="scan'208";a="313112481" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 26 Mar 2014 20:53:29 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2QKrTdK003826 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Mar 2014 20:53:29 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.37]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Wed, 26 Mar 2014 15:53:29 -0500 From: "Yi Yang (yiya)" To: Ladislav Lhotka , "Derek Man-Kit Yeung (myeung)" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt Thread-Index: AQHPDgglsV7ZhSMgp02l6cqKlZJTf5rW54cAgAAKUQCACr4yAIAABNeAgAZ/kACAAJNSgIAKXeIAgAD/3wCAADoPAA== Date: Wed, 26 Mar 2014 20:53:28 +0000 Message-ID: References: <20140110133016.24678.42711.idtracker@ietfa.amsl.com> <9C81158E-5B4C-4479-AEA5-23CBCC020ADD@nic.cz> <0ED855DA-51BE-4DE6-AB22-E1A9E04C0E5F@nic.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [64.102.95.103] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/axSkvk91k264h6IK06blVGioyaM Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 20:53:36 -0000 SGkgTGFkYSwNCg0KQWhhLiBTbyB3aGVuIG11bHRpcGxlLXJpYnMgaXMgbm90IHN1cHBvcnRlZCwg dGhlIGRlZmF1bHQtcmlicyBvbmx5IGV4aXN0DQppbiB0aGUgb3BlcmF0aW9uYWwgYnV0IG5vdCBp biBjb25maWd1cmF0aW9uLg0KDQpCdXQgaW4gdGhhdCBjYXNlLCBzaG91bGQgd2Ugc3RpbGwgYWxs b3cgdXNlcnMgdG8gY29uZmlndXJlIHRoZQ0KY29ycmVzcG9uZGluZyByaWIgZW50cnkgaW4gdGhl IHJpYnM/DQoNCllpDQoNCk9uIDMvMjYvMTQgOToyNSBBTSwgIkxhZGlzbGF2IExob3RrYSIgPGxo b3RrYUBuaWMuY3o+IHdyb3RlOg0KDQo+SGkgWWksDQo+DQo+IllpIFlhbmcgKHlpeWEpIiA8eWl5 YUBjaXNjby5jb20+IHdyaXRlczoNCj4NCj4+IEhpIExhZGEsDQo+Pg0KPj4gSW4gdGhlIGN1cnJl bnQgbW9kZWwsIGRlZmF1bHQtcmlicyB3aWxsIGV4aXN0IG9ubHkgd2hlbiBmZWF0dXJlDQo+PiBt dWx0aXBsZS1yaWJzIGV4aXN0cy4gVGhpcyBpcyBjb250cmFkaWN0b3J5IHRvIHdoYXQgcGVvcGxl IGFyZSBmYW1pbGlhcg0KPj5pbg0KPj4gdGhlIHJlYWwgd29ybGQgZGVwbG95bWVudCAgLS0gZGVm YXVsdC1yaWJzIGFsd2F5cyBleGlzdC4NCj4NCj5Ob3RlIHRoYXQgZGVmYXVsdC1yaWJzIGRlcGVu ZHMgb24gdGhhdCBmZWF0dXJlIG9ubHkgaW4gY29uZmlndXJhdGlvbiBidXQNCj5ub3QgaW4gb3Bl cmF0aW9uYWwgc3RhdGUgZGF0YS4gU28sIHRoZSBpZGVhIGlzIHRoYXQgdGhlIHN5c3RlbSBwdXRz IHRoZQ0KPm5hbWUocykgb2YgZGVmYXVsdCBSSUIocykgaW50byB0aGUgZGVmYXVsdC1yaWIgbGlz dCBpbiBvcGVyYXRpb25hbCBzdGF0ZSwNCj5zbyB0aGUgY2xpZW50IGlzIGFibGUgdG8gbGVhcm4g ZWFzaWx5IHdoYXQgdGhlIGRlZmF1bHQgKGFuZCBvbmx5KSBSSUIgaXMNCj5mb3IgZWFjaCBhZGRy ZXNzIGZhbWlseS4gQnV0IHdoZW5ldmVyIHRoZSBzZXJ2ZXIgZG9lc24ndCBzdXBwb3J0IG11bHRp cGxlDQo+UklCcyBwZXIgYWRkcmVzcyBmYW1pbHksIHRoZXJlIGlzIG5vIHBvaW50IHRvIGhhdmUg ZGVmYXVsdC1yaWJzIGFzIGENCj5jb25maWd1cmF0aW9uIG9wdGlvbi4NCj4NCj5Eb2VzIGl0IG1h a2Ugc2Vuc2U/DQo+DQo+VGhhbmtzLCBMYWRhDQo+DQo+Pg0KPj4gVG8gcmVmbGVjdCBzdWNoIGFu IGV4cGVjdGF0aW9uLCBJIHN1Z2dlc3QgdG8ga2VlcCBkZWZhdWx0LXJpYnMNCj4+IHVuY29uZGl0 aW9uYWxseS4gSW5zdGVhZCwgbW92ZSB0aGUgY29uZGl0aW9ucyB0byB0aGUgcmlicyAtLSBpZiBm ZWF0dXJlDQo+PiBtdWx0aXBsZS1yaWJzIGRvZXNuJ3QgZXhpc3QsIG9ubHkgb25lIHJpYiBpcyBh bGxvd2VkIHBlciBhZGRyZXNzIGZhbWlseS4NCj4+DQo+PiBZaQ0KPj4NCj4+DQo+PiBPbiAzLzE5 LzE0IDM6NTEgQU0sICJMYWRpc2xhdiBMaG90a2EiIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4+ DQo+Pj4iRGVyZWsgTWFuLUtpdCBZZXVuZyAobXlldW5nKSIgPG15ZXVuZ0BjaXNjby5jb20+IHdy aXRlczoNCj4+Pg0KPj4+PiBPbiAzLzE0LzE0IDEyOjQ5IFBNLCAiTGFkaXNsYXYgTGhvdGthIiA8 bGhvdGthQG5pYy5jej4gd3JvdGU6DQo+Pj4+DQo+Pj4+Pg0KPj4+Pj5PbiAxNCBNYXIgMjAxNCwg YXQgMjA6MzIsIERlcmVrIE1hbi1LaXQgWWV1bmcgKG15ZXVuZykNCj4+Pj4+PG15ZXVuZ0BjaXNj by5jb20+DQo+Pj4+Pndyb3RlOg0KPj4+Pj4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBPbiAz LzcvMTQgMjoyOSBQTSwgIkxhZGlzbGF2IExob3RrYSIgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0K Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gT24gMDcgTWFyIDIwMTQsIGF0IDIyOjUyLCBZaSBZ YW5nICh5aXlhKSA8eWl5YUBjaXNjby5jb20+IHdyb3RlOg0KPj4+Pj4+PiANCj4+Pj4+Pj4+IE9u ZSB0aGluZyBpcyBtaXNzaW5nIGZyb20gdGhlIGRhdGEgbW9kZWwgaXMgYXNzb2NpYXRpb24gd2l0 aCB2cmYuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBJIGFncmVlIHdpdGggd2hhdCBNYXJ0aW4gd3JvdGUg aW4gYSBwYXJhbGxlbCB0aHJlYWQuIEkgYmVsaWV2ZSB0aGUNCj4+Pj4+Pj4gcm91dGluZyBtb2R1 bGUgKGFuZCBZQU5HIGF1Z21lbnQgc3RhdGVtZW50KSBwcm92aWRlIHN1ZmZpY2llbnQNCj4+Pj4+ Pj5ob29rcw0KPj4+Pj4+PmZvcg0KPj4+Pj4+PiBpbXBsZW1lbnRpbmcgVlJGIGFzIGEgc3BlY2lm aWMgdHlwZSBvZiByb3V0aW5nLWluc3RhbmNlLg0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IFRo ZSBkcmFmdCBtZW50aW9uZWQgdGhlIHJvdXRpbmctaW5zdGFuY2UgY291bGQgYmUgdXNlZCB0bw0K Pj4+Pj4+cmVwcmVzZW50cyBhDQo+Pj4+Pj4gbG9naWNhbCByb3V0ZXIuDQo+Pj4+Pj4gDQo+Pj4+ Pj4gVGhlIHRlcm0gImxvZ2ljYWwgcm91dGVyIiBpbiBvbmUgb3IgbW9yZSB2ZW5kb3JzIG1lYW4g YSBwYXJ0aXRpb24gb2YNCj4+Pj4+PnRoZQ0KPj4+Pj4+IHBoeXNpY2FsIHJvdXRlciBpbnRvIG11 bHRpcGxlIGxvZ2ljYWwgdW5pdHMsIGVhY2ggY291bGQgaGF2ZQ0KPj4+Pj4+bXVsdGlwbGUNCj4+ Pj4+PlZSRnMuDQo+Pj4+Pj4gDQo+Pj4+Pj4gRG9lcyB0aGUgZHJhZnQgaW50ZW5kIHRvIG1hbmFn ZSAibG9naWNhbCByb3V0ZXIiIGluIHRoZSBhYm92ZQ0KPj4+Pj4+ZGVmaW5pdGlvbj8NCj4+Pj4+ PiBTb21lIGNsYXJpZmljYXRpb24gd2lsbCBiZSB1c2VmdWwuDQo+Pj4+Pg0KPj4+Pj5PbmUgd2F5 IHRvIGltcGxlbWVudCB0aGlzIGlzIHRvIGludHJvZHVjZSB0d28gdHlwZXMgb2Ygcm91dGluZw0K Pj4+Pj5pbnN0YW5jZXMsDQo+Pj4+PnNheSAnbG9naWNhbC1yb3V0ZXLCuSBhbmQgxZJ2cmbCuS4g VGhlIMWSdnJmwrkgdHlwZSB0aGVuIHdvdWxkIGhhdmUgYW5vdGhlcg0KPj4+Pj5sZWFmIGxpbmtp bmcgaXQgdG8gYSBsb2dpY2FsIHJvdXRlci4gVGhpcyBpcyBxdWl0ZSBsaWtlIHRoZSB2YXJpb3Vz DQo+Pj4+Pm1ldGhvZHMgb2YgaW50ZXJmYWNlIHN0YWNraW5nLCBzZWUgdGhlIGV4YW1wbGVzIGlu DQo+Pj4+PmRyYWZ0LWlldGYtbmV0bW9kLWludGVyZmFjZXMtY2ZnLTE2Lg0KPj4+Pj4NCj4+Pj4+ TGFkYQ0KPj4+Pg0KPj4+Pg0KPj4+PiBJdCBpcyBvbmUgd2F5Lg0KPj4+PiBIb3dldmVyLCBnaXZl biB0aGF0IGN1cnJlbnQgbW9kZWwgdGhhdCBldmVyeXRoaW5nIGlzIHB1dCBpbnNpZGUgYQ0KPj4+ PiByb3V0aW5nLWluc3RhbmNlLCB0aGluZ3MgbGlrZSBSSUIsIHJvdXRpbmctcHJvdG9jb2xzIGV0 YyBhcmUgbm8gbG9uZ2VyDQo+Pj4+IG5lZWRlZCBkaXJlY3RseSB1bmRlciB0aGUgJ2xvZ2ljYWwt cm91dGVyJy4NCj4+Pg0KPj4+Tm90ZSB0aGF0IFJJQnMgYXJlIG5vdCBpbnNpZGUgInJvdXRpbmct aW5zdGFuY2UiLCBhbHRob3VnaCBhbg0KPj4+aW1wbGVtZW50YXRpb24gbWF5IGRlZmluZSBzb21l IFJJQnMgdG8gYmUgcm91dGluZy1pbnN0YW5jZS1zcGVjaWZpYy4NCj4+Pg0KPj4+PiBXaGF0IG5l ZWRlZCBpbiB0aGUgJ2xvZ2ljYWwgcm91dGVyJyBhcmUgcmVzb3VyY2VzIGFsbG9jYXRpb24gbGlr ZQ0KPj4+PiBpbnRlcmZhY2VzLCBDUFUgZXRjLg0KPj4+DQo+Pj4iaW50ZXJmYWNlcyIgaXMgYSBj b250YWluZXIgaW5zaWRlICJyb3V0aW5nLWluc3RhbmNlIiwgYW5kICJjcHUiIGNhbiBiZQ0KPj4+ ZWFzaWx5IGFkZGVkIGJ5IGFub3RoZXIgbW9kdWxlIHZpYSBhdWdtZW50YXRpb24uDQo+Pj4NCj4+ Pj4gVGhvdWdoIHJvdXRpbmctaW5zdGFuY2UgY291bGQgYmUgYXVnbWVudGVkIHRvIGluY2x1ZGUg J2xvZ2ljYWwgcm91dGVyJw0KPj4+PiBzcGVjaWZpYyBmaWVsZCBhbmQgYWRkIG5ldyBjb25kaXRp b24gdG8gcmVzdHJpY3QgZXhpc3RpbmcgbGVhZiB0aGF0IG5vDQo+Pj4+IGxvbmcgYXBwbHksIEkg dGhpbmsgYSBuZXcgY29udGFpbmVyIGFib3ZlIHJvdXRpbmctaW5zdGFuY2UgaXMgY2xlYW5lci4N Cj4+Pj5JdA0KPj4+PiBjb3VsZCBiZSBhIG5ldyBkYXRhIG1vZGVsIHRoYXQgcmVmZXJlbmNlIHRo ZSBkZWZpbml0aW9uIGluIHRoZSBjdXJyZW50DQo+Pj4+IGRyYWZ0Lg0KPj4+DQo+Pj5JIGd1ZXNz IHBhcnQgb2YgdGhlIGNvbmZ1c2lvbiBzdGVtcyBmcm9tIHRoZSBuYW1lICJyb3V0aW5nLWluc3Rh bmNlIg0KPj4+d2hpY2ggYWxyZWFkeSBtZWFucyBhIHBhcnRpY3VsYXIgKHBsYXRmb3JtLXNwZWNp ZmljKSBzdHlsZSBvZiByb3V0ZXINCj4+PnZpcnR1YWxpemF0aW9uLiBFYXJsaWVyIHJldmlzaW9u cyBvZiB0aGUgZHJhZnQgdXNlZCAicm91dGVyIiBsaXN0IGluDQo+Pj50aGlzDQo+Pj5wbGFjZSBi dXQgaXQgd2FzIGFuIHNwZWNpZmljIHJlcXVpcmVtZW50IG9mIEkyUlMgZm9sa3MgdG8gY2hhbmdl IHRoaXMNCj4+Pm5hbWUgdG8gInJvdXRpbmctaW5zdGFuY2UiLiBPaCB3ZWxsIC4uLg0KPj4+DQo+ Pj5TbyBwbGVhc2Uga2VlcCBpbiBtaW5kIHRoYXQgInJvdXRpbmctaW5zdGFuY2UiIGNhbiByZWFs bHkgbWVhbiBkaWZmZXJlbnQNCj4+PnRoaW5ncyBkZXBlbmRpbmcgb24gaXRzIHR5cGUgKGFuZCBj YW4gYmUgYXVnbWVudGVkIGluIGRpZmZlcmVudCB3YXlzDQo+Pj5kZXBlbmRpbmcgb24gdGhlIHR5 cGUpLiBBZ2FpbiwgdGhpcyBhcHByb2FjaCBpcyB2ZXJ5IHNpbWlsYXIgdG8gdGhlIG9uZQ0KPj4+ YWRvcHRlZCBmb3IgdGhlICJpbnRlcmZhY2UiIGxpc3QgaW4gImlldGYtaW50ZXJmYWNlcyIgbW9k dWxlLg0KPj4+DQo+Pj5MYWRhDQo+Pj4NCj4+Pj4NCj4+Pj4gLSBEZXJlaw0KPj4+Pg0KPj4+Pj4N Cj4+Pj4+PiANCj4+Pj4+PiAtIERlcmVrDQo+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBJIHRo aW5rIHRob3VnaCB0aGF0IG90aGVyIHdvcmsgZXh0ZW5kaW5nIHRoZSByb3V0aW5nIG1vZHVsZSBp cyBtdWNoDQo+Pj4+Pj4+bW9yZQ0KPj4+Pj4+PiBuZWVkZWQsIG5hbWVseSB2ZW5kb3ItbmV1dHJh bCBkYXRhIG1vZGVscyBmb3Igcm91dGluZyBwcm90b2NvbHMuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBU aGUgY29uc2Vuc3VzIG9mIHRoZSBORVRNT0QgV0cgd2FzIHRoYXQgdGhlc2UgbmV3IG1vZHVsZXMg c2hvdWxkIGJlDQo+Pj4+Pj4+IGRldmVsb3BlZCBieSBleHBlcnRzIGluIHRoZSBSb3V0aW5nIEFy ZWEgKFZSRiBpbiB0aGUgTVBMUyBXRz8pLiBUaGUNCj4+Pj4+Pj4gTkVUTU9EIFdHIGFuZCBZQU5H IERvY3RvcnMgd2lsbCBjZXJ0YWlubHkgaGVscCBidXQgdGhlIGJ1bGsgb2YgdGhpcw0KPj4+Pj4+ PndvcmsNCj4+Pj4+Pj4gc2hvdWxkIGJlIGRvbmUgYnkgZG9tYWluIGV4cGVydHMuDQo+Pj4+Pj4+ IA0KPj4+Pj4+PiBMYWRhDQo+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBBbm90aGVyIGNv bmNlcm4gSSBoYXZlIGlzIGFib3V0IGFkZHJlc3MgZmFtaWx5LiBUbyBmYWNpbGl0YXRlIGENCj4+ Pj4+Pj4+cXVlcnkNCj4+Pj4+Pj4+IGJhc2VkIG9uIEFGSSBvbmx5LCBvciBTQUZJIG9ubHksIGl0 IHNlZW1zIG1vcmUgY29udmVuaWVudCB0byB1c2UNCj4+Pj4+Pj4+dHdvDQo+Pj4+Pj4+PiBsZWFm cw0KPj4+Pj4+Pj4gKEFGSSBhbmQgU0FGSSkgaW5zdGVhZCBvZiBvbmUgKEFGSS1TQUZJKS4NCj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4gWWkNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4gT24gMS8xMC8xNCA4OjMwIEFNLCAiaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIg0KPj4+Pj4+Pj4gPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCj4+Pj4+Pj4+IHdy b3RlOg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gQSBOZXcgSW50ZXJuZXQtRHJh ZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUNCj4+Pj4+Pj4+PkludGVybmV0LURyYWZ0 cw0KPj4+Pj4+Pj4+IGRpcmVjdG9yaWVzLg0KPj4+Pj4+Pj4+IFRoaXMgZHJhZnQgaXMgYSB3b3Jr IGl0ZW0gb2YgdGhlIE5FVENPTkYgRGF0YSBNb2RlbGluZyBMYW5ndWFnZQ0KPj4+Pj4+Pj4+V29y a2luZw0KPj4+Pj4+Pj4+IEdyb3VwIG9mIHRoZSBJRVRGLg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+ ICAgICAgVGl0bGUgICAgICAgICAgIDogQSBZQU5HIERhdGEgTW9kZWwgZm9yIFJvdXRpbmcgTWFu YWdlbWVudA0KPj4+Pj4+Pj4+ICAgICAgQXV0aG9yICAgICAgICAgIDogTGFkaXNsYXYgTGhvdGth DQo+Pj4+Pj4+Pj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtbmV0bW9kLXJvdXRpbmct Y2ZnLTEzLnR4dA0KPj4+Pj4+Pj4+IAlQYWdlcyAgICAgICAgICAgOiA5NQ0KPj4+Pj4+Pj4+IAlE YXRlICAgICAgICAgICAgOiAyMDE0LTAxLTEwDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gQWJzdHJh Y3Q6DQo+Pj4+Pj4+Pj4gVGhpcyBkb2N1bWVudCBjb250YWlucyBhIHNwZWNpZmljYXRpb24gb2Yg dGhyZWUgWUFORyBtb2R1bGVzLg0KPj4+Pj4+Pj4+IFRvZ2V0aGVyIHRoZXkgZm9ybSB0aGUgY29y ZSByb3V0aW5nIGRhdGEgbW9kZWwgd2hpY2ggc2VydmVzIGFzIGENCj4+Pj4+Pj4+PiBmcmFtZXdv cmsgZm9yIGNvbmZpZ3VyaW5nIGFuZCBtYW5hZ2luZyBhIHJvdXRpbmcgc3Vic3lzdGVtLiAgSXQN Cj4+Pj4+Pj4+PmlzDQo+Pj4+Pj4+Pj4gZXhwZWN0ZWQgdGhhdCB0aGVzZSBtb2R1bGVzIHdpbGwg YmUgYXVnbWVudGVkIGJ5IGFkZGl0aW9uYWwgWUFORw0KPj4+Pj4+Pj4+IG1vZHVsZXMgZGVmaW5p bmcgZGF0YSBtb2RlbHMgZm9yIGluZGl2aWR1YWwgcm91dGluZyBwcm90b2NvbHMgYW5kDQo+Pj4+ Pj4+Pj4gb3RoZXIgcmVsYXRlZCBmdW5jdGlvbnMuICBUaGUgY29yZSByb3V0aW5nIGRhdGEgbW9k ZWwgcHJvdmlkZXMNCj4+Pj4+Pj4+PmNvbW1vbg0KPj4+Pj4+Pj4+IGJ1aWxkaW5nIGJsb2NrcyBm b3Igc3VjaCBleHRlbnNpb25zIC0gcm91dGluZyBpbnN0YW5jZXMsIHJvdXRlcywNCj4+Pj4+Pj4+ PiByb3V0aW5nIGluZm9ybWF0aW9uIGJhc2VzIChSSUIpLCByb3V0aW5nIHByb3RvY29scyBhbmQg cm91dGUNCj4+Pj4+Pj4+PmZpbHRlcnMuDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+ Pj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ Pj4+Pj4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRt b2Qtcm91dGluZy1jZmcvDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gVGhlcmUncyBhbHNvIGEgaHRt bGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+Pj4+Pj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmctMTMNCj4+Pj4+Pj4+PiANCj4+ Pj4+Pj4+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6 DQo+Pj4+Pj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1u ZXRtb2Qtcm91dGluZy1jZmctMTMNCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZg0KPj4+Pj4+Pj4+IHN1Ym1pc3Npb24NCj4+Pj4+Pj4+PiB1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+Pj4+Pj4+Pj50b29scy5pZXRm Lm9yZy4NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZh aWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+Pj4+Pj4+Pj4gZnRwOi8vZnRwLmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy8NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4+IG5ldG1vZCBtYWlsaW5n IGxpc3QNCj4+Pj4+Pj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+Pj4+Pj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4gbmV0 bW9kIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4gbmV0bW9kQGlldGYub3JnDQo+Pj4+Pj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPj4+Pj4+PiANCj4+Pj4+ Pj4gLS0NCj4+Pj4+Pj4gTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPj4+Pj4+PiBQR1Ag S2V5IElEOiBFNzRFOEMwQw0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiAN Cj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+Pj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+ Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4+Pj4+ PiANCj4+Pj4+DQo+Pj4+Pi0tDQo+Pj4+PkxhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj4+ Pj4+UEdQIEtleSBJRDogRTc0RThDMEMNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+ DQo+Pj4NCj4+Pi0tIA0KPj4+TGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPj4+UEdQIEtl eSBJRDogRTc0RThDMEMNCj4+DQo+DQo+LS0gDQo+TGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFi cw0KPlBHUCBLZXkgSUQ6IEU3NEU4QzBDDQoNCg== From nobody Wed Mar 26 20:53:41 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3301A0077 for ; Wed, 26 Mar 2014 20:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wZqp9DHdAvE for ; Wed, 26 Mar 2014 20:53:37 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id ADD011A0043 for ; Wed, 26 Mar 2014 20:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19480; q=dns/txt; s=iport; t=1395892415; x=1397102015; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lXJSvq+rKtwf9atTtVeHqJClhaRadCGrpiRkusxed7c=; b=Y6PuRPoqnyCOvEM4EuhH3RhOgDgOpvzh8KFqM59L9eOMkEtdTU+Ubc+v P5xOMcoBSDPwF/cSOikfrsynws7+DeTyktoUgB1BzfWrWjn/BFApu4nK+ bYyP2J5GB3zFp/6VuvTQ9ycmxZE31ho65sqgohFeiBq42DWldiceswVOS c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFACegM1OtJXG8/2dsb2JhbABZgkJEO1e6CYgpUYEbFnSCJQEBAQQtTBACAQgRBAEBAQodBzIUCQgCBAENBQgBEodeDdEHF44gAQEeMQYBgySBFASaAJEAgy6Bcjk X-IronPort-AV: E=Sophos;i="4.97,739,1389744000"; d="scan'208,217";a="313212147" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 27 Mar 2014 03:53:34 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2R3rYC8028375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Mar 2014 03:53:34 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.48]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 26 Mar 2014 22:53:33 -0500 From: "Alexander Clemm (alex)" To: Andy Bierman , Ladislav Lhotka Thread-Topic: [netmod] allow mandatory nodes in augments Thread-Index: AQHPR4Lzu/4i41ezwEW9iEdPnEsinZrw00QAgAAbSgCAAArWgIAAECUAgAALxgCAAzrXQA== Date: Thu, 27 Mar 2014 03:53:33 +0000 Message-ID: References: <69BF499A-DD00-450B-AE41-07F937866103@nic.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.83.167] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B571874901Axmbrcdx05ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nm7UvfcUYlKXqR3lRmmRKH52kB8 Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 03:53:40 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B571874901Axmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree that this type of solution is what is needed. This has been our ex= perience developing models as well. The solution as indicated in the example, that the augmenting module itself= (and hence "top-level" data nodes) cannot be mandatory, but that in the pr= esence of container data nodes, nodes underneath can become mandatory, make= s a lot of sense to me. --- Alex From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Monday, March 24, 2014 2:30 PM To: Ladislav Lhotka Cc: netmod@ietf.org Subject: Re: [netmod] allow mandatory nodes in augments On Mon, Mar 24, 2014 at 1:48 PM, Ladislav Lhotka > wrote: On 24 Mar 2014, at 20:50, Andy Bierman > wrote: > > > > On Mon, Mar 24, 2014 at 12:11 PM, Ladislav Lhotka > wrote: > > On 24 Mar 2014, at 18:33, Andy Bierman > wrote: > > > > > > > > > On Mon, Mar 24, 2014 at 10:03 AM, Ladislav Lhotka > wrote: > > * allow mandatory nodes in augments > > > > ** Description > > > > RFC 6020 states in [[http://tools.ietf.org/html/rfc6020#section-7.15][S= ec. 7.15]]: > > > > If the target node is in another module, then nodes added by the > > augmentation MUST NOT be mandatory nodes (see Section 3.1). > > > > This rule was probably based on the assumption that augments will be us= ed for really optional data that can be safely ignored. However, as it turn= ed out, augments have become an essential tool for modular development of Y= ANG data models. In some cases, the inability to define mandatory nodes in = augments prevents the data modeller from specifying desired schema constrai= nts. > > > > For instance, [[http://tools.ietf.org/html/draft-ietf-netmod-interfaces= -cfg-16#appendix-A][Appendix A]] in "interfaces-cfg" shows how an Ethernet = module can be written that augments "if:interface". However, the container = "ethernet" cannot define any child leafs as mandatory even though it may be= necessary and would be normally done if the "ethernet" container was defin= ed directly in the "ietf-interfaces" module. > > > > ** Solution > > > > Remove the rule cited above. > > > > > > > > In the examples of this sort of augment usage, the augments are in diff= erent > > modules. There is no requirement that a server implement all-or-none o= f > > these modules, just because they happen to be published in 1 RFC. > > This is not what I am saying. > > > > > The reason this rule exists is so a server implementation of the augmen= ting module > > does not break old clients that do not know about this module. They wi= ll not provide > > the mandatory values and edits will fail. (Bonica Principle again). > > I don't buy this principle. I have already argued that new non-mandatory = data in server's model can lead to unexpected consequences if the client is= n't aware of them, see > > http://www.ietf.org/mail-archive/web/netmod/current/msg09296.html > > > > If a new YANG object is defined such that it changes the way an existing > YANG object works, then the new object is broken. > > An old client should be able to configure the objects it already knows > and the request should not be rejected because of missing mandatory nodes= . > > The server can pick reasonable defaults for the new objects without > an old client needing to be re-coded. A client can use merge instead of = replace to > make sure that new objects do not get deleted. The new objects can be ign= ored > for editing purposes. This is not true if the merge is rejected because = of missing > mandatory nodes. Let me rephrase the main point of this issue: Significant parts of our core= models are defined inside augments, with more to come (e.g., modules for a= ll interface type). These parts cannot have mandatory contents due to that = rule from sec. 7.15, which can be a serious limitation because some paramet= ers simply have no reasonable defaults and have to be configured. The possi= bility of supporting old clients (IMO dubious) does not outweigh this limit= ation. If all these augments are in the same YANG module then the augment-stmt is = not really needed and inline definitions should be used instead. If they are in different modules, then a server vendor may choose to implem= ent the augmenting module in a later release than the base module. It doesn't matter that a bu= nch of modules are published around the same time. The likely case is that the augmenting mod= ule is over a year later. It has nothing to do with YANG 1.0 vs. 1.1. It is a bad idea to break old clients that don't know about the new module. Note that it is possible to add new nodes, such that the sibling/child node= s to the augmented nodes are optional, but their descendant nodes are mandato= ry. This should be OK. An old client that provides just the base objects in a create or merge will not break if the new mandatory objects are "protected" via an extra layer: container top { leaf old-1 { type string; } } NOT OK: augment /top { leaf from-augment-1 { type string; mandatory true; } } OK: augment /top { container pcon { presence "must exist to make the leaf mandatory"; leaf from-augment-1 { type string; mandatory true; } } } Lada > Andy --_000_DBC595ED2346914F9F81D17DD5C32B571874901Axmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree that this type of= solution is what is needed.  This has been our experience developing = models as well. 

The solution as indicated= in the example, that the augmenting module itself (and hence “top-le= vel” data nodes) cannot be mandatory, but that in the presence of container data nodes, nodes underneath can become mandatory, makes a lo= t of sense to me. 

--- Alex

 <= /p>

From: netmod [= mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Monday, March 24, 2014 2:30 PM
To: Ladislav Lhotka
Cc: netmod@ietf.org
Subject: Re: [netmod] allow mandatory nodes in augments

 

 

 

On Mon, Mar 24, 2014 at 1:48 PM, Ladislav Lhotka <= ;lhotka@nic.cz> w= rote:


On 24 Mar 2014, at 20:50, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Mon, Mar 24, 2014 at 12:11 PM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On 24 Mar 2014, at 18:33, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Mon, Mar 24, 2014 at 10:03 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > * allow mandatory nodes in augments
> >
> > ** Description
> >
> > RFC 6020 states in [[http://tools.ietf.org/html/rfc6020#s= ection-7.15][Sec. 7.15]]:
> >
> >    If the target node is in another module, then nodes = added by the
> >    augmentation MUST NOT be mandatory nodes (see Sectio= n 3.1).
> >
> > This rule was probably based on the assumption that augments will= be used for really optional data that can be safely ignored. However, as i= t turned out, augments have become an essential tool for modular developmen= t of YANG data models. In some cases, the inability to define mandatory nodes in augments prevents the data mode= ller from specifying desired schema constraints.
> >
> > For instance, [[http://too= ls.ietf.org/html/draft-ietf-netmod-interfaces-cfg-16#appendix-A][Appendix A]] in "interfaces-cfg" shows how an Ethernet module can be written that augments "if:interface". However, the= container "ethernet" cannot define any child leafs as mandatory = even though it may be necessary and would be normally done if the "eth= ernet" container was defined directly in the "ietf-interfaces&quo= t; module.
> >
> > ** Solution
> >
> > Remove the rule cited above.
> >
> >
> >
> > In the examples of this sort of augment usage, the augments are i= n different
> > modules.  There is no requirement that a server implement al= l-or-none of
> > these modules, just because they happen to be published in 1 RFC.=
>
> This is not what I am saying.
>
> >
> > The reason this rule exists is so a server implementation of the = augmenting module
> > does not break old clients that do not know about this module. &n= bsp;They will not provide
> > the mandatory values and edits will fail. (Bonica Principle again= ).
>
> I don’t buy this principle. I have already argued that new non-m= andatory data in server’s model can lead to unexpected consequences i= f the client isn’t aware of them, see
>
> http://www.ietf.org/mail-archive/web/netmod/current/msg09296.html
>
>
>
> If a new YANG object is defined such that it changes the way an existi= ng
> YANG object works, then the new object is broken.
>
> An old client should be able to configure the objects it already knows=
> and the request should not be rejected because of missing mandatory no= des.
>
> The server can pick reasonable defaults for the new objects without > an old client needing to be re-coded.  A client can use merge ins= tead of replace to
> make sure that new objects do not get deleted. The new objects can be = ignored
> for editing purposes.  This is not true if the merge is rejected = because of missing
> mandatory nodes.

Let me rephrase the main point of this issue: Significant parts of our core= models are defined inside augments, with more to come (e.g., modules for a= ll interface type). These parts cannot have mandatory contents due to that = rule from sec. 7.15, which can be a serious limitation because some parameters simply have no reasonable def= aults and have to be configured. The possibility of supporting old clients = (IMO dubious) does not outweigh this limitation.

 

 

If all these augments are in the same YANG module th= en the augment-stmt is not

really needed and inline definitions should be used = instead.

 

If they are in different modules, then a server vend= or may choose to implement the augmenting

module in a later release than the base module. It d= oesn't matter that a bunch of modules are

published around the same time.  The likely cas= e is that the augmenting module is over a year later.

 

It has nothing to do with YANG 1.0 vs. 1.1.

It is a bad idea to break old clients that don't kno= w about the new module.

 

Note that it is possible to add new nodes, such that= the sibling/child nodes

to the augmented nodes are optional, but their desce= ndant nodes are mandatory.

This should be OK.  An old client that provides= just the base objects in a

create or merge will not break if the new mandatory = objects are "protected"

via an extra layer:

 

 

   container top {

      leaf old-1 { type string; }

   }

 

 

NOT OK:

 

   augment /top {

       leaf from-augment-1 {

         type string;<= /o:p>

         mandatory true;

       }

   }

 

 

 

OK:

 

   augment /top {

       container pcon {

           presence &q= uot;must exist to make the leaf mandatory";

 

          leaf from-augment= -1 {

             type= string;

             mand= atory true;

           }

        }

    }

 

 

 

Lada

>

 

 

Andy

 

--_000_DBC595ED2346914F9F81D17DD5C32B571874901Axmbrcdx05ciscoc_-- From nobody Thu Mar 27 00:04:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE201A01F6 for ; Thu, 27 Mar 2014 00:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsbIjgeOKILI for ; Thu, 27 Mar 2014 00:04:28 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 276B21A047B for ; Thu, 27 Mar 2014 00:04:25 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 5846F240C385; Thu, 27 Mar 2014 08:04:23 +0100 (CET) Date: Thu, 27 Mar 2014 08:04:23 +0100 (CET) Message-Id: <20140327.080423.2031221427554871516.mbj@tail-f.com> To: alex@cisco.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/J7IyrubxWhl7S58ImnGrhT4yBwo Cc: netmod@ietf.org Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 07:04:41 -0000 Hi Alex, "Alexander Clemm (alex)" wrote: > I agree that this type of solution is what is needed. This has been > our experience developing models as well. > The solution as indicated in the example, that the augmenting module > itself (and hence "top-level" data nodes) cannot be mandatory, but > that in the presence of container data nodes, nodes underneath can > become mandatory, makes a lot of sense to me. I don't really understand what you mean. Do you agree with Lada that augment should be allowed to add mandatory nodes, or do you agree with Andy that it is ok to augment e.g. a P-container which defines the mandatory nodes? /martin > --- Alex > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy > Bierman > Sent: Monday, March 24, 2014 2:30 PM > To: Ladislav Lhotka > Cc: netmod@ietf.org > Subject: Re: [netmod] allow mandatory nodes in augments > > > > On Mon, Mar 24, 2014 at 1:48 PM, Ladislav Lhotka > > wrote: > > On 24 Mar 2014, at 20:50, Andy Bierman > > wrote: > > > > > > > > > On Mon, Mar 24, 2014 at 12:11 PM, Ladislav Lhotka > > > wrote: > > > > On 24 Mar 2014, at 18:33, Andy Bierman > > > wrote: > > > > > > > > > > > > > > On Mon, Mar 24, 2014 at 10:03 AM, Ladislav Lhotka > > > > wrote: > > > * allow mandatory nodes in augments > > > > > > ** Description > > > > > > RFC 6020 states in > > > [[http://tools.ietf.org/html/rfc6020#section-7.15][Sec. 7.15]]: > > > > > > If the target node is in another module, then nodes added by the > > > augmentation MUST NOT be mandatory nodes (see Section 3.1). > > > > > > This rule was probably based on the assumption that augments will be > > > used for really optional data that can be safely ignored. However, as > > > it turned out, augments have become an essential tool for modular > > > development of YANG data models. In some cases, the inability to > > > define mandatory nodes in augments prevents the data modeller from > > > specifying desired schema constraints. > > > > > > For instance, > > > [[http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-16#appendix-A][Appendix > > > A]] in "interfaces-cfg" shows how an Ethernet module can be written > > > that augments "if:interface". However, the container "ethernet" cannot > > > define any child leafs as mandatory even though it may be necessary > > > and would be normally done if the "ethernet" container was defined > > > directly in the "ietf-interfaces" module. > > > > > > ** Solution > > > > > > Remove the rule cited above. > > > > > > > > > > > > In the examples of this sort of augment usage, the augments are in > > > different > > > modules. There is no requirement that a server implement all-or-none > > > of > > > these modules, just because they happen to be published in 1 RFC. > > > > This is not what I am saying. > > > > > > > > The reason this rule exists is so a server implementation of the > > > augmenting module > > > does not break old clients that do not know about this module. They > > > will not provide > > > the mandatory values and edits will fail. (Bonica Principle again). > > > > I don't buy this principle. I have already argued that new > > non-mandatory data in server's model can lead to unexpected > > consequences if the client isn't aware of them, see > > > > http://www.ietf.org/mail-archive/web/netmod/current/msg09296.html > > > > > > > > If a new YANG object is defined such that it changes the way an > > existing > > YANG object works, then the new object is broken. > > > > An old client should be able to configure the objects it already knows > > and the request should not be rejected because of missing mandatory > > nodes. > > > > The server can pick reasonable defaults for the new objects without > > an old client needing to be re-coded. A client can use merge instead > > of replace to > > make sure that new objects do not get deleted. The new objects can be > > ignored > > for editing purposes. This is not true if the merge is rejected > > because of missing > > mandatory nodes. > > Let me rephrase the main point of this issue: Significant parts of our > core models are defined inside augments, with more to come (e.g., > modules for all interface type). These parts cannot have mandatory > contents due to that rule from sec. 7.15, which can be a serious > limitation because some parameters simply have no reasonable defaults > and have to be configured. The possibility of supporting old clients > (IMO dubious) does not outweigh this limitation. > > > If all these augments are in the same YANG module then the > augment-stmt is not > really needed and inline definitions should be used instead. > > If they are in different modules, then a server vendor may choose to > implement the augmenting > module in a later release than the base module. It doesn't matter that > a bunch of modules are > published around the same time. The likely case is that the > augmenting module is over a year later. > > It has nothing to do with YANG 1.0 vs. 1.1. > It is a bad idea to break old clients that don't know about the new > module. > > Note that it is possible to add new nodes, such that the sibling/child > nodes > to the augmented nodes are optional, but their descendant nodes are > mandatory. > This should be OK. An old client that provides just the base objects > in a > create or merge will not break if the new mandatory objects are > "protected" > via an extra layer: > > > container top { > leaf old-1 { type string; } > } > > > NOT OK: > > augment /top { > leaf from-augment-1 { > type string; > mandatory true; > } > } > > > > OK: > > augment /top { > container pcon { > presence "must exist to make the leaf mandatory"; > > leaf from-augment-1 { > type string; > mandatory true; > } > } > } > > > > Lada > > > > > > Andy > From nobody Thu Mar 27 00:38:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B6F1A02A3 for ; Thu, 27 Mar 2014 00:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B201i7KsCZ5c for ; Thu, 27 Mar 2014 00:38:28 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) by ietfa.amsl.com (Postfix) with ESMTP id 20B061A01F0 for ; Thu, 27 Mar 2014 00:38:28 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id f51so2306273qge.2 for ; Thu, 27 Mar 2014 00:38:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UZK8thbvO+k/+idlEGTEzwTkVs6F10ycaYR6ooSWeFA=; b=WASCSX6qY8kwHreka+qvordk+QJ/bzlFfj0kQ+jfQIO/FpgB3PxViPWgSBF/f0SaRc bsupKJHQfE7N8LhDRxQPEMY+VXUx+DxEu8Qzpg3aC1YyHcVJk7nH0BV03zWkz9a8PtwO 875bPJLVVuMZaIfMc9xAVkiDWGB/4oNDDFPAjttnhlu+v4OV5lNngM9xb24dsTGyYzrj Pt3hwfkRznnkbsC946cnEgEo2GQ4//DaUFutB2TxVdmiFJLmsvUi4J3DgqksyIRxf9Im mDXXg/WgLmM54u3zbmKPY58POoHmcpvkLRrsUueFTbgSaoXWczKF6a4mjbuIcY0n/rnU DYlg== X-Gm-Message-State: ALoCoQkf9NOe2hy7ENtp1o3lgamX2X7080OJnV2Oi7RduJ1b4I2ULWWTEaeCB6nDGBjXbQyM8P1M MIME-Version: 1.0 X-Received: by 10.140.87.67 with SMTP id q61mr261648qgd.94.1395905906265; Thu, 27 Mar 2014 00:38:26 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Thu, 27 Mar 2014 00:38:26 -0700 (PDT) In-Reply-To: <20140327.080423.2031221427554871516.mbj@tail-f.com> References: <20140327.080423.2031221427554871516.mbj@tail-f.com> Date: Thu, 27 Mar 2014 00:38:26 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a113abee6aefc2e04f591ab5b Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_HiY48h6mGcj8TXjPn_9QumIwoQ Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 07:38:31 -0000 --001a113abee6aefc2e04f591ab5b Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 27, 2014 at 12:04 AM, Martin Bjorklund wrote: > Hi Alex, > > "Alexander Clemm (alex)" wrote: > > I agree that this type of solution is what is needed. This has been > > our experience developing models as well. > > The solution as indicated in the example, that the augmenting module > > itself (and hence "top-level" data nodes) cannot be mandatory, but > > that in the presence of container data nodes, nodes underneath can > > become mandatory, makes a lot of sense to me. > > I don't really understand what you mean. Do you agree with Lada that > augment should be allowed to add mandatory nodes, or do you agree with > Andy that it is ok to augment e.g. a P-container which defines the > mandatory nodes? > > IMO we cannot break existing clients. Since it is possible to add the nodes in a way that does not expose the mandatory nodes to an "old" create or merge, then that should always be used. Any create or merge that adds the P container (or list) has to do so correctly with the mandatory sub-nodes. /martin > Andy > > > --- Alex > > > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy > > Bierman > > Sent: Monday, March 24, 2014 2:30 PM > > To: Ladislav Lhotka > > Cc: netmod@ietf.org > > Subject: Re: [netmod] allow mandatory nodes in augments > > > > > > > > On Mon, Mar 24, 2014 at 1:48 PM, Ladislav Lhotka > > > wrote: > > > > On 24 Mar 2014, at 20:50, Andy Bierman > > > wrote: > > > > > > > > > > > > > > On Mon, Mar 24, 2014 at 12:11 PM, Ladislav Lhotka > > > > wrote: > > > > > > On 24 Mar 2014, at 18:33, Andy Bierman > > > > wrote: > > > > > > > > > > > > > > > > > > > On Mon, Mar 24, 2014 at 10:03 AM, Ladislav Lhotka > > > > > wrote: > > > > * allow mandatory nodes in augments > > > > > > > > ** Description > > > > > > > > RFC 6020 states in > > > > [[http://tools.ietf.org/html/rfc6020#section-7.15][Sec. 7.15]]: > > > > > > > > If the target node is in another module, then nodes added by the > > > > augmentation MUST NOT be mandatory nodes (see Section 3.1). > > > > > > > > This rule was probably based on the assumption that augments will be > > > > used for really optional data that can be safely ignored. However, as > > > > it turned out, augments have become an essential tool for modular > > > > development of YANG data models. In some cases, the inability to > > > > define mandatory nodes in augments prevents the data modeller from > > > > specifying desired schema constraints. > > > > > > > > For instance, > > > > [[ > http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-16#appendix-A][Appendix > > > > A]] in "interfaces-cfg" shows how an Ethernet module can be written > > > > that augments "if:interface". However, the container "ethernet" > cannot > > > > define any child leafs as mandatory even though it may be necessary > > > > and would be normally done if the "ethernet" container was defined > > > > directly in the "ietf-interfaces" module. > > > > > > > > ** Solution > > > > > > > > Remove the rule cited above. > > > > > > > > > > > > > > > > In the examples of this sort of augment usage, the augments are in > > > > different > > > > modules. There is no requirement that a server implement all-or-none > > > > of > > > > these modules, just because they happen to be published in 1 RFC. > > > > > > This is not what I am saying. > > > > > > > > > > > The reason this rule exists is so a server implementation of the > > > > augmenting module > > > > does not break old clients that do not know about this module. They > > > > will not provide > > > > the mandatory values and edits will fail. (Bonica Principle again). > > > > > > I don't buy this principle. I have already argued that new > > > non-mandatory data in server's model can lead to unexpected > > > consequences if the client isn't aware of them, see > > > > > > http://www.ietf.org/mail-archive/web/netmod/current/msg09296.html > > > > > > > > > > > > If a new YANG object is defined such that it changes the way an > > > existing > > > YANG object works, then the new object is broken. > > > > > > An old client should be able to configure the objects it already knows > > > and the request should not be rejected because of missing mandatory > > > nodes. > > > > > > The server can pick reasonable defaults for the new objects without > > > an old client needing to be re-coded. A client can use merge instead > > > of replace to > > > make sure that new objects do not get deleted. The new objects can be > > > ignored > > > for editing purposes. This is not true if the merge is rejected > > > because of missing > > > mandatory nodes. > > > > Let me rephrase the main point of this issue: Significant parts of our > > core models are defined inside augments, with more to come (e.g., > > modules for all interface type). These parts cannot have mandatory > > contents due to that rule from sec. 7.15, which can be a serious > > limitation because some parameters simply have no reasonable defaults > > and have to be configured. The possibility of supporting old clients > > (IMO dubious) does not outweigh this limitation. > > > > > > If all these augments are in the same YANG module then the > > augment-stmt is not > > really needed and inline definitions should be used instead. > > > > If they are in different modules, then a server vendor may choose to > > implement the augmenting > > module in a later release than the base module. It doesn't matter that > > a bunch of modules are > > published around the same time. The likely case is that the > > augmenting module is over a year later. > > > > It has nothing to do with YANG 1.0 vs. 1.1. > > It is a bad idea to break old clients that don't know about the new > > module. > > > > Note that it is possible to add new nodes, such that the sibling/child > > nodes > > to the augmented nodes are optional, but their descendant nodes are > > mandatory. > > This should be OK. An old client that provides just the base objects > > in a > > create or merge will not break if the new mandatory objects are > > "protected" > > via an extra layer: > > > > > > container top { > > leaf old-1 { type string; } > > } > > > > > > NOT OK: > > > > augment /top { > > leaf from-augment-1 { > > type string; > > mandatory true; > > } > > } > > > > > > > > OK: > > > > augment /top { > > container pcon { > > presence "must exist to make the leaf mandatory"; > > > > leaf from-augment-1 { > > type string; > > mandatory true; > > } > > } > > } > > > > > > > > Lada > > > > > > > > > > > Andy > > > --001a113abee6aefc2e04f591ab5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 27, 2014 at 12:04 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Hi Alex,

"Alexander Clemm (alex)" <al= ex@cisco.com> wrote:
> I agree that this type of solution is what is needed. =A0This has been=
> our experience developing models as well.
> The solution as indicated in the example, that the augmenting module > itself (and hence "top-level" data nodes) cannot be mandator= y, but
> that in the presence of container data nodes, nodes underneath can
> become mandatory, makes a lot of sense to me.

I don't really understand what you mean. =A0Do you agree with Lada that=
augment should be allowed to add mandatory nodes, or do you agree with
Andy that it is ok to augment e.g. a P-container which defines the
mandatory nodes?

=A0

IMO = we cannot break existing clients.
Since it is possible to add the= nodes in a way that does not expose the mandatory
nodes to an &q= uot;old" create or merge, then that should always be used.
Any create or merge that adds the P container (or list) has to do so c= orrectly
with the mandatory sub-nodes.

<= br>
/martin
=A0

Andy



> --- Alex
>
> From: netmod [mailto:netmod= -bounces@ietf.org] On Behalf Of Andy
> Bierman
> Sent: Monday, March 24, 2014 2:30 PM
> To: Ladislav Lhotka
> Cc: netmod@ietf.org
> Subject: Re: [netmod] allow mandatory nodes in augments
>
>
>
> On Mon, Mar 24, 2014 at 1:48 PM, Ladislav Lhotka
> <lhotka@nic.cz<mailto:lhotka@nic.cz>> wrote:
>
> On 24 Mar 2014, at 20:50, Andy Bierman
> <andy@yumaworks.com<ma= ilto:andy@yumaworks.com>> w= rote:
>
> >
> >
> >
> > On Mon, Mar 24, 2014 at 12:11 PM, Ladislav Lhotka
> > <lhotka@nic.cz<mailto:= lhotka@nic.cz>> wrote:
> >
> > On 24 Mar 2014, at 18:33, Andy Bierman
> > <andy@yumaworks.com&= lt;mailto:andy@yumaworks.com>&= gt; wrote:
> >
> > >
> > >
> > >
> > > On Mon, Mar 24, 2014 at 10:03 AM, Ladislav Lhotka
> > > <lhotka@nic.cz<ma= ilto:lhotka@nic.cz>> wrote:
> > > * allow mandatory nodes in augments
> > >
> > > ** Description
> > >
> > > RFC 6020 states in
> > > [[http://tools.ietf.org/html/rfc6020#section-7.15][S= ec. 7.15]]:
> > >
> > > =A0 =A0If the target node is in another module, then nodes a= dded by the
> > > =A0 =A0augmentation MUST NOT be mandatory nodes (see Section= 3.1).
> > >
> > > This rule was probably based on the assumption that augments= will be
> > > used for really optional data that can be safely ignored. Ho= wever, as
> > > it turned out, augments have become an essential tool for mo= dular
> > > development of YANG data models. In some cases, the inabilit= y to
> > > define mandatory nodes in augments prevents the data modelle= r from
> > > specifying desired schema constraints.
> > >
> > > For instance,
> > > [[http://tools.ietf.o= rg/html/draft-ietf-netmod-interfaces-cfg-16#appendix-A][Appendix
> > > A]] in "interfaces-cfg" shows how an Ethernet modu= le can be written
> > > that augments "if:interface". However, the contain= er "ethernet" cannot
> > > define any child leafs as mandatory even though it may be ne= cessary
> > > and would be normally done if the "ethernet" conta= iner was defined
> > > directly in the "ietf-interfaces" module.
> > >
> > > ** Solution
> > >
> > > Remove the rule cited above.
> > >
> > >
> > >
> > > In the examples of this sort of augment usage, the augments = are in
> > > different
> > > modules. =A0There is no requirement that a server implement = all-or-none
> > > of
> > > these modules, just because they happen to be published in 1= RFC.
> >
> > This is not what I am saying.
> >
> > >
> > > The reason this rule exists is so a server implementation of= the
> > > augmenting module
> > > does not break old clients that do not know about this modul= e. =A0They
> > > will not provide
> > > the mandatory values and edits will fail. (Bonica Principle = again).
> >
> > I don't buy this principle. I have already argued that new > > non-mandatory data in server's model can lead to unexpected > > consequences if the client isn't aware of them, see
> >
> > http://www.ietf.org/mail-archive/web/netmod/= current/msg09296.html
> >
> >
> >
> > If a new YANG object is defined such that it changes the way an > > existing
> > YANG object works, then the new object is broken.
> >
> > An old client should be able to configure the objects it already = knows
> > and the request should not be rejected because of missing mandato= ry
> > nodes.
> >
> > The server can pick reasonable defaults for the new objects witho= ut
> > an old client needing to be re-coded. =A0A client can use merge i= nstead
> > of replace to
> > make sure that new objects do not get deleted. The new objects ca= n be
> > ignored
> > for editing purposes. =A0This is not true if the merge is rejecte= d
> > because of missing
> > mandatory nodes.
>
> Let me rephrase the main point of this issue: Significant parts of our=
> core models are defined inside augments, with more to come (e.g.,
> modules for all interface type). These parts cannot have mandatory
> contents due to that rule from sec. 7.15, which can be a serious
> limitation because some parameters simply have no reasonable defaults<= br> > and have to be configured. The possibility of supporting old clients > (IMO dubious) does not outweigh this limitation.
>
>
> If all these augments are in the same YANG module then the
> augment-stmt is not
> really needed and inline definitions should be used instead.
>
> If they are in different modules, then a server vendor may choose to > implement the augmenting
> module in a later release than the base module. It doesn't matter = that
> a bunch of modules are
> published around the same time. =A0The likely case is that the
> augmenting module is over a year later.
>
> It has nothing to do with YANG 1.0 vs. 1.1.
> It is a bad idea to break old clients that don't know about the ne= w
> module.
>
> Note that it is possible to add new nodes, such that the sibling/child=
> nodes
> to the augmented nodes are optional, but their descendant nodes are > mandatory.
> This should be OK. =A0An old client that provides just the base object= s
> in a
> create or merge will not break if the new mandatory objects are
> "protected"
> via an extra layer:
>
>
> =A0 =A0container top {
> =A0 =A0 =A0 leaf old-1 { type string; }
> =A0 =A0}
>
>
> NOT OK:
>
> =A0 =A0augment /top {
> =A0 =A0 =A0 =A0leaf from-augment-1 {
> =A0 =A0 =A0 =A0 =A0type string;
> =A0 =A0 =A0 =A0 =A0mandatory true;
> =A0 =A0 =A0 =A0}
> =A0 =A0}
>
>
>
> OK:
>
> =A0 =A0augment /top {
> =A0 =A0 =A0 =A0container pcon {
> =A0 =A0 =A0 =A0 =A0 =A0presence "must exist to make the leaf mand= atory";
>
> =A0 =A0 =A0 =A0 =A0 leaf from-augment-1 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0type string;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0mandatory true;
> =A0 =A0 =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0 }
> =A0 =A0 }
>
>
>
> Lada
>
> >
>
>
> Andy
>

--001a113abee6aefc2e04f591ab5b-- From nobody Thu Mar 27 00:46:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA381A01F0 for ; Thu, 27 Mar 2014 00:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xLYTrjn7CzL for ; Thu, 27 Mar 2014 00:46:33 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id E31411A00FF for ; Thu, 27 Mar 2014 00:46:32 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 90164240C385; Thu, 27 Mar 2014 08:46:30 +0100 (CET) Date: Thu, 27 Mar 2014 08:46:30 +0100 (CET) Message-Id: <20140327.084630.744815920970998929.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140327.080423.2031221427554871516.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/L5EZwrfVmKpAQ2K7jjrjf3SAa1s Cc: netmod@ietf.org Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 07:46:34 -0000 Andy Bierman wrote: > On Thu, Mar 27, 2014 at 12:04 AM, Martin Bjorklund wrote: > > > Hi Alex, > > > > "Alexander Clemm (alex)" wrote: > > > I agree that this type of solution is what is needed. This has been > > > our experience developing models as well. > > > The solution as indicated in the example, that the augmenting module > > > itself (and hence "top-level" data nodes) cannot be mandatory, but > > > that in the presence of container data nodes, nodes underneath can > > > become mandatory, makes a lot of sense to me. > > > > I don't really understand what you mean. Do you agree with Lada that > > augment should be allowed to add mandatory nodes, or do you agree with > > Andy that it is ok to augment e.g. a P-container which defines the > > mandatory nodes? > > > > > > IMO we cannot break existing clients. +1 > Since it is possible to add the nodes in a way that does not expose the > mandatory > nodes to an "old" create or merge, then that should always be used. > Any create or merge that adds the P container (or list) has to do so > correctly > with the mandatory sub-nodes. I agree that this works, and probably is acceptable. However, as was demonstrated earlier in this thread, there are situations where it would be safe to augment a mandatory node, for example if an identity is defined in the augmenting module, and the augment is made conditional on that identity. I don't know if this can be captured in plain text though. /martin From nobody Thu Mar 27 03:38:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC011A0639 for ; Thu, 27 Mar 2014 03:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPsELUKQ-F8j for ; Thu, 27 Mar 2014 03:38:23 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id EEE511A01FF for ; Thu, 27 Mar 2014 03:38:22 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id s2RAcJPV024393; Thu, 27 Mar 2014 11:38:19 +0100 Message-ID: <5333FF9A.6090004@mg-soft.com> Date: Thu, 27 Mar 2014 11:38:18 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andy Bierman References: <5CAA392C-3951-4AA4-AE57-BFC26FE4A3FD@nic.cz> <20140326.150935.1428873551094973632.mbj@tail-f.com> <36E4F7A8-8A0E-4666-B469-6934E6F7802C@nic.cz> <5332EC02.2020607@mg-soft.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080002080107080304050405" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ijEWOE7r7aozzmY0jYVQFNVin-4 Cc: "netmod@ietf.org" Subject: Re: [netmod] Y18: fix "when" expression context node problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 10:38:27 -0000 This is a multi-part message in MIME format. --------------080002080107080304050405 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Dne 26.3.2014 16:36, pi¹e Andy Bierman: > > > > On Wed, Mar 26, 2014 at 8:02 AM, Jernej Tuljak > > wrote: > > Dne 26.3.2014 15:48, pi¹e Ladislav Lhotka: > > On 26 Mar 2014, at 15:09, Martin Bjorklund > wrote: > > Ladislav Lhotka > wrote: > > On 26 Mar 2014, at 14:53, Andy Bierman > > wrote: > > > > On Wed, Mar 26, 2014 at 6:40 AM, Ladislav Lhotka > > > wrote: > Andy Bierman > writes: > > On Tue, Mar 25, 2014 at 2:40 PM, Ladislav > Lhotka > > wrote: > > Andy Bierman > writes: > > > I do not see the error. Are you > saying all the when-stmts that are in > > YANG > > 1.0 > modules now are broken? Are you saying > they are unimplementable? > > What I am saying is that data model > fragments like > > container foo { > when "1 = 0"; > leaf bar { > mandatory true; > ... > } > } > > don't have a satisfactory interpretation. > It is fully defensible if a > validation tool flags datastore content as > invalid if it doesn't > contain > the "foo" container and the mandatory > "bar" leaf. > > > Like I said, the pathological cases are > operationally useless. > Nobody would ever write "when 1 = 0". We > should avoid adding > > The XPath expression doesn't matter, the problem > is the same whatever > the expression is. > > CLRs to YANG that are intended from preventing > people from doing > things > they would not even try to do. It is just > busy work for compiler > writers. > > > > > YANG 1.0 when-stmts need to be > unchanged in YANG 1.1. > The issue of evaluating a when-expr as > if there was a context > node inserted is a completely > different issue than the order that > multiple when-stmts are evaluated. > Changing the context node > to the parent does not alter the > evaluation order problem. > > That's true, but it does make a difference > whether you insert all the > temporary context nodes at once or one by one. > > > To be honest -- it doesn't. Setting all the > context nodes to random > values > > It doesn't? So how do you proceed with inserting > these dummy nodes in > my recent dhcp/bootp example? > > > I would not allow that module to be published. > It would have to be rewritten so there was no > dependency loop. > > Each container can be in a separate module maintained > by a different > party. > > If I understand your concern this isn't possible, since > you can't > refer to nodes from other module w/o importing the other > module, and > cirular imports are not allowed. > > Yes, you are right, it is not possible in this form (but see > below). > > Alternatively, it can be intentionally crafted by an > attacker. > > ? > > Somebody can write a module that looks innocent and compiles > properly but creates this when loop under some circumstances. > > IMO it is up to YANG spec to make sure this is not > allowed, and > compilers should do their best to eliminate it. > > How can we state that there MUST NOT be any ciruclar > references in > when expressions? > > I proposed a formulation earlier: > > "The XPath expression must not involve any node that is > directly or indirectly conditional." > > Checking it can be tricky, because the XPath expression may > contain things like count(../*) whose result depends on the > presence or absence of the context node. > > > I don't think you need the actual result of the evaluation though. > All you need to know is what the expression is referencing; > parent, self and siblings of the context node in your case. > > > I think all the intermediate and final node-set results of every > must/when expression in order to know if any XPath expressions > access the same nodes. > > Examining the schema tree instead of the value tree has some problems, > but ignoring that for the moment, it would be possible to detect that some > previous when-stmt accessed the same node as another when-stmt. > What problems related to examining the schema tree were you referring to here? > Is there an example for the A->B->C->A loop case? > > > > Simple loop: > > container foo { > leaf A { > when "../B = 10"; > type int32; > } > leaf B { > when "../C = 10"; > type int32; > } > leaf C { > when "../A != 10"; > type int32; > } > } > > There are no real examples AFAIK. > > Of course, it is more complicated. Nodes can inherit > multiple when-stmts, so even the order that when-stmts are processed > for a single node can affect the ability to detect these loops. > (You stop at the first false when-stmt). > There are no false when-stmts at compile time. If all you require from an XPath expression for loop detection is a set of data nodes upon which the expression relies, these can be determined at compile time, as long as there are no unknown XPath functions that return node sets. I don't think the order is relevant really - the analysis would be about what could potentially happen, not about what is happening in a given situation (compile time vs. runtime). > If there are if-feature statements then it gets even more complicated. > If-features simply imply a conditional branch that relies on some condition which is only available at runtime. These conditions do not reference data nodes, so I don't think they are problematic. Two when statements that do not reference each other in any way are not an issue even if they are nested, right? An if-feature and a when is no different. Do you have an example that would demonstrate your concern? If leaf C had an if-feature that would not change the fact there's a potential loop in your example. > It's fine to say when-stmt references MUST NOT create circular references, > but I doubt compilers will detect these errors very well. > I agree. Also agree that it would not be easy to implement. Perhaps transforming the all data nodes of a schema tree (cooked YANG) into a directed graph, where edges are constructed as pairs of the initial context node and all subsequent context nodes for each expression and then applying an algorithm for finding cycles is enough to find all potential loops. G=(V,E) V= {foo, A, B, C} E= {{A,foo}, {A,B}, {B,foo}, {B,C}, {C,foo}, {C,A}} Just guessing though. Jernej > Jernej > > > Andy > > > > I think XPath is too powerful for this purpose. > > Lada > > > /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > 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 > > --------------080002080107080304050405 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit
Dne 26.3.2014 16:36, pi¹e Andy Bierman:



On Wed, Mar 26, 2014 at 8:02 AM, Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote:
Dne 26.3.2014 15:48, pi¹e Ladislav Lhotka:
On 26 Mar 2014, at 15:09, Martin Bjorklund <mbj@tail-f.com> wrote:

Ladislav Lhotka <lhotka@nic.cz> wrote:
On 26 Mar 2014, at 14:53, Andy Bierman <andy@yumaworks.com> wrote:



On Wed, Mar 26, 2014 at 6:40 AM, Ladislav Lhotka <lhotka@nic.cz>
wrote:
Andy Bierman <andy@yumaworks.com> writes:

On Tue, Mar 25, 2014 at 2:40 PM, Ladislav Lhotka <lhotka@nic.cz>
wrote:

Andy Bierman <andy@yumaworks.com> writes:


I do not see the error.  Are you saying all the when-stmts that are in
YANG
1.0
modules now are broken? Are you saying they are unimplementable?
What I am saying is that data model fragments like

container foo {
    when "1 = 0";
    leaf bar {
        mandatory true;
        ...
    }
}

don't have a satisfactory interpretation. It is fully defensible if a
validation tool flags datastore content as invalid if it doesn't
contain
the "foo" container and the mandatory "bar" leaf.


Like I said, the pathological cases are operationally useless.
Nobody would ever write "when 1 = 0". We should avoid adding
The XPath expression doesn't matter, the problem is the same whatever
the expression is.

CLRs to YANG that are intended from preventing people from doing
things
they would not even try to do.  It is just busy work for compiler
writers.




YANG 1.0 when-stmts need to be unchanged in YANG 1.1.
The issue of evaluating a when-expr as if there was a context
node inserted is a completely different issue than the order that
multiple when-stmts are evaluated.  Changing the context node
to the parent does not alter the evaluation order problem.
That's true, but it does make a difference whether you insert all the
temporary context nodes at once or one by one.


To be honest -- it doesn't.  Setting all the context nodes to random
values
It doesn't? So how do you proceed with inserting these dummy nodes in
my recent dhcp/bootp example?


I would not allow that module to be published.
It would have to be rewritten so there was no dependency loop.
Each container can be in a separate module maintained by a different
party.
If I understand your concern this isn't possible, since you can't
refer to nodes from other module w/o importing the other module, and
cirular imports are not allowed.
Yes, you are right, it is not possible in this form (but see below).

Alternatively, it can be intentionally crafted by an attacker.
?
Somebody can write a module that looks innocent and compiles properly but creates this when loop under some circumstances.

IMO it is up to YANG spec to make sure this is not allowed, and
compilers should do their best to eliminate it.
How can we state that there MUST NOT be any ciruclar references in
when expressions?
I proposed a formulation earlier:

"The XPath expression must not involve any node that is directly or indirectly conditional."

Checking it can be tricky, because the XPath expression may contain things like count(../*) whose result depends on the presence or absence of the context node.

I don't think you need the actual result of the evaluation though. All you need to know is what the expression is referencing; parent, self and siblings of the context node in your case.


I think all the intermediate and final node-set results of every
must/when expression in order to know if any XPath expressions
access the same nodes.

Examining the schema tree instead of the value tree has some problems,
but ignoring that for the moment, it would be possible to detect that some
previous when-stmt accessed the same node as another when-stmt.


What problems related to examining the schema tree were you referring to here?

 
Is there an example for the A->B->C->A loop case?



Simple loop:

  container foo {
     leaf A {
        when "../B = 10";
        type int32;
     }
     leaf B {
        when "../C = 10";
        type int32;
     }
     leaf C {
        when "../A != 10";
        type int32;
     }
  }

There are no real examples AFAIK.

Of course, it is more complicated. Nodes can inherit
multiple when-stmts, so even the order that when-stmts are processed
for a single node can affect the ability to detect these loops.
(You stop at the first false when-stmt).


There are no false when-stmts at compile time. If all you require from an XPath expression for loop detection is a set of data nodes upon which the expression relies, these can be determined at compile time, as long as there are no unknown XPath functions that return node sets. I don't think the order is relevant really - the analysis would be about what could potentially happen, not about what is happening in a given situation (compile time vs. runtime).

If there are if-feature statements then it gets even more complicated.


If-features simply imply a conditional branch that relies on some condition which is only available at runtime. These conditions do not reference data nodes, so I don't think they are problematic. Two when statements that do not reference each other in any way are not an issue even if they are nested, right? An if-feature and a when is no different. Do you have an example that would demonstrate your concern? If leaf C had an if-feature that would not change the fact there's a potential loop in your example.

It's fine to say when-stmt references MUST NOT create circular references,
but I doubt compilers will detect these errors very well.


I agree. Also agree that it would not be easy to implement.

Perhaps transforming the all data nodes of a schema tree (cooked YANG) into a directed graph, where edges are constructed as pairs of the initial context node and all subsequent context nodes for each expression and then applying an algorithm for finding cycles is enough to find all potential loops.

G=(V,E)
V= {foo, A, B, C}
E= {{A,foo}, {A,B}, {B,foo}, {B,C}, {C,foo}, {C,A}}

Just guessing though.

Jernej

 
Jernej

Andy

 


I think XPath is too powerful for this purpose.

Lada


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




_______________________________________________
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


--------------080002080107080304050405-- From nobody Thu Mar 27 06:27:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538DF1A00FD for ; Thu, 27 Mar 2014 06:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2C_lEmMA5qF for ; Thu, 27 Mar 2014 06:27:42 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 128A51A00B4 for ; Thu, 27 Mar 2014 06:27:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 7C1A9540796; Thu, 27 Mar 2014 14:27:39 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2-ZS0cwrR+G; Thu, 27 Mar 2014 14:27:32 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 8755E540010; Thu, 27 Mar 2014 14:27:31 +0100 (CET) From: Ladislav Lhotka To: "Yi Yang \(yiya\)" , "Derek Man-Kit Yeung \(myeung\)" In-Reply-To: References: <20140110133016.24678.42711.idtracker@ietfa.amsl.com> <9C81158E-5B4C-4479-AEA5-23CBCC020ADD@nic.cz> <0ED855DA-51BE-4DE6-AB22-E1A9E04C0E5F@nic.cz> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Thu, 27 Mar 2014 14:27:31 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wkVa8BcI7vKw72AQwKEnGd4deLw Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 13:27:45 -0000 "Yi Yang (yiya)" writes: > Hi Lada, > > Aha. So when multiple-ribs is not supported, the default-ribs only exist > in the operational but not in configuration. Right. > > But in that case, should we still allow users to configure the > corresponding rib entry in the ribs? It is still needed for specifying route filters between a routing protocol = and the default routing table. This is done via the "connected-rib" list wh= ose keys are references to routing tables. Since YANG doesn't allow leafref= s in configuration to point to state data, it is necessary to put even the = default (system-controlled) RIB to the "rib" list and then refer to it from= "connected-rib". Perhaps it could be another YANG 1.1 issue to relax this rule about referen= ces from configuration to state data. They can often be useful and, as in t= his case, simplify the configuration. Lada =20=20 > > Yi > > On 3/26/14 9:25 AM, "Ladislav Lhotka" wrote: > >>Hi Yi, >> >>"Yi Yang (yiya)" writes: >> >>> Hi Lada, >>> >>> In the current model, default-ribs will exist only when feature >>> multiple-ribs exists. This is contradictory to what people are familiar >>>in >>> the real world deployment -- default-ribs always exist. >> >>Note that default-ribs depends on that feature only in configuration but >>not in operational state data. So, the idea is that the system puts the >>name(s) of default RIB(s) into the default-rib list in operational state, >>so the client is able to learn easily what the default (and only) RIB is >>for each address family. But whenever the server doesn't support multiple >>RIBs per address family, there is no point to have default-ribs as a >>configuration option. >> >>Does it make sense? >> >>Thanks, Lada >> >>> >>> To reflect such an expectation, I suggest to keep default-ribs >>> unconditionally. Instead, move the conditions to the ribs -- if feature >>> multiple-ribs doesn't exist, only one rib is allowed per address family. >>> >>> Yi >>> >>> >>> On 3/19/14 3:51 AM, "Ladislav Lhotka" wrote: >>> >>>>"Derek Man-Kit Yeung (myeung)" writes: >>>> >>>>> On 3/14/14 12:49 PM, "Ladislav Lhotka" wrote: >>>>> >>>>>> >>>>>>On 14 Mar 2014, at 20:32, Derek Man-Kit Yeung (myeung) >>>>>> >>>>>>wrote: >>>>>> >>>>>>>=20 >>>>>>>=20 >>>>>>> On 3/7/14 2:29 PM, "Ladislav Lhotka" wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 07 Mar 2014, at 22:52, Yi Yang (yiya) wrote: >>>>>>>>=20 >>>>>>>>> One thing is missing from the data model is association with vrf. >>>>>>>>=20 >>>>>>>> I agree with what Martin wrote in a parallel thread. I believe the >>>>>>>> routing module (and YANG augment statement) provide sufficient >>>>>>>>hooks >>>>>>>>for >>>>>>>> implementing VRF as a specific type of routing-instance. >>>>>>>=20 >>>>>>>=20 >>>>>>> The draft mentioned the routing-instance could be used to >>>>>>>represents a >>>>>>> logical router. >>>>>>>=20 >>>>>>> The term "logical router" in one or more vendors mean a partition of >>>>>>>the >>>>>>> physical router into multiple logical units, each could have >>>>>>>multiple >>>>>>>VRFs. >>>>>>>=20 >>>>>>> Does the draft intend to manage "logical router" in the above >>>>>>>definition? >>>>>>> Some clarification will be useful. >>>>>> >>>>>>One way to implement this is to introduce two types of routing >>>>>>instances, >>>>>>say 'logical-router=C2=B9 and =C5=92vrf=C2=B9. The =C5=92vrf=C2=B9 ty= pe then would have another >>>>>>leaf linking it to a logical router. This is quite like the various >>>>>>methods of interface stacking, see the examples in >>>>>>draft-ietf-netmod-interfaces-cfg-16. >>>>>> >>>>>>Lada >>>>> >>>>> >>>>> It is one way. >>>>> However, given that current model that everything is put inside a >>>>> routing-instance, things like RIB, routing-protocols etc are no longer >>>>> needed directly under the 'logical-router'. >>>> >>>>Note that RIBs are not inside "routing-instance", although an >>>>implementation may define some RIBs to be routing-instance-specific. >>>> >>>>> What needed in the 'logical router' are resources allocation like >>>>> interfaces, CPU etc. >>>> >>>>"interfaces" is a container inside "routing-instance", and "cpu" can be >>>>easily added by another module via augmentation. >>>> >>>>> Though routing-instance could be augmented to include 'logical router' >>>>> specific field and add new condition to restrict existing leaf that no >>>>> long apply, I think a new container above routing-instance is cleaner. >>>>>It >>>>> could be a new data model that reference the definition in the current >>>>> draft. >>>> >>>>I guess part of the confusion stems from the name "routing-instance" >>>>which already means a particular (platform-specific) style of router >>>>virtualization. Earlier revisions of the draft used "router" list in >>>>this >>>>place but it was an specific requirement of I2RS folks to change this >>>>name to "routing-instance". Oh well ... >>>> >>>>So please keep in mind that "routing-instance" can really mean different >>>>things depending on its type (and can be augmented in different ways >>>>depending on the type). Again, this approach is very similar to the one >>>>adopted for the "interface" list in "ietf-interfaces" module. >>>> >>>>Lada >>>> >>>>> >>>>> - Derek >>>>> >>>>>> >>>>>>>=20 >>>>>>> - Derek >>>>>>>=20 >>>>>>>>=20 >>>>>>>> I think though that other work extending the routing module is much >>>>>>>>more >>>>>>>> needed, namely vendor-neutral data models for routing protocols. >>>>>>>>=20 >>>>>>>> The consensus of the NETMOD WG was that these new modules should be >>>>>>>> developed by experts in the Routing Area (VRF in the MPLS WG?). The >>>>>>>> NETMOD WG and YANG Doctors will certainly help but the bulk of this >>>>>>>>work >>>>>>>> should be done by domain experts. >>>>>>>>=20 >>>>>>>> Lada >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Another concern I have is about address family. To facilitate a >>>>>>>>>query >>>>>>>>> based on AFI only, or SAFI only, it seems more convenient to use >>>>>>>>>two >>>>>>>>> leafs >>>>>>>>> (AFI and SAFI) instead of one (AFI-SAFI). >>>>>>>>>=20 >>>>>>>>> Yi >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 1/10/14 8:30 AM, "internet-drafts@ietf.org" >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> 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 >>>>>>>>>>Working >>>>>>>>>> Group of the IETF. >>>>>>>>>>=20 >>>>>>>>>> Title : A YANG Data Model for Routing Management >>>>>>>>>> Author : Ladislav Lhotka >>>>>>>>>> Filename : draft-ietf-netmod-routing-cfg-13.txt >>>>>>>>>> Pages : 95 >>>>>>>>>> Date : 2014-01-10 >>>>>>>>>>=20 >>>>>>>>>> Abstract: >>>>>>>>>> This document contains a specification of three YANG modules. >>>>>>>>>> Together they form the core routing data model which serves as a >>>>>>>>>> framework for configuring and managing a routing subsystem. It >>>>>>>>>>is >>>>>>>>>> expected that these modules will be augmented by additional YANG >>>>>>>>>> modules defining data models for individual routing protocols and >>>>>>>>>> other related functions. The core routing data model provides >>>>>>>>>>common >>>>>>>>>> building blocks for such extensions - routing instances, routes, >>>>>>>>>> routing information bases (RIB), routing protocols and route >>>>>>>>>>filters. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ >>>>>>>>>>=20 >>>>>>>>>> There's also a htmlized version available at: >>>>>>>>>> http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13 >>>>>>>>>>=20 >>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg= -13 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> netmod mailing list >>>>>>>>>> netmod@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>>>>>=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 >>>>>> >>>>>>-- >>>>>>Ladislav Lhotka, CZ.NIC Labs >>>>>>PGP Key ID: E74E8C0C >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>>--=20 >>>>Ladislav Lhotka, CZ.NIC Labs >>>>PGP Key ID: E74E8C0C >>> >> >>--=20 >>Ladislav Lhotka, CZ.NIC Labs >>PGP Key ID: E74E8C0C > --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Mar 27 07:10:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A091A06FD for ; Thu, 27 Mar 2014 07:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbuXhQ6AXuQj for ; Thu, 27 Mar 2014 07:10:35 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id EDF4B1A0713 for ; Thu, 27 Mar 2014 07:10:34 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id e9so4243072qcy.26 for ; Thu, 27 Mar 2014 07:10:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=izR8W9vXn/o/Jju0mobWbFBTeYj2SMO6pf6v1F1INJw=; b=AmLHQuB7P7nMDhGI3dpY+1tKMHUQkjiuwMt0ZLrdthSjsd1RlIFntwyldPpmJkKRNe M0pvWjaBnjut1dgOQ9c8ndN0wMW++ksy3RlpVQtS+y3KFiyyWEubLMTy+XeeLSEG6uCu ah2ojRovlOP9RiF6EtISOrDo1TaA86Qhlfqoux7hp8ExBVOYvbAjD56IdaATa7Vagtnd 2cGEpdkbdYe/cScQQA1DREy5pq6BrsLx1A0g/DiXJMmuKx2BqqJgRZg4XOb0YDzbSMfc JTnqZXsrSZtMl1UvOePKJX3WXRlvJKrFoRsXJL9xFHKFlQh70LIFoqUk7ixGn8sBDQS5 gl8g== X-Gm-Message-State: ALoCoQkrC0swtn7tvT//Nz8EUu+95OZswAw5YwU6fP9yBUOpb2C6s6LX7McUfZIaOMoKRogVZzeH MIME-Version: 1.0 X-Received: by 10.229.81.71 with SMTP id w7mr2415941qck.8.1395929433074; Thu, 27 Mar 2014 07:10:33 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Thu, 27 Mar 2014 07:10:32 -0700 (PDT) In-Reply-To: <20140327.084630.744815920970998929.mbj@tail-f.com> References: <20140327.080423.2031221427554871516.mbj@tail-f.com> <20140327.084630.744815920970998929.mbj@tail-f.com> Date: Thu, 27 Mar 2014 07:10:32 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a1133b2b0fd9cf304f5972517 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/O5GLAv0o5fPj98Na616X4rAa_NM Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 14:10:38 -0000 --001a1133b2b0fd9cf304f5972517 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 27, 2014 at 12:46 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Thu, Mar 27, 2014 at 12:04 AM, Martin Bjorklund > wrote: > > > > > Hi Alex, > > > > > > "Alexander Clemm (alex)" wrote: > > > > I agree that this type of solution is what is needed. This has been > > > > our experience developing models as well. > > > > The solution as indicated in the example, that the augmenting module > > > > itself (and hence "top-level" data nodes) cannot be mandatory, but > > > > that in the presence of container data nodes, nodes underneath can > > > > become mandatory, makes a lot of sense to me. > > > > > > I don't really understand what you mean. Do you agree with Lada that > > > augment should be allowed to add mandatory nodes, or do you agree with > > > Andy that it is ok to augment e.g. a P-container which defines the > > > mandatory nodes? > > > > > > > > > > IMO we cannot break existing clients. > > +1 > > > Since it is possible to add the nodes in a way that does not expose the > > mandatory > > nodes to an "old" create or merge, then that should always be used. > > Any create or merge that adds the P container (or list) has to do so > > correctly > > with the mandatory sub-nodes. > > I agree that this works, and probably is acceptable. However, as was > demonstrated earlier in this thread, there are situations where it > would be safe to augment a mandatory node, for example if an identity > is defined in the augmenting module, and the augment is made > conditional on that identity. I don't know if this can be captured in > plain text though. > > I am not seeing how this works: module A { container top { leaf a { type string; } } } module B { identity X { base XX; } leaf flag { type identityref { base XX; } } augment /A:top { leaf Y { when "/B:flag = 'B:X'"; mandatory true; type string; } } } The problem is that it doesn't matter if Y is conditional since /B:flag can be set by a new client. What matters is that an old client can use module A no matter what is happening with modules that augment module A. Maybe you have an example that shows how a mandatory node can be added to /A:top so that an old client can edit /A:top or /A:top/A:aa and not be impacted by the mandatory sibling of 'aa'. thanks, Andy > > /martin > --001a1133b2b0fd9cf304f5972517 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 27, 2014 at 12:46 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Thu, Mar 27, 2014 at 12:04 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Hi Alex,
> >
> > "Alexander Clemm (alex)" <alex@cisco.com> wrote:
> > > I agree that this type of solution is what is needed. =A0Thi= s has been
> > > our experience developing models as well.
> > > The solution as indicated in the example, that the augmentin= g module
> > > itself (and hence "top-level" data nodes) cannot b= e mandatory, but
> > > that in the presence of container data nodes, nodes undernea= th can
> > > become mandatory, makes a lot of sense to me.
> >
> > I don't really understand what you mean. =A0Do you agree with= Lada that
> > augment should be allowed to add mandatory nodes, or do you agree= with
> > Andy that it is ok to augment e.g. a P-container which defines th= e
> > mandatory nodes?
> >
> >
>
> IMO we cannot break existing clients.

+1

> Since it is possible to add the nodes in a way that does not expose th= e
> mandatory
> nodes to an "old" create or merge, then that should always b= e used.
> Any create or merge that adds the P container (or list) has to do so > correctly
> with the mandatory sub-nodes.

I agree that this works, and probably is acceptable. =A0However, as was
demonstrated earlier in this thread, there are situations where it
would be safe to augment a mandatory node, for example if an identity
is defined in the augmenting module, and the augment is made
conditional on that identity. =A0I don't know if this can be captured i= n
plain text though.



I am not seeing how this works:
=

module A {
=A0 =A0 container top {
= =A0 =A0 =A0 =A0 leaf a { type string; }
=A0 =A0 }
}

module B {
= =A0 =A0identity X { base XX; }

=A0 =A0 leaf flag {= type identityref { base XX; } }

=A0 =A0 augment /= A:top {
=A0 =A0 =A0 =A0 =A0leaf Y {
=A0 =A0 =A0 =A0 =A0 =A0 when "/B= :flag =3D 'B:X'";
=A0 =A0 =A0 =A0 =A0 =A0 mandatory = true;
=A0 =A0 =A0 =A0 =A0 =A0 type string;
=A0 =A0 =A0 = =A0 }
=A0 =A0 }
}


The problem is that it doesn't matter if Y is condi= tional since /B:flag can be
set by a new client. =A0What matters = is that an old client can use module A
no matter what is happenin= g with modules that augment module A.

Maybe you have an example that shows how a mandatory no= de can
be added to /A:top so that an old client can edit /A:top o= r /A:top/A:aa
and not be impacted by the mandatory sibling of = 9;aa'.


thanks,
Andy



=A0 =A0 =A0 =A0=A0

/martin

--001a1133b2b0fd9cf304f5972517-- From nobody Thu Mar 27 07:23:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161D01A0705 for ; Thu, 27 Mar 2014 07:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PH4o8PN38IVv for ; Thu, 27 Mar 2014 07:23:26 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5A81A0728 for ; Thu, 27 Mar 2014 07:23:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 89A47540796; Thu, 27 Mar 2014 15:23:23 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2K-Gw0PNg71; Thu, 27 Mar 2014 15:23:18 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 9136854071B; Thu, 27 Mar 2014 15:23:16 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman , Martin Bjorklund In-Reply-To: References: <20140327.080423.2031221427554871516.mbj@tail-f.com> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Thu, 27 Mar 2014 15:23:16 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wqDTaE92bxoK52MyogjC4DVnTg8 Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 14:23:29 -0000 Andy Bierman writes: > On Thu, Mar 27, 2014 at 12:04 AM, Martin Bjorklund wrote: > >> Hi Alex, >> >> "Alexander Clemm (alex)" wrote: >> > I agree that this type of solution is what is needed. This has been >> > our experience developing models as well. >> > The solution as indicated in the example, that the augmenting module >> > itself (and hence "top-level" data nodes) cannot be mandatory, but >> > that in the presence of container data nodes, nodes underneath can >> > become mandatory, makes a lot of sense to me. >> >> I don't really understand what you mean. Do you agree with Lada that >> augment should be allowed to add mandatory nodes, or do you agree with >> Andy that it is ok to augment e.g. a P-container which defines the >> mandatory nodes? >> >> > > IMO we cannot break existing clients. > Since it is possible to add the nodes in a way that does not expose the > mandatory > nodes to an "old" create or merge, then that should always be used. > Any create or merge that adds the P container (or list) has to do so > correctly > with the mandatory sub-nodes. I think this doesn't solve anything. Let's take the example of the "interface" list (which is a very typical use case) and assume the server and client want to use both the base and augmenting module that defines parameters for a particular interface type, say "foo". The client creates an new entry like "interface": { "name": "foo0", "type": "foo" } and can stop here because all foo parameters are inside a P-container. This may not be acceptable if some of the parameters are really required for a foo interface to work. The P-container makes no difference: the data model is still too loose. Lada > > > /martin >> > > > Andy > > > >> >> > --- Alex >> > >> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy >> > Bierman >> > Sent: Monday, March 24, 2014 2:30 PM >> > To: Ladislav Lhotka >> > Cc: netmod@ietf.org >> > Subject: Re: [netmod] allow mandatory nodes in augments >> > >> > >> > >> > On Mon, Mar 24, 2014 at 1:48 PM, Ladislav Lhotka >> > > wrote: >> > >> > On 24 Mar 2014, at 20:50, Andy Bierman >> > > wrote: >> > >> > > >> > > >> > > >> > > On Mon, Mar 24, 2014 at 12:11 PM, Ladislav Lhotka >> > > > wrote: >> > > >> > > On 24 Mar 2014, at 18:33, Andy Bierman >> > > > wrote: >> > > >> > > > >> > > > >> > > > >> > > > On Mon, Mar 24, 2014 at 10:03 AM, Ladislav Lhotka >> > > > > wrote: >> > > > * allow mandatory nodes in augments >> > > > >> > > > ** Description >> > > > >> > > > RFC 6020 states in >> > > > [[http://tools.ietf.org/html/rfc6020#section-7.15][Sec. 7.15]]: >> > > > >> > > > If the target node is in another module, then nodes added by the >> > > > augmentation MUST NOT be mandatory nodes (see Section 3.1). >> > > > >> > > > This rule was probably based on the assumption that augments will be >> > > > used for really optional data that can be safely ignored. However, as >> > > > it turned out, augments have become an essential tool for modular >> > > > development of YANG data models. In some cases, the inability to >> > > > define mandatory nodes in augments prevents the data modeller from >> > > > specifying desired schema constraints. >> > > > >> > > > For instance, >> > > > [[ >> http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-16#appendix-A][Appendix >> > > > A]] in "interfaces-cfg" shows how an Ethernet module can be written >> > > > that augments "if:interface". However, the container "ethernet" >> cannot >> > > > define any child leafs as mandatory even though it may be necessary >> > > > and would be normally done if the "ethernet" container was defined >> > > > directly in the "ietf-interfaces" module. >> > > > >> > > > ** Solution >> > > > >> > > > Remove the rule cited above. >> > > > >> > > > >> > > > >> > > > In the examples of this sort of augment usage, the augments are in >> > > > different >> > > > modules. There is no requirement that a server implement all-or-none >> > > > of >> > > > these modules, just because they happen to be published in 1 RFC. >> > > >> > > This is not what I am saying. >> > > >> > > > >> > > > The reason this rule exists is so a server implementation of the >> > > > augmenting module >> > > > does not break old clients that do not know about this module. They >> > > > will not provide >> > > > the mandatory values and edits will fail. (Bonica Principle again). >> > > >> > > I don't buy this principle. I have already argued that new >> > > non-mandatory data in server's model can lead to unexpected >> > > consequences if the client isn't aware of them, see >> > > >> > > http://www.ietf.org/mail-archive/web/netmod/current/msg09296.html >> > > >> > > >> > > >> > > If a new YANG object is defined such that it changes the way an >> > > existing >> > > YANG object works, then the new object is broken. >> > > >> > > An old client should be able to configure the objects it already knows >> > > and the request should not be rejected because of missing mandatory >> > > nodes. >> > > >> > > The server can pick reasonable defaults for the new objects without >> > > an old client needing to be re-coded. A client can use merge instead >> > > of replace to >> > > make sure that new objects do not get deleted. The new objects can be >> > > ignored >> > > for editing purposes. This is not true if the merge is rejected >> > > because of missing >> > > mandatory nodes. >> > >> > Let me rephrase the main point of this issue: Significant parts of our >> > core models are defined inside augments, with more to come (e.g., >> > modules for all interface type). These parts cannot have mandatory >> > contents due to that rule from sec. 7.15, which can be a serious >> > limitation because some parameters simply have no reasonable defaults >> > and have to be configured. The possibility of supporting old clients >> > (IMO dubious) does not outweigh this limitation. >> > >> > >> > If all these augments are in the same YANG module then the >> > augment-stmt is not >> > really needed and inline definitions should be used instead. >> > >> > If they are in different modules, then a server vendor may choose to >> > implement the augmenting >> > module in a later release than the base module. It doesn't matter that >> > a bunch of modules are >> > published around the same time. The likely case is that the >> > augmenting module is over a year later. >> > >> > It has nothing to do with YANG 1.0 vs. 1.1. >> > It is a bad idea to break old clients that don't know about the new >> > module. >> > >> > Note that it is possible to add new nodes, such that the sibling/child >> > nodes >> > to the augmented nodes are optional, but their descendant nodes are >> > mandatory. >> > This should be OK. An old client that provides just the base objects >> > in a >> > create or merge will not break if the new mandatory objects are >> > "protected" >> > via an extra layer: >> > >> > >> > container top { >> > leaf old-1 { type string; } >> > } >> > >> > >> > NOT OK: >> > >> > augment /top { >> > leaf from-augment-1 { >> > type string; >> > mandatory true; >> > } >> > } >> > >> > >> > >> > OK: >> > >> > augment /top { >> > container pcon { >> > presence "must exist to make the leaf mandatory"; >> > >> > leaf from-augment-1 { >> > type string; >> > mandatory true; >> > } >> > } >> > } >> > >> > >> > >> > Lada >> > >> > > >> > >> > >> > Andy >> > >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Mar 27 07:38:01 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DA21A00F9 for ; Thu, 27 Mar 2014 07:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXwxC3MzfO6f for ; Thu, 27 Mar 2014 07:37:56 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id D430C1A02DB for ; Thu, 27 Mar 2014 07:37:55 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id hw13so3796580qab.4 for ; Thu, 27 Mar 2014 07:37:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uQYA0bYjva/3X/+eRT7tUqAYfaOTqoaU08qWLny2t7Y=; b=mnpxqUdh/TeFNdDheRQC3fMuoo8lArtUHaPKwJt/OJBEhFtaPy+s4oO0Ctn2waVrj3 VeueOJrQDZ1nrcb3xDP4NPjOtg2CDrUgEMnQhOUQQApjCvNenVaOrR8jJNSJNa0RH9Mx HZYgo+xf2VoWqHnw4pwq9NdflrjmFf8clO9ApNIaV2enljNTfEPfdonA9npd12pouUVX 2V/4YzuU7qJ3QXtNrLGX8sEuSPkQfhEyKoA69Fq5cX3rdRPu4Ere4BBPJMs9rPTl6CwO rD/pisxsuGLFF67/JaXrzBO8Rru3pKi+dbMHzHE4Xmr9KuOPkwdawv6gPOTltuAVVHXi 3ccA== X-Gm-Message-State: ALoCoQm7yJyy5kp9WNYa4Kc0LtB9aIq2ZFK4xcJMXxlOwsOlQ7VZXhvojgRxVBZOIkxTTLHrBXNz MIME-Version: 1.0 X-Received: by 10.224.66.8 with SMTP id l8mr2601968qai.16.1395931073759; Thu, 27 Mar 2014 07:37:53 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Thu, 27 Mar 2014 07:37:53 -0700 (PDT) In-Reply-To: References: <20140327.080423.2031221427554871516.mbj@tail-f.com> Date: Thu, 27 Mar 2014 07:37:53 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c2c27ac8775d04f5978781 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Sb42jMj4xa4XvYt6T1bP1m4XIOE Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 14:37:59 -0000 --001a11c2c27ac8775d04f5978781 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 27, 2014 at 7:23 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Thu, Mar 27, 2014 at 12:04 AM, Martin Bjorklund > wrote: > > > >> Hi Alex, > >> > >> "Alexander Clemm (alex)" wrote: > >> > I agree that this type of solution is what is needed. This has been > >> > our experience developing models as well. > >> > The solution as indicated in the example, that the augmenting module > >> > itself (and hence "top-level" data nodes) cannot be mandatory, but > >> > that in the presence of container data nodes, nodes underneath can > >> > become mandatory, makes a lot of sense to me. > >> > >> I don't really understand what you mean. Do you agree with Lada that > >> augment should be allowed to add mandatory nodes, or do you agree with > >> Andy that it is ok to augment e.g. a P-container which defines the > >> mandatory nodes? > >> > >> > > > > IMO we cannot break existing clients. > > Since it is possible to add the nodes in a way that does not expose the > > mandatory > > nodes to an "old" create or merge, then that should always be used. > > Any create or merge that adds the P container (or list) has to do so > > correctly > > with the mandatory sub-nodes. > > I think this doesn't solve anything. Let's take the example of the > "interface" list (which is a very typical use case) and assume the server > and client want to use both the base and augmenting module that defines > parameters for a particular interface type, say "foo". The client creates > an new entry like > > "interface": { > "name": "foo0", > "type": "foo" > } > > and can stop here because all foo parameters are inside a P-container. > This may not be acceptable if some of the parameters are really required > for a foo interface to work. The P-container makes no difference: the data > model is still too loose. > > It doesn't matter that there might be some parameters that are needed. They have to be added correctly. They can be set by the server or a new client. The rules in sec. 10 are very clear. YANG is modular. An old client is not required in any way to use augmenting modules added after the client was written. The P-container wrapper is not itself mandatory so an old client can safely use create and merge without error (by ignoring the new P-container). This is how real software has to be maintained. Applications get coded to work with a specific release of a data model. If that code is working and deployed, then adding a new module in a future release cannot cause the deployed app to start getting validation errors. Lada > > Andy > > > > > > /martin > >> > > > > > > Andy > > > > > > > >> > >> > --- Alex > >> > > >> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy > >> > Bierman > >> > Sent: Monday, March 24, 2014 2:30 PM > >> > To: Ladislav Lhotka > >> > Cc: netmod@ietf.org > >> > Subject: Re: [netmod] allow mandatory nodes in augments > >> > > >> > > >> > > >> > On Mon, Mar 24, 2014 at 1:48 PM, Ladislav Lhotka > >> > > wrote: > >> > > >> > On 24 Mar 2014, at 20:50, Andy Bierman > >> > > wrote: > >> > > >> > > > >> > > > >> > > > >> > > On Mon, Mar 24, 2014 at 12:11 PM, Ladislav Lhotka > >> > > > wrote: > >> > > > >> > > On 24 Mar 2014, at 18:33, Andy Bierman > >> > > > wrote: > >> > > > >> > > > > >> > > > > >> > > > > >> > > > On Mon, Mar 24, 2014 at 10:03 AM, Ladislav Lhotka > >> > > > > wrote: > >> > > > * allow mandatory nodes in augments > >> > > > > >> > > > ** Description > >> > > > > >> > > > RFC 6020 states in > >> > > > [[http://tools.ietf.org/html/rfc6020#section-7.15][Sec. 7.15]]: > >> > > > > >> > > > If the target node is in another module, then nodes added by > the > >> > > > augmentation MUST NOT be mandatory nodes (see Section 3.1). > >> > > > > >> > > > This rule was probably based on the assumption that augments will > be > >> > > > used for really optional data that can be safely ignored. > However, as > >> > > > it turned out, augments have become an essential tool for modular > >> > > > development of YANG data models. In some cases, the inability to > >> > > > define mandatory nodes in augments prevents the data modeller from > >> > > > specifying desired schema constraints. > >> > > > > >> > > > For instance, > >> > > > [[ > >> > http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-16#appendix-A][Appendix > >> > > > A]] in "interfaces-cfg" shows how an Ethernet module can be > written > >> > > > that augments "if:interface". However, the container "ethernet" > >> cannot > >> > > > define any child leafs as mandatory even though it may be > necessary > >> > > > and would be normally done if the "ethernet" container was defined > >> > > > directly in the "ietf-interfaces" module. > >> > > > > >> > > > ** Solution > >> > > > > >> > > > Remove the rule cited above. > >> > > > > >> > > > > >> > > > > >> > > > In the examples of this sort of augment usage, the augments are in > >> > > > different > >> > > > modules. There is no requirement that a server implement > all-or-none > >> > > > of > >> > > > these modules, just because they happen to be published in 1 RFC. > >> > > > >> > > This is not what I am saying. > >> > > > >> > > > > >> > > > The reason this rule exists is so a server implementation of the > >> > > > augmenting module > >> > > > does not break old clients that do not know about this module. > They > >> > > > will not provide > >> > > > the mandatory values and edits will fail. (Bonica Principle > again). > >> > > > >> > > I don't buy this principle. I have already argued that new > >> > > non-mandatory data in server's model can lead to unexpected > >> > > consequences if the client isn't aware of them, see > >> > > > >> > > http://www.ietf.org/mail-archive/web/netmod/current/msg09296.html > >> > > > >> > > > >> > > > >> > > If a new YANG object is defined such that it changes the way an > >> > > existing > >> > > YANG object works, then the new object is broken. > >> > > > >> > > An old client should be able to configure the objects it already > knows > >> > > and the request should not be rejected because of missing mandatory > >> > > nodes. > >> > > > >> > > The server can pick reasonable defaults for the new objects without > >> > > an old client needing to be re-coded. A client can use merge > instead > >> > > of replace to > >> > > make sure that new objects do not get deleted. The new objects can > be > >> > > ignored > >> > > for editing purposes. This is not true if the merge is rejected > >> > > because of missing > >> > > mandatory nodes. > >> > > >> > Let me rephrase the main point of this issue: Significant parts of our > >> > core models are defined inside augments, with more to come (e.g., > >> > modules for all interface type). These parts cannot have mandatory > >> > contents due to that rule from sec. 7.15, which can be a serious > >> > limitation because some parameters simply have no reasonable defaults > >> > and have to be configured. The possibility of supporting old clients > >> > (IMO dubious) does not outweigh this limitation. > >> > > >> > > >> > If all these augments are in the same YANG module then the > >> > augment-stmt is not > >> > really needed and inline definitions should be used instead. > >> > > >> > If they are in different modules, then a server vendor may choose to > >> > implement the augmenting > >> > module in a later release than the base module. It doesn't matter that > >> > a bunch of modules are > >> > published around the same time. The likely case is that the > >> > augmenting module is over a year later. > >> > > >> > It has nothing to do with YANG 1.0 vs. 1.1. > >> > It is a bad idea to break old clients that don't know about the new > >> > module. > >> > > >> > Note that it is possible to add new nodes, such that the sibling/child > >> > nodes > >> > to the augmented nodes are optional, but their descendant nodes are > >> > mandatory. > >> > This should be OK. An old client that provides just the base objects > >> > in a > >> > create or merge will not break if the new mandatory objects are > >> > "protected" > >> > via an extra layer: > >> > > >> > > >> > container top { > >> > leaf old-1 { type string; } > >> > } > >> > > >> > > >> > NOT OK: > >> > > >> > augment /top { > >> > leaf from-augment-1 { > >> > type string; > >> > mandatory true; > >> > } > >> > } > >> > > >> > > >> > > >> > OK: > >> > > >> > augment /top { > >> > container pcon { > >> > presence "must exist to make the leaf mandatory"; > >> > > >> > leaf from-augment-1 { > >> > type string; > >> > mandatory true; > >> > } > >> > } > >> > } > >> > > >> > > >> > > >> > Lada > >> > > >> > > > >> > > >> > > >> > Andy > >> > > >> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --001a11c2c27ac8775d04f5978781 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 27, 2014 at 7:23 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:
Andy Bierman <andy@yumaworks.com> writes:

> On Thu, Mar 27, 2014 at 12:04 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
>> Hi Alex,
>>
>> "Alexander Clemm (alex)" <alex@cisco.com> wrote:
>> > I agree that this type of solution is what is needed. =A0This= has been
>> > our experience developing models as well.
>> > The solution as indicated in the example, that the augmenting= module
>> > itself (and hence "top-level" data nodes) cannot be= mandatory, but
>> > that in the presence of container data nodes, nodes underneat= h can
>> > become mandatory, makes a lot of sense to me.
>>
>> I don't really understand what you mean. =A0Do you agree with = Lada that
>> augment should be allowed to add mandatory nodes, or do you agree = with
>> Andy that it is ok to augment e.g. a P-container which defines the=
>> mandatory nodes?
>>
>>
>
> IMO we cannot break existing clients.
> Since it is possible to add the nodes in a way that does not expose th= e
> mandatory
> nodes to an "old" create or merge, then that should always b= e used.
> Any create or merge that adds the P container (or list) has to do so > correctly
> with the mandatory sub-nodes.

I think this doesn't solve anything. Let's take the example of the = "interface" list (which is a very typical use case) and assume th= e server and client want to use both the base and augmenting module that de= fines parameters for a particular interface type, say "foo". The = client creates an new entry like

"interface": {
=A0 "name": "foo0",
=A0 "type": "foo"
}

and can stop here because all foo parameters are inside a P-container. This= may not be acceptable if some of the parameters are really required for a = foo interface to work. The P-container makes no difference: the data model = is still too loose.



It doesn't matter t= hat there might be some parameters that are needed.
They have to = be added correctly. They can be set by the server or a new client.

The rules in sec. 10 are very clear. =A0YANG is modular= . =A0An old client is not
required in any way to use augmenting m= odules added after the client was written.

The P-c= ontainer wrapper is not itself mandatory so an old client can safely use
create and merge without error (by ignoring the new P-container).

This is how real software has to be maintained. =A0App= lications get coded
to work with a specific release of a data mod= el. If that code is working and
deployed, then adding a new module in a future release cannot cause th= e
deployed app to start getting validation errors.

=
Lada


Andy

=A0
>
>
> /martin
>>
>
>
> Andy
>
>
>
>>
>> > --- Alex
>> >
>> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy
>> > Bierman
>> > Sent: Monday, March 24, 2014 2:30 PM
>> > To: Ladislav Lhotka
>> > Cc: netmod@ietf.org >> > Subject: Re: [netmod] allow mandatory nodes in augments
>> >
>> >
>> >
>> > On Mon, Mar 24, 2014 at 1:48 PM, Ladislav Lhotka
>> > <lhotka@nic.cz<mai= lto:lhotka@nic.cz>> wrote:
>> >
>> > On 24 Mar 2014, at 20:50, Andy Bierman
>> > <andy@yumaworks.com<= /a><mailto:andy@yumaworks.com&= gt;> wrote:
>> >
>> > >
>> > >
>> > >
>> > > On Mon, Mar 24, 2014 at 12:11 PM, Ladislav Lhotka
>> > > <lhotka@nic.cz&l= t;mailto:lhotka@nic.cz>> wrote:<= br> >> > >
>> > > On 24 Mar 2014, at 18:33, Andy Bierman
>> > > <andy@yumaworks= .com<mailto:andy@yumaworks.com= >> wrote:
>> > >
>> > > >
>> > > >
>> > > >
>> > > > On Mon, Mar 24, 2014 at 10:03 AM, Ladislav Lhotka >> > > > <lhotka@nic.cz<= /a><mailto:lhotka@nic.cz>> wr= ote:
>> > > > * allow mandatory nodes in augments
>> > > >
>> > > > ** Description
>> > > >
>> > > > RFC 6020 states in
>> > > > [[http://tools.ietf.org/html/rfc6020#sectio= n-7.15][Sec. 7.15]]:
>> > > >
>> > > > =A0 =A0If the target node is in another module, the= n nodes added by the
>> > > > =A0 =A0augmentation MUST NOT be mandatory nodes (se= e Section 3.1).
>> > > >
>> > > > This rule was probably based on the assumption that= augments will be
>> > > > used for really optional data that can be safely ig= nored. However, as
>> > > > it turned out, augments have become an essential to= ol for modular
>> > > > development of YANG data models. In some cases, the= inability to
>> > > > define mandatory nodes in augments prevents the dat= a modeller from
>> > > > specifying desired schema constraints.
>> > > >
>> > > > For instance,
>> > > > [[
>> http://tools.ietf.org/html/= draft-ietf-netmod-interfaces-cfg-16#appendix-A][Appendix
>> > > > A]] in "interfaces-cfg" shows how an Ethe= rnet module can be written
>> > > > that augments "if:interface". However, th= e container "ethernet"
>> cannot
>> > > > define any child leafs as mandatory even though it = may be necessary
>> > > > and would be normally done if the "ethernet&qu= ot; container was defined
>> > > > directly in the "ietf-interfaces" module.=
>> > > >
>> > > > ** Solution
>> > > >
>> > > > Remove the rule cited above.
>> > > >
>> > > >
>> > > >
>> > > > In the examples of this sort of augment usage, the = augments are in
>> > > > different
>> > > > modules. =A0There is no requirement that a server i= mplement all-or-none
>> > > > of
>> > > > these modules, just because they happen to be publi= shed in 1 RFC.
>> > >
>> > > This is not what I am saying.
>> > >
>> > > >
>> > > > The reason this rule exists is so a server implemen= tation of the
>> > > > augmenting module
>> > > > does not break old clients that do not know about t= his module. =A0They
>> > > > will not provide
>> > > > the mandatory values and edits will fail. (Bonica P= rinciple again).
>> > >
>> > > I don't buy this principle. I have already argued th= at new
>> > > non-mandatory data in server's model can lead to une= xpected
>> > > consequences if the client isn't aware of them, see<= br> >> > >
>> > > http://www.ietf.org/mail-archive/we= b/netmod/current/msg09296.html
>> > >
>> > >
>> > >
>> > > If a new YANG object is defined such that it changes the= way an
>> > > existing
>> > > YANG object works, then the new object is broken.
>> > >
>> > > An old client should be able to configure the objects it= already knows
>> > > and the request should not be rejected because of missin= g mandatory
>> > > nodes.
>> > >
>> > > The server can pick reasonable defaults for the new obje= cts without
>> > > an old client needing to be re-coded. =A0A client can us= e merge instead
>> > > of replace to
>> > > make sure that new objects do not get deleted. The new o= bjects can be
>> > > ignored
>> > > for editing purposes. =A0This is not true if the merge i= s rejected
>> > > because of missing
>> > > mandatory nodes.
>> >
>> > Let me rephrase the main point of this issue: Significant par= ts of our
>> > core models are defined inside augments, with more to come (e= .g.,
>> > modules for all interface type). These parts cannot have mand= atory
>> > contents due to that rule from sec. 7.15, which can be a seri= ous
>> > limitation because some parameters simply have no reasonable = defaults
>> > and have to be configured. The possibility of supporting old = clients
>> > (IMO dubious) does not outweigh this limitation.
>> >
>> >
>> > If all these augments are in the same YANG module then the >> > augment-stmt is not
>> > really needed and inline definitions should be used instead.<= br> >> >
>> > If they are in different modules, then a server vendor may ch= oose to
>> > implement the augmenting
>> > module in a later release than the base module. It doesn'= t matter that
>> > a bunch of modules are
>> > published around the same time. =A0The likely case is that th= e
>> > augmenting module is over a year later.
>> >
>> > It has nothing to do with YANG 1.0 vs. 1.1.
>> > It is a bad idea to break old clients that don't know abo= ut the new
>> > module.
>> >
>> > Note that it is possible to add new nodes, such that the sibl= ing/child
>> > nodes
>> > to the augmented nodes are optional, but their descendant nod= es are
>> > mandatory.
>> > This should be OK. =A0An old client that provides just the ba= se objects
>> > in a
>> > create or merge will not break if the new mandatory objects a= re
>> > "protected"
>> > via an extra layer:
>> >
>> >
>> > =A0 =A0container top {
>> > =A0 =A0 =A0 leaf old-1 { type string; }
>> > =A0 =A0}
>> >
>> >
>> > NOT OK:
>> >
>> > =A0 =A0augment /top {
>> > =A0 =A0 =A0 =A0leaf from-augment-1 {
>> > =A0 =A0 =A0 =A0 =A0type string;
>> > =A0 =A0 =A0 =A0 =A0mandatory true;
>> > =A0 =A0 =A0 =A0}
>> > =A0 =A0}
>> >
>> >
>> >
>> > OK:
>> >
>> > =A0 =A0augment /top {
>> > =A0 =A0 =A0 =A0container pcon {
>> > =A0 =A0 =A0 =A0 =A0 =A0presence "must exist to make the = leaf mandatory";
>> >
>> > =A0 =A0 =A0 =A0 =A0 leaf from-augment-1 {
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0type string;
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0mandatory true;
>> > =A0 =A0 =A0 =A0 =A0 =A0}
>> > =A0 =A0 =A0 =A0 }
>> > =A0 =A0 }
>> >
>> >
>> >
>> > Lada
>> >
>> > >
>> >
>> >
>> > Andy
>> >
>>

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

--001a11c2c27ac8775d04f5978781-- From nobody Thu Mar 27 08:06:44 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4D71A0766 for ; Thu, 27 Mar 2014 08:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s91CoeO6feAb for ; Thu, 27 Mar 2014 08:06:24 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9121A0760 for ; Thu, 27 Mar 2014 08:06:21 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 34170140268; Thu, 27 Mar 2014 16:06:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395932778; bh=lEtOMqOlmfS2552EPc+lc0MG+Rzj8gXp7YL4p4NDhdY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=DHDS/n7LJQWZ2cMuTIJ0vSwt4dwFQ3ZzOmjvKJWXktQf9hmudohQPWOmCUSHx7Kno eHPuPKPdXp/okv+V81ZkJWferrLDVaDbr7vwnqWfXSR0AG7reUFPjyErbAiNF5TbFA ESxGMgJh8wKj78cWBSbqyLwVNwR2ElA/GDB4N+nk= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 27 Mar 2014 16:06:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140327.080423.2031221427554871516.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5hPLilXv3EInaODHNjJGKPK3htg Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 15:06:28 -0000 On 27 Mar 2014, at 15:37, Andy Bierman wrote: >=20 >=20 >=20 > On Thu, Mar 27, 2014 at 7:23 AM, Ladislav Lhotka = wrote: > Andy Bierman writes: >=20 > > On Thu, Mar 27, 2014 at 12:04 AM, Martin Bjorklund = wrote: > > > >> Hi Alex, > >> > >> "Alexander Clemm (alex)" wrote: > >> > I agree that this type of solution is what is needed. This has = been > >> > our experience developing models as well. > >> > The solution as indicated in the example, that the augmenting = module > >> > itself (and hence "top-level" data nodes) cannot be mandatory, = but > >> > that in the presence of container data nodes, nodes underneath = can > >> > become mandatory, makes a lot of sense to me. > >> > >> I don't really understand what you mean. Do you agree with Lada = that > >> augment should be allowed to add mandatory nodes, or do you agree = with > >> Andy that it is ok to augment e.g. a P-container which defines the > >> mandatory nodes? > >> > >> > > > > IMO we cannot break existing clients. > > Since it is possible to add the nodes in a way that does not expose = the > > mandatory > > nodes to an "old" create or merge, then that should always be used. > > Any create or merge that adds the P container (or list) has to do so > > correctly > > with the mandatory sub-nodes. >=20 > I think this doesn't solve anything. Let's take the example of the = "interface" list (which is a very typical use case) and assume the = server and client want to use both the base and augmenting module that = defines parameters for a particular interface type, say "foo". The = client creates an new entry like >=20 > "interface": { > "name": "foo0", > "type": "foo" > } >=20 > and can stop here because all foo parameters are inside a P-container. = This may not be acceptable if some of the parameters are really required = for a foo interface to work. The P-container makes no difference: the = data model is still too loose. >=20 >=20 >=20 > It doesn't matter that there might be some parameters that are needed. > They have to be added correctly. They can be set by the server or a = new client. I am talking about a new client, and I assume some items, such as = cryptographic data, cannot be set by the server. >=20 > The rules in sec. 10 are very clear. YANG is modular. An old client = is not > required in any way to use augmenting modules added after the client = was written. This could work in theory if augments were restricted to adding marginal = stuff, but as I wrote in the description of this issue, augments do some = heavy lifting in the core data models. For example, the routing module = is pretty much useless by itself, it has to be augmented by at least one = address-family specific module. >=20 > The P-container wrapper is not itself mandatory so an old client can = safely use > create and merge without error (by ignoring the new P-container). I don=92t get the benefit of this P-container, the problem is still the = same: the data model doesn=92t bind the client to configure parameters = that are in fact mandatory. >=20 > This is how real software has to be maintained. Applications get = coded > to work with a specific release of a data model. If that code is = working and > deployed, then adding a new module in a future release cannot cause = the > deployed app to start getting validation errors. This could work if the modules were totally isolated, or carefully = designed to support this kind of cherry-picking. But in general it is = unsafe: augmenting modules might add defaults that the server will use = even if the client isn=92t aware of them. Yes, as a client of an insurance company, I can also sign their contract = without reading the fine print =85 Lada >=20 > Lada >=20 >=20 > Andy >=20 > =20 > > > > > > /martin > >> > > > > > > Andy > > > > > > > >> > >> > --- Alex > >> > > >> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy > >> > Bierman > >> > Sent: Monday, March 24, 2014 2:30 PM > >> > To: Ladislav Lhotka > >> > Cc: netmod@ietf.org > >> > Subject: Re: [netmod] allow mandatory nodes in augments > >> > > >> > > >> > > >> > On Mon, Mar 24, 2014 at 1:48 PM, Ladislav Lhotka > >> > > wrote: > >> > > >> > On 24 Mar 2014, at 20:50, Andy Bierman > >> > > wrote: > >> > > >> > > > >> > > > >> > > > >> > > On Mon, Mar 24, 2014 at 12:11 PM, Ladislav Lhotka > >> > > > wrote: > >> > > > >> > > On 24 Mar 2014, at 18:33, Andy Bierman > >> > > > wrote: > >> > > > >> > > > > >> > > > > >> > > > > >> > > > On Mon, Mar 24, 2014 at 10:03 AM, Ladislav Lhotka > >> > > > > wrote: > >> > > > * allow mandatory nodes in augments > >> > > > > >> > > > ** Description > >> > > > > >> > > > RFC 6020 states in > >> > > > [[http://tools.ietf.org/html/rfc6020#section-7.15][Sec. = 7.15]]: > >> > > > > >> > > > If the target node is in another module, then nodes added = by the > >> > > > augmentation MUST NOT be mandatory nodes (see Section = 3.1). > >> > > > > >> > > > This rule was probably based on the assumption that augments = will be > >> > > > used for really optional data that can be safely ignored. = However, as > >> > > > it turned out, augments have become an essential tool for = modular > >> > > > development of YANG data models. In some cases, the inability = to > >> > > > define mandatory nodes in augments prevents the data modeller = from > >> > > > specifying desired schema constraints. > >> > > > > >> > > > For instance, > >> > > > [[ > >> = http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-16#appendix-A]= [Appendix > >> > > > A]] in "interfaces-cfg" shows how an Ethernet module can be = written > >> > > > that augments "if:interface". However, the container = "ethernet" > >> cannot > >> > > > define any child leafs as mandatory even though it may be = necessary > >> > > > and would be normally done if the "ethernet" container was = defined > >> > > > directly in the "ietf-interfaces" module. > >> > > > > >> > > > ** Solution > >> > > > > >> > > > Remove the rule cited above. > >> > > > > >> > > > > >> > > > > >> > > > In the examples of this sort of augment usage, the augments = are in > >> > > > different > >> > > > modules. There is no requirement that a server implement = all-or-none > >> > > > of > >> > > > these modules, just because they happen to be published in 1 = RFC. > >> > > > >> > > This is not what I am saying. > >> > > > >> > > > > >> > > > The reason this rule exists is so a server implementation of = the > >> > > > augmenting module > >> > > > does not break old clients that do not know about this = module. They > >> > > > will not provide > >> > > > the mandatory values and edits will fail. (Bonica Principle = again). > >> > > > >> > > I don't buy this principle. I have already argued that new > >> > > non-mandatory data in server's model can lead to unexpected > >> > > consequences if the client isn't aware of them, see > >> > > > >> > > = http://www.ietf.org/mail-archive/web/netmod/current/msg09296.html > >> > > > >> > > > >> > > > >> > > If a new YANG object is defined such that it changes the way an > >> > > existing > >> > > YANG object works, then the new object is broken. > >> > > > >> > > An old client should be able to configure the objects it = already knows > >> > > and the request should not be rejected because of missing = mandatory > >> > > nodes. > >> > > > >> > > The server can pick reasonable defaults for the new objects = without > >> > > an old client needing to be re-coded. A client can use merge = instead > >> > > of replace to > >> > > make sure that new objects do not get deleted. The new objects = can be > >> > > ignored > >> > > for editing purposes. This is not true if the merge is = rejected > >> > > because of missing > >> > > mandatory nodes. > >> > > >> > Let me rephrase the main point of this issue: Significant parts = of our > >> > core models are defined inside augments, with more to come (e.g., > >> > modules for all interface type). These parts cannot have = mandatory > >> > contents due to that rule from sec. 7.15, which can be a serious > >> > limitation because some parameters simply have no reasonable = defaults > >> > and have to be configured. The possibility of supporting old = clients > >> > (IMO dubious) does not outweigh this limitation. > >> > > >> > > >> > If all these augments are in the same YANG module then the > >> > augment-stmt is not > >> > really needed and inline definitions should be used instead. > >> > > >> > If they are in different modules, then a server vendor may choose = to > >> > implement the augmenting > >> > module in a later release than the base module. It doesn't matter = that > >> > a bunch of modules are > >> > published around the same time. The likely case is that the > >> > augmenting module is over a year later. > >> > > >> > It has nothing to do with YANG 1.0 vs. 1.1. > >> > It is a bad idea to break old clients that don't know about the = new > >> > module. > >> > > >> > Note that it is possible to add new nodes, such that the = sibling/child > >> > nodes > >> > to the augmented nodes are optional, but their descendant nodes = are > >> > mandatory. > >> > This should be OK. An old client that provides just the base = objects > >> > in a > >> > create or merge will not break if the new mandatory objects are > >> > "protected" > >> > via an extra layer: > >> > > >> > > >> > container top { > >> > leaf old-1 { type string; } > >> > } > >> > > >> > > >> > NOT OK: > >> > > >> > augment /top { > >> > leaf from-augment-1 { > >> > type string; > >> > mandatory true; > >> > } > >> > } > >> > > >> > > >> > > >> > OK: > >> > > >> > augment /top { > >> > container pcon { > >> > presence "must exist to make the leaf mandatory"; > >> > > >> > leaf from-augment-1 { > >> > type string; > >> > mandatory true; > >> > } > >> > } > >> > } > >> > > >> > > >> > > >> > Lada > >> > > >> > > > >> > > >> > > >> > Andy > >> > > >> >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Mar 27 08:18:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 579B31A02DB for ; Thu, 27 Mar 2014 08:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jF3P4IUvZrDf for ; Thu, 27 Mar 2014 08:18:03 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D09D21A0146 for ; Thu, 27 Mar 2014 08:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14098; q=dns/txt; s=iport; t=1395933481; x=1397143081; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/x/r4Fk5yLFe7sii+Uz1Gacikrwm+YeyZN8Zi0BmCrA=; b=NELxtxkqwAIAqj6GbrVIBhsGMsPIyN4v1oWuHLtA66/GTSr2L0742QTv 9MgcSn+k/dSIaq9faAvgh5wH2QlOmB8/sINwbskXmSyApLcGsjFFx71C8 jrGj0TLAOB0FCz7jJoIhDUNTR0Z/cs77de9NSt1Rb+60M4HoQjncBJzjq o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMFAO5ANFOtJXG+/2dsb2JhbABZgwY7UQaDCrgbhmpRGYECFnSCJQEBAQQBAQEgETcDCxACAQgYAgImAgICJQsVEAIEAQ0FCYdwCAWuDaJoF4EpjRczB4JvgUkEmE2BM5EBgy6CKw X-IronPort-AV: E=Sophos;i="4.97,743,1389744000"; d="scan'208";a="313333500" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 27 Mar 2014 15:17:52 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2RFHpFO005899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Mar 2014 15:17:51 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.37]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Thu, 27 Mar 2014 10:17:51 -0500 From: "Yi Yang (yiya)" To: Ladislav Lhotka , "Derek Man-Kit Yeung (myeung)" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt Thread-Index: AQHPDgglsV7ZhSMgp02l6cqKlZJTf5rW54cAgAAKUQCACr4yAIAABNeAgAZ/kACAAJNSgIAKXeIAgAD/3wCAADoPAIABWMqA///bxAA= Date: Thu, 27 Mar 2014 15:17:51 +0000 Message-ID: References: <20140110133016.24678.42711.idtracker@ietfa.amsl.com> <9C81158E-5B4C-4479-AEA5-23CBCC020ADD@nic.cz> <0ED855DA-51BE-4DE6-AB22-E1A9E04C0E5F@nic.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [64.102.95.103] Content-Type: text/plain; charset="utf-8" Content-ID: <7092E7F62DDCA84D84ECFE1DE45D79E8@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/sJRtjS8e4gYRLfp-3O_Pd0qnI6U Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 15:18:06 -0000 SGkgTGFkYSwNCg0KSW5saW5lLi4uDQoNCk9uIDMvMjcvMTQgOToyNyBBTSwgIkxhZGlzbGF2IExo b3RrYSIgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KDQo+IllpIFlhbmcgKHlpeWEpIiA8eWl5YUBj aXNjby5jb20+IHdyaXRlczoNCj4NCj4+IEhpIExhZGEsDQo+Pg0KPj4gQWhhLiBTbyB3aGVuIG11 bHRpcGxlLXJpYnMgaXMgbm90IHN1cHBvcnRlZCwgdGhlIGRlZmF1bHQtcmlicyBvbmx5IGV4aXN0 DQo+PiBpbiB0aGUgb3BlcmF0aW9uYWwgYnV0IG5vdCBpbiBjb25maWd1cmF0aW9uLg0KPg0KPlJp Z2h0Lg0KPg0KPj4NCj4+IEJ1dCBpbiB0aGF0IGNhc2UsIHNob3VsZCB3ZSBzdGlsbCBhbGxvdyB1 c2VycyB0byBjb25maWd1cmUgdGhlDQo+PiBjb3JyZXNwb25kaW5nIHJpYiBlbnRyeSBpbiB0aGUg cmlicz8NCj4NCj5JdCBpcyBzdGlsbCBuZWVkZWQgZm9yIHNwZWNpZnlpbmcgcm91dGUgZmlsdGVy cyBiZXR3ZWVuIGEgcm91dGluZw0KPnByb3RvY29sIGFuZCB0aGUgZGVmYXVsdCByb3V0aW5nIHRh YmxlLiBUaGlzIGlzIGRvbmUgdmlhIHRoZQ0KPiJjb25uZWN0ZWQtcmliIiBsaXN0IHdob3NlIGtl eXMgYXJlIHJlZmVyZW5jZXMgdG8gcm91dGluZyB0YWJsZXMuIFNpbmNlDQo+WUFORyBkb2Vzbid0 IGFsbG93IGxlYWZyZWZzIGluIGNvbmZpZ3VyYXRpb24gdG8gcG9pbnQgdG8gc3RhdGUgZGF0YSwg aXQNCj5pcyBuZWNlc3NhcnkgdG8gcHV0IGV2ZW4gdGhlIGRlZmF1bHQgKHN5c3RlbS1jb250cm9s bGVkKSBSSUIgdG8gdGhlICJyaWIiDQo+bGlzdCBhbmQgdGhlbiByZWZlciB0byBpdCBmcm9tICJj b25uZWN0ZWQtcmliIi4NCg0KQWN0dWFsbHksIGNvbm5lY3RlZC1yaWJzIGhhcyBhIGRlcGVuZGVu Y3kgb24gZmVhdHVyZSBtdWx0aXBsZS1yaWJzIGFzIHdlbGwuDQoNCistLXJ3IGNvbm5lY3RlZC1y aWJzIHttdWx0aXBsZS1yaWJzfT8NCg0KDQpZaQ0KDQoNCg0KPg0KPlBlcmhhcHMgaXQgY291bGQg YmUgYW5vdGhlciBZQU5HIDEuMSBpc3N1ZSB0byByZWxheCB0aGlzIHJ1bGUgYWJvdXQNCj5yZWZl cmVuY2VzIGZyb20gY29uZmlndXJhdGlvbiB0byBzdGF0ZSBkYXRhLiBUaGV5IGNhbiBvZnRlbiBi ZSB1c2VmdWwNCj5hbmQsIGFzIGluIHRoaXMgY2FzZSwgc2ltcGxpZnkgdGhlIGNvbmZpZ3VyYXRp b24uDQo+DQo+TGFkYQ0KPiAgDQo+Pg0KPj4gWWkNCj4+DQo+PiBPbiAzLzI2LzE0IDk6MjUgQU0s ICJMYWRpc2xhdiBMaG90a2EiIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4+DQo+Pj5IaSBZaSwN Cj4+Pg0KPj4+IllpIFlhbmcgKHlpeWEpIiA8eWl5YUBjaXNjby5jb20+IHdyaXRlczoNCj4+Pg0K Pj4+PiBIaSBMYWRhLA0KPj4+Pg0KPj4+PiBJbiB0aGUgY3VycmVudCBtb2RlbCwgZGVmYXVsdC1y aWJzIHdpbGwgZXhpc3Qgb25seSB3aGVuIGZlYXR1cmUNCj4+Pj4gbXVsdGlwbGUtcmlicyBleGlz dHMuIFRoaXMgaXMgY29udHJhZGljdG9yeSB0byB3aGF0IHBlb3BsZSBhcmUNCj4+Pj5mYW1pbGlh cg0KPj4+PmluDQo+Pj4+IHRoZSByZWFsIHdvcmxkIGRlcGxveW1lbnQgIC0tIGRlZmF1bHQtcmli cyBhbHdheXMgZXhpc3QuDQo+Pj4NCj4+Pk5vdGUgdGhhdCBkZWZhdWx0LXJpYnMgZGVwZW5kcyBv biB0aGF0IGZlYXR1cmUgb25seSBpbiBjb25maWd1cmF0aW9uIGJ1dA0KPj4+bm90IGluIG9wZXJh dGlvbmFsIHN0YXRlIGRhdGEuIFNvLCB0aGUgaWRlYSBpcyB0aGF0IHRoZSBzeXN0ZW0gcHV0cyB0 aGUNCj4+Pm5hbWUocykgb2YgZGVmYXVsdCBSSUIocykgaW50byB0aGUgZGVmYXVsdC1yaWIgbGlz dCBpbiBvcGVyYXRpb25hbA0KPj4+c3RhdGUsDQo+Pj5zbyB0aGUgY2xpZW50IGlzIGFibGUgdG8g bGVhcm4gZWFzaWx5IHdoYXQgdGhlIGRlZmF1bHQgKGFuZCBvbmx5KSBSSUIgaXMNCj4+PmZvciBl YWNoIGFkZHJlc3MgZmFtaWx5LiBCdXQgd2hlbmV2ZXIgdGhlIHNlcnZlciBkb2Vzbid0IHN1cHBv cnQNCj4+Pm11bHRpcGxlDQo+Pj5SSUJzIHBlciBhZGRyZXNzIGZhbWlseSwgdGhlcmUgaXMgbm8g cG9pbnQgdG8gaGF2ZSBkZWZhdWx0LXJpYnMgYXMgYQ0KPj4+Y29uZmlndXJhdGlvbiBvcHRpb24u DQo+Pj4NCj4+PkRvZXMgaXQgbWFrZSBzZW5zZT8NCj4+Pg0KPj4+VGhhbmtzLCBMYWRhDQo+Pj4N Cj4+Pj4NCj4+Pj4gVG8gcmVmbGVjdCBzdWNoIGFuIGV4cGVjdGF0aW9uLCBJIHN1Z2dlc3QgdG8g a2VlcCBkZWZhdWx0LXJpYnMNCj4+Pj4gdW5jb25kaXRpb25hbGx5LiBJbnN0ZWFkLCBtb3ZlIHRo ZSBjb25kaXRpb25zIHRvIHRoZSByaWJzIC0tIGlmDQo+Pj4+ZmVhdHVyZQ0KPj4+PiBtdWx0aXBs ZS1yaWJzIGRvZXNuJ3QgZXhpc3QsIG9ubHkgb25lIHJpYiBpcyBhbGxvd2VkIHBlciBhZGRyZXNz DQo+Pj4+ZmFtaWx5Lg0KPj4+Pg0KPj4+PiBZaQ0KPj4+Pg0KPj4+Pg0KPj4+PiBPbiAzLzE5LzE0 IDM6NTEgQU0sICJMYWRpc2xhdiBMaG90a2EiIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4+Pj4N Cj4+Pj4+IkRlcmVrIE1hbi1LaXQgWWV1bmcgKG15ZXVuZykiIDxteWV1bmdAY2lzY28uY29tPiB3 cml0ZXM6DQo+Pj4+Pg0KPj4+Pj4+IE9uIDMvMTQvMTQgMTI6NDkgUE0sICJMYWRpc2xhdiBMaG90 a2EiIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pk9uIDE0 IE1hciAyMDE0LCBhdCAyMDozMiwgRGVyZWsgTWFuLUtpdCBZZXVuZyAobXlldW5nKQ0KPj4+Pj4+ PjxteWV1bmdAY2lzY28uY29tPg0KPj4+Pj4+Pndyb3RlOg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gDQo+ Pj4+Pj4+PiANCj4+Pj4+Pj4+IE9uIDMvNy8xNCAyOjI5IFBNLCAiTGFkaXNsYXYgTGhvdGthIiA8 bGhvdGthQG5pYy5jej4gd3JvdGU6DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBP biAwNyBNYXIgMjAxNCwgYXQgMjI6NTIsIFlpIFlhbmcgKHlpeWEpIDx5aXlhQGNpc2NvLmNvbT4g d3JvdGU6DQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IE9uZSB0aGluZyBpcyBtaXNzaW5nIGZyb20g dGhlIGRhdGEgbW9kZWwgaXMgYXNzb2NpYXRpb24gd2l0aA0KPj4+Pj4+Pj4+PnZyZi4NCj4+Pj4+ Pj4+PiANCj4+Pj4+Pj4+PiBJIGFncmVlIHdpdGggd2hhdCBNYXJ0aW4gd3JvdGUgaW4gYSBwYXJh bGxlbCB0aHJlYWQuIEkgYmVsaWV2ZQ0KPj4+Pj4+Pj4+dGhlDQo+Pj4+Pj4+Pj4gcm91dGluZyBt b2R1bGUgKGFuZCBZQU5HIGF1Z21lbnQgc3RhdGVtZW50KSBwcm92aWRlIHN1ZmZpY2llbnQNCj4+ Pj4+Pj4+Pmhvb2tzDQo+Pj4+Pj4+Pj5mb3INCj4+Pj4+Pj4+PiBpbXBsZW1lbnRpbmcgVlJGIGFz IGEgc3BlY2lmaWMgdHlwZSBvZiByb3V0aW5nLWluc3RhbmNlLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+ PiANCj4+Pj4+Pj4+IFRoZSBkcmFmdCBtZW50aW9uZWQgdGhlIHJvdXRpbmctaW5zdGFuY2UgY291 bGQgYmUgdXNlZCB0bw0KPj4+Pj4+Pj5yZXByZXNlbnRzIGENCj4+Pj4+Pj4+IGxvZ2ljYWwgcm91 dGVyLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBUaGUgdGVybSAibG9naWNhbCByb3V0ZXIiIGluIG9u ZSBvciBtb3JlIHZlbmRvcnMgbWVhbiBhIHBhcnRpdGlvbg0KPj4+Pj4+Pj5vZg0KPj4+Pj4+Pj50 aGUNCj4+Pj4+Pj4+IHBoeXNpY2FsIHJvdXRlciBpbnRvIG11bHRpcGxlIGxvZ2ljYWwgdW5pdHMs IGVhY2ggY291bGQgaGF2ZQ0KPj4+Pj4+Pj5tdWx0aXBsZQ0KPj4+Pj4+Pj5WUkZzLg0KPj4+Pj4+ Pj4gDQo+Pj4+Pj4+PiBEb2VzIHRoZSBkcmFmdCBpbnRlbmQgdG8gbWFuYWdlICJsb2dpY2FsIHJv dXRlciIgaW4gdGhlIGFib3ZlDQo+Pj4+Pj4+PmRlZmluaXRpb24/DQo+Pj4+Pj4+PiBTb21lIGNs YXJpZmljYXRpb24gd2lsbCBiZSB1c2VmdWwuDQo+Pj4+Pj4+DQo+Pj4+Pj4+T25lIHdheSB0byBp bXBsZW1lbnQgdGhpcyBpcyB0byBpbnRyb2R1Y2UgdHdvIHR5cGVzIG9mIHJvdXRpbmcNCj4+Pj4+ Pj5pbnN0YW5jZXMsDQo+Pj4+Pj4+c2F5ICdsb2dpY2FsLXJvdXRlcsK5IGFuZCDFknZyZsK5LiBU aGUgxZJ2cmbCuSB0eXBlIHRoZW4gd291bGQgaGF2ZQ0KPj4+Pj4+PmFub3RoZXINCj4+Pj4+Pj5s ZWFmIGxpbmtpbmcgaXQgdG8gYSBsb2dpY2FsIHJvdXRlci4gVGhpcyBpcyBxdWl0ZSBsaWtlIHRo ZSB2YXJpb3VzDQo+Pj4+Pj4+bWV0aG9kcyBvZiBpbnRlcmZhY2Ugc3RhY2tpbmcsIHNlZSB0aGUg ZXhhbXBsZXMgaW4NCj4+Pj4+Pj5kcmFmdC1pZXRmLW5ldG1vZC1pbnRlcmZhY2VzLWNmZy0xNi4N Cj4+Pj4+Pj4NCj4+Pj4+Pj5MYWRhDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEl0IGlzIG9uZSB3 YXkuDQo+Pj4+Pj4gSG93ZXZlciwgZ2l2ZW4gdGhhdCBjdXJyZW50IG1vZGVsIHRoYXQgZXZlcnl0 aGluZyBpcyBwdXQgaW5zaWRlIGENCj4+Pj4+PiByb3V0aW5nLWluc3RhbmNlLCB0aGluZ3MgbGlr ZSBSSUIsIHJvdXRpbmctcHJvdG9jb2xzIGV0YyBhcmUgbm8NCj4+Pj4+Pmxvbmdlcg0KPj4+Pj4+ IG5lZWRlZCBkaXJlY3RseSB1bmRlciB0aGUgJ2xvZ2ljYWwtcm91dGVyJy4NCj4+Pj4+DQo+Pj4+ Pk5vdGUgdGhhdCBSSUJzIGFyZSBub3QgaW5zaWRlICJyb3V0aW5nLWluc3RhbmNlIiwgYWx0aG91 Z2ggYW4NCj4+Pj4+aW1wbGVtZW50YXRpb24gbWF5IGRlZmluZSBzb21lIFJJQnMgdG8gYmUgcm91 dGluZy1pbnN0YW5jZS1zcGVjaWZpYy4NCj4+Pj4+DQo+Pj4+Pj4gV2hhdCBuZWVkZWQgaW4gdGhl ICdsb2dpY2FsIHJvdXRlcicgYXJlIHJlc291cmNlcyBhbGxvY2F0aW9uIGxpa2UNCj4+Pj4+PiBp bnRlcmZhY2VzLCBDUFUgZXRjLg0KPj4+Pj4NCj4+Pj4+ImludGVyZmFjZXMiIGlzIGEgY29udGFp bmVyIGluc2lkZSAicm91dGluZy1pbnN0YW5jZSIsIGFuZCAiY3B1IiBjYW4NCj4+Pj4+YmUNCj4+ Pj4+ZWFzaWx5IGFkZGVkIGJ5IGFub3RoZXIgbW9kdWxlIHZpYSBhdWdtZW50YXRpb24uDQo+Pj4+ Pg0KPj4+Pj4+IFRob3VnaCByb3V0aW5nLWluc3RhbmNlIGNvdWxkIGJlIGF1Z21lbnRlZCB0byBp bmNsdWRlICdsb2dpY2FsDQo+Pj4+Pj5yb3V0ZXInDQo+Pj4+Pj4gc3BlY2lmaWMgZmllbGQgYW5k IGFkZCBuZXcgY29uZGl0aW9uIHRvIHJlc3RyaWN0IGV4aXN0aW5nIGxlYWYgdGhhdA0KPj4+Pj4+ bm8NCj4+Pj4+PiBsb25nIGFwcGx5LCBJIHRoaW5rIGEgbmV3IGNvbnRhaW5lciBhYm92ZSByb3V0 aW5nLWluc3RhbmNlIGlzDQo+Pj4+Pj5jbGVhbmVyLg0KPj4+Pj4+SXQNCj4+Pj4+PiBjb3VsZCBi ZSBhIG5ldyBkYXRhIG1vZGVsIHRoYXQgcmVmZXJlbmNlIHRoZSBkZWZpbml0aW9uIGluIHRoZQ0K Pj4+Pj4+Y3VycmVudA0KPj4+Pj4+IGRyYWZ0Lg0KPj4+Pj4NCj4+Pj4+SSBndWVzcyBwYXJ0IG9m IHRoZSBjb25mdXNpb24gc3RlbXMgZnJvbSB0aGUgbmFtZSAicm91dGluZy1pbnN0YW5jZSINCj4+ Pj4+d2hpY2ggYWxyZWFkeSBtZWFucyBhIHBhcnRpY3VsYXIgKHBsYXRmb3JtLXNwZWNpZmljKSBz dHlsZSBvZiByb3V0ZXINCj4+Pj4+dmlydHVhbGl6YXRpb24uIEVhcmxpZXIgcmV2aXNpb25zIG9m IHRoZSBkcmFmdCB1c2VkICJyb3V0ZXIiIGxpc3QgaW4NCj4+Pj4+dGhpcw0KPj4+Pj5wbGFjZSBi dXQgaXQgd2FzIGFuIHNwZWNpZmljIHJlcXVpcmVtZW50IG9mIEkyUlMgZm9sa3MgdG8gY2hhbmdl IHRoaXMNCj4+Pj4+bmFtZSB0byAicm91dGluZy1pbnN0YW5jZSIuIE9oIHdlbGwgLi4uDQo+Pj4+ Pg0KPj4+Pj5TbyBwbGVhc2Uga2VlcCBpbiBtaW5kIHRoYXQgInJvdXRpbmctaW5zdGFuY2UiIGNh biByZWFsbHkgbWVhbg0KPj4+Pj5kaWZmZXJlbnQNCj4+Pj4+dGhpbmdzIGRlcGVuZGluZyBvbiBp dHMgdHlwZSAoYW5kIGNhbiBiZSBhdWdtZW50ZWQgaW4gZGlmZmVyZW50IHdheXMNCj4+Pj4+ZGVw ZW5kaW5nIG9uIHRoZSB0eXBlKS4gQWdhaW4sIHRoaXMgYXBwcm9hY2ggaXMgdmVyeSBzaW1pbGFy IHRvIHRoZQ0KPj4+Pj5vbmUNCj4+Pj4+YWRvcHRlZCBmb3IgdGhlICJpbnRlcmZhY2UiIGxpc3Qg aW4gImlldGYtaW50ZXJmYWNlcyIgbW9kdWxlLg0KPj4+Pj4NCj4+Pj4+TGFkYQ0KPj4+Pj4NCj4+ Pj4+Pg0KPj4+Pj4+IC0gRGVyZWsNCj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+ PiAtIERlcmVrDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBJIHRoaW5rIHRob3Vn aCB0aGF0IG90aGVyIHdvcmsgZXh0ZW5kaW5nIHRoZSByb3V0aW5nIG1vZHVsZSBpcw0KPj4+Pj4+ Pj4+bXVjaA0KPj4+Pj4+Pj4+bW9yZQ0KPj4+Pj4+Pj4+IG5lZWRlZCwgbmFtZWx5IHZlbmRvci1u ZXV0cmFsIGRhdGEgbW9kZWxzIGZvciByb3V0aW5nIHByb3RvY29scy4NCj4+Pj4+Pj4+PiANCj4+ Pj4+Pj4+PiBUaGUgY29uc2Vuc3VzIG9mIHRoZSBORVRNT0QgV0cgd2FzIHRoYXQgdGhlc2UgbmV3 IG1vZHVsZXMgc2hvdWxkDQo+Pj4+Pj4+Pj5iZQ0KPj4+Pj4+Pj4+IGRldmVsb3BlZCBieSBleHBl cnRzIGluIHRoZSBSb3V0aW5nIEFyZWEgKFZSRiBpbiB0aGUgTVBMUyBXRz8pLg0KPj4+Pj4+Pj4+ VGhlDQo+Pj4+Pj4+Pj4gTkVUTU9EIFdHIGFuZCBZQU5HIERvY3RvcnMgd2lsbCBjZXJ0YWlubHkg aGVscCBidXQgdGhlIGJ1bGsgb2YNCj4+Pj4+Pj4+PnRoaXMNCj4+Pj4+Pj4+PndvcmsNCj4+Pj4+ Pj4+PiBzaG91bGQgYmUgZG9uZSBieSBkb21haW4gZXhwZXJ0cy4NCj4+Pj4+Pj4+PiANCj4+Pj4+ Pj4+PiBMYWRhDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBBbm90aGVyIGNv bmNlcm4gSSBoYXZlIGlzIGFib3V0IGFkZHJlc3MgZmFtaWx5LiBUbyBmYWNpbGl0YXRlIGENCj4+ Pj4+Pj4+Pj5xdWVyeQ0KPj4+Pj4+Pj4+PiBiYXNlZCBvbiBBRkkgb25seSwgb3IgU0FGSSBvbmx5 LCBpdCBzZWVtcyBtb3JlIGNvbnZlbmllbnQgdG8gdXNlDQo+Pj4+Pj4+Pj4+dHdvDQo+Pj4+Pj4+ Pj4+IGxlYWZzDQo+Pj4+Pj4+Pj4+IChBRkkgYW5kIFNBRkkpIGluc3RlYWQgb2Ygb25lIChBRkkt U0FGSSkuDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBZaQ0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+ Pj4gDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gT24gMS8xMC8xNCA4OjMw IEFNLCAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIg0KPj4+Pj4+Pj4+PiA8aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPg0KPj4+Pj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+ PiANCj4+Pj4+Pj4+Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRo ZSBvbi1saW5lDQo+Pj4+Pj4+Pj4+PkludGVybmV0LURyYWZ0cw0KPj4+Pj4+Pj4+Pj4gZGlyZWN0 b3JpZXMuDQo+Pj4+Pj4+Pj4+PiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBORVRD T05GIERhdGEgTW9kZWxpbmcgTGFuZ3VhZ2UNCj4+Pj4+Pj4+Pj4+V29ya2luZw0KPj4+Pj4+Pj4+ Pj4gR3JvdXAgb2YgdGhlIElFVEYuDQo+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+ICAgICAgVGl0 bGUgICAgICAgICAgIDogQSBZQU5HIERhdGEgTW9kZWwgZm9yIFJvdXRpbmcgTWFuYWdlbWVudA0K Pj4+Pj4+Pj4+Pj4gICAgICBBdXRob3IgICAgICAgICAgOiBMYWRpc2xhdiBMaG90a2ENCj4+Pj4+ Pj4+Pj4+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy0x My50eHQNCj4+Pj4+Pj4+Pj4+IAlQYWdlcyAgICAgICAgICAgOiA5NQ0KPj4+Pj4+Pj4+Pj4gCURh dGUgICAgICAgICAgICA6IDIwMTQtMDEtMTANCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gQWJz dHJhY3Q6DQo+Pj4+Pj4+Pj4+PiBUaGlzIGRvY3VtZW50IGNvbnRhaW5zIGEgc3BlY2lmaWNhdGlv biBvZiB0aHJlZSBZQU5HIG1vZHVsZXMuDQo+Pj4+Pj4+Pj4+PiBUb2dldGhlciB0aGV5IGZvcm0g dGhlIGNvcmUgcm91dGluZyBkYXRhIG1vZGVsIHdoaWNoIHNlcnZlcyBhcw0KPj4+Pj4+Pj4+Pj5h DQo+Pj4+Pj4+Pj4+PiBmcmFtZXdvcmsgZm9yIGNvbmZpZ3VyaW5nIGFuZCBtYW5hZ2luZyBhIHJv dXRpbmcgc3Vic3lzdGVtLiAgSXQNCj4+Pj4+Pj4+Pj4+aXMNCj4+Pj4+Pj4+Pj4+IGV4cGVjdGVk IHRoYXQgdGhlc2UgbW9kdWxlcyB3aWxsIGJlIGF1Z21lbnRlZCBieSBhZGRpdGlvbmFsDQo+Pj4+ Pj4+Pj4+PllBTkcNCj4+Pj4+Pj4+Pj4+IG1vZHVsZXMgZGVmaW5pbmcgZGF0YSBtb2RlbHMgZm9y IGluZGl2aWR1YWwgcm91dGluZyBwcm90b2NvbHMNCj4+Pj4+Pj4+Pj4+YW5kDQo+Pj4+Pj4+Pj4+ PiBvdGhlciByZWxhdGVkIGZ1bmN0aW9ucy4gIFRoZSBjb3JlIHJvdXRpbmcgZGF0YSBtb2RlbCBw cm92aWRlcw0KPj4+Pj4+Pj4+Pj5jb21tb24NCj4+Pj4+Pj4+Pj4+IGJ1aWxkaW5nIGJsb2NrcyBm b3Igc3VjaCBleHRlbnNpb25zIC0gcm91dGluZyBpbnN0YW5jZXMsDQo+Pj4+Pj4+Pj4+PnJvdXRl cywNCj4+Pj4+Pj4+Pj4+IHJvdXRpbmcgaW5mb3JtYXRpb24gYmFzZXMgKFJJQiksIHJvdXRpbmcg cHJvdG9jb2xzIGFuZCByb3V0ZQ0KPj4+Pj4+Pj4+Pj5maWx0ZXJzLg0KPj4+Pj4+Pj4+Pj4gDQo+ Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdl IGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4+Pj4+Pj4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmcvDQo+Pj4+Pj4+Pj4+PiANCj4+ Pj4+Pj4+Pj4+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0K Pj4+Pj4+Pj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2Qt cm91dGluZy1jZmctMTMNCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gQSBkaWZmIGZyb20gdGhl IHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+ Pj4+Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbmV0bW9kLXJv dXRpbmctY2ZnLTENCj4+Pj4+Pj4+Pj4+Mw0KPj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+PiANCj4+ Pj4+Pj4+Pj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lDQo+Pj4+Pj4+Pj4+Pm9mDQo+Pj4+Pj4+Pj4+PiBzdWJtaXNzaW9uDQo+ Pj4+Pj4+Pj4+PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0DQo+Pj4+Pj4+Pj4+PnRvb2xzLmlldGYub3JnLg0KPj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+ Pj4+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAg YXQ6DQo+Pj4+Pj4+Pj4+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4+ Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+Pj4+Pj4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+ Pj4gbmV0bW9kQGlldGYub3JnDQo+Pj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldG1vZA0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+Pj4gbmV0bW9kIG1h aWxpbmcgbGlzdA0KPj4+Pj4+Pj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4+Pj4+Pj4+PiANCj4+Pj4+ Pj4+PiAtLQ0KPj4+Pj4+Pj4+IExhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj4+Pj4+Pj4+ PiBQR1AgS2V5IElEOiBFNzRFOEMwQw0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4+Pj4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+ IG5ldG1vZEBpZXRmLm9yZw0KPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4NCj4+Pj4+Pj4tLQ0KPj4+Pj4+Pkxh ZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj4+Pj4+Pj5QR1AgS2V5IElEOiBFNzRFOEMwQw0K Pj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4t LSANCj4+Pj4+TGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPj4+Pj5QR1AgS2V5IElEOiBF NzRFOEMwQw0KPj4+Pg0KPj4+DQo+Pj4tLSANCj4+PkxhZGlzbGF2IExob3RrYSwgQ1ouTklDIExh YnMNCj4+PlBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+Pg0KPg0KPi0tIA0KPkxhZGlzbGF2IExob3Rr YSwgQ1ouTklDIExhYnMNCj5QR1AgS2V5IElEOiBFNzRFOEMwQw0KDQo= From nobody Thu Mar 27 08:29:52 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C801A0322 for ; Thu, 27 Mar 2014 08:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5m8sPdIYEY5h for ; Thu, 27 Mar 2014 08:29:47 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E36601A0147 for ; Thu, 27 Mar 2014 08:29:46 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 1EE1413F686; Thu, 27 Mar 2014 16:29:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395934184; bh=hJ6Bxdx0KXfU8aYF0P18XfalRzggBxHBVwkeV8B2/iA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=s2iJgx3VjtUdAfYhF6NQZz/xKd2+kVC9LNfL1h0pUcSPUuGvAnIjZ0J/2mUt5Zb9M eBv0m8M69bLu2ObywiG4YH0418GwukSMoU0zcPbKOYp1WPH2YLCM36RVX2v4c1AiQU B7CyMeqWkHPYlMYr1LP9AGMCO625J6H557x/tFLA= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 27 Mar 2014 16:29:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2830A589-DCCF-47C8-A066-D416C752D48C@nic.cz> References: <20140110133016.24678.42711.idtracker@ietfa.amsl.com> <9C81158E-5B4C-4479-AEA5-23CBCC020ADD@nic.cz> <0ED855DA-51BE-4DE6-AB22-E1A9E04C0E5F@nic.cz> To: "Yi Yang (yiya)" X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/PdjJe8gC_4Nk2a25m5KBE1pmPTI Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 15:29:50 -0000 On 27 Mar 2014, at 16:17, Yi Yang (yiya) wrote: > Hi Lada, >=20 > Inline... >=20 > On 3/27/14 9:27 AM, "Ladislav Lhotka" wrote: >=20 >> "Yi Yang (yiya)" writes: >>=20 >>> Hi Lada, >>>=20 >>> Aha. So when multiple-ribs is not supported, the default-ribs only = exist >>> in the operational but not in configuration. >>=20 >> Right. >>=20 >>>=20 >>> But in that case, should we still allow users to configure the >>> corresponding rib entry in the ribs? >>=20 >> It is still needed for specifying route filters between a routing >> protocol and the default routing table. This is done via the >> "connected-rib" list whose keys are references to routing tables. = Since >> YANG doesn't allow leafrefs in configuration to point to state data, = it >> is necessary to put even the default (system-controlled) RIB to the = "rib" >> list and then refer to it from "connected-rib". >=20 > Actually, connected-ribs has a dependency on feature multiple-ribs as = well. >=20 > +--rw connected-ribs {multiple-ribs}? So this looks like a mistake, good that you spotted it! The possibility = of filtering routes from/to routing protocol instances (which includes = redistribution between protocols) is important even with a single RIB. I will correct it in the next revision, probably/hopefully after IETF = last call. Thanks, Lada >=20 >=20 > Yi >=20 >=20 >=20 >>=20 >> Perhaps it could be another YANG 1.1 issue to relax this rule about >> references from configuration to state data. They can often be useful >> and, as in this case, simplify the configuration. >>=20 >> Lada >>=20 >>>=20 >>> Yi >>>=20 >>> On 3/26/14 9:25 AM, "Ladislav Lhotka" wrote: >>>=20 >>>> Hi Yi, >>>>=20 >>>> "Yi Yang (yiya)" writes: >>>>=20 >>>>> Hi Lada, >>>>>=20 >>>>> In the current model, default-ribs will exist only when feature >>>>> multiple-ribs exists. This is contradictory to what people are >>>>> familiar >>>>> in >>>>> the real world deployment -- default-ribs always exist. >>>>=20 >>>> Note that default-ribs depends on that feature only in = configuration but >>>> not in operational state data. So, the idea is that the system puts = the >>>> name(s) of default RIB(s) into the default-rib list in operational >>>> state, >>>> so the client is able to learn easily what the default (and only) = RIB is >>>> for each address family. But whenever the server doesn't support >>>> multiple >>>> RIBs per address family, there is no point to have default-ribs as = a >>>> configuration option. >>>>=20 >>>> Does it make sense? >>>>=20 >>>> Thanks, Lada >>>>=20 >>>>>=20 >>>>> To reflect such an expectation, I suggest to keep default-ribs >>>>> unconditionally. Instead, move the conditions to the ribs -- if >>>>> feature >>>>> multiple-ribs doesn't exist, only one rib is allowed per address >>>>> family. >>>>>=20 >>>>> Yi >>>>>=20 >>>>>=20 >>>>> On 3/19/14 3:51 AM, "Ladislav Lhotka" wrote: >>>>>=20 >>>>>> "Derek Man-Kit Yeung (myeung)" writes: >>>>>>=20 >>>>>>> On 3/14/14 12:49 PM, "Ladislav Lhotka" wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 14 Mar 2014, at 20:32, Derek Man-Kit Yeung (myeung) >>>>>>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 3/7/14 2:29 PM, "Ladislav Lhotka" wrote: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 07 Mar 2014, at 22:52, Yi Yang (yiya) = wrote: >>>>>>>>>>=20 >>>>>>>>>>> One thing is missing from the data model is association with >>>>>>>>>>> vrf. >>>>>>>>>>=20 >>>>>>>>>> I agree with what Martin wrote in a parallel thread. I = believe >>>>>>>>>> the >>>>>>>>>> routing module (and YANG augment statement) provide = sufficient >>>>>>>>>> hooks >>>>>>>>>> for >>>>>>>>>> implementing VRF as a specific type of routing-instance. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The draft mentioned the routing-instance could be used to >>>>>>>>> represents a >>>>>>>>> logical router. >>>>>>>>>=20 >>>>>>>>> The term "logical router" in one or more vendors mean a = partition >>>>>>>>> of >>>>>>>>> the >>>>>>>>> physical router into multiple logical units, each could have >>>>>>>>> multiple >>>>>>>>> VRFs. >>>>>>>>>=20 >>>>>>>>> Does the draft intend to manage "logical router" in the above >>>>>>>>> definition? >>>>>>>>> Some clarification will be useful. >>>>>>>>=20 >>>>>>>> One way to implement this is to introduce two types of routing >>>>>>>> instances, >>>>>>>> say 'logical-router=B9 and =8Cvrf=B9. The =8Cvrf=B9 type then = would have >>>>>>>> another >>>>>>>> leaf linking it to a logical router. This is quite like the = various >>>>>>>> methods of interface stacking, see the examples in >>>>>>>> draft-ietf-netmod-interfaces-cfg-16. >>>>>>>>=20 >>>>>>>> Lada >>>>>>>=20 >>>>>>>=20 >>>>>>> It is one way. >>>>>>> However, given that current model that everything is put inside = a >>>>>>> routing-instance, things like RIB, routing-protocols etc are no >>>>>>> longer >>>>>>> needed directly under the 'logical-router'. >>>>>>=20 >>>>>> Note that RIBs are not inside "routing-instance", although an >>>>>> implementation may define some RIBs to be = routing-instance-specific. >>>>>>=20 >>>>>>> What needed in the 'logical router' are resources allocation = like >>>>>>> interfaces, CPU etc. >>>>>>=20 >>>>>> "interfaces" is a container inside "routing-instance", and "cpu" = can >>>>>> be >>>>>> easily added by another module via augmentation. >>>>>>=20 >>>>>>> Though routing-instance could be augmented to include 'logical >>>>>>> router' >>>>>>> specific field and add new condition to restrict existing leaf = that >>>>>>> no >>>>>>> long apply, I think a new container above routing-instance is >>>>>>> cleaner. >>>>>>> It >>>>>>> could be a new data model that reference the definition in the >>>>>>> current >>>>>>> draft. >>>>>>=20 >>>>>> I guess part of the confusion stems from the name = "routing-instance" >>>>>> which already means a particular (platform-specific) style of = router >>>>>> virtualization. Earlier revisions of the draft used "router" list = in >>>>>> this >>>>>> place but it was an specific requirement of I2RS folks to change = this >>>>>> name to "routing-instance". Oh well ... >>>>>>=20 >>>>>> So please keep in mind that "routing-instance" can really mean >>>>>> different >>>>>> things depending on its type (and can be augmented in different = ways >>>>>> depending on the type). Again, this approach is very similar to = the >>>>>> one >>>>>> adopted for the "interface" list in "ietf-interfaces" module. >>>>>>=20 >>>>>> Lada >>>>>>=20 >>>>>>>=20 >>>>>>> - Derek >>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> - Derek >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> I think though that other work extending the routing module = is >>>>>>>>>> much >>>>>>>>>> more >>>>>>>>>> needed, namely vendor-neutral data models for routing = protocols. >>>>>>>>>>=20 >>>>>>>>>> The consensus of the NETMOD WG was that these new modules = should >>>>>>>>>> be >>>>>>>>>> developed by experts in the Routing Area (VRF in the MPLS = WG?). >>>>>>>>>> The >>>>>>>>>> NETMOD WG and YANG Doctors will certainly help but the bulk = of >>>>>>>>>> this >>>>>>>>>> work >>>>>>>>>> should be done by domain experts. >>>>>>>>>>=20 >>>>>>>>>> Lada >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Another concern I have is about address family. To = facilitate a >>>>>>>>>>> query >>>>>>>>>>> based on AFI only, or SAFI only, it seems more convenient to = use >>>>>>>>>>> two >>>>>>>>>>> leafs >>>>>>>>>>> (AFI and SAFI) instead of one (AFI-SAFI). >>>>>>>>>>>=20 >>>>>>>>>>> Yi >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 1/10/14 8:30 AM, "internet-drafts@ietf.org" >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> 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 >>>>>>>>>>>> Working >>>>>>>>>>>> Group of the IETF. >>>>>>>>>>>>=20 >>>>>>>>>>>> Title : A YANG Data Model for Routing = Management >>>>>>>>>>>> Author : Ladislav Lhotka >>>>>>>>>>>> Filename : draft-ietf-netmod-routing-cfg-13.txt >>>>>>>>>>>> Pages : 95 >>>>>>>>>>>> Date : 2014-01-10 >>>>>>>>>>>>=20 >>>>>>>>>>>> Abstract: >>>>>>>>>>>> This document contains a specification of three YANG = modules. >>>>>>>>>>>> Together they form the core routing data model which serves = as >>>>>>>>>>>> a >>>>>>>>>>>> framework for configuring and managing a routing subsystem. = It >>>>>>>>>>>> is >>>>>>>>>>>> expected that these modules will be augmented by additional >>>>>>>>>>>> YANG >>>>>>>>>>>> modules defining data models for individual routing = protocols >>>>>>>>>>>> and >>>>>>>>>>>> other related functions. The core routing data model = provides >>>>>>>>>>>> common >>>>>>>>>>>> building blocks for such extensions - routing instances, >>>>>>>>>>>> routes, >>>>>>>>>>>> routing information bases (RIB), routing protocols and = route >>>>>>>>>>>> filters. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>>> = https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ >>>>>>>>>>>>=20 >>>>>>>>>>>> There's also a htmlized version available at: >>>>>>>>>>>> http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13 >>>>>>>>>>>>=20 >>>>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>>>>=20 >>>>>>>>>>>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg-1 >>>>>>>>>>>> 3 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> 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. >>>>>>>>>>>>=20 >>>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> netmod mailing list >>>>>>>>>>>> netmod@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>>>>>>>=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 >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>> PGP Key ID: E74E8C0C >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>> PGP Key ID: E74E8C0C >>>>>=20 >>>>=20 >>>> --=20 >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>=20 >>=20 >> --=20 >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Mar 27 08:35:59 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E5E1A067A for ; Thu, 27 Mar 2014 08:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKVbx4kqa9fU for ; Thu, 27 Mar 2014 08:35:52 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 461951A0400 for ; Thu, 27 Mar 2014 08:35:52 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e16so4398995qcx.41 for ; Thu, 27 Mar 2014 08:35:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tWuflFIbiTeYyEZs+bM52uU0dSGPSEpM7lc4iExMeGo=; b=lU3DU4zKmuOjyFZ5LLm72pvLjdUPC/4HDnkmnzijD4WBsKf8O4yQnO3xkXqIOppxv0 g2/LD3cZaaujKwR01Gr9cP3sq9vmWmz+Chmxq4edEwvCZ3np++xqVdlawKh9cD/hrpie nWVR2NcFSZwe1R7HRb5YOr9Wk+qjrhco61EhJlGI8FxeKkrf9r6V6XO5Mc1d5UZCsl0Q OErpneAHpRRGdII4MEInTK9ix1V+sH5MHndgBnEHMMOIsaINqCheXcSU6BVCL7sXLBk4 l6J6OtaDrL1O+eIHnmWG2A687GwxYkSx8JN92xTb35bG/dujvb5mkBk5+H5fLU+TBh9K Gf7w== X-Gm-Message-State: ALoCoQn9wwyglgykmkuxuY5QpIiJHB2GOKG8pt/6F+zE3P7rmFUpCteZYTqZZzLYJEAIXBm/zGTW MIME-Version: 1.0 X-Received: by 10.224.16.69 with SMTP id n5mr1425600qaa.7.1395934550256; Thu, 27 Mar 2014 08:35:50 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Thu, 27 Mar 2014 08:35:50 -0700 (PDT) In-Reply-To: References: <20140327.080423.2031221427554871516.mbj@tail-f.com> Date: Thu, 27 Mar 2014 08:35:50 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7bea3986ff9da604f5985671 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/oAnXRNW7-kjG2TNphYrkR3remDM Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 15:35:58 -0000 --047d7bea3986ff9da604f5985671 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 27, 2014 at 8:06 AM, Ladislav Lhotka wrote: > > On 27 Mar 2014, at 15:37, Andy Bierman wrote: > > > > > > > > > On Thu, Mar 27, 2014 at 7:23 AM, Ladislav Lhotka wrote: > > Andy Bierman writes: > > > > > On Thu, Mar 27, 2014 at 12:04 AM, Martin Bjorklund > wrote: > > > > > >> Hi Alex, > > >> > > >> "Alexander Clemm (alex)" wrote: > > >> > I agree that this type of solution is what is needed. This has been > > >> > our experience developing models as well. > > >> > The solution as indicated in the example, that the augmenting module > > >> > itself (and hence "top-level" data nodes) cannot be mandatory, but > > >> > that in the presence of container data nodes, nodes underneath can > > >> > become mandatory, makes a lot of sense to me. > > >> > > >> I don't really understand what you mean. Do you agree with Lada that > > >> augment should be allowed to add mandatory nodes, or do you agree with > > >> Andy that it is ok to augment e.g. a P-container which defines the > > >> mandatory nodes? > > >> > > >> > > > > > > IMO we cannot break existing clients. > > > Since it is possible to add the nodes in a way that does not expose the > > > mandatory > > > nodes to an "old" create or merge, then that should always be used. > > > Any create or merge that adds the P container (or list) has to do so > > > correctly > > > with the mandatory sub-nodes. > > > > I think this doesn't solve anything. Let's take the example of the > "interface" list (which is a very typical use case) and assume the server > and client want to use both the base and augmenting module that defines > parameters for a particular interface type, say "foo". The client creates > an new entry like > > > > "interface": { > > "name": "foo0", > > "type": "foo" > > } > > > > and can stop here because all foo parameters are inside a P-container. > This may not be acceptable if some of the parameters are really required > for a foo interface to work. The P-container makes no difference: the data > model is still too loose. > > > > > > > > It doesn't matter that there might be some parameters that are needed. > > They have to be added correctly. They can be set by the server or a new > client. > > I am talking about a new client, and I assume some items, such as > cryptographic data, cannot be set by the server. > > > > > The rules in sec. 10 are very clear. YANG is modular. An old client is > not > > required in any way to use augmenting modules added after the client was > written. > > This could work in theory if augments were restricted to adding marginal > stuff, but as I wrote in the description of this issue, augments do some > heavy lifting in the core data models. For example, the routing module is > pretty much useless by itself, it has to be augmented by at least one > address-family specific module. > > > > > The P-container wrapper is not itself mandatory so an old client can > safely use > > create and merge without error (by ignoring the new P-container). > > I don't get the benefit of this P-container, the problem is still the > same: the data model doesn't bind the client to configure parameters that > are in fact mandatory. > I do not agree that mandatory objects can be added via augments without breaking the contract specified by the augmented module. You have to up > > > > > This is how real software has to be maintained. Applications get coded > > to work with a specific release of a data model. If that code is working > and > > deployed, then adding a new module in a future release cannot cause the > > deployed app to start getting validation errors. > > This could work if the modules were totally isolated, or carefully > designed to support this kind of cherry-picking. But in general it is > unsafe: augmenting modules might add defaults that the server will use even > if the client isn't aware of them. > > Yes, as a client of an insurance company, I can also sign their contract > without reading the fine print ... > > from RFC 6020, sec. 10: New data definition statements may be added if they do not add mandatory nodes (Section 3.1) to existing nodes or at the top level in a module or submodule, or if they are conditionally dependent on a new feature (i.e., have an "if-feature" statement that refers to a new feature). The old client did read the fine print in module A. New contracts (augmenting modules) have to add content in a way that allows the old client to opt-in. New parameters that augment the interface need to require the conceptual service or feature to be enabled (create P-container) before any mandatory parameters for that feature can be required. I think the text above prevents any mandatory child nodes to ever be added, even if it is done inline in a new module revision. The if-feature text does not help an old-client/new-server if the module is updated. The feature was not in the revision of the module the old client knows. This is no different than adding mandatory nodes directly. (The if-feature text is irrelevant). It should be OK to add new mandatory child nodes directly to a new module revision. The old client only has a contract for module A, rev N. It should be OK to add more requirements in a new contract. Augments is not the same, because the revision for module A does not change. Lada > > > Andy > > > > Lada > > > > > > Andy > > > > > > > > > > > > > /martin > > >> > > > > > > > > > Andy > > > > > > > > > > > >> > > >> > --- Alex > > >> > > > >> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy > > >> > Bierman > > >> > Sent: Monday, March 24, 2014 2:30 PM > > >> > To: Ladislav Lhotka > > >> > Cc: netmod@ietf.org > > >> > Subject: Re: [netmod] allow mandatory nodes in augments > > >> > > > >> > > > >> > > > >> > On Mon, Mar 24, 2014 at 1:48 PM, Ladislav Lhotka > > >> > > wrote: > > >> > > > >> > On 24 Mar 2014, at 20:50, Andy Bierman > > >> > > wrote: > > >> > > > >> > > > > >> > > > > >> > > > > >> > > On Mon, Mar 24, 2014 at 12:11 PM, Ladislav Lhotka > > >> > > > wrote: > > >> > > > > >> > > On 24 Mar 2014, at 18:33, Andy Bierman > > >> > > > wrote: > > >> > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > On Mon, Mar 24, 2014 at 10:03 AM, Ladislav Lhotka > > >> > > > > wrote: > > >> > > > * allow mandatory nodes in augments > > >> > > > > > >> > > > ** Description > > >> > > > > > >> > > > RFC 6020 states in > > >> > > > [[http://tools.ietf.org/html/rfc6020#section-7.15][Sec. 7.15]]: > > >> > > > > > >> > > > If the target node is in another module, then nodes added by > the > > >> > > > augmentation MUST NOT be mandatory nodes (see Section 3.1). > > >> > > > > > >> > > > This rule was probably based on the assumption that augments > will be > > >> > > > used for really optional data that can be safely ignored. > However, as > > >> > > > it turned out, augments have become an essential tool for > modular > > >> > > > development of YANG data models. In some cases, the inability to > > >> > > > define mandatory nodes in augments prevents the data modeller > from > > >> > > > specifying desired schema constraints. > > >> > > > > > >> > > > For instance, > > >> > > > [[ > > >> > http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-16#appendix-A][Appendix > > >> > > > A]] in "interfaces-cfg" shows how an Ethernet module can be > written > > >> > > > that augments "if:interface". However, the container "ethernet" > > >> cannot > > >> > > > define any child leafs as mandatory even though it may be > necessary > > >> > > > and would be normally done if the "ethernet" container was > defined > > >> > > > directly in the "ietf-interfaces" module. > > >> > > > > > >> > > > ** Solution > > >> > > > > > >> > > > Remove the rule cited above. > > >> > > > > > >> > > > > > >> > > > > > >> > > > In the examples of this sort of augment usage, the augments are > in > > >> > > > different > > >> > > > modules. There is no requirement that a server implement > all-or-none > > >> > > > of > > >> > > > these modules, just because they happen to be published in 1 > RFC. > > >> > > > > >> > > This is not what I am saying. > > >> > > > > >> > > > > > >> > > > The reason this rule exists is so a server implementation of the > > >> > > > augmenting module > > >> > > > does not break old clients that do not know about this module. > They > > >> > > > will not provide > > >> > > > the mandatory values and edits will fail. (Bonica Principle > again). > > >> > > > > >> > > I don't buy this principle. I have already argued that new > > >> > > non-mandatory data in server's model can lead to unexpected > > >> > > consequences if the client isn't aware of them, see > > >> > > > > >> > > http://www.ietf.org/mail-archive/web/netmod/current/msg09296.html > > >> > > > > >> > > > > >> > > > > >> > > If a new YANG object is defined such that it changes the way an > > >> > > existing > > >> > > YANG object works, then the new object is broken. > > >> > > > > >> > > An old client should be able to configure the objects it already > knows > > >> > > and the request should not be rejected because of missing > mandatory > > >> > > nodes. > > >> > > > > >> > > The server can pick reasonable defaults for the new objects > without > > >> > > an old client needing to be re-coded. A client can use merge > instead > > >> > > of replace to > > >> > > make sure that new objects do not get deleted. The new objects > can be > > >> > > ignored > > >> > > for editing purposes. This is not true if the merge is rejected > > >> > > because of missing > > >> > > mandatory nodes. > > >> > > > >> > Let me rephrase the main point of this issue: Significant parts of > our > > >> > core models are defined inside augments, with more to come (e.g., > > >> > modules for all interface type). These parts cannot have mandatory > > >> > contents due to that rule from sec. 7.15, which can be a serious > > >> > limitation because some parameters simply have no reasonable > defaults > > >> > and have to be configured. The possibility of supporting old clients > > >> > (IMO dubious) does not outweigh this limitation. > > >> > > > >> > > > >> > If all these augments are in the same YANG module then the > > >> > augment-stmt is not > > >> > really needed and inline definitions should be used instead. > > >> > > > >> > If they are in different modules, then a server vendor may choose to > > >> > implement the augmenting > > >> > module in a later release than the base module. It doesn't matter > that > > >> > a bunch of modules are > > >> > published around the same time. The likely case is that the > > >> > augmenting module is over a year later. > > >> > > > >> > It has nothing to do with YANG 1.0 vs. 1.1. > > >> > It is a bad idea to break old clients that don't know about the new > > >> > module. > > >> > > > >> > Note that it is possible to add new nodes, such that the > sibling/child > > >> > nodes > > >> > to the augmented nodes are optional, but their descendant nodes are > > >> > mandatory. > > >> > This should be OK. An old client that provides just the base > objects > > >> > in a > > >> > create or merge will not break if the new mandatory objects are > > >> > "protected" > > >> > via an extra layer: > > >> > > > >> > > > >> > container top { > > >> > leaf old-1 { type string; } > > >> > } > > >> > > > >> > > > >> > NOT OK: > > >> > > > >> > augment /top { > > >> > leaf from-augment-1 { > > >> > type string; > > >> > mandatory true; > > >> > } > > >> > } > > >> > > > >> > > > >> > > > >> > OK: > > >> > > > >> > augment /top { > > >> > container pcon { > > >> > presence "must exist to make the leaf mandatory"; > > >> > > > >> > leaf from-augment-1 { > > >> > type string; > > >> > mandatory true; > > >> > } > > >> > } > > >> > } > > >> > > > >> > > > >> > > > >> > Lada > > >> > > > >> > > > > >> > > > >> > > > >> > Andy > > >> > > > >> > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --047d7bea3986ff9da604f5985671 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 27, 2014 at 8:06 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 27 Mar 2014, at 15:37, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Thu, Mar 27, 2014 at 7:23 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> Andy Bierman <andy@yumaworks.= com> writes:
>
> > On Thu, Mar 27, 2014 at 12:04 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> >
> >> Hi Alex,
> >>
> >> "Alexander Clemm (alex)" <alex@cisco.com> wrote:
> >> > I agree that this type of solution is what is needed. &n= bsp;This has been
> >> > our experience developing models as well.
> >> > The solution as indicated in the example, that the augme= nting module
> >> > itself (and hence "top-level" data nodes) cann= ot be mandatory, but
> >> > that in the presence of container data nodes, nodes unde= rneath can
> >> > become mandatory, makes a lot of sense to me.
> >>
> >> I don't really understand what you mean.  Do you agr= ee with Lada that
> >> augment should be allowed to add mandatory nodes, or do you a= gree with
> >> Andy that it is ok to augment e.g. a P-container which define= s the
> >> mandatory nodes?
> >>
> >>
> >
> > IMO we cannot break existing clients.
> > Since it is possible to add the nodes in a way that does not expo= se the
> > mandatory
> > nodes to an "old" create or merge, then that should alw= ays be used.
> > Any create or merge that adds the P container (or list) has to do= so
> > correctly
> > with the mandatory sub-nodes.
>
> I think this doesn't solve anything. Let's take the example of= the "interface" list (which is a very typical use case) and assu= me the server and client want to use both the base and augmenting module th= at defines parameters for a particular interface type, say "foo".= The client creates an new entry like
>
> "interface": {
>   "name": "foo0",
>   "type": "foo"
> }
>
> and can stop here because all foo parameters are inside a P-container.= This may not be acceptable if some of the parameters are really required f= or a foo interface to work. The P-container makes no difference: the data m= odel is still too loose.
>
>
>
> It doesn't matter that there might be some parameters that are nee= ded.
> They have to be added correctly. They can be set by the server or a ne= w client.

I am talking about a new client, and I assume some items, such as cryptogra= phic data, cannot be set by the server.

>
> The rules in sec. 10 are very clear.  YANG is modular.  An o= ld client is not
> required in any way to use augmenting modules added after the client w= as written.

This could work in theory if augments were restricted to adding marginal st= uff, but as I wrote in the description of this issue, augments do some heav= y lifting in the core data models. For example, the routing module is prett= y much useless by itself, it has to be augmented by at least one address-fa= mily specific module.

>
> The P-container wrapper is not itself mandatory so an old client can s= afely use
> create and merge without error (by ignoring the new P-container).

I don’t get the benefit of this P-container, the problem is still the= same: the data model doesn’t bind the client to configure parameters= that are in fact mandatory.

I do not a= gree that mandatory objects can be added via augments without
breaking the contract specified by the augmented module. You have to u= p
 

>
> This is how real software has to be maintained.  Applications get= coded
> to work with a specific release of a data model. If that code is worki= ng and
> deployed, then adding a new module in a future release cannot cause th= e
> deployed app to start getting validation errors.

This could work if the modules were totally isolated, or carefully designed= to support this kind of cherry-picking. But in general it is unsafe: augme= nting modules might add defaults that the server will use even if the clien= t isn’t aware of them.

Yes, as a client of an insurance company, I can also sign their contract wi= thout reading the fine print …

 
from RFC 6020, sec. 10:
= New data definition statements may be added if they do not add mandatory nodes (Section 3.1) to existing nodes or at the top level in a module or submodule, or if they are conditionally dependent on a new feature (i.e., have an "if-feature" stat= ement that refers to a new feature).

The old= client did read the fine print in module A.  New contracts
= (augmenting modules) have to add content
in a way that allows the= old client to opt-in.

New parameters that augment the interface need to requi= re the conceptual
service or feature to be enabled (create P-cont= ainer) before any mandatory parameters
for that feature can be re= quired.

I think the text above prevents any mandatory child nod= es to ever be added, even if it
is done inline in a new module re= vision.

The if-feature text does not help an old-c= lient/new-server if the module is updated.
The feature was not in the revision of the module the old client knows= .
This is no different than adding mandatory nodes directly. (The= if-feature text
is irrelevant).

It shou= ld be OK to add new mandatory child nodes directly to a new module revision= .

The old client only has a contract for module A, rev N.=  It should be OK to
add more requirements in a new contract= .  Augments is not the same, because
the revision for module= A does not change.



Lada



Andy

 
>
> Lada
>
>
> Andy
>
>
> >
> >
> > /martin
> >>
> >
> >
> > Andy
> >
> >
> >
> >>
> >> > --- Alex
> >> >
> >> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy
> >> > Bierman
> >> > Sent: Monday, March 24, 2014 2:30 PM
> >> > To: Ladislav Lhotka
> >> > Cc: netmod@ietf.org
> >> > Subject: Re: [netmod] allow mandatory nodes in augments<= br> > >> >
> >> >
> >> >
> >> > On Mon, Mar 24, 2014 at 1:48 PM, Ladislav Lhotka
> >> > <lhotka@nic.cz&l= t;mailto:lhotka@nic.cz>> wrote:<= br> > >> >
> >> > On 24 Mar 2014, at 20:50, Andy Bierman
> >> > <andy@yumaworks= .com<mailto:andy@yumaworks.com= >> wrote:
> >> >
> >> > >
> >> > >
> >> > >
> >> > > On Mon, Mar 24, 2014 at 12:11 PM, Ladislav Lhotka > >> > > <lhotka@nic.cz<= /a><mailto:lhotka@nic.cz>> wr= ote:
> >> > >
> >> > > On 24 Mar 2014, at 18:33, Andy Bierman
> >> > > <andy@yuma= works.com<mailto:andy@yumawork= s.com>> wrote:
> >> > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Mon, Mar 24, 2014 at 10:03 AM, Ladislav Lho= tka
> >> > > > <lhotka@ni= c.cz<mailto:lhotka@nic.cz>&g= t; wrote:
> >> > > > * allow mandatory nodes in augments
> >> > > >
> >> > > > ** Description
> >> > > >
> >> > > > RFC 6020 states in
> >> > > > [[http://tools.ietf.org/html/rfc6020#s= ection-7.15][Sec. 7.15]]:
> >> > > >
> >> > > >    If the target node is in another = module, then nodes added by the
> >> > > >    augmentation MUST NOT be mandator= y nodes (see Section 3.1).
> >> > > >
> >> > > > This rule was probably based on the assumption= that augments will be
> >> > > > used for really optional data that can be safe= ly ignored. However, as
> >> > > > it turned out, augments have become an essenti= al tool for modular
> >> > > > development of YANG data models. In some cases= , the inability to
> >> > > > define mandatory nodes in augments prevents th= e data modeller from
> >> > > > specifying desired schema constraints.
> >> > > >
> >> > > > For instance,
> >> > > > [[
> >> http://tools.ietf.org/= html/draft-ietf-netmod-interfaces-cfg-16#appendix-A][Appendix
> >> > > > A]] in "interfaces-cfg" shows how an= Ethernet module can be written
> >> > > > that augments "if:interface". Howeve= r, the container "ethernet"
> >> cannot
> >> > > > define any child leafs as mandatory even thoug= h it may be necessary
> >> > > > and would be normally done if the "ethern= et" container was defined
> >> > > > directly in the "ietf-interfaces" mo= dule.
> >> > > >
> >> > > > ** Solution
> >> > > >
> >> > > > Remove the rule cited above.
> >> > > >
> >> > > >
> >> > > >
> >> > > > In the examples of this sort of augment usage,= the augments are in
> >> > > > different
> >> > > > modules.  There is no requirement that a = server implement all-or-none
> >> > > > of
> >> > > > these modules, just because they happen to be = published in 1 RFC.
> >> > >
> >> > > This is not what I am saying.
> >> > >
> >> > > >
> >> > > > The reason this rule exists is so a server imp= lementation of the
> >> > > > augmenting module
> >> > > > does not break old clients that do not know ab= out this module.  They
> >> > > > will not provide
> >> > > > the mandatory values and edits will fail. (Bon= ica Principle again).
> >> > >
> >> > > I don't buy this principle. I have already argu= ed that new
> >> > > non-mandatory data in server's model can lead t= o unexpected
> >> > > consequences if the client isn't aware of them,= see
> >> > >
> >> > > http://www.ietf.org/mail-archi= ve/web/netmod/current/msg09296.html
> >> > >
> >> > >
> >> > >
> >> > > If a new YANG object is defined such that it change= s the way an
> >> > > existing
> >> > > YANG object works, then the new object is broken. > >> > >
> >> > > An old client should be able to configure the objec= ts it already knows
> >> > > and the request should not be rejected because of m= issing mandatory
> >> > > nodes.
> >> > >
> >> > > The server can pick reasonable defaults for the new= objects without
> >> > > an old client needing to be re-coded.  A clien= t can use merge instead
> >> > > of replace to
> >> > > make sure that new objects do not get deleted. The = new objects can be
> >> > > ignored
> >> > > for editing purposes.  This is not true if the= merge is rejected
> >> > > because of missing
> >> > > mandatory nodes.
> >> >
> >> > Let me rephrase the main point of this issue: Significan= t parts of our
> >> > core models are defined inside augments, with more to co= me (e.g.,
> >> > modules for all interface type). These parts cannot have= mandatory
> >> > contents due to that rule from sec. 7.15, which can be a= serious
> >> > limitation because some parameters simply have no reason= able defaults
> >> > and have to be configured. The possibility of supporting= old clients
> >> > (IMO dubious) does not outweigh this limitation.
> >> >
> >> >
> >> > If all these augments are in the same YANG module then t= he
> >> > augment-stmt is not
> >> > really needed and inline definitions should be used inst= ead.
> >> >
> >> > If they are in different modules, then a server vendor m= ay choose to
> >> > implement the augmenting
> >> > module in a later release than the base module. It doesn= 't matter that
> >> > a bunch of modules are
> >> > published around the same time.  The likely case is= that the
> >> > augmenting module is over a year later.
> >> >
> >> > It has nothing to do with YANG 1.0 vs. 1.1.
> >> > It is a bad idea to break old clients that don't kno= w about the new
> >> > module.
> >> >
> >> > Note that it is possible to add new nodes, such that the= sibling/child
> >> > nodes
> >> > to the augmented nodes are optional, but their descendan= t nodes are
> >> > mandatory.
> >> > This should be OK.  An old client that provides jus= t the base objects
> >> > in a
> >> > create or merge will not break if the new mandatory obje= cts are
> >> > "protected"
> >> > via an extra layer:
> >> >
> >> >
> >> >    container top {
> >> >       leaf old-1 { type string; }
> >> >    }
> >> >
> >> >
> >> > NOT OK:
> >> >
> >> >    augment /top {
> >> >        leaf from-augment-1 {
> >> >          type string;
> >> >          mandatory true;
> >> >        }
> >> >    }
> >> >
> >> >
> >> >
> >> > OK:
> >> >
> >> >    augment /top {
> >> >        container pcon {
> >> >            presence "= must exist to make the leaf mandatory";
> >> >
> >> >           leaf from-augment-1 {=
> >> >              type str= ing;
> >> >              mandator= y true;
> >> >            }
> >> >         }
> >> >     }
> >> >
> >> >
> >> >
> >> > Lada
> >> >
> >> > >
> >> >
> >> >
> >> > Andy
> >> >
> >>
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>

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





--047d7bea3986ff9da604f5985671-- From nobody Thu Mar 27 09:04:15 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1555A1A0147 for ; Thu, 27 Mar 2014 09:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luMRbve-zHGt for ; Thu, 27 Mar 2014 09:04:09 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1A71A016A for ; Thu, 27 Mar 2014 09:04:09 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id CAB6913F686; Thu, 27 Mar 2014 17:04:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1395936247; bh=KkbLbkrizFCxhluI5yqX25PjfH4Zr88mm26YBaQbfHU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=s5AY2sLD9qRHEvoneR5sFSIxc36RDdbJ+e8Pp4mse9YhPg9xUW/xU6yJQakbRMu9p z9WVkLEmhWRICZaKktfU75ySrAooF8NFwxbX/SAAwLGqtLmCkBuWvI66xiLIvuxugp gVva4G5tjyeGjzptHZUuPIbejriHO9BgGV9oUxNg= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 27 Mar 2014 17:04:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <44D79BA2-D259-4A8C-ABA5-BC5AB5B69254@nic.cz> References: <20140327.080423.2031221427554871516.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Sj0I-lEGHnyRs3xLEtR-cAl05lM Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 16:04:12 -0000 On 27 Mar 2014, at 16:35, Andy Bierman wrote: >=20 >=20 >=20 > On Thu, Mar 27, 2014 at 8:06 AM, Ladislav Lhotka = wrote: >=20 > On 27 Mar 2014, at 15:37, Andy Bierman wrote: >=20 > > > > > > > > On Thu, Mar 27, 2014 at 7:23 AM, Ladislav Lhotka = wrote: > > Andy Bierman writes: > > > > > On Thu, Mar 27, 2014 at 12:04 AM, Martin Bjorklund = wrote: > > > > > >> Hi Alex, > > >> > > >> "Alexander Clemm (alex)" wrote: > > >> > I agree that this type of solution is what is needed. This has = been > > >> > our experience developing models as well. > > >> > The solution as indicated in the example, that the augmenting = module > > >> > itself (and hence "top-level" data nodes) cannot be mandatory, = but > > >> > that in the presence of container data nodes, nodes underneath = can > > >> > become mandatory, makes a lot of sense to me. > > >> > > >> I don't really understand what you mean. Do you agree with Lada = that > > >> augment should be allowed to add mandatory nodes, or do you agree = with > > >> Andy that it is ok to augment e.g. a P-container which defines = the > > >> mandatory nodes? > > >> > > >> > > > > > > IMO we cannot break existing clients. > > > Since it is possible to add the nodes in a way that does not = expose the > > > mandatory > > > nodes to an "old" create or merge, then that should always be = used. > > > Any create or merge that adds the P container (or list) has to do = so > > > correctly > > > with the mandatory sub-nodes. > > > > I think this doesn't solve anything. Let's take the example of the = "interface" list (which is a very typical use case) and assume the = server and client want to use both the base and augmenting module that = defines parameters for a particular interface type, say "foo". The = client creates an new entry like > > > > "interface": { > > "name": "foo0", > > "type": "foo" > > } > > > > and can stop here because all foo parameters are inside a = P-container. This may not be acceptable if some of the parameters are = really required for a foo interface to work. The P-container makes no = difference: the data model is still too loose. > > > > > > > > It doesn't matter that there might be some parameters that are = needed. > > They have to be added correctly. They can be set by the server or a = new client. >=20 > I am talking about a new client, and I assume some items, such as = cryptographic data, cannot be set by the server. >=20 > > > > The rules in sec. 10 are very clear. YANG is modular. An old = client is not > > required in any way to use augmenting modules added after the client = was written. >=20 > This could work in theory if augments were restricted to adding = marginal stuff, but as I wrote in the description of this issue, = augments do some heavy lifting in the core data models. For example, the = routing module is pretty much useless by itself, it has to be augmented = by at least one address-family specific module. >=20 > > > > The P-container wrapper is not itself mandatory so an old client can = safely use > > create and merge without error (by ignoring the new P-container). >=20 > I don=92t get the benefit of this P-container, the problem is still = the same: the data model doesn=92t bind the client to configure = parameters that are in fact mandatory. >=20 > I do not agree that mandatory objects can be added via augments = without > breaking the contract specified by the augmented module. You have to = up > =20 >=20 > > > > This is how real software has to be maintained. Applications get = coded > > to work with a specific release of a data model. If that code is = working and > > deployed, then adding a new module in a future release cannot cause = the > > deployed app to start getting validation errors. >=20 > This could work if the modules were totally isolated, or carefully = designed to support this kind of cherry-picking. But in general it is = unsafe: augmenting modules might add defaults that the server will use = even if the client isn=92t aware of them. >=20 > Yes, as a client of an insurance company, I can also sign their = contract without reading the fine print =85 >=20 > =20 > from RFC 6020, sec. 10: > New data definition statements may be added if they do not add > mandatory nodes (Section 3.1) to existing nodes or at the top > level in a module or submodule, or if they are conditionally > dependent on a new feature (i.e., have an "if-feature" statement > that refers to a new feature). >=20 >=20 > The old client did read the fine print in module A. New contracts > (augmenting modules) have to add content > in a way that allows the old client to opt-in. The old client has =93signed=94 the new contract by not closing the = session after seeing new server=92s hello. >=20 > New parameters that augment the interface need to require the = conceptual > service or feature to be enabled (create P-container) before any = mandatory parameters > for that feature can be required. The thing is: Every module=92s data tree normally starts at the top = level. The only way for putting new nodes deeper into the hierarchy of = an existing module is to use augments. Now, the desired modularity and need for supporting other address = families in the future dictate that address-family-specific data be = factored out of ietf-routing, so augments have to be used. This all means this =93Bonica Principle=94 leaves me with a crippled = data modelling language. Having a P-container in every route is a sheer = nonsense. IMO the requirement of supporting old clients shouldn=92t be an absolute = priority. Lada >=20 > I think the text above prevents any mandatory child nodes to ever be = added, even if it > is done inline in a new module revision. >=20 > The if-feature text does not help an old-client/new-server if the = module is updated. > The feature was not in the revision of the module the old client = knows. > This is no different than adding mandatory nodes directly. (The = if-feature text > is irrelevant). >=20 > It should be OK to add new mandatory child nodes directly to a new = module revision. >=20 > The old client only has a contract for module A, rev N. It should be = OK to > add more requirements in a new contract. Augments is not the same, = because > the revision for module A does not change. >=20 >=20 >=20 > Lada >=20 >=20 >=20 > Andy >=20 > =20 > > > > Lada > > > > > > Andy > > > > > > > > > > > > > /martin > > >> > > > > > > > > > Andy > > > > > > > > > > > >> > > >> > --- Alex > > >> > > > >> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy > > >> > Bierman > > >> > Sent: Monday, March 24, 2014 2:30 PM > > >> > To: Ladislav Lhotka > > >> > Cc: netmod@ietf.org > > >> > Subject: Re: [netmod] allow mandatory nodes in augments > > >> > > > >> > > > >> > > > >> > On Mon, Mar 24, 2014 at 1:48 PM, Ladislav Lhotka > > >> > > wrote: > > >> > > > >> > On 24 Mar 2014, at 20:50, Andy Bierman > > >> > > wrote: > > >> > > > >> > > > > >> > > > > >> > > > > >> > > On Mon, Mar 24, 2014 at 12:11 PM, Ladislav Lhotka > > >> > > > wrote: > > >> > > > > >> > > On 24 Mar 2014, at 18:33, Andy Bierman > > >> > > > wrote: > > >> > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > On Mon, Mar 24, 2014 at 10:03 AM, Ladislav Lhotka > > >> > > > > wrote: > > >> > > > * allow mandatory nodes in augments > > >> > > > > > >> > > > ** Description > > >> > > > > > >> > > > RFC 6020 states in > > >> > > > [[http://tools.ietf.org/html/rfc6020#section-7.15][Sec. = 7.15]]: > > >> > > > > > >> > > > If the target node is in another module, then nodes = added by the > > >> > > > augmentation MUST NOT be mandatory nodes (see Section = 3.1). > > >> > > > > > >> > > > This rule was probably based on the assumption that = augments will be > > >> > > > used for really optional data that can be safely ignored. = However, as > > >> > > > it turned out, augments have become an essential tool for = modular > > >> > > > development of YANG data models. In some cases, the = inability to > > >> > > > define mandatory nodes in augments prevents the data = modeller from > > >> > > > specifying desired schema constraints. > > >> > > > > > >> > > > For instance, > > >> > > > [[ > > >> = http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-16#appendix-A]= [Appendix > > >> > > > A]] in "interfaces-cfg" shows how an Ethernet module can be = written > > >> > > > that augments "if:interface". However, the container = "ethernet" > > >> cannot > > >> > > > define any child leafs as mandatory even though it may be = necessary > > >> > > > and would be normally done if the "ethernet" container was = defined > > >> > > > directly in the "ietf-interfaces" module. > > >> > > > > > >> > > > ** Solution > > >> > > > > > >> > > > Remove the rule cited above. > > >> > > > > > >> > > > > > >> > > > > > >> > > > In the examples of this sort of augment usage, the augments = are in > > >> > > > different > > >> > > > modules. There is no requirement that a server implement = all-or-none > > >> > > > of > > >> > > > these modules, just because they happen to be published in = 1 RFC. > > >> > > > > >> > > This is not what I am saying. > > >> > > > > >> > > > > > >> > > > The reason this rule exists is so a server implementation = of the > > >> > > > augmenting module > > >> > > > does not break old clients that do not know about this = module. They > > >> > > > will not provide > > >> > > > the mandatory values and edits will fail. (Bonica Principle = again). > > >> > > > > >> > > I don't buy this principle. I have already argued that new > > >> > > non-mandatory data in server's model can lead to unexpected > > >> > > consequences if the client isn't aware of them, see > > >> > > > > >> > > = http://www.ietf.org/mail-archive/web/netmod/current/msg09296.html > > >> > > > > >> > > > > >> > > > > >> > > If a new YANG object is defined such that it changes the way = an > > >> > > existing > > >> > > YANG object works, then the new object is broken. > > >> > > > > >> > > An old client should be able to configure the objects it = already knows > > >> > > and the request should not be rejected because of missing = mandatory > > >> > > nodes. > > >> > > > > >> > > The server can pick reasonable defaults for the new objects = without > > >> > > an old client needing to be re-coded. A client can use merge = instead > > >> > > of replace to > > >> > > make sure that new objects do not get deleted. The new = objects can be > > >> > > ignored > > >> > > for editing purposes. This is not true if the merge is = rejected > > >> > > because of missing > > >> > > mandatory nodes. > > >> > > > >> > Let me rephrase the main point of this issue: Significant parts = of our > > >> > core models are defined inside augments, with more to come = (e.g., > > >> > modules for all interface type). These parts cannot have = mandatory > > >> > contents due to that rule from sec. 7.15, which can be a = serious > > >> > limitation because some parameters simply have no reasonable = defaults > > >> > and have to be configured. The possibility of supporting old = clients > > >> > (IMO dubious) does not outweigh this limitation. > > >> > > > >> > > > >> > If all these augments are in the same YANG module then the > > >> > augment-stmt is not > > >> > really needed and inline definitions should be used instead. > > >> > > > >> > If they are in different modules, then a server vendor may = choose to > > >> > implement the augmenting > > >> > module in a later release than the base module. It doesn't = matter that > > >> > a bunch of modules are > > >> > published around the same time. The likely case is that the > > >> > augmenting module is over a year later. > > >> > > > >> > It has nothing to do with YANG 1.0 vs. 1.1. > > >> > It is a bad idea to break old clients that don't know about the = new > > >> > module. > > >> > > > >> > Note that it is possible to add new nodes, such that the = sibling/child > > >> > nodes > > >> > to the augmented nodes are optional, but their descendant nodes = are > > >> > mandatory. > > >> > This should be OK. An old client that provides just the base = objects > > >> > in a > > >> > create or merge will not break if the new mandatory objects are > > >> > "protected" > > >> > via an extra layer: > > >> > > > >> > > > >> > container top { > > >> > leaf old-1 { type string; } > > >> > } > > >> > > > >> > > > >> > NOT OK: > > >> > > > >> > augment /top { > > >> > leaf from-augment-1 { > > >> > type string; > > >> > mandatory true; > > >> > } > > >> > } > > >> > > > >> > > > >> > > > >> > OK: > > >> > > > >> > augment /top { > > >> > container pcon { > > >> > presence "must exist to make the leaf mandatory"; > > >> > > > >> > leaf from-augment-1 { > > >> > type string; > > >> > mandatory true; > > >> > } > > >> > } > > >> > } > > >> > > > >> > > > >> > > > >> > Lada > > >> > > > >> > > > > >> > > > >> > > > >> > Andy > > >> > > > >> > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Mar 27 09:37:21 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414D01A0691 for ; Thu, 27 Mar 2014 09:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJcipLYDBXkr for ; Thu, 27 Mar 2014 09:37:12 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7155B1A00D9 for ; Thu, 27 Mar 2014 09:37:12 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id j5so3076539qga.18 for ; Thu, 27 Mar 2014 09:37:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=I4oNuc0CpDtRRF+b0RWDaflFii9mXuiRd4TWunOSqjg=; b=fM5HnESEoNgE0WgKw1c6il7UE4yrRZYmRjrGjwdSZ89AeTbuV+5ZlfJFTPpdLtuqoJ Ge6jlE3wuZjHE4VUa9AeR5lDn49naFB2albOVcNmKCG1rKKOV1OlU6FuidVtTGV7Y1jM hqmH4WSwx7WloCK0JioebAJz/xfsdpWdrg41212f7CdLS9yygj0ZgQ0Ht6nnM3+ay7Ij rUgEVc/RKrk9xje9lWyszUbghmp6qSNiAPi2SgW6f/LKT0lc+Dyi39ZSHpDeAnoJD91T gYvwG8fofKw34IYfnZ6aKBRsBqZ28Wafi4DFTcpZ337GCHAZDX6AnegZKt6p/BvLVRfl KmWQ== X-Gm-Message-State: ALoCoQlD0S5uwV2WDViGch92GXos44Dl/wkLjVrRhirRB1YqkaJZqr17L/q6BT8Q81qtabaG2new MIME-Version: 1.0 X-Received: by 10.224.112.6 with SMTP id u6mr3369712qap.78.1395938229962; Thu, 27 Mar 2014 09:37:09 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Thu, 27 Mar 2014 09:37:09 -0700 (PDT) In-Reply-To: <44D79BA2-D259-4A8C-ABA5-BC5AB5B69254@nic.cz> References: <20140327.080423.2031221427554871516.mbj@tail-f.com> <44D79BA2-D259-4A8C-ABA5-BC5AB5B69254@nic.cz> Date: Thu, 27 Mar 2014 09:37:09 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c2e84853747c04f59932b0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hQp3KW8MHdIN5rCsnz541saKLz0 Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 16:37:18 -0000 --001a11c2e84853747c04f59932b0 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 27, 2014 at 9:04 AM, Ladislav Lhotka wrote: > > On 27 Mar 2014, at 16:35, Andy Bierman wrote: > > > > > > > > > On Thu, Mar 27, 2014 at 8:06 AM, Ladislav Lhotka wrote: > > > > On 27 Mar 2014, at 15:37, Andy Bierman wrote: > > > > > > > > > > > > > > On Thu, Mar 27, 2014 at 7:23 AM, Ladislav Lhotka > wrote: > > > Andy Bierman writes: > > > > > > > On Thu, Mar 27, 2014 at 12:04 AM, Martin Bjorklund > wrote: > > > > > > > >> Hi Alex, > > > >> > > > >> "Alexander Clemm (alex)" wrote: > > > >> > I agree that this type of solution is what is needed. This has > been > > > >> > our experience developing models as well. > > > >> > The solution as indicated in the example, that the augmenting > module > > > >> > itself (and hence "top-level" data nodes) cannot be mandatory, but > > > >> > that in the presence of container data nodes, nodes underneath can > > > >> > become mandatory, makes a lot of sense to me. > > > >> > > > >> I don't really understand what you mean. Do you agree with Lada > that > > > >> augment should be allowed to add mandatory nodes, or do you agree > with > > > >> Andy that it is ok to augment e.g. a P-container which defines the > > > >> mandatory nodes? > > > >> > > > >> > > > > > > > > IMO we cannot break existing clients. > > > > Since it is possible to add the nodes in a way that does not expose > the > > > > mandatory > > > > nodes to an "old" create or merge, then that should always be used. > > > > Any create or merge that adds the P container (or list) has to do so > > > > correctly > > > > with the mandatory sub-nodes. > > > > > > I think this doesn't solve anything. Let's take the example of the > "interface" list (which is a very typical use case) and assume the server > and client want to use both the base and augmenting module that defines > parameters for a particular interface type, say "foo". The client creates > an new entry like > > > > > > "interface": { > > > "name": "foo0", > > > "type": "foo" > > > } > > > > > > and can stop here because all foo parameters are inside a P-container. > This may not be acceptable if some of the parameters are really required > for a foo interface to work. The P-container makes no difference: the data > model is still too loose. > > > > > > > > > > > > It doesn't matter that there might be some parameters that are needed. > > > They have to be added correctly. They can be set by the server or a > new client. > > > > I am talking about a new client, and I assume some items, such as > cryptographic data, cannot be set by the server. > > > > > > > > The rules in sec. 10 are very clear. YANG is modular. An old client > is not > > > required in any way to use augmenting modules added after the client > was written. > > > > This could work in theory if augments were restricted to adding marginal > stuff, but as I wrote in the description of this issue, augments do some > heavy lifting in the core data models. For example, the routing module is > pretty much useless by itself, it has to be augmented by at least one > address-family specific module. > > > > > > > > The P-container wrapper is not itself mandatory so an old client can > safely use > > > create and merge without error (by ignoring the new P-container). > > > > I don't get the benefit of this P-container, the problem is still the > same: the data model doesn't bind the client to configure parameters that > are in fact mandatory. > > > > I do not agree that mandatory objects can be added via augments without > > breaking the contract specified by the augmented module. You have to up > > > > > > > > > > This is how real software has to be maintained. Applications get coded > > > to work with a specific release of a data model. If that code is > working and > > > deployed, then adding a new module in a future release cannot cause the > > > deployed app to start getting validation errors. > > > > This could work if the modules were totally isolated, or carefully > designed to support this kind of cherry-picking. But in general it is > unsafe: augmenting modules might add defaults that the server will use even > if the client isn't aware of them. > > > > Yes, as a client of an insurance company, I can also sign their contract > without reading the fine print ... > > > > > > from RFC 6020, sec. 10: > > New data definition statements may be added if they do not add > > mandatory nodes (Section 3.1) to existing nodes or at the top > > level in a module or submodule, or if they are conditionally > > dependent on a new feature (i.e., have an "if-feature" statement > > that refers to a new feature). > > > > > > The old client did read the fine print in module A. New contracts > > (augmenting modules) have to add content > > in a way that allows the old client to opt-in. > > The old client has "signed" the new contract by not closing the session > after seeing new server's hello. > > It doesn't work that way -- customers get mad when the tools they paid for stop working when equipment is upgraded. > > > > New parameters that augment the interface need to require the conceptual > > service or feature to be enabled (create P-container) before any > mandatory parameters > > for that feature can be required. > > The thing is: Every module's data tree normally starts at the top level. > The only way for putting new nodes deeper into the hierarchy of an existing > module is to use augments. > > Now, the desired modularity and need for supporting other address families > in the future dictate that address-family-specific data be factored out of > ietf-routing, so augments have to be used. > > This all means this "Bonica Principle" leaves me with a crippled data > modelling language. Having a P-container in every route is a sheer nonsense. > > It is not crippled. You do not have to use augment. YANG allows a new revision of the original module to add a new mandatory object if there is an if-feature-stmt. IMO the requirement of supporting old clients shouldn't be an absolute > priority. > > I disagree. You can update the module revision and make a new contract for a YANG module. You cannot make these contract changes without updating the module revision. > Lada > Andy > > > > > I think the text above prevents any mandatory child nodes to ever be > added, even if it > > is done inline in a new module revision. > > > > The if-feature text does not help an old-client/new-server if the module > is updated. > > The feature was not in the revision of the module the old client knows. > > This is no different than adding mandatory nodes directly. (The > if-feature text > > is irrelevant). > > > > It should be OK to add new mandatory child nodes directly to a new > module revision. > > > > The old client only has a contract for module A, rev N. It should be OK > to > > add more requirements in a new contract. Augments is not the same, > because > > the revision for module A does not change. > > > > > > > > Lada > > > > > > > > Andy > > > > > > > > > > Lada > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > /martin > > > >> > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > >> > > > >> > --- Alex > > > >> > > > > >> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy > > > >> > Bierman > > > >> > Sent: Monday, March 24, 2014 2:30 PM > > > >> > To: Ladislav Lhotka > > > >> > Cc: netmod@ietf.org > > > >> > Subject: Re: [netmod] allow mandatory nodes in augments > > > >> > > > > >> > > > > >> > > > > >> > On Mon, Mar 24, 2014 at 1:48 PM, Ladislav Lhotka > > > >> > > wrote: > > > >> > > > > >> > On 24 Mar 2014, at 20:50, Andy Bierman > > > >> > > wrote: > > > >> > > > > >> > > > > > >> > > > > > >> > > > > > >> > > On Mon, Mar 24, 2014 at 12:11 PM, Ladislav Lhotka > > > >> > > > wrote: > > > >> > > > > > >> > > On 24 Mar 2014, at 18:33, Andy Bierman > > > >> > > > wrote: > > > >> > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > On Mon, Mar 24, 2014 at 10:03 AM, Ladislav Lhotka > > > >> > > > > wrote: > > > >> > > > * allow mandatory nodes in augments > > > >> > > > > > > >> > > > ** Description > > > >> > > > > > > >> > > > RFC 6020 states in > > > >> > > > [[http://tools.ietf.org/html/rfc6020#section-7.15][Sec. > 7.15]]: > > > >> > > > > > > >> > > > If the target node is in another module, then nodes added > by the > > > >> > > > augmentation MUST NOT be mandatory nodes (see Section 3.1). > > > >> > > > > > > >> > > > This rule was probably based on the assumption that augments > will be > > > >> > > > used for really optional data that can be safely ignored. > However, as > > > >> > > > it turned out, augments have become an essential tool for > modular > > > >> > > > development of YANG data models. In some cases, the inability > to > > > >> > > > define mandatory nodes in augments prevents the data modeller > from > > > >> > > > specifying desired schema constraints. > > > >> > > > > > > >> > > > For instance, > > > >> > > > [[ > > > >> > http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-16#appendix-A][Appendix > > > >> > > > A]] in "interfaces-cfg" shows how an Ethernet module can be > written > > > >> > > > that augments "if:interface". However, the container > "ethernet" > > > >> cannot > > > >> > > > define any child leafs as mandatory even though it may be > necessary > > > >> > > > and would be normally done if the "ethernet" container was > defined > > > >> > > > directly in the "ietf-interfaces" module. > > > >> > > > > > > >> > > > ** Solution > > > >> > > > > > > >> > > > Remove the rule cited above. > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > In the examples of this sort of augment usage, the augments > are in > > > >> > > > different > > > >> > > > modules. There is no requirement that a server implement > all-or-none > > > >> > > > of > > > >> > > > these modules, just because they happen to be published in 1 > RFC. > > > >> > > > > > >> > > This is not what I am saying. > > > >> > > > > > >> > > > > > > >> > > > The reason this rule exists is so a server implementation of > the > > > >> > > > augmenting module > > > >> > > > does not break old clients that do not know about this > module. They > > > >> > > > will not provide > > > >> > > > the mandatory values and edits will fail. (Bonica Principle > again). > > > >> > > > > > >> > > I don't buy this principle. I have already argued that new > > > >> > > non-mandatory data in server's model can lead to unexpected > > > >> > > consequences if the client isn't aware of them, see > > > >> > > > > > >> > > > http://www.ietf.org/mail-archive/web/netmod/current/msg09296.html > > > >> > > > > > >> > > > > > >> > > > > > >> > > If a new YANG object is defined such that it changes the way an > > > >> > > existing > > > >> > > YANG object works, then the new object is broken. > > > >> > > > > > >> > > An old client should be able to configure the objects it > already knows > > > >> > > and the request should not be rejected because of missing > mandatory > > > >> > > nodes. > > > >> > > > > > >> > > The server can pick reasonable defaults for the new objects > without > > > >> > > an old client needing to be re-coded. A client can use merge > instead > > > >> > > of replace to > > > >> > > make sure that new objects do not get deleted. The new objects > can be > > > >> > > ignored > > > >> > > for editing purposes. This is not true if the merge is rejected > > > >> > > because of missing > > > >> > > mandatory nodes. > > > >> > > > > >> > Let me rephrase the main point of this issue: Significant parts > of our > > > >> > core models are defined inside augments, with more to come (e.g., > > > >> > modules for all interface type). These parts cannot have mandatory > > > >> > contents due to that rule from sec. 7.15, which can be a serious > > > >> > limitation because some parameters simply have no reasonable > defaults > > > >> > and have to be configured. The possibility of supporting old > clients > > > >> > (IMO dubious) does not outweigh this limitation. > > > >> > > > > >> > > > > >> > If all these augments are in the same YANG module then the > > > >> > augment-stmt is not > > > >> > really needed and inline definitions should be used instead. > > > >> > > > > >> > If they are in different modules, then a server vendor may choose > to > > > >> > implement the augmenting > > > >> > module in a later release than the base module. It doesn't matter > that > > > >> > a bunch of modules are > > > >> > published around the same time. The likely case is that the > > > >> > augmenting module is over a year later. > > > >> > > > > >> > It has nothing to do with YANG 1.0 vs. 1.1. > > > >> > It is a bad idea to break old clients that don't know about the > new > > > >> > module. > > > >> > > > > >> > Note that it is possible to add new nodes, such that the > sibling/child > > > >> > nodes > > > >> > to the augmented nodes are optional, but their descendant nodes > are > > > >> > mandatory. > > > >> > This should be OK. An old client that provides just the base > objects > > > >> > in a > > > >> > create or merge will not break if the new mandatory objects are > > > >> > "protected" > > > >> > via an extra layer: > > > >> > > > > >> > > > > >> > container top { > > > >> > leaf old-1 { type string; } > > > >> > } > > > >> > > > > >> > > > > >> > NOT OK: > > > >> > > > > >> > augment /top { > > > >> > leaf from-augment-1 { > > > >> > type string; > > > >> > mandatory true; > > > >> > } > > > >> > } > > > >> > > > > >> > > > > >> > > > > >> > OK: > > > >> > > > > >> > augment /top { > > > >> > container pcon { > > > >> > presence "must exist to make the leaf mandatory"; > > > >> > > > > >> > leaf from-augment-1 { > > > >> > type string; > > > >> > mandatory true; > > > >> > } > > > >> > } > > > >> > } > > > >> > > > > >> > > > > >> > > > > >> > Lada > > > >> > > > > >> > > > > > >> > > > > >> > > > > >> > Andy > > > >> > > > > >> > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c2e84853747c04f59932b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 27, 2014 at 9:04 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 27 Mar 2014, at 16:35, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Thu, Mar 27, 2014 at 8:06 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On 27 Mar 2014, at 15:37, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Thu, Mar 27, 2014 at 7:23 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > Andy Bierman <andy@yumaw= orks.com> writes:
> >
> > > On Thu, Mar 27, 2014 at 12:04 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> > >
> > >> Hi Alex,
> > >>
> > >> "Alexander Clemm (alex)" <alex@cisco.com> wrote:
> > >> > I agree that this type of solution is what is neede= d.  This has been
> > >> > our experience developing models as well.
> > >> > The solution as indicated in the example, that the = augmenting module
> > >> > itself (and hence "top-level" data nodes)= cannot be mandatory, but
> > >> > that in the presence of container data nodes, nodes= underneath can
> > >> > become mandatory, makes a lot of sense to me.
> > >>
> > >> I don't really understand what you mean.  Do yo= u agree with Lada that
> > >> augment should be allowed to add mandatory nodes, or do = you agree with
> > >> Andy that it is ok to augment e.g. a P-container which d= efines the
> > >> mandatory nodes?
> > >>
> > >>
> > >
> > > IMO we cannot break existing clients.
> > > Since it is possible to add the nodes in a way that does not= expose the
> > > mandatory
> > > nodes to an "old" create or merge, then that shoul= d always be used.
> > > Any create or merge that adds the P container (or list) has = to do so
> > > correctly
> > > with the mandatory sub-nodes.
> >
> > I think this doesn't solve anything. Let's take the examp= le of the "interface" list (which is a very typical use case) and= assume the server and client want to use both the base and augmenting modu= le that defines parameters for a particular interface type, say "foo&q= uot;. The client creates an new entry like
> >
> > "interface": {
> >   "name": "foo0",
> >   "type": "foo"
> > }
> >
> > and can stop here because all foo parameters are inside a P-conta= iner. This may not be acceptable if some of the parameters are really requi= red for a foo interface to work. The P-container makes no difference: the d= ata model is still too loose.
> >
> >
> >
> > It doesn't matter that there might be some parameters that ar= e needed.
> > They have to be added correctly. They can be set by the server or= a new client.
>
> I am talking about a new client, and I assume some items, such as cryp= tographic data, cannot be set by the server.
>
> >
> > The rules in sec. 10 are very clear.  YANG is modular.  = ;An old client is not
> > required in any way to use augmenting modules added after the cli= ent was written.
>
> This could work in theory if augments were restricted to adding margin= al stuff, but as I wrote in the description of this issue, augments do some= heavy lifting in the core data models. For example, the routing module is = pretty much useless by itself, it has to be augmented by at least one addre= ss-family specific module.
>
> >
> > The P-container wrapper is not itself mandatory so an old client = can safely use
> > create and merge without error (by ignoring the new P-container).=
>
> I don’t get the benefit of this P-container, the problem is stil= l the same: the data model doesn’t bind the client to configure param= eters that are in fact mandatory.
>
> I do not agree that mandatory objects can be added via augments withou= t
> breaking the contract specified by the augmented module. You have to u= p
>
>
> >
> > This is how real software has to be maintained.  Application= s get coded
> > to work with a specific release of a data model. If that code is = working and
> > deployed, then adding a new module in a future release cannot cau= se the
> > deployed app to start getting validation errors.
>
> This could work if the modules were totally isolated, or carefully des= igned to support this kind of cherry-picking. But in general it is unsafe: = augmenting modules might add defaults that the server will use even if the = client isn’t aware of them.
>
> Yes, as a client of an insurance company, I can also sign their contra= ct without reading the fine print …
>
>
> from RFC 6020, sec. 10:
>       New data definition statements may be added if th= ey do not add
>       mandatory nodes (Section 3.1) to existing nodes o= r at the top
>       level in a module or submodule, or if they are co= nditionally
>       dependent on a new feature (i.e., have an "i= f-feature" statement
>       that refers to a new feature).
>
>
> The old client did read the fine print in module A.  New contract= s
> (augmenting modules) have to add content
> in a way that allows the old client to opt-in.

The old client has “signed” the new contract by not closing the= session after seeing new server’s hello.



It doesn't work tha= t way -- customers get mad when the tools they paid for
stop work= ing when equipment is upgraded.

 
>
> New parameters that augment the interface need to require the conceptu= al
> service or feature to be enabled (create P-container) before any manda= tory parameters
> for that feature can be required.

The thing is: Every module’s data tree normally starts at the top lev= el. The only way for putting new nodes deeper into the hierarchy of an exis= ting module is to use augments.

Now, the desired modularity and need for supporting other address families = in the future dictate that address-family-specific data be factored out of = ietf-routing, so augments have to be used.

This all means this “Bonica Principle” leaves me with a cripple= d data modelling language. Having a P-container in every route is a sheer n= onsense.



It is not crippled. &nb= sp;You do not have to use augment.

YANG allows a n= ew revision of the original module to add a new
mandatory object = if there is an if-feature-stmt.

IMO the requirement of supporting old clients shouldn’t be an absolut= e priority.


I disagree. You can update the module = revision and make a new contract for a YANG module.
You cannot ma= ke these contract changes without updating the module revision.


 
Lada


Andy

=
 

>
> I think the text above prevents any mandatory child nodes to ever be a= dded, even if it
> is done inline in a new module revision.
>
> The if-feature text does not help an old-client/new-server if the modu= le is updated.
> The feature was not in the revision of the module the old client knows= .
> This is no different than adding mandatory nodes directly. (The if-fea= ture text
> is irrelevant).
>
> It should be OK to add new mandatory child nodes directly to a new mod= ule revision.
>
> The old client only has a contract for module A, rev N.  It shoul= d be OK to
> add more requirements in a new contract.  Augments is not the sam= e, because
> the revision for module A does not change.
>
>
>
> Lada
>
>
>
> Andy
>
>
> >
> > Lada
> >
> >
> > Andy
> >
> >
> > >
> > >
> > > /martin
> > >>
> > >
> > >
> > > Andy
> > >
> > >
> > >
> > >>
> > >> > --- Alex
> > >> >
> > >> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy
> > >> > Bierman
> > >> > Sent: Monday, March 24, 2014 2:30 PM
> > >> > To: Ladislav Lhotka
> > >> > Cc: netmod@ietf.= org
> > >> > Subject: Re: [netmod] allow mandatory nodes in augm= ents
> > >> >
> > >> >
> > >> >
> > >> > On Mon, Mar 24, 2014 at 1:48 PM, Ladislav Lhotka > > >> > <lhotka@nic.cz<= /a><mailto:lhotka@nic.cz>> wr= ote:
> > >> >
> > >> > On 24 Mar 2014, at 20:50, Andy Bierman
> > >> > <andy@yuma= works.com<mailto:andy@yumawork= s.com>> wrote:
> > >> >
> > >> > >
> > >> > >
> > >> > >
> > >> > > On Mon, Mar 24, 2014 at 12:11 PM, Ladislav Lho= tka
> > >> > > <lhotka@ni= c.cz<mailto:lhotka@nic.cz>&g= t; wrote:
> > >> > >
> > >> > > On 24 Mar 2014, at 18:33, Andy Bierman
> > >> > > <andy= @yumaworks.com<mailto:andy@yum= aworks.com>> wrote:
> > >> > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > On Mon, Mar 24, 2014 at 10:03 AM, Ladisla= v Lhotka
> > >> > > > <lhot= ka@nic.cz<mailto:lhotka@nic.cz&= gt;> wrote:
> > >> > > > * allow mandatory nodes in augments
> > >> > > >
> > >> > > > ** Description
> > >> > > >
> > >> > > > RFC 6020 states in
> > >> > > > [[http://tools.ietf.org/html/rfc6= 020#section-7.15][Sec. 7.15]]:
> > >> > > >
> > >> > > >    If the target node is in ano= ther module, then nodes added by the
> > >> > > >    augmentation MUST NOT be man= datory nodes (see Section 3.1).
> > >> > > >
> > >> > > > This rule was probably based on the assum= ption that augments will be
> > >> > > > used for really optional data that can be= safely ignored. However, as
> > >> > > > it turned out, augments have become an es= sential tool for modular
> > >> > > > development of YANG data models. In some = cases, the inability to
> > >> > > > define mandatory nodes in augments preven= ts the data modeller from
> > >> > > > specifying desired schema constraints. > > >> > > >
> > >> > > > For instance,
> > >> > > > [[
> > >> http://tools.ietf= .org/html/draft-ietf-netmod-interfaces-cfg-16#appendix-A][Appendix
> > >> > > > A]] in "interfaces-cfg" shows h= ow an Ethernet module can be written
> > >> > > > that augments "if:interface". H= owever, the container "ethernet"
> > >> cannot
> > >> > > > define any child leafs as mandatory even = though it may be necessary
> > >> > > > and would be normally done if the "e= thernet" container was defined
> > >> > > > directly in the "ietf-interfaces&quo= t; module.
> > >> > > >
> > >> > > > ** Solution
> > >> > > >
> > >> > > > Remove the rule cited above.
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > In the examples of this sort of augment u= sage, the augments are in
> > >> > > > different
> > >> > > > modules.  There is no requirement th= at a server implement all-or-none
> > >> > > > of
> > >> > > > these modules, just because they happen t= o be published in 1 RFC.
> > >> > >
> > >> > > This is not what I am saying.
> > >> > >
> > >> > > >
> > >> > > > The reason this rule exists is so a serve= r implementation of the
> > >> > > > augmenting module
> > >> > > > does not break old clients that do not kn= ow about this module.  They
> > >> > > > will not provide
> > >> > > > the mandatory values and edits will fail.= (Bonica Principle again).
> > >> > >
> > >> > > I don't buy this principle. I have already= argued that new
> > >> > > non-mandatory data in server's model can l= ead to unexpected
> > >> > > consequences if the client isn't aware of = them, see
> > >> > >
> > >> > > http://www.ietf.org/mail-= archive/web/netmod/current/msg09296.html
> > >> > >
> > >> > >
> > >> > >
> > >> > > If a new YANG object is defined such that it c= hanges the way an
> > >> > > existing
> > >> > > YANG object works, then the new object is brok= en.
> > >> > >
> > >> > > An old client should be able to configure the = objects it already knows
> > >> > > and the request should not be rejected because= of missing mandatory
> > >> > > nodes.
> > >> > >
> > >> > > The server can pick reasonable defaults for th= e new objects without
> > >> > > an old client needing to be re-coded.  A = client can use merge instead
> > >> > > of replace to
> > >> > > make sure that new objects do not get deleted.= The new objects can be
> > >> > > ignored
> > >> > > for editing purposes.  This is not true i= f the merge is rejected
> > >> > > because of missing
> > >> > > mandatory nodes.
> > >> >
> > >> > Let me rephrase the main point of this issue: Signi= ficant parts of our
> > >> > core models are defined inside augments, with more = to come (e.g.,
> > >> > modules for all interface type). These parts cannot= have mandatory
> > >> > contents due to that rule from sec. 7.15, which can= be a serious
> > >> > limitation because some parameters simply have no r= easonable defaults
> > >> > and have to be configured. The possibility of suppo= rting old clients
> > >> > (IMO dubious) does not outweigh this limitation. > > >> >
> > >> >
> > >> > If all these augments are in the same YANG module t= hen the
> > >> > augment-stmt is not
> > >> > really needed and inline definitions should be used= instead.
> > >> >
> > >> > If they are in different modules, then a server ven= dor may choose to
> > >> > implement the augmenting
> > >> > module in a later release than the base module. It = doesn't matter that
> > >> > a bunch of modules are
> > >> > published around the same time.  The likely ca= se is that the
> > >> > augmenting module is over a year later.
> > >> >
> > >> > It has nothing to do with YANG 1.0 vs. 1.1.
> > >> > It is a bad idea to break old clients that don'= t know about the new
> > >> > module.
> > >> >
> > >> > Note that it is possible to add new nodes, such tha= t the sibling/child
> > >> > nodes
> > >> > to the augmented nodes are optional, but their desc= endant nodes are
> > >> > mandatory.
> > >> > This should be OK.  An old client that provide= s just the base objects
> > >> > in a
> > >> > create or merge will not break if the new mandatory= objects are
> > >> > "protected"
> > >> > via an extra layer:
> > >> >
> > >> >
> > >> >    container top {
> > >> >       leaf old-1 { type string; } > > >> >    }
> > >> >
> > >> >
> > >> > NOT OK:
> > >> >
> > >> >    augment /top {
> > >> >        leaf from-augment-1 { > > >> >          type string;
> > >> >          mandatory true; > > >> >        }
> > >> >    }
> > >> >
> > >> >
> > >> >
> > >> > OK:
> > >> >
> > >> >    augment /top {
> > >> >        container pcon {
> > >> >            presence &= quot;must exist to make the leaf mandatory";
> > >> >
> > >> >           leaf from-augmen= t-1 {
> > >> >              typ= e string;
> > >> >              man= datory true;
> > >> >            }
> > >> >         }
> > >> >     }
> > >> >
> > >> >
> > >> >
> > >> > Lada
> > >> >
> > >> > >
> > >> >
> > >> >
> > >> > Andy
> > >> >
> > >>
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

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





--001a11c2e84853747c04f59932b0-- From nobody Thu Mar 27 09:57:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02621A01B5 for ; Thu, 27 Mar 2014 09:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJOi0WyJSTUe for ; Thu, 27 Mar 2014 09:57:47 -0700 (PDT) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5E51A00E3 for ; Thu, 27 Mar 2014 09:57:47 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id i17so4665670qcy.0 for ; Thu, 27 Mar 2014 09:57:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=2XfyJVC9wFHYofzysjJVn8efgCpxojZ2E8adHDBGQbI=; b=BpP2GKwiNiD/bnBFm2bdENR913LicwlZMIvQVKlE1ZF4862N/iH5Fnp/pj4CYuQZkp FRtqUxqzzOtZvC/Vb+7Jiqero+qIAPuRHeBFT4iXzeUL88t7abI76WAZAxSkf7YmBiBL Bdk+fG6Og3U6TQnrTa6qTQXoLYkUiK7st0HjbnQf9pe5gsqwMDLRwgEnS8gV/gBhZo4g jF/kFg5dc4vTyFpo12El6ffQRfoNoaxdks1n/VldHDH/wkwepCbiL7ZYzOm7kesO7TDQ LhbwZt9wCO4fYXHk+1pi7FJiTHWdRaf/m3ia3wIgEv47+RbWZpuofsgUgm34PBa7+VpY fbFQ== X-Gm-Message-State: ALoCoQkZqknKXMtMNRtioxlDQGnw+VR8gVgL3N+8UTSt5nwbvpuEJmeWLukYvd3XUVcrHFIizwUR MIME-Version: 1.0 X-Received: by 10.224.16.69 with SMTP id n5mr2012125qaa.7.1395939465386; Thu, 27 Mar 2014 09:57:45 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Thu, 27 Mar 2014 09:57:45 -0700 (PDT) Date: Thu, 27 Mar 2014 09:57:45 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7bea3986f66d4004f5997bf4 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/J-eJbQw6MbkFq2hpCLxGmUg1be4 Cc: "netmod@ietf.org" Subject: [netmod] new YANG 1.1 issue: adding mandatory nodes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 16:57:49 -0000 --047d7bea3986f66d4004f5997bf4 Content-Type: text/plain; charset=ISO-8859-1 Hi, This text in sec 10 is problematic: New data definition statements may be added if they do not add mandatory nodes (Section 3.1) to existing nodes or at the top level in a module or submodule, or if they are conditionally dependent on a new feature (i.e., have an "if-feature" statement that refers to a new feature). Issues: - What difference does a new YANG feature make to an old client? Why is the text about if-feature in the document? - It seems a mandatory child node (without if-feature) can never be added to a new revision. All mandatory child nodes need to be known in version 1. Adding new top-level objects (and replicating sub-trees) is impractical. - Any 'current' node can be changed to 'obsolete' status in a new revision. This will break an old client just as badly as adding a new mandatory node. Solution: - Allow new mandatory data definitions to be added in new releases. New data definition statements may be added to existing nodes or at the top level in a module or submodule. Andy --047d7bea3986f66d4004f5997bf4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

This text in sec 10 is problematic:= 

      New data definition statements may be added =
if they do not add
      mandatory nodes (Section 3.1) to existing nodes or at the top
      level in a module or submodule, or if they are conditionally
      dependent on a new feature (i.e., have an "if-feature" stat=
ement
      that refers to a new feature).

Issues:

=A0 - Wha= t difference does a new YANG feature make to an old client?
=A0 =A0 Why = is the text about if-feature in the document?

=A0 - It seems a mandatory child node (without if-featu= re) can never be added
=A0 =A0 to a new revision. =A0All mandator= y child nodes need to be known in version 1.
=A0 =A0 Adding new t= op-level objects (and replicating sub-trees) is impractical.

=A0- Any 'current' node can be changed to '= obsolete' status in a new revision.
=A0 =A0This will break an= old client just as badly as adding a new mandatory node.

Solution:

=A0 - Allow new mandatory data defi= nitions to be added in new releases.

      New data=
 definition statements may be added to existing nodes
      or at the top level in a module or submodule.

<= pre style=3D"color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap"> Andy


--047d7bea3986f66d4004f5997bf4-- From nobody Fri Mar 28 02:48:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4517B1A08B4; Fri, 28 Mar 2014 02:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wB8cxKvuMRta; Fri, 28 Mar 2014 02:48:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7321A08B2; Fri, 28 Mar 2014 02:48:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140328094851.9787.30496.idtracker@ietfa.amsl.com> Date: Fri, 28 Mar 2014 02:48:51 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/CGAezqEhUTaLIWlA3aghdUzH6yU Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-14.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 09:48:53 -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 Working Group of the IETF. Title : A YANG Data Model for IP Management Author : Martin Bjorklund Filename : draft-ietf-netmod-ip-cfg-14.txt Pages : 32 Date : 2014-03-28 Abstract: This document defines a YANG data model for management of IP implementations. The data model includes configuration data and state data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-ip-cfg-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 28 03:49:41 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6CE1A04CD; Fri, 28 Mar 2014 03:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lqQLK8hLkQE; Fri, 28 Mar 2014 03:49:38 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3891A04C8; Fri, 28 Mar 2014 03:49:38 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8345FFE8; Fri, 28 Mar 2014 11:49:35 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id HJb7aiUo7aVV; Fri, 28 Mar 2014 11:49:35 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 28 Mar 2014 11:49:35 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EAA3B2002C; Fri, 28 Mar 2014 11:49:34 +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 DEMJVuZKGeyT; Fri, 28 Mar 2014 11:49:34 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C85332002F; Fri, 28 Mar 2014 11:49:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D9B932C16B3C; Fri, 28 Mar 2014 11:49:31 +0100 (CET) Date: Fri, 28 Mar 2014 11:49:30 +0100 From: Juergen Schoenwaelder To: internet-drafts@ietf.org Message-ID: <20140328104930.GA60294@elstar.local> Mail-Followup-To: internet-drafts@ietf.org, i-d-announce@ietf.org, netmod@ietf.org References: <20140328094851.9787.30496.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140328094851.9787.30496.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/vfHj-g-_w-OW4oAruT4zkF0oHjw Cc: netmod@ietf.org, i-d-announce@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-14.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 28 Mar 2014 10:49:40 -0000 Martin, perhaps you can change the format a bit by including a reference statement as we do in all other definitions. This is purely an editorial and style consistency thing, I know (so if it is problematic, ignore it). I guess this can be done during auth48 once we know the RFC number of I-D.ietf-6man-stable-privacy-addresses: OLD enum random { description "Indicates an address chosen by the system at random, e.g., an IPv4 address within 169.254/16, an RFC 4941 temporary address, or a semantically opaque address [I-D.ietf-6man-stable-privacy-addresses]"; } NEW enum random { description "Indicates an address chosen by the system at random, e.g., an IPv4 address within 169.254/16, an RFC 4941 temporary address, or an RFC XXXX semantically opaque address."; reference "RFC 4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 RFC XXXX: A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)"; } /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 Mar 28 08:03:17 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECD61A069C for ; Fri, 28 Mar 2014 08:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4f8ej6_2swhI for ; Fri, 28 Mar 2014 08:03:12 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5524C1A0696 for ; Fri, 28 Mar 2014 08:03:12 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 52675140266; Fri, 28 Mar 2014 16:03:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1396018989; bh=ofmruiub7VmgvT1gJptce0fIzvHKOQT4kECEpr6ARBs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=HfknB/6/mt55lsnAWup/LMKPxId5J+ryAArdLWN4CW6WkuChtCj1NqUT/O3ul0mnc WW4CeqUglekNbeLjoCyWEcqFYbhdy/kmuXcIiZeoysa2La1zMdi5NT9VNmR6dN+42i RrtfKzWGCB7IMWcvXZzdhvqX8jrjBuSmqAmwbI+Q= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 28 Mar 2014 16:03:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140327.080423.2031221427554871516.mbj@tail-f.com> <44D79BA2-D259-4A8C-ABA5-BC5AB5B69254@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/MCkZPfy9dPuoXOB9_nu6RtMd-50 Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 15:03:16 -0000 On 27 Mar 2014, at 17:37, Andy Bierman wrote: >=20 >=20 >=20 > On Thu, Mar 27, 2014 at 9:04 AM, Ladislav Lhotka = wrote: >=20 > On 27 Mar 2014, at 16:35, Andy Bierman wrote: >=20 > > > > > > > > On Thu, Mar 27, 2014 at 8:06 AM, Ladislav Lhotka = wrote: > > > > On 27 Mar 2014, at 15:37, Andy Bierman wrote: > > > > > > > > > > > > > > On Thu, Mar 27, 2014 at 7:23 AM, Ladislav Lhotka = wrote: > > > Andy Bierman writes: > > > > > > > On Thu, Mar 27, 2014 at 12:04 AM, Martin Bjorklund = wrote: > > > > > > > >> Hi Alex, > > > >> > > > >> "Alexander Clemm (alex)" wrote: > > > >> > I agree that this type of solution is what is needed. This = has been > > > >> > our experience developing models as well. > > > >> > The solution as indicated in the example, that the augmenting = module > > > >> > itself (and hence "top-level" data nodes) cannot be = mandatory, but > > > >> > that in the presence of container data nodes, nodes = underneath can > > > >> > become mandatory, makes a lot of sense to me. > > > >> > > > >> I don't really understand what you mean. Do you agree with = Lada that > > > >> augment should be allowed to add mandatory nodes, or do you = agree with > > > >> Andy that it is ok to augment e.g. a P-container which defines = the > > > >> mandatory nodes? > > > >> > > > >> > > > > > > > > IMO we cannot break existing clients. > > > > Since it is possible to add the nodes in a way that does not = expose the > > > > mandatory > > > > nodes to an "old" create or merge, then that should always be = used. > > > > Any create or merge that adds the P container (or list) has to = do so > > > > correctly > > > > with the mandatory sub-nodes. > > > > > > I think this doesn't solve anything. Let's take the example of the = "interface" list (which is a very typical use case) and assume the = server and client want to use both the base and augmenting module that = defines parameters for a particular interface type, say "foo". The = client creates an new entry like > > > > > > "interface": { > > > "name": "foo0", > > > "type": "foo" > > > } > > > > > > and can stop here because all foo parameters are inside a = P-container. This may not be acceptable if some of the parameters are = really required for a foo interface to work. The P-container makes no = difference: the data model is still too loose. > > > > > > > > > > > > It doesn't matter that there might be some parameters that are = needed. > > > They have to be added correctly. They can be set by the server or = a new client. > > > > I am talking about a new client, and I assume some items, such as = cryptographic data, cannot be set by the server. > > > > > > > > The rules in sec. 10 are very clear. YANG is modular. An old = client is not > > > required in any way to use augmenting modules added after the = client was written. > > > > This could work in theory if augments were restricted to adding = marginal stuff, but as I wrote in the description of this issue, = augments do some heavy lifting in the core data models. For example, the = routing module is pretty much useless by itself, it has to be augmented = by at least one address-family specific module. > > > > > > > > The P-container wrapper is not itself mandatory so an old client = can safely use > > > create and merge without error (by ignoring the new P-container). > > > > I don=92t get the benefit of this P-container, the problem is still = the same: the data model doesn=92t bind the client to configure = parameters that are in fact mandatory. > > > > I do not agree that mandatory objects can be added via augments = without > > breaking the contract specified by the augmented module. You have to = up > > > > > > > > > > This is how real software has to be maintained. Applications get = coded > > > to work with a specific release of a data model. If that code is = working and > > > deployed, then adding a new module in a future release cannot = cause the > > > deployed app to start getting validation errors. > > > > This could work if the modules were totally isolated, or carefully = designed to support this kind of cherry-picking. But in general it is = unsafe: augmenting modules might add defaults that the server will use = even if the client isn=92t aware of them. > > > > Yes, as a client of an insurance company, I can also sign their = contract without reading the fine print =85 > > > > > > from RFC 6020, sec. 10: > > New data definition statements may be added if they do not add > > mandatory nodes (Section 3.1) to existing nodes or at the top > > level in a module or submodule, or if they are conditionally > > dependent on a new feature (i.e., have an "if-feature" = statement > > that refers to a new feature). > > > > > > The old client did read the fine print in module A. New contracts > > (augmenting modules) have to add content > > in a way that allows the old client to opt-in. >=20 > The old client has =93signed=94 the new contract by not closing the = session after seeing new server=92s hello. >=20 >=20 >=20 > It doesn't work that way -- customers get mad when the tools they paid = for > stop working when equipment is upgraded. Yes, and blokes who sold them those tools suffer, that=92s what I = understand. But it is IMO not the complete story. >=20 > =20 > > > > New parameters that augment the interface need to require the = conceptual > > service or feature to be enabled (create P-container) before any = mandatory parameters > > for that feature can be required. >=20 > The thing is: Every module=92s data tree normally starts at the top = level. The only way for putting new nodes deeper into the hierarchy of = an existing module is to use augments. >=20 > Now, the desired modularity and need for supporting other address = families in the future dictate that address-family-specific data be = factored out of ietf-routing, so augments have to be used. >=20 > This all means this =93Bonica Principle=94 leaves me with a crippled = data modelling language. Having a P-container in every route is a sheer = nonsense. >=20 >=20 >=20 > It is not crippled. You do not have to use augment. What do you mean? Our core data models use augments in several places as = a first-class data modelling tool for achieving top-down modularity, not = for adding parameters as an afterthought. As far as I can tell, every = larger undertaking in YANG does use augments. >=20 > YANG allows a new revision of the original module to add a new > mandatory object if there is an if-feature-stmt. >=20 > IMO the requirement of supporting old clients shouldn=92t be an = absolute priority. >=20 >=20 > I disagree. You can update the module revision and make a new contract = for a YANG module. > You cannot make these contract changes without updating the module = revision. One idea - would it be possible to use the packages is a way that = guarantees that every package is self-sustainable? This could solve this = issue. Lada >=20 >=20 > =20 > Lada >=20 >=20 > Andy >=20 > =20 >=20 > > > > I think the text above prevents any mandatory child nodes to ever be = added, even if it > > is done inline in a new module revision. > > > > The if-feature text does not help an old-client/new-server if the = module is updated. > > The feature was not in the revision of the module the old client = knows. > > This is no different than adding mandatory nodes directly. (The = if-feature text > > is irrelevant). > > > > It should be OK to add new mandatory child nodes directly to a new = module revision. > > > > The old client only has a contract for module A, rev N. It should = be OK to > > add more requirements in a new contract. Augments is not the same, = because > > the revision for module A does not change. > > > > > > > > Lada > > > > > > > > Andy > > > > > > > > > > Lada > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > /martin > > > >> > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > >> > > > >> > --- Alex > > > >> > > > > >> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of = Andy > > > >> > Bierman > > > >> > Sent: Monday, March 24, 2014 2:30 PM > > > >> > To: Ladislav Lhotka > > > >> > Cc: netmod@ietf.org > > > >> > Subject: Re: [netmod] allow mandatory nodes in augments > > > >> > > > > >> > > > > >> > > > > >> > On Mon, Mar 24, 2014 at 1:48 PM, Ladislav Lhotka > > > >> > > wrote: > > > >> > > > > >> > On 24 Mar 2014, at 20:50, Andy Bierman > > > >> > > wrote: > > > >> > > > > >> > > > > > >> > > > > > >> > > > > > >> > > On Mon, Mar 24, 2014 at 12:11 PM, Ladislav Lhotka > > > >> > > > wrote: > > > >> > > > > > >> > > On 24 Mar 2014, at 18:33, Andy Bierman > > > >> > > > wrote: > > > >> > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > On Mon, Mar 24, 2014 at 10:03 AM, Ladislav Lhotka > > > >> > > > > wrote: > > > >> > > > * allow mandatory nodes in augments > > > >> > > > > > > >> > > > ** Description > > > >> > > > > > > >> > > > RFC 6020 states in > > > >> > > > [[http://tools.ietf.org/html/rfc6020#section-7.15][Sec. = 7.15]]: > > > >> > > > > > > >> > > > If the target node is in another module, then nodes = added by the > > > >> > > > augmentation MUST NOT be mandatory nodes (see Section = 3.1). > > > >> > > > > > > >> > > > This rule was probably based on the assumption that = augments will be > > > >> > > > used for really optional data that can be safely ignored. = However, as > > > >> > > > it turned out, augments have become an essential tool for = modular > > > >> > > > development of YANG data models. In some cases, the = inability to > > > >> > > > define mandatory nodes in augments prevents the data = modeller from > > > >> > > > specifying desired schema constraints. > > > >> > > > > > > >> > > > For instance, > > > >> > > > [[ > > > >> = http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-16#appendix-A]= [Appendix > > > >> > > > A]] in "interfaces-cfg" shows how an Ethernet module can = be written > > > >> > > > that augments "if:interface". However, the container = "ethernet" > > > >> cannot > > > >> > > > define any child leafs as mandatory even though it may be = necessary > > > >> > > > and would be normally done if the "ethernet" container = was defined > > > >> > > > directly in the "ietf-interfaces" module. > > > >> > > > > > > >> > > > ** Solution > > > >> > > > > > > >> > > > Remove the rule cited above. > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > In the examples of this sort of augment usage, the = augments are in > > > >> > > > different > > > >> > > > modules. There is no requirement that a server implement = all-or-none > > > >> > > > of > > > >> > > > these modules, just because they happen to be published = in 1 RFC. > > > >> > > > > > >> > > This is not what I am saying. > > > >> > > > > > >> > > > > > > >> > > > The reason this rule exists is so a server implementation = of the > > > >> > > > augmenting module > > > >> > > > does not break old clients that do not know about this = module. They > > > >> > > > will not provide > > > >> > > > the mandatory values and edits will fail. (Bonica = Principle again). > > > >> > > > > > >> > > I don't buy this principle. I have already argued that new > > > >> > > non-mandatory data in server's model can lead to unexpected > > > >> > > consequences if the client isn't aware of them, see > > > >> > > > > > >> > > = http://www.ietf.org/mail-archive/web/netmod/current/msg09296.html > > > >> > > > > > >> > > > > > >> > > > > > >> > > If a new YANG object is defined such that it changes the = way an > > > >> > > existing > > > >> > > YANG object works, then the new object is broken. > > > >> > > > > > >> > > An old client should be able to configure the objects it = already knows > > > >> > > and the request should not be rejected because of missing = mandatory > > > >> > > nodes. > > > >> > > > > > >> > > The server can pick reasonable defaults for the new objects = without > > > >> > > an old client needing to be re-coded. A client can use = merge instead > > > >> > > of replace to > > > >> > > make sure that new objects do not get deleted. The new = objects can be > > > >> > > ignored > > > >> > > for editing purposes. This is not true if the merge is = rejected > > > >> > > because of missing > > > >> > > mandatory nodes. > > > >> > > > > >> > Let me rephrase the main point of this issue: Significant = parts of our > > > >> > core models are defined inside augments, with more to come = (e.g., > > > >> > modules for all interface type). These parts cannot have = mandatory > > > >> > contents due to that rule from sec. 7.15, which can be a = serious > > > >> > limitation because some parameters simply have no reasonable = defaults > > > >> > and have to be configured. The possibility of supporting old = clients > > > >> > (IMO dubious) does not outweigh this limitation. > > > >> > > > > >> > > > > >> > If all these augments are in the same YANG module then the > > > >> > augment-stmt is not > > > >> > really needed and inline definitions should be used instead. > > > >> > > > > >> > If they are in different modules, then a server vendor may = choose to > > > >> > implement the augmenting > > > >> > module in a later release than the base module. It doesn't = matter that > > > >> > a bunch of modules are > > > >> > published around the same time. The likely case is that the > > > >> > augmenting module is over a year later. > > > >> > > > > >> > It has nothing to do with YANG 1.0 vs. 1.1. > > > >> > It is a bad idea to break old clients that don't know about = the new > > > >> > module. > > > >> > > > > >> > Note that it is possible to add new nodes, such that the = sibling/child > > > >> > nodes > > > >> > to the augmented nodes are optional, but their descendant = nodes are > > > >> > mandatory. > > > >> > This should be OK. An old client that provides just the base = objects > > > >> > in a > > > >> > create or merge will not break if the new mandatory objects = are > > > >> > "protected" > > > >> > via an extra layer: > > > >> > > > > >> > > > > >> > container top { > > > >> > leaf old-1 { type string; } > > > >> > } > > > >> > > > > >> > > > > >> > NOT OK: > > > >> > > > > >> > augment /top { > > > >> > leaf from-augment-1 { > > > >> > type string; > > > >> > mandatory true; > > > >> > } > > > >> > } > > > >> > > > > >> > > > > >> > > > > >> > OK: > > > >> > > > > >> > augment /top { > > > >> > container pcon { > > > >> > presence "must exist to make the leaf mandatory"; > > > >> > > > > >> > leaf from-augment-1 { > > > >> > type string; > > > >> > mandatory true; > > > >> > } > > > >> > } > > > >> > } > > > >> > > > > >> > > > > >> > > > > >> > Lada > > > >> > > > > >> > > > > > >> > > > > >> > > > > >> > Andy > > > >> > > > > >> > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Mar 28 08:10:40 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6029E1A069C for ; Fri, 28 Mar 2014 08:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koXA4EKbLwTt for ; Fri, 28 Mar 2014 08:10:38 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id DE7FC1A06FE for ; Fri, 28 Mar 2014 08:10:37 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 32C423940C3; Fri, 28 Mar 2014 16:10:33 +0100 (CET) Date: Fri, 28 Mar 2014 16:10:32 +0100 (CET) Message-Id: <20140328.161032.686609160477820768.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cZgorhnPYitBg4nD-I2hQ9HAMW8 Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 issue: adding mandatory nodes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 15:10:39 -0000 Hi, This is now Y27. /martin Andy Bierman wrote: > Hi, > > This text in sec 10 is problematic: > > New data definition statements may be added if they do not add > mandatory nodes (Section 3.1) to existing nodes or at the top > level in a module or submodule, or if they are conditionally > dependent on a new feature (i.e., have an "if-feature" statement > that refers to a new feature). > > > Issues: > > - What difference does a new YANG feature make to an old client? > Why is the text about if-feature in the document? > > - It seems a mandatory child node (without if-feature) can never be added > to a new revision. All mandatory child nodes need to be known in > version 1. > Adding new top-level objects (and replicating sub-trees) is impractical. > > - Any 'current' node can be changed to 'obsolete' status in a new revision. > This will break an old client just as badly as adding a new mandatory > node. > > Solution: > > - Allow new mandatory data definitions to be added in new releases. > > New data definition statements may be added to existing nodes > or at the top level in a module or submodule. > > > Andy From nobody Fri Mar 28 08:14:40 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2F41A0738 for ; Fri, 28 Mar 2014 08:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_C-iQbFeWqD for ; Fri, 28 Mar 2014 08:14:34 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 519971A0919 for ; Fri, 28 Mar 2014 08:14:33 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id AF2AE3940C3 for ; Fri, 28 Mar 2014 16:14:30 +0100 (CET) Date: Fri, 28 Mar 2014 16:14:30 +0100 (CET) Message-Id: <20140328.161430.1163391055037715516.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7unGOd9Gm4AbSPFbnSgawK5xC88 Subject: [netmod] Y27: allow mandatory nodes in an updated module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 15:14:35 -0000 Hi, > This text in sec 10 is problematic: > > New data definition statements may be added if they do not add > mandatory nodes (Section 3.1) to existing nodes or at the top > level in a module or submodule, or if they are conditionally > dependent on a new feature (i.e., have an "if-feature" statement > that refers to a new feature). > > > Issues: > > - What difference does a new YANG feature make to an old client? > Why is the text about if-feature in the document? I agree that this is wrong. So, the reason for doing having this rule is stated in section 10: changes are not allowed if they have any potential to cause interoperability problems between a client using an original specification and a server using an updated specification. Adding a mandatory node can break the old client. So if we relax this rule, we need to be aware of how this affects old clients. /martin From nobody Fri Mar 28 08:27:16 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E641A074F for ; Fri, 28 Mar 2014 08:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTP04RsoHxoV for ; Fri, 28 Mar 2014 08:27:12 -0700 (PDT) Received: from exprod5og116.obsmtp.com (exprod5og116.obsmtp.com [64.18.0.147]) by ietfa.amsl.com (Postfix) with ESMTP id E28DA1A0735 for ; Fri, 28 Mar 2014 08:27:11 -0700 (PDT) Received: from alpmlip10.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob116.postini.com ([64.18.4.12]) with SMTP ID DSNKUzWUzWcz+XD8YVGEOWlQU6s31QuEVw6m@postini.com; Fri, 28 Mar 2014 08:27:10 PDT Received: from unknown (HELO ALPMBHT03.e2k.ad.ge.com) ([3.159.19.196]) by alpmlip10.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 28 Mar 2014 12:15:33 -0400 Received: from CINURCNA13.e2k.ad.ge.com (3.159.212.150) by ALPMBHT03.e2k.ad.ge.com (3.159.19.196) with Microsoft SMTP Server (TLS) id 14.3.174.2; Fri, 28 Mar 2014 11:27:08 -0400 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.29]) by CINURCNA13.e2k.ad.ge.com ([169.254.1.143]) with mapi id 14.03.0174.002; Fri, 28 Mar 2014 11:27:08 -0400 From: "Lange, Jeffrey K (GE Energy Management)" To: "netmod@ietf.org" Thread-Topic: [netmod] Default presence containers Thread-Index: AQHPSpoujlbBEy7y5Ue1A9weoXE0Ag== Date: Fri, 28 Mar 2014 15:27:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [3.159.212.181] Content-Type: text/plain; charset="euc-kr" Content-ID: <624E420A1F83EF42BE5244F580EB54DD@mail.ad.ge.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/y1ISwTMKAo8EBzQ24UCOz2M9BQI Subject: Re: [netmod] Default presence containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 15:27:14 -0000 RGlkIHRoaXMgZ2V0IGxvc3QgaW4gdGhlIHdlZWRzPyBPciBpcyBpdCBqdXN0IHRoYXQgbm8gb25l IHRoaW5rcyBpdKGvcyBhDQp2YWxpZCBjb25jZXJuPw0KDQotSmVmZg0KDQoNCg0KT24gMy8yNi8x NCwgMTA6MTYgQU0sICJMYW5nZSwgSmVmZnJleSBLIChHRSBFbmVyZ3kgTWFuYWdlbWVudCkiDQo8 amVmZnJleS5LLmxhbmdlQGdlLmNvbT4gd3JvdGU6DQoNCj5JcyB0aGVyZSBhbnkgd2F5IGluIFlB TkcgdGhhdCBvbmUgY2FuIGNyZWF0ZSBhIHByZXNlbmNlIGNvbnRhaW5lciB3aXRoIGENCj5kZWZh dWx0IHN0YXRlPyA2MDIwIGRvZXMgbm90IGxpc3QgqfhkZWZhdWx0qfcgYXMgYSBzdWIgc3RhdGVt ZW50IHRvDQo+Y29udGFpbmVyLiBJZiBub3QsIHBlcmhhcHMgdGhpcyBpcyBhIHVzZWZ1bCBmZWF0 dXJlIGZvciBZQU5HIDEuMQ0KPg0KPmUuZy4gKGZyb20gNjAyMCk6DQo+DQo+Y29udGFpbmVyIHN5 c3RlbSB7DQo+ICAgIGRlc2NyaXB0aW9uICJDb250YWlucyB2YXJpb3VzIHN5c3RlbSBwYXJhbWV0 ZXJzIjsNCj4gICAgY29udGFpbmVyIHNlcnZpY2VzIHsNCj4gICAgICAgIGRlc2NyaXB0aW9uICJD b25maWd1cmUgZXh0ZXJuYWxseSBhdmFpbGFibGUgc2VydmljZXMiOw0KPiAgICAgICAgY29udGFp bmVyICJzc2giIHsNCj4gICAgICAgICAgICBwcmVzZW5jZSAiRW5hYmxlcyBTU0giOw0KPiAgICAg ICAgICAgIGRlc2NyaXB0aW9uICJTU0ggc2VydmljZSBzcGVjaWZpYyBjb25maWd1cmF0aW9uqfc7 DQo+ICAgICAgICAgICAgZGVmYXVsdCBwcmVzZW50OyAvLyBvciBub3QtcHJlc2VudA0KPiAgICAg ICAgfQ0KPiAgICB9DQo+fQ0KPg0KPlRoYW5rcyENCj4tSmVmZg0KPg0KPiANCj4NCj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5ldG1vZCBtYWlsaW5n IGxpc3QNCj5uZXRtb2RAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZA0KDQo= From nobody Fri Mar 28 08:31:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088FD1A063C for ; Fri, 28 Mar 2014 08:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGgdHPo5Z3A4 for ; Fri, 28 Mar 2014 08:31:01 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) by ietfa.amsl.com (Postfix) with ESMTP id 76F9A1A02DB for ; Fri, 28 Mar 2014 08:31:01 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id j107so4559958qga.35 for ; Fri, 28 Mar 2014 08:30:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WdjDPmo/p3XQRVxCii/y3llwHu6ihrezr+QvSHXD7z8=; b=f4R+SbxAD6c69XdDKAV3YBmk6NoufnKix2YAPeqJibvucGu5ouTQXXYacdSPv9+mq6 VtaXFBHWjnbEOVYcwb7Gfwx9KWKTMP2ZoSTOBFnTyQ/ZFbWgIxBv2A9HvO+gsHHuIkbi OYNbum725HH7uAr78D86t1H/tSFr/lOM5Cp6vsWAZ+aNG1ConQoprpA4esxUX0HXFOTh 5K6YS/WmzSeXm7zj6UPDYZTnLRHJqfoLJnu3AMMH46YYHpXqH9euZsHXCIOYvDTBWcRj FyDxm0dK2CMQyatuyowSiBRboaVNBvYweTKszKDDimF0AE2vMrv71+JgHmxe2gwKwx3q ZSdg== X-Gm-Message-State: ALoCoQnWc/oDCQq4wcJlIoRbK6dnWR+efbrm87iWi8L361x2YwunP35LZUy/BaOCayz2C2yc+crf MIME-Version: 1.0 X-Received: by 10.140.104.103 with SMTP id z94mr2723945qge.91.1396020659075; Fri, 28 Mar 2014 08:30:59 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Fri, 28 Mar 2014 08:30:59 -0700 (PDT) In-Reply-To: <20140328.161430.1163391055037715516.mbj@tail-f.com> References: <20140328.161430.1163391055037715516.mbj@tail-f.com> Date: Fri, 28 Mar 2014 08:30:59 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a1134f2be7bd2bd04f5ac6336 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6CQwAdAUAVgcuKFOA6f3KMlxXSE Cc: "netmod@ietf.org" Subject: Re: [netmod] Y27: allow mandatory nodes in an updated module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 15:31:03 -0000 --001a1134f2be7bd2bd04f5ac6336 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 28, 2014 at 8:14 AM, Martin Bjorklund wrote: > Hi, > > > This text in sec 10 is problematic: > > > > New data definition statements may be added if they do not add > > mandatory nodes (Section 3.1) to existing nodes or at the top > > level in a module or submodule, or if they are conditionally > > dependent on a new feature (i.e., have an "if-feature" statement > > that refers to a new feature). > > > > > > Issues: > > > > - What difference does a new YANG feature make to an old client? > > Why is the text about if-feature in the document? > > I agree that this is wrong. > > > > So, the reason for doing having this rule is stated in section 10: > > changes are not allowed if they have any > potential to cause interoperability problems between a client using > an original specification and a server using an updated > specification. > > > Adding a mandatory node can break the old client. > > Yes. Removing an object (status=obsolete) can break a client, yet this is allowed. > So if we relax this rule, we need to be aware of how this affects > old clients. > > It means there may be a max-version of a YANG module that an application can use -- for either reason (objects added or removed). IMO it is unrealistic to require all mandatory functionality to be specified in the first version of a module. > /martin > > Andy --001a1134f2be7bd2bd04f5ac6336 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Mar 28, 2014 at 8:14 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Hi,

> =A0 This text in sec 10 is problematic:
>
> =A0 =A0 =A0 New data definition statements may be added if they do not= add
> =A0 =A0 =A0 mandatory nodes (Section 3.1) to existing nodes or at the = top
> =A0 =A0 =A0 level in a module or submodule, or if they are conditional= ly
> =A0 =A0 =A0 dependent on a new feature (i.e., have an "if-feature= " statement
> =A0 =A0 =A0 that refers to a new feature).
>
>
> =A0 Issues:
>
> =A0 =A0 - What difference does a new YANG feature make to an old clien= t?
> =A0 =A0 =A0 Why is the text about if-feature in the document?

I agree that this is wrong.



So, the reason for doing having this rule is stated in section 10:

=A0 =A0changes are not allowed if they have any
=A0 =A0potential to cause interoperability problems between a client using<= br> =A0 =A0an original specification and a server using an updated
=A0 =A0specification.


Adding a mandatory node can break the old client.


Yes. Removing an object (status=3Dobso= lete) can break a client,
yet this is allowed.

=A0
So if we relax this rule, we need to be aware of how this affects
old clients.


It means there may be a max-version of= a YANG module that
an application can use -- for either reason (= objects added or removed).

IMO it is unrealistic t= o require all mandatory functionality
to be specified in the first version of a module.

=


/martin


Andy

<= /div> --001a1134f2be7bd2bd04f5ac6336-- From nobody Fri Mar 28 08:36:19 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65ED31A0374 for ; Fri, 28 Mar 2014 08:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gR_2H_ey1z7 for ; Fri, 28 Mar 2014 08:36:14 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFD11A02DB for ; Fri, 28 Mar 2014 08:36:14 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id r5so6168838qcx.32 for ; Fri, 28 Mar 2014 08:36:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dvpviXKaNJEEbDxUPzMMOonTCca33mmCEAylLAdWlhg=; b=L6082HghumvAkJFOGTIo49yzr5uJDWp+5Jys+ORErXlyR1lu3ypl07UgCJ+5UifLwm pgq9GjY30Sgm9hE4O9wVxjY4eL06UCYvLLp9PjoePQF0xEjIJKKMsgqyJP7oWTBeM3WE HgH7HT1DFoZiIGucSvDh8Yn3W0OuTh7RVJPpvDhVWAhh8FEgGVneg8aBpRt7T6+uXxIG sxWfs05FcuewidfmS8gGpGsD9vCpTKz4x1COKcIM08IpJ64LfkX2QQdblKfVk26PLzEP xyg9dhN2cFwwK4qzI3nBC4x6EIG+xpK/J9n2bkHSjPpqwDPTcqbwYmNQBqUbuO7MSFih GqtQ== X-Gm-Message-State: ALoCoQnVFCAX6F/KZ+X2lxzZzsWtc96/34Xml2sHLwqFtrDJzadFf9XAl/GfJbCTsaAJBR/aI9Ck MIME-Version: 1.0 X-Received: by 10.224.16.69 with SMTP id n5mr8558723qaa.7.1396020972095; Fri, 28 Mar 2014 08:36:12 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Fri, 28 Mar 2014 08:36:12 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 Mar 2014 08:36:12 -0700 Message-ID: From: Andy Bierman To: "Lange, Jeffrey K (GE Energy Management)" Content-Type: multipart/alternative; boundary=047d7bea39862464ac04f5ac7657 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/8BQfK4Yww8V6H0gfiGJjFXyapDE Cc: "netmod@ietf.org" Subject: Re: [netmod] Default presence containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 15:36:17 -0000 --047d7bea39862464ac04f5ac7657 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Mar 28, 2014 at 8:27 AM, Lange, Jeffrey K (GE Energy Management) < jeffrey.K.lange@ge.com> wrote: > Did this get lost in the weeds? Or is it just that no one thinks it's a > valid concern? > > I think this is interesting. A new statement should be used instead of overloading the default-stmt. That is supposed to be for a leaf only, and the string must be valid for the data type. Maybe: default-presence true|false; > -Jeff > Andy > > > > On 3/26/14, 10:16 AM, "Lange, Jeffrey K (GE Energy Management)" > wrote: > > >Is there any way in YANG that one can create a presence container with a > >default state? 6020 does not list =B3default=B2 as a sub statement to > >container. If not, perhaps this is a useful feature for YANG 1.1 > > > >e.g. (from 6020): > > > >container system { > > description "Contains various system parameters"; > > container services { > > description "Configure externally available services"; > > container "ssh" { > > presence "Enables SSH"; > > description "SSH service specific configuration=B2; > > default present; // or not-present > > } > > } > >} > > > >Thanks! > >-Jeff > > > > > > > >_______________________________________________ > >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 > --047d7bea39862464ac04f5ac7657 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Mar 28, 2014 at 8:27 AM, Lange, Jeffrey K (GE Energy Manage= ment) <jeffrey.K.lange@ge.com> wrote:
Did this get lost in the weeds? Or is it jus= t that no one thinks it’s a
valid concern?



I think this is interes= ting.
A new statement should be used instead of overloading the d= efault-stmt.
That is supposed to be for a leaf only, and the stri= ng must be valid for the data type.

Maybe:

   default-pr= esence true|false;

 
-Jeff

Andy
 



On 3/26/14, 10:16 AM, "Lange, Jeffrey K (GE Energy Management)" <jeffrey.K.lange@ge.com>= ; wrote:

>Is there any way in YANG that one can create a presence container with = a
>default state? 6020 does not list =B3default=B2 as a sub statement to >container. If not, perhaps this is a useful feature for YANG 1.1
>
>e.g. (from 6020):
>
>container system {
>    description "Contains various system parameters"= ;;
>    container services {
>        description "Configure externally avai= lable services";
>        container "ssh" {
>            presence "Enables SSH&qu= ot;;
>            description "SSH service= specific configuration=B2;
>            default present; // or not-pr= esent
>        }
>    }
>}
>
>Thanks!
>-Jeff
>
>
>
>_______________________________________________
>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

--047d7bea39862464ac04f5ac7657-- From nobody Fri Mar 28 08:43:48 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6551A063C for ; Fri, 28 Mar 2014 08:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBG-VSdcLQh2 for ; Fri, 28 Mar 2014 08:43:44 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) by ietfa.amsl.com (Postfix) with ESMTP id BDCA71A0639 for ; Fri, 28 Mar 2014 08:43:44 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id 63so4579417qgz.34 for ; Fri, 28 Mar 2014 08:43:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=OGiF+3a18n9Nj36eBvvFoYcoPAJ0LVgaOz9jrcv57d4=; b=dvrjP45CYP4EjbLOnLngiVzQiBFYVMcn84bdN1pTldj9Q4HKKHsBODR6Qi78od+F1b bd3aBaYkILb+v7tHSNYJ/n1tsIbPrEkjlBZTRO2EyGoAmfe5LmAz2HcPXeLIxsda+GLk XCK+a9hmY0zi8AFFHt7+3Sylwh99YkAE6Dg4D1CF5ziykIP0PVdIQ7SAOqHJZd2H5kyw rd6Nz96JtFCMzUxOrsqc3gmb55ks5KioNjxABHykxU1YqYzd1Es5MCyb/NQBSqjZJZrC C7TnJD4DNMu7hBJQVwx87QY0D8YswE5VtuHsuhFN+7THHnI2I+RA964/CLDWubjGnHY4 hEMA== X-Gm-Message-State: ALoCoQl3bptHK2orV65cSA4ztM4pw15nilhNrTQsmoiqrGoc+O0KU5bVWlegmtTI87szSiZ/Zoru MIME-Version: 1.0 X-Received: by 10.140.92.6 with SMTP id a6mr9434248qge.34.1396021422444; Fri, 28 Mar 2014 08:43:42 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Fri, 28 Mar 2014 08:43:42 -0700 (PDT) Date: Fri, 28 Mar 2014 08:43:42 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a1139a970fc5cb704f5ac9086 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OvwzJDjEsfIMSkw9cop3Eo1_iVA Subject: [netmod] new YANG 1.1 issue: default for leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 15:43:46 -0000 --001a1139a970fc5cb704f5ac9086 Content-Type: text/plain; charset=ISO-8859-1 Hi, Not sure if this is too difficult or too minor... There are use cases where a leaf-list is initialized with some default value if no client value is provided (same as a leaf). E.g. leaf-list ncport { type inet:port-number; description "The port numbers that should be accepted for NETCONF sessions"; default "[830]"; } This would require some new syntax to represent an array of default values. Proposal: support default for leaf-list somehow Andy --001a1139a970fc5cb704f5ac9086 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Not sure if this is too difficult o= r too minor...

There are use cases where a leaf-li= st is initialized
with some default value if no client value is p= rovided
(same as a leaf).

E.g.=A0

=A0 =A0leaf-list ncport {
=A0 =A0 =A0 type inet:port-number= ;
=A0 =A0 =A0 description=A0
=A0 =A0 =A0 =A0 =A0"T= he port numbers that should be accepted for NETCONF sessions";
=A0 =A0 =A0 default "[830]";
=A0 =A0}

This would require some new syntax to represent= an array of default values.

Proposal: support def= ault for leaf-list somehow


Andy


=
--001a1139a970fc5cb704f5ac9086-- From nobody Fri Mar 28 08:46:59 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17F71A091C for ; Fri, 28 Mar 2014 08:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uldGe4lc_7S for ; Fri, 28 Mar 2014 08:46:57 -0700 (PDT) Received: from exprod5og106.obsmtp.com (exprod5og106.obsmtp.com [64.18.0.182]) by ietfa.amsl.com (Postfix) with ESMTP id 69A261A07FB for ; Fri, 28 Mar 2014 08:46:57 -0700 (PDT) Received: from alpmlip12.e2k.ad.ge.com ([12.43.191.1]) (using TLSv1) by exprod5ob106.postini.com ([64.18.4.12]) with SMTP ID DSNKUzWZb+HuicTW2Vhq0Cz/CzFezb7R1Tdh@postini.com; Fri, 28 Mar 2014 08:46:55 PDT Received: from unknown (HELO CINMBHT01.e2k.ad.ge.com) ([3.159.212.194]) by alpmlip12.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 28 Mar 2014 12:35:14 -0400 Received: from CINURAPD03.e2k.ad.ge.com (3.159.212.111) by CINMBHT01.e2k.ad.ge.com (3.159.212.194) with Microsoft SMTP Server (TLS) id 14.3.174.2; Fri, 28 Mar 2014 11:46:54 -0400 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.29]) by CINURAPD03.e2k.ad.ge.com ([169.254.9.73]) with mapi id 14.03.0174.002; Fri, 28 Mar 2014 11:46:53 -0400 From: "Lange, Jeffrey K (GE Energy Management)" To: "netmod@ietf.org" Thread-Topic: [netmod] new YANG 1.1 issue: default for leaf-list Thread-Index: AQHPSpyDsdlEvUur+EWeStJlSH5cfZr2pKcA Date: Fri, 28 Mar 2014 15:46:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [3.159.212.181] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8826A93925849F47B5497A8E95A2D1D6@mail.ad.ge.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/w75Q_lfK6gN35V-AZaIgWCutHo0 Subject: Re: [netmod] new YANG 1.1 issue: default for leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 15:46:59 -0000 I like this. I=92ve had to implement my way around this limitation with de= scription text that explained what the behavior is if the leaf-list is empt= y. -Jeff From: Andy Bierman > Date: Friday, March 28, 2014 at 11:43 AM To: "netmod@ietf.org" > Subject: [netmod] new YANG 1.1 issue: default for leaf-list Hi, Not sure if this is too difficult or too minor... There are use cases where a leaf-list is initialized with some default value if no client value is provided (same as a leaf). E.g. leaf-list ncport { type inet:port-number; description "The port numbers that should be accepted for NETCONF sessions"; default "[830]"; } This would require some new syntax to represent an array of default values. Proposal: support default for leaf-list somehow Andy From nobody Fri Mar 28 09:01:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5F31A0450 for ; Fri, 28 Mar 2014 09:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaokBIs525uG for ; Fri, 28 Mar 2014 09:01:04 -0700 (PDT) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE8E1A00FB for ; Fri, 28 Mar 2014 09:00:59 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id q108so4532642qgd.37 for ; Fri, 28 Mar 2014 09:00:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=6uemim+Pu7beRYllsz0hJbrNA2sgL6xLw6/rXFZ38/4=; b=YY/HhfAKaKjYMUchQ3xqggx0q19IPgR3qSCV3Rd+g1XxlSy6OdnLpTNbRxvm1cZ7uo lma7Gl0qZRda9Tn+Rdg8wXvBAt/HGjy8fEoGiCN5bvfE/losQpp57KEO2GwpV+emrZBG /a4uGIluolfq+wZsvHtVe3/JTMUELIkaC5MTB/Et3rxTYp8sU9vjSV0FiV+sm82DiloU 7oU/koSePicRbOn3fn0D4o0DcNLrMuKlbWxNaS+mICVxlBcejx3LrcMfbh3Ni9pK0wIw ED6YQ1Rue+H8EYs+yzOHrKP4Xkm/m1tsJ+uFE1hp7TPvd4oY35Rfl1pDCtZVwEABP0gz Q0Ug== X-Gm-Message-State: ALoCoQmIR9KWELfII+uqsuYRLjE6dK/AA7er2h2X9O7cWJ6q6oPxTy6YGaR1seK+U/q3OrOPZbHE MIME-Version: 1.0 X-Received: by 10.140.87.67 with SMTP id q61mr2681332qgd.94.1396022456905; Fri, 28 Mar 2014 09:00:56 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Fri, 28 Mar 2014 09:00:56 -0700 (PDT) Date: Fri, 28 Mar 2014 09:00:56 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a113abee6a4848804f5acce99 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qUX1qjuuVl4hWwnUBZ7jGIrX0lI Subject: [netmod] new YANG 1.1 issue: allow choice in case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 16:01:05 -0000 --001a113abee6a4848804f5acce99 Content-Type: text/plain; charset=ISO-8859-1 Hi, A case-stmt is not allowed to have a choice-stmt as a child. However, it is allowed to have a use-stmt. and the grouping is allowed to have a choice-stmt in it. grouping FOO { choice foo { leaf A { type string; } leaf B { type string; } } } choice top { case one { uses FOO; // now legal } case two { choice foo2 { // now illegal leaf A2 { type string; } leaf B2 { type string; } } } } Even though the case with a nested choice be flattened into N objects instead, this may be undesirable for readability or augment purposes. Proposal: allow choice-stmt to be a child of case-stmt. Andy --001a113abee6a4848804f5acce99 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

A case-stmt is not allowed to have = a choice-stmt as a child.
However, it is allowed to have a use-st= mt. and the grouping
is allowed to have a choice-stmt in it.

grouping FOO {
=A0 choice foo {
=A0= =A0 leaf A { type string; }
=A0 =A0 leaf B { type string; }
=A0 }
}

=A0choice top {
= =A0 =A0case one {
=A0 =A0 =A0 uses FOO; =A0 // now legal
=A0 =A0}
= =A0 =A0case two {
=A0 =A0 =A0choice foo2 { =A0 =A0// now ill= egal
=A0 =A0 =A0 =A0leaf A2 { type string; }
=A0 =A0 = =A0 =A0leaf B2 { type string; }
=A0 =A0 }
=A0 }
}

Even t= hough the case with a nested choice be flattened into
N objects i= nstead, this may be undesirable for readability
or augment purpos= es.

Proposal: allow choice-stmt to be a child of case-stmt.=


Andy


=
--001a113abee6a4848804f5acce99-- From nobody Fri Mar 28 09:12:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3411A0762 for ; Fri, 28 Mar 2014 09:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svZQ2r2S4tlB for ; Fri, 28 Mar 2014 09:12:28 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5521A0705 for ; Fri, 28 Mar 2014 09:12:22 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id A843E140266; Fri, 28 Mar 2014 17:12:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1396023139; bh=t23DjCj2ZK1sQbUznmFMX//FtxN1begR+pSHNJTzYrQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=arkRMWon5ib12De9CSYgGaIUw0v7jwAd+ggkIInQ3Dp3iECsFNHbkRY9xrl9OcWRj ThQIk5MiLtZ0Z7Hwc2OHCzDHGNza8wcOOPGslOpS+rQzM1JC959mF9zDeHhQSL5OlS RhgQVbiIPFO0Us2TdLGno2pfp9us1bjUQNU5rocQ= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 28 Mar 2014 17:12:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8742B7A5-CD63-4C56-9363-A23F149ADE88@nic.cz> References: To: "Lange, Jeffrey K (GE Energy Management)" X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Yd_rJOlqAFhfUHcmqyBCK8jf-kY Cc: "netmod@ietf.org" Subject: Re: [netmod] Default presence containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 16:12:30 -0000 On 26 Mar 2014, at 15:16, Lange, Jeffrey K (GE Energy Management) = wrote: > Is there any way in YANG that one can create a presence container with = a > default state? 6020 does not list =B3default=B2 as a sub statement to > container. If not, perhaps this is a useful feature for YANG 1.1 It seems the same effect can be achieved by using either type of = container with an additional child leaf =93enabled=94. Several examples = of this arrangement are in the core modules.=20 That is: - on by default container ssh { // non-presence leaf enabled { type boolean; default "true=94; } =85 } - off by default container ssh { presence "Enable ssh"; leaf enabled { type boolean; default "true=94; } =85 } The advantage of having the extra switch =93enabled=94 is that one can = disable the function without wiping out the existing configuration. Lada >=20 > e.g. (from 6020): >=20 > container system { > description "Contains various system parameters"; > container services { > description "Configure externally available services"; > container "ssh" { > presence "Enables SSH"; > description "SSH service specific configuration=B2; > default present; // or not-present > } > } > } >=20 > Thanks! > -Jeff >=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 Mar 28 09:56:52 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C941A093D for ; Fri, 28 Mar 2014 09:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfhUjVR39PxR for ; Fri, 28 Mar 2014 09:56:46 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 704011A093B for ; Fri, 28 Mar 2014 09:56:45 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id D6895140266; Fri, 28 Mar 2014 17:56:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1396025802; bh=xMcunOiGxEBA+hKzkfaBM7TWmFIV7vDkGshTfzhsxMg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=eucRjyKPDoa0MopJkeWfmZF4y/KTDMoNJjkuz/f8xDnZZHquA9mfM2dk3uwtgp2v3 cAGRkTaQFUWM4fUExLzseZW5AAYF8JganhO5k/fD+DSIoax6FsrRaM9+HwkyavCDsD UCZVaMVkq80MVi90RESOIQ2zZewfmJ3+VwZyFRI8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 28 Mar 2014 17:56:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <299DC51A-70A8-49FE-AB88-8BD0CB171972@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/L_F1oGsxmzvXSr5L3NJ7-tNMV4M Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 issue: allow choice in case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 16:56:50 -0000 On 28 Mar 2014, at 17:00, Andy Bierman wrote: > Hi, >=20 > A case-stmt is not allowed to have a choice-stmt as a child. > However, it is allowed to have a use-stmt. and the grouping > is allowed to have a choice-stmt in it. I agree, this is probably an omission. Speaking about choice, I encountered the following use case for making = the choice=92s default statement work for cases that are empty leafs. choice destination { default broadcast; container destination-host { leaf address { =85 } } leaf broadcast { type empty; } } Lada >=20 > grouping FOO { > choice foo { > leaf A { type string; } > leaf B { type string; } > } > } >=20 > choice top { > case one { > uses FOO; // now legal > } > case two { > choice foo2 { // now illegal > leaf A2 { type string; } > leaf B2 { type string; } > } > } > } >=20 > Even though the case with a nested choice be flattened into > N objects instead, this may be undesirable for readability > or augment purposes. >=20 > Proposal: allow choice-stmt to be a child of case-stmt. >=20 >=20 > Andy >=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 Mar 28 09:57:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9AF1A0929 for ; Fri, 28 Mar 2014 09:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwHves0qlHnM for ; Fri, 28 Mar 2014 09:57:31 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 364881A0930 for ; Fri, 28 Mar 2014 09:57:31 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id A4DAB140266 for ; Fri, 28 Mar 2014 17:57:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1396025848; bh=cgFGdRJ2VbVSZroebss4JLGyHDD8bFhsNBoBqRjv7Ek=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=IHES8N5hgVtxt1bHc2XbfsrKv2jrjwB+L4E953qdR3IC+Og6RtE/2lSB4twPYUmrX lWkREKH40hESdrZgeJnciQcPT2kJa6w96Naspt2rUtgXHyM2eM4s/0jBBPvcnlzBi/ tLG5eq5SqzhjYEoVbHUKe8XVqgdgBfZndmQbbmIc= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 28 Mar 2014 17:57:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8742B7A5-CD63-4C56-9363-A23F149ADE88@nic.cz> To: netmod@ietf.org X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2WHeLjk8hmWJ3MVEy_cO5RdWiWM Subject: Re: [netmod] Default presence containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 16:57:33 -0000 On 28 Mar 2014, at 17:17, Lange, Jeffrey K (GE Energy Management) = wrote: >=20 > On 3/28/14, 12:12 PM, "Ladislav Lhotka" wrote: >=20 >>=20 >> On 26 Mar 2014, at 15:16, Lange, Jeffrey K (GE Energy Management) >> wrote: >>=20 >>> Is there any way in YANG that one can create a presence container = with a >>> default state? 6020 does not list =B3default=B2 as a sub statement = to >>> container. If not, perhaps this is a useful feature for YANG 1.1 >>=20 >> It seems the same effect can be achieved by using either type of >> container with an additional child leaf =93enabled=94. Several = examples of >> this arrangement are in the core modules. >>=20 >> That is: >>=20 >> - on by default >>=20 >> container ssh { // non-presence >> leaf enabled { >> type boolean; >> default "true=94; >> } >> =85 >> } >>=20 >> - off by default >>=20 >> container ssh { >> presence "Enable ssh"; >> leaf enabled { >> type boolean; >> default "true=94; >> } >> =85 >> } >>=20 >> The advantage of having the extra switch =93enabled=94 is that one = can >> disable the function without wiping out the existing configuration. >=20 > While this is true, using that same logic you should be able to safely > remove presence containers from YANG all together. But I don=92t think = you The nice property of presence containers is that they keep the stuff = that=92s off by default out of the configuration until it is explicitly = configured, no matter what the handling of defaults is. Things that are on by default can simply use just a non-presence = container, and if the modeller wants to offer the option of turning them = off, the =93enabled=94 leaf would do. > are proposing that. Coming back to the inability to augment in = mandatory > statements, presence containers are currently the only option for = adding > new mandatory statements. Presence containers provide no such option. Encapsulating mandatory = nodes in a presence container makes them optional. Lada >=20 > -Jeff >=20 >>=20 >> Lada >>=20 >>>=20 >>> e.g. (from 6020): >>>=20 >>> container system { >>> description "Contains various system parameters"; >>> container services { >>> description "Configure externally available services"; >>> container "ssh" { >>> presence "Enables SSH"; >>> description "SSH service specific configuration=B2; >>> default present; // or not-present >>> } >>> } >>> } >>>=20 >>> Thanks! >>> -Jeff >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Mar 28 10:07:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B193F1A0929 for ; Fri, 28 Mar 2014 10:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyG_2_lZb9Fx for ; Fri, 28 Mar 2014 10:07:49 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id A420D1A093D for ; Fri, 28 Mar 2014 10:07:47 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e16so6160226qcx.41 for ; Fri, 28 Mar 2014 10:07:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kV1fGfnIdlK+PwzgiU4jG2RMCSzCcoOZIxndCjGdTjQ=; b=CIisx5fX6s9kPezb/OKOclwRW8KUxMrLovHBp2LZO75Fj7bu1hVbFvxqVnMCQnaV4G heyrmf23gtju7YL9nDpOZY635ObIHrdo6rubG2GL3M3dDuEUiEHjWMoV1pfyB9QMcBt8 FZEmX1STcoFeUx+5/8x2qnzfSjYcuVq8ZzPMUra+DDYfQnUwpopeYt+TkY+LQiCQNslr BvtwxYzWQWEw2W01YZn7OBMBm6GRe/3s1gc2iuAb0miKyDoJYjSLtPIe9w3lCRY9Mwfb smzSsRko/eCGjooBkMQxwmBMtsSDoNDbt3cV7pEwji2CgnENLL7Yk34tzLAzcH7smfFA 0egw== X-Gm-Message-State: ALoCoQlxYUUoTZ+vyVCPYsrQqm+yRyAOYzSiwiAkr1K81ePvwr49pEnXUR/mjo/dv3iSXYzeugZs MIME-Version: 1.0 X-Received: by 10.140.87.67 with SMTP id q61mr3072759qgd.94.1396026465239; Fri, 28 Mar 2014 10:07:45 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Fri, 28 Mar 2014 10:07:45 -0700 (PDT) In-Reply-To: References: <8742B7A5-CD63-4C56-9363-A23F149ADE88@nic.cz> Date: Fri, 28 Mar 2014 10:07:45 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113abee68f537f04f5adbdfb Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Vran9xlc2PEteqbnSSwMrejIL7c Cc: "netmod@ietf.org" Subject: Re: [netmod] Default presence containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 17:07:53 -0000 --001a113abee68f537f04f5adbdfb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Mar 28, 2014 at 9:57 AM, Ladislav Lhotka wrote: > > On 28 Mar 2014, at 17:17, Lange, Jeffrey K (GE Energy Management) < > jeffrey.K.lange@ge.com> wrote: > > > > > On 3/28/14, 12:12 PM, "Ladislav Lhotka" wrote: > > > >> > >> On 26 Mar 2014, at 15:16, Lange, Jeffrey K (GE Energy Management) > >> wrote: > >> > >>> Is there any way in YANG that one can create a presence container wit= h > a > >>> default state? 6020 does not list =B3default=B2 as a sub statement to > >>> container. If not, perhaps this is a useful feature for YANG 1.1 > >> > >> It seems the same effect can be achieved by using either type of > >> container with an additional child leaf "enabled". Several examples of > >> this arrangement are in the core modules. > >> > >> That is: > >> > >> - on by default > >> > >> container ssh { // non-presence > >> leaf enabled { > >> type boolean; > >> default "true"; > >> } > >> ... > >> } > >> > >> - off by default > >> > >> container ssh { > >> presence "Enable ssh"; > >> leaf enabled { > >> type boolean; > >> default "true"; > >> } > >> ... > >> } > >> > >> The advantage of having the extra switch "enabled" is that one can > >> disable the function without wiping out the existing configuration. > > > > While this is true, using that same logic you should be able to safely > > remove presence containers from YANG all together. But I don't think yo= u > > The nice property of presence containers is that they keep the stuff > that's off by default out of the configuration until it is explicitly > configured, no matter what the handling of defaults is. > > Things that are on by default can simply use just a non-presence > container, and if the modeller wants to offer the option of turning them > off, the "enabled" leaf would do. > > > are proposing that. Coming back to the inability to augment in mandato= ry > > statements, presence containers are currently the only option for addin= g > > new mandatory statements. > > Presence containers provide no such option. Encapsulating mandatory nodes > in a presence container makes them optional. > > Most parameters are not always mandatory. In fact, top-level mandatory nodes are not allowed in IETF YANG modules so all mandatory nodes need some sort of optional parent node. The mandatory nodes only apply if the SSH service is enabled in this case. Lada > > Andy > > > > -Jeff > > > >> > >> Lada > >> > >>> > >>> e.g. (from 6020): > >>> > >>> container system { > >>> description "Contains various system parameters"; > >>> container services { > >>> description "Configure externally available services"; > >>> container "ssh" { > >>> presence "Enables SSH"; > >>> description "SSH service specific configuration=B2; > >>> default present; // or not-present > >>> } > >>> } > >>> } > >>> > >>> Thanks! > >>> -Jeff > >>> > >>> > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a113abee68f537f04f5adbdfb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Mar 28, 2014 at 9:57 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 28 Mar 2014, at 17:17, Lange, Jeffrey K (GE Energy Management) <jeffrey.K.lange@ge.com> wrote:<= br>
>
> On 3/28/14, 12:12 PM, "Ladislav Lhotka" <lhotka@nic.cz> wrote:
>
>>
>> On 26 Mar 2014, at 15:16, Lange, Jeffrey K (GE Energy Management)<= br> >> <jeffrey.K.lange@ge.c= om> wrote:
>>
>>> Is there any way in YANG that one can create a presence contai= ner with a
>>> default state? 6020 does not list =B3default=B2 as a sub state= ment to
>>> container. If not, perhaps this is a useful feature for YANG 1= .1
>>
>> It seems the same effect can be achieved by using either type of >> container with an additional child leaf “enabled”. Sev= eral examples of
>> this arrangement are in the core modules.
>>
>> That is:
>>
>> - on by default
>>
>> container ssh {     // non-presence
>> leaf enabled {
>>  type boolean;
>>  default "true”;
>> }
>> …
>> }
>>
>> - off by default
>>
>> container ssh {
>> presence "Enable ssh";
>> leaf enabled {
>>  type boolean;
>>  default "true”;
>> }
>> …
>> }
>>
>> The advantage of having the extra switch “enabled” is = that one can
>> disable the function without wiping out the existing configuration= .
>
> While this is true, using that same logic you should be able to safely=
> remove presence containers from YANG all together. But I don’t t= hink you

The nice property of presence containers is that they keep the stuff that&r= squo;s off by default out of the configuration until it is explicitly confi= gured, no matter what the handling of defaults is.

Things that are on by default can simply use just a non-presence container,= and if the modeller wants to offer the option of turning them off, the &ld= quo;enabled” leaf would do.

> are proposing that.  Coming back to the inability to augment in m= andatory
> statements, presence containers are currently the only option for addi= ng
> new mandatory statements.

Presence containers provide no such option. Encapsulating mandatory nodes i= n a presence container makes them optional.


Most parameters are not always mandato= ry.
In fact, top-level mandatory nodes are not allowed in IETF YA= NG modules
so all mandatory nodes need some sort of optional pare= nt node.

 The mandatory nodes only apply if the SSH service= is enabled in this case.


Lada


Andy
 
>
> -Jeff
>
>>
>> Lada
>>
>>>
>>> e.g. (from 6020):
>>>
>>> container system {
>>>  description "Contains various system parameters&quo= t;;
>>>  container services {
>>>      description "Configure externally ava= ilable services";
>>>      container "ssh" {
>>>          presence "Enables SSH&q= uot;;
>>>          description "SSH servic= e specific configuration=B2;
>>>          default present; // or not-p= resent
>>>      }
>>>  }
>>> }
>>>
>>> Thanks!
>>> -Jeff
>>>
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

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




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

--001a113abee68f537f04f5adbdfb-- From nobody Fri Mar 28 10:28:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2A61A0738 for ; Fri, 28 Mar 2014 10:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxLdH3blDvqs for ; Fri, 28 Mar 2014 10:28:04 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 524A91A00DD for ; Fri, 28 Mar 2014 10:28:04 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 23CE83B4135; Fri, 28 Mar 2014 18:28:01 +0100 (CET) Date: Fri, 28 Mar 2014 18:28:00 +0100 (CET) Message-Id: <20140328.182800.296693209.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/RPy05jrBjIgviJ58LuaeOSmDNyQ Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 issue: allow choice in case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 17:28:05 -0000 Andy Bierman wrote: > Hi, > > A case-stmt is not allowed to have a choice-stmt as a child. Yes it can. Section 7.9.2.1 lists choice as substatement to case, and the grammar allows it as well. /martin From nobody Fri Mar 28 10:45:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000671A0738 for ; Fri, 28 Mar 2014 10:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.061 X-Spam-Level: X-Spam-Status: No, score=-0.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_29=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H08MXGnumSAA for ; Fri, 28 Mar 2014 10:45:34 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 901D51A0949 for ; Fri, 28 Mar 2014 10:45:34 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 14624140269; Fri, 28 Mar 2014 18:45:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1396028731; bh=BomywXJQ/Buizn2OMkYtPEb9EotCHEMC9NYL5o2qWbU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=a/62t2L+WGyVl8jsUIFFMqfBrQCTwQRynwAGbzva3yl1HvzPzjG9mOcnw/EFlq1jR xEUVPN6T9biqLRWyzqlfbBWrqIxBdImHcJvVuYc/cU9LBIVbtECDRX/ZouwLw4aGX8 8d2luL7d3Xfx1mXmyWA0ef/PxSklRe9plA6JMTKo= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 28 Mar 2014 18:45:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3D860F42-8941-4788-9870-9E4082326E98@nic.cz> References: <8742B7A5-CD63-4C56-9363-A23F149ADE88@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yFc2jdg74U9Rwg2UsVKYCKUVvm8 Cc: "netmod@ietf.org" Subject: Re: [netmod] Default presence containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 17:45:37 -0000 On 28 Mar 2014, at 18:07, Andy Bierman wrote: >=20 >=20 >=20 > On Fri, Mar 28, 2014 at 9:57 AM, Ladislav Lhotka = wrote: >=20 > On 28 Mar 2014, at 17:17, Lange, Jeffrey K (GE Energy Management) = wrote: >=20 > > > > On 3/28/14, 12:12 PM, "Ladislav Lhotka" wrote: > > > >> > >> On 26 Mar 2014, at 15:16, Lange, Jeffrey K (GE Energy Management) > >> wrote: > >> > >>> Is there any way in YANG that one can create a presence container = with a > >>> default state? 6020 does not list =B3default=B2 as a sub statement = to > >>> container. If not, perhaps this is a useful feature for YANG 1.1 > >> > >> It seems the same effect can be achieved by using either type of > >> container with an additional child leaf =93enabled=94. Several = examples of > >> this arrangement are in the core modules. > >> > >> That is: > >> > >> - on by default > >> > >> container ssh { // non-presence > >> leaf enabled { > >> type boolean; > >> default "true=94; > >> } > >> =85 > >> } > >> > >> - off by default > >> > >> container ssh { > >> presence "Enable ssh"; > >> leaf enabled { > >> type boolean; > >> default "true=94; > >> } > >> =85 > >> } > >> > >> The advantage of having the extra switch =93enabled=94 is that one = can > >> disable the function without wiping out the existing configuration. > > > > While this is true, using that same logic you should be able to = safely > > remove presence containers from YANG all together. But I don=92t = think you >=20 > The nice property of presence containers is that they keep the stuff = that=92s off by default out of the configuration until it is explicitly = configured, no matter what the handling of defaults is. >=20 > Things that are on by default can simply use just a non-presence = container, and if the modeller wants to offer the option of turning them = off, the =93enabled=94 leaf would do. >=20 > > are proposing that. Coming back to the inability to augment in = mandatory > > statements, presence containers are currently the only option for = adding > > new mandatory statements. >=20 > Presence containers provide no such option. Encapsulating mandatory = nodes in a presence container makes them optional. >=20 >=20 > Most parameters are not always mandatory. > In fact, top-level mandatory nodes are not allowed in IETF YANG = modules > so all mandatory nodes need some sort of optional parent node. >=20 > The mandatory nodes only apply if the SSH service is enabled in this = case. The case I am most concerned about is a list defined in a =93base=94 = module that expects instances of different types and the parameters of = each type are left to be defined in separate modules via augments. = Examples are: if:interface, rt:routing-instance, rt:routing-protocol, = rt:route-filter =85 I think this is a very useful pattern that should be recommended in data = modelling guidelines, and it has nothing to do with support of old = clients.=20 The presence container doesn=92t help here at all. Lada=20 >=20 >=20 > Lada >=20 >=20 > Andy > =20 > > > > -Jeff > > > >> > >> Lada > >> > >>> > >>> e.g. (from 6020): > >>> > >>> container system { > >>> description "Contains various system parameters"; > >>> container services { > >>> description "Configure externally available services"; > >>> container "ssh" { > >>> presence "Enables SSH"; > >>> description "SSH service specific configuration=B2; > >>> default present; // or not-present > >>> } > >>> } > >>> } > >>> > >>> Thanks! > >>> -Jeff > >>> > >>> > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Mar 28 10:50:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4704F1A0955 for ; Fri, 28 Mar 2014 10:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltjaAdXtaJpD for ; Fri, 28 Mar 2014 10:50:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 203AC1A0961 for ; Fri, 28 Mar 2014 10:50:36 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6B6D1140269; Fri, 28 Mar 2014 18:50:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1396029032; bh=PJq+KEzPviBtqTYWRiQnaGbY1lnHpisnb0RdRf9FmxU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hP5E4oYfX6SLYVYiC+7GiNPg0KqQaKXo6IgoqwOVUmJyqRDw/mfZAtZLRKB79fixD 13Iwc7P+a1unhbxkZv5YxP+1iQJjwEvb/P++JBake6VWhwllUcFeGpy7mIJgJONhO7 8PqsSDJTphNpzZE1CJcuyIpMvkxvbUzBoU7kYFDU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140328.182800.296693209.mbj@tail-f.com> Date: Fri, 28 Mar 2014 18:50:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140328.182800.296693209.mbj@tail-f.com> To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/smmMhuPA2IUnxyEvATiYM2ZiREg Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 issue: allow choice in case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 17:50:37 -0000 On 28 Mar 2014, at 18:28, Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >>=20 >> A case-stmt is not allowed to have a choice-stmt as a child. >=20 > Yes it can. Section 7.9.2.1 lists choice as substatement to case, and > the grammar allows it as well. Oh yes, choice is only not allowed as a short-case-stmt - it could be, = but it is I guess not a big deal. Lada >=20 >=20 > /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Mar 28 11:02:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697141A01C8 for ; Fri, 28 Mar 2014 11:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxmD9cpQecaA for ; Fri, 28 Mar 2014 11:02:44 -0700 (PDT) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) by ietfa.amsl.com (Postfix) with ESMTP id 72A7D1A0955 for ; Fri, 28 Mar 2014 11:02:26 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id c9so6229191qcz.19 for ; Fri, 28 Mar 2014 11:02:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Quf+iYCA6Xg2Bdl0H93TUJ7Tvs8rS3gPm9c2gtNCkok=; b=ex6CNp3Tz25obMoOFBJ3b4e+fesjNp/EMGQ+Etu8g4F34/UW3wGgRCFOs+8qW1qF2t h1ZhkL0zPxcNuRIf36wuo6btZn5Ws3gQ3y/KKHIcVeL9Qu5R4Pp0xvXYxAIkwM96IACQ V1p9Qp4KEfz0AZfuhboNQ1+PCo+ukD9PpWtboj3qvvg311+bcz56QXagIXCBmkRjSzub EUgeH/xvdnm6sogIrqkcV+U6/vcbg0D3LGpbwlwcSgrRZYN6DJ/nxrzQvfWwSMmijb4L Zl7y19j93BWaxqf7Xs4Y/PspwyR1+yKOFlQXy6calnjcYtmdB6UoYzfeAHeSLu5j/A9c 4yOA== X-Gm-Message-State: ALoCoQkAN8EOWKDon2HtABZ0CpM+b0Gm0ipEoJQIWcnKlSRq6wXPmFsT8pWdVya7nQA9XQea0gEK MIME-Version: 1.0 X-Received: by 10.229.96.199 with SMTP id i7mr4122156qcn.20.1396029744033; Fri, 28 Mar 2014 11:02:24 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Fri, 28 Mar 2014 11:02:23 -0700 (PDT) In-Reply-To: References: <20140328.182800.296693209.mbj@tail-f.com> Date: Fri, 28 Mar 2014 11:02:23 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1133886efd4f0704f5ae8003 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4gCWO2ECZlgtqVjbF55ODSjQO8I Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 issue: allow choice in case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 18:02:46 -0000 --001a1133886efd4f0704f5ae8003 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 28, 2014 at 10:50 AM, Ladislav Lhotka wrote: > > On 28 Mar 2014, at 18:28, Martin Bjorklund wrote: > > > Andy Bierman wrote: > >> Hi, > >> > >> A case-stmt is not allowed to have a choice-stmt as a child. > > > > Yes it can. Section 7.9.2.1 lists choice as substatement to case, and > > the grammar allows it as well. > > Oh yes, choice is only not allowed as a short-case-stmt - it could be, but > it is I guess not a big deal. > > You are right -- that's what I meant. It is not allowed in the short form. There does not seem to be any reason it could be used in the short form. > Lada > > Andy > > > > > /martin > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a1133886efd4f0704f5ae8003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Mar 28, 2014 at 10:50 AM, Ladislav Lhotka <lhotka@nic.cz&g= t; wrote:

On 28 Mar 2014, at 18:28, Martin Bjorklund <mbj@tail-f.com> wrote:

> Andy Bierman <andy@yumaworks.= com> wrote:
>> Hi,
>>
>> A case-stmt is not allowed to have a choice-stmt as a child.
>
> Yes it can. =A0Section 7.9.2.1 lists choice as substatement to case, a= nd
> the grammar allows it as well.

Oh yes, choice is only not allowed as a short-case-stmt - it could be, but = it is I guess not a big deal.


You are right -- that's what I mea= nt. =A0It is not allowed in the short form.
There does not seem t= o be any reason it could be used in the short form.

=A0
Lada


=A0Andy

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

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





--001a1133886efd4f0704f5ae8003-- From nobody Fri Mar 28 11:06:24 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1821A06CB for ; Fri, 28 Mar 2014 11:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0Ls8hCeIM_4 for ; Fri, 28 Mar 2014 11:06:20 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 77C631A0670 for ; Fri, 28 Mar 2014 11:06:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 42413540681; Fri, 28 Mar 2014 19:06:16 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gv71M3t1xxdu; Fri, 28 Mar 2014 19:06:09 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 08DA8540204; Fri, 28 Mar 2014 19:06:08 +0100 (CET) From: Ladislav Lhotka To: "Yi Yang \(yiya\)" , netmod@ietf.org In-Reply-To: References: <20140110133016.24678.42711.idtracker@ietfa.amsl.com> <9C81158E-5B4C-4479-AEA5-23CBCC020ADD@nic.cz> <0ED855DA-51BE-4DE6-AB22-E1A9E04C0E5F@nic.cz> <2830A589-DCCF-47C8-A066-D416C752D48C@nic.cz> <2512EFED-F10A-4D70-A6EC-81ACC54D1334@nic.cz> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Fri, 28 Mar 2014 19:06:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4q6pg-2C55-ew21B5rx2PBM0SSk Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 18:06:24 -0000 "Yi Yang (yiya)" writes: > This brings up an interesting question -- how would a client know if an > entry is system-controlled or user-controlled? This is a good question. I think currently the answer is that the client ca= n infer it from comparing the contents of configuration and operational sta= te versions of the list. The server will reject all edits that are not allo= wed for system-controlled entries. This might be another candidate for a global attribute. Lada > > Yi=20 > > > > On 3/27/14 12:10 PM, "Ladislav Lhotka" wrote: > >> >>On 27 Mar 2014, at 16:47, Yi Yang (yiya) wrote: >> >>> Hi Lada, >>>=20 >>> Back to the original question -- As routing-protocol's connected-ribs >>>need >>> to refer default ribs to configure the filters, we still need these >>> default-ribs to be shown under ribs. But we need only name for this, >>> right? One thing I am concerned is, what if a client is trying to change >>> the address family of a default rib? >> >>These default ribs are system-controlled entries, so the server will not >>allow to do this, or even delete the entry. It is the same as with >>system-controlled interfaces - the client must not be allowed to change >>the type of a hardware interface. >> >>Lada >> >>>=20 >>> Yi >>>=20 >>>=20 >>>=20 >>> On 3/27/14 11:29 AM, "Ladislav Lhotka" wrote: >>>=20 >>>>=20 >>>> On 27 Mar 2014, at 16:17, Yi Yang (yiya) wrote: >>>>=20 >>>>> Hi Lada, >>>>>=20 >>>>> Inline... >>>>>=20 >>>>> On 3/27/14 9:27 AM, "Ladislav Lhotka" wrote: >>>>>=20 >>>>>> "Yi Yang (yiya)" writes: >>>>>>=20 >>>>>>> Hi Lada, >>>>>>>=20 >>>>>>> Aha. So when multiple-ribs is not supported, the default-ribs only >>>>>>> exist >>>>>>> in the operational but not in configuration. >>>>>>=20 >>>>>> Right. >>>>>>=20 >>>>>>>=20 >>>>>>> But in that case, should we still allow users to configure the >>>>>>> corresponding rib entry in the ribs? >>>>>>=20 >>>>>> It is still needed for specifying route filters between a routing >>>>>> protocol and the default routing table. This is done via the >>>>>> "connected-rib" list whose keys are references to routing tables. >>>>>>Since >>>>>> YANG doesn't allow leafrefs in configuration to point to state data, >>>>>>it >>>>>> is necessary to put even the default (system-controlled) RIB to the >>>>>> "rib" >>>>>> list and then refer to it from "connected-rib". >>>>>=20 >>>>> Actually, connected-ribs has a dependency on feature multiple-ribs as >>>>> well. >>>>>=20 >>>>> +--rw connected-ribs {multiple-ribs}? >>>>=20 >>>> So this looks like a mistake, good that you spotted it! The possibility >>>> of filtering routes from/to routing protocol instances (which includes >>>> redistribution between protocols) is important even with a single RIB. >>>>=20 >>>> I will correct it in the next revision, probably/hopefully after IETF >>>> last call. >>>>=20 >>>> Thanks, Lada >>>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>> Yi >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Perhaps it could be another YANG 1.1 issue to relax this rule about >>>>>> references from configuration to state data. They can often be useful >>>>>> and, as in this case, simplify the configuration. >>>>>>=20 >>>>>> Lada >>>>>>=20 >>>>>>>=20 >>>>>>> Yi >>>>>>>=20 >>>>>>> On 3/26/14 9:25 AM, "Ladislav Lhotka" wrote: >>>>>>>=20 >>>>>>>> Hi Yi, >>>>>>>>=20 >>>>>>>> "Yi Yang (yiya)" writes: >>>>>>>>=20 >>>>>>>>> Hi Lada, >>>>>>>>>=20 >>>>>>>>> In the current model, default-ribs will exist only when feature >>>>>>>>> multiple-ribs exists. This is contradictory to what people are >>>>>>>>> familiar >>>>>>>>> in >>>>>>>>> the real world deployment -- default-ribs always exist. >>>>>>>>=20 >>>>>>>> Note that default-ribs depends on that feature only in >>>>>>>>configuration >>>>>>>> but >>>>>>>> not in operational state data. So, the idea is that the system puts >>>>>>>> the >>>>>>>> name(s) of default RIB(s) into the default-rib list in operational >>>>>>>> state, >>>>>>>> so the client is able to learn easily what the default (and only) >>>>>>>> RIB is >>>>>>>> for each address family. But whenever the server doesn't support >>>>>>>> multiple >>>>>>>> RIBs per address family, there is no point to have default-ribs as >>>>>>>>a >>>>>>>> configuration option. >>>>>>>>=20 >>>>>>>> Does it make sense? >>>>>>>>=20 >>>>>>>> Thanks, Lada >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> To reflect such an expectation, I suggest to keep default-ribs >>>>>>>>> unconditionally. Instead, move the conditions to the ribs -- if >>>>>>>>> feature >>>>>>>>> multiple-ribs doesn't exist, only one rib is allowed per address >>>>>>>>> family. >>>>>>>>>=20 >>>>>>>>> Yi >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 3/19/14 3:51 AM, "Ladislav Lhotka" wrote: >>>>>>>>>=20 >>>>>>>>>> "Derek Man-Kit Yeung (myeung)" writes: >>>>>>>>>>=20 >>>>>>>>>>> On 3/14/14 12:49 PM, "Ladislav Lhotka" wrote: >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 14 Mar 2014, at 20:32, Derek Man-Kit Yeung (myeung) >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 3/7/14 2:29 PM, "Ladislav Lhotka" wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 07 Mar 2014, at 22:52, Yi Yang (yiya) >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> One thing is missing from the data model is association with >>>>>>>>>>>>>>> vrf. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I agree with what Martin wrote in a parallel thread. I >>>>>>>>>>>>>>believe >>>>>>>>>>>>>> the >>>>>>>>>>>>>> routing module (and YANG augment statement) provide >>>>>>>>>>>>>>sufficient >>>>>>>>>>>>>> hooks >>>>>>>>>>>>>> for >>>>>>>>>>>>>> implementing VRF as a specific type of routing-instance. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The draft mentioned the routing-instance could be used to >>>>>>>>>>>>> represents a >>>>>>>>>>>>> logical router. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The term "logical router" in one or more vendors mean a >>>>>>>>>>>>> partition >>>>>>>>>>>>> of >>>>>>>>>>>>> the >>>>>>>>>>>>> physical router into multiple logical units, each could have >>>>>>>>>>>>> multiple >>>>>>>>>>>>> VRFs. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Does the draft intend to manage "logical router" in the above >>>>>>>>>>>>> definition? >>>>>>>>>>>>> Some clarification will be useful. >>>>>>>>>>>>=20 >>>>>>>>>>>> One way to implement this is to introduce two types of routing >>>>>>>>>>>> instances, >>>>>>>>>>>> say 'logical-router=C2=B9 and =C5=92vrf=C2=B9. The =C5=92vrf= =C2=B9 type then would have >>>>>>>>>>>> another >>>>>>>>>>>> leaf linking it to a logical router. This is quite like the >>>>>>>>>>>> various >>>>>>>>>>>> methods of interface stacking, see the examples in >>>>>>>>>>>> draft-ietf-netmod-interfaces-cfg-16. >>>>>>>>>>>>=20 >>>>>>>>>>>> Lada >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> It is one way. >>>>>>>>>>> However, given that current model that everything is put inside >>>>>>>>>>>a >>>>>>>>>>> routing-instance, things like RIB, routing-protocols etc are no >>>>>>>>>>> longer >>>>>>>>>>> needed directly under the 'logical-router'. >>>>>>>>>>=20 >>>>>>>>>> Note that RIBs are not inside "routing-instance", although an >>>>>>>>>> implementation may define some RIBs to be >>>>>>>>>> routing-instance-specific. >>>>>>>>>>=20 >>>>>>>>>>> What needed in the 'logical router' are resources allocation >>>>>>>>>>>like >>>>>>>>>>> interfaces, CPU etc. >>>>>>>>>>=20 >>>>>>>>>> "interfaces" is a container inside "routing-instance", and "cpu" >>>>>>>>>> can >>>>>>>>>> be >>>>>>>>>> easily added by another module via augmentation. >>>>>>>>>>=20 >>>>>>>>>>> Though routing-instance could be augmented to include 'logical >>>>>>>>>>> router' >>>>>>>>>>> specific field and add new condition to restrict existing leaf >>>>>>>>>>> that >>>>>>>>>>> no >>>>>>>>>>> long apply, I think a new container above routing-instance is >>>>>>>>>>> cleaner. >>>>>>>>>>> It >>>>>>>>>>> could be a new data model that reference the definition in the >>>>>>>>>>> current >>>>>>>>>>> draft. >>>>>>>>>>=20 >>>>>>>>>> I guess part of the confusion stems from the name >>>>>>>>>> "routing-instance" >>>>>>>>>> which already means a particular (platform-specific) style of >>>>>>>>>> router >>>>>>>>>> virtualization. Earlier revisions of the draft used "router" list >>>>>>>>>> in >>>>>>>>>> this >>>>>>>>>> place but it was an specific requirement of I2RS folks to change >>>>>>>>>> this >>>>>>>>>> name to "routing-instance". Oh well ... >>>>>>>>>>=20 >>>>>>>>>> So please keep in mind that "routing-instance" can really mean >>>>>>>>>> different >>>>>>>>>> things depending on its type (and can be augmented in different >>>>>>>>>> ways >>>>>>>>>> depending on the type). Again, this approach is very similar to >>>>>>>>>>the >>>>>>>>>> one >>>>>>>>>> adopted for the "interface" list in "ietf-interfaces" module. >>>>>>>>>>=20 >>>>>>>>>> Lada >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> - Derek >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> - Derek >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I think though that other work extending the routing module >>>>>>>>>>>>>>is >>>>>>>>>>>>>> much >>>>>>>>>>>>>> more >>>>>>>>>>>>>> needed, namely vendor-neutral data models for routing >>>>>>>>>>>>>> protocols. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The consensus of the NETMOD WG was that these new modules >>>>>>>>>>>>>> should >>>>>>>>>>>>>> be >>>>>>>>>>>>>> developed by experts in the Routing Area (VRF in the MPLS >>>>>>>>>>>>>>WG?). >>>>>>>>>>>>>> The >>>>>>>>>>>>>> NETMOD WG and YANG Doctors will certainly help but the bulk >>>>>>>>>>>>>>of >>>>>>>>>>>>>> this >>>>>>>>>>>>>> work >>>>>>>>>>>>>> should be done by domain experts. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Lada >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Another concern I have is about address family. To >>>>>>>>>>>>>>>facilitate >>>>>>>>>>>>>>> a >>>>>>>>>>>>>>> query >>>>>>>>>>>>>>> based on AFI only, or SAFI only, it seems more convenient to >>>>>>>>>>>>>>> use >>>>>>>>>>>>>>> two >>>>>>>>>>>>>>> leafs >>>>>>>>>>>>>>> (AFI and SAFI) instead of one (AFI-SAFI). >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Yi >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 1/10/14 8:30 AM, "internet-drafts@ietf.org" >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>> Working >>>>>>>>>>>>>>>> Group of the IETF. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Title : A YANG Data Model for Routing >>>>>>>>>>>>>>>> Management >>>>>>>>>>>>>>>> Author : Ladislav Lhotka >>>>>>>>>>>>>>>> Filename : draft-ietf-netmod-routing-cfg-13.txt >>>>>>>>>>>>>>>> Pages : 95 >>>>>>>>>>>>>>>> Date : 2014-01-10 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Abstract: >>>>>>>>>>>>>>>> This document contains a specification of three YANG >>>>>>>>>>>>>>>>modules. >>>>>>>>>>>>>>>> Together they form the core routing data model which serves >>>>>>>>>>>>>>>> as >>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>> framework for configuring and managing a routing subsystem. >>>>>>>>>>>>>>>> It >>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>> expected that these modules will be augmented by additional >>>>>>>>>>>>>>>> YANG >>>>>>>>>>>>>>>> modules defining data models for individual routing >>>>>>>>>>>>>>>>protocols >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> other related functions. The core routing data model >>>>>>>>>>>>>>>> provides >>>>>>>>>>>>>>>> common >>>>>>>>>>>>>>>> building blocks for such extensions - routing instances, >>>>>>>>>>>>>>>> routes, >>>>>>>>>>>>>>>> routing information bases (RIB), routing protocols and >>>>>>>>>>>>>>>>route >>>>>>>>>>>>>>>> filters. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-c >>>>>>>>>>>>>>>>fg >>>>>>>>>>>>>>>> / >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> There's also a htmlized version available at: >>>>>>>>>>>>>>>> http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routin= g-c >>>>>>>>>>>>>>>>fg >>>>>>>>>>>>>>>> -1 >>>>>>>>>>>>>>>> 3 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> netmod mailing list >>>>>>>>>>>>>>>> netmod@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>>>>>>>>>>>=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 >>>>>>>>>>>>=20 >>>>>>>>>>>> -- >>>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>>>>>> PGP Key ID: E74E8C0C >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> --=20 >>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>>>> PGP Key ID: E74E8C0C >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>> PGP Key ID: E74E8C0C >>>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>> PGP Key ID: E74E8C0C >>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >> >>-- >>Ladislav Lhotka, CZ.NIC Labs >>PGP Key ID: E74E8C0C >> >> >> >> > --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Mar 28 11:08:43 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2641A06C3 for ; Fri, 28 Mar 2014 11:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZKkJILJXwi7 for ; Fri, 28 Mar 2014 11:08:35 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7BA1A06A3 for ; Fri, 28 Mar 2014 11:08:35 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id 63so4785085qgz.34 for ; Fri, 28 Mar 2014 11:08:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ib0Figzrdb3fV/3xKL5Obtuif8k/pmR1o9MrBC+6GHA=; b=XO9L2cESVQBS6nrCp0Lf4I8cPlGXLjrvJbLw5HaXbGODguV0taOXRAKlBYrL3AxmGa BeLzH23c/wa+8735KoaL5WNijkKnTXE+sf9IsXrWclyUjH/8TdPdeMG8Zcp82pLeCwFB +2zFGiCWmlqtbGfVupIxTnl0po47NHhBOCZPfU90APMXNA71qQT+2ONxABdoxCsDm3AV bbKbSJbNYSVnXU9zb7OfAlhcufB6mtE0KQzYslNaN+kbAW5TueDl7A6Zo5QZ96qPigvB 6j9909NbguJghG+MyIISOZdvlke9f6VY5KTWfWf8vrgOUE34z0f/RileIzO6Lr2KXIBd 0sFA== X-Gm-Message-State: ALoCoQmJgzMr18kDNpo0M8zwxf/18BxvV7GWsTLdlH6JY5rYuCoKvdkDjOOCBdkk8t0wD2ZiCN3y MIME-Version: 1.0 X-Received: by 10.224.16.69 with SMTP id n5mr9480375qaa.7.1396030113001; Fri, 28 Mar 2014 11:08:33 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Fri, 28 Mar 2014 11:08:32 -0700 (PDT) In-Reply-To: <3D860F42-8941-4788-9870-9E4082326E98@nic.cz> References: <8742B7A5-CD63-4C56-9363-A23F149ADE88@nic.cz> <3D860F42-8941-4788-9870-9E4082326E98@nic.cz> Date: Fri, 28 Mar 2014 11:08:32 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7bea3986fb64bf04f5ae9645 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9riphCv8hIpfseFUHn577g5Ox0E Cc: "netmod@ietf.org" Subject: Re: [netmod] Default presence containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 18:08:40 -0000 --047d7bea3986fb64bf04f5ae9645 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Mar 28, 2014 at 10:45 AM, Ladislav Lhotka wrote: > > On 28 Mar 2014, at 18:07, Andy Bierman wrote: > > > > > > > > > On Fri, Mar 28, 2014 at 9:57 AM, Ladislav Lhotka wrote: > > > > On 28 Mar 2014, at 17:17, Lange, Jeffrey K (GE Energy Management) < > jeffrey.K.lange@ge.com> wrote: > > > > > > > > On 3/28/14, 12:12 PM, "Ladislav Lhotka" wrote: > > > > > >> > > >> On 26 Mar 2014, at 15:16, Lange, Jeffrey K (GE Energy Management) > > >> wrote: > > >> > > >>> Is there any way in YANG that one can create a presence container > with a > > >>> default state? 6020 does not list =B3default=B2 as a sub statement = to > > >>> container. If not, perhaps this is a useful feature for YANG 1.1 > > >> > > >> It seems the same effect can be achieved by using either type of > > >> container with an additional child leaf "enabled". Several examples = of > > >> this arrangement are in the core modules. > > >> > > >> That is: > > >> > > >> - on by default > > >> > > >> container ssh { // non-presence > > >> leaf enabled { > > >> type boolean; > > >> default "true"; > > >> } > > >> ... > > >> } > > >> > > >> - off by default > > >> > > >> container ssh { > > >> presence "Enable ssh"; > > >> leaf enabled { > > >> type boolean; > > >> default "true"; > > >> } > > >> ... > > >> } > > >> > > >> The advantage of having the extra switch "enabled" is that one can > > >> disable the function without wiping out the existing configuration. > > > > > > While this is true, using that same logic you should be able to safel= y > > > remove presence containers from YANG all together. But I don't think > you > > > > The nice property of presence containers is that they keep the stuff > that's off by default out of the configuration until it is explicitly > configured, no matter what the handling of defaults is. > > > > Things that are on by default can simply use just a non-presence > container, and if the modeller wants to offer the option of turning them > off, the "enabled" leaf would do. > > > > > are proposing that. Coming back to the inability to augment in > mandatory > > > statements, presence containers are currently the only option for > adding > > > new mandatory statements. > > > > Presence containers provide no such option. Encapsulating mandatory > nodes in a presence container makes them optional. > > > > > > Most parameters are not always mandatory. > > In fact, top-level mandatory nodes are not allowed in IETF YANG modules > > so all mandatory nodes need some sort of optional parent node. > > > > The mandatory nodes only apply if the SSH service is enabled in this > case. > > The case I am most concerned about is a list defined in a "base" module > that expects instances of different types and the parameters of each type > are left to be defined in separate modules via augments. Examples are: > if:interface, rt:routing-instance, rt:routing-protocol, rt:route-filter .= .. > > I think this is a very useful pattern that should be recommended in data > modelling guidelines, and it has nothing to do with support of old client= s. > > The presence container doesn't help here at all. > > We keep going over this point. Module Y cannot add mandatory nodes to module X. It changes the contract for whatever revision of module X is being advertised. Otherwise modules are coupled, and that's what we have sub-modules for. The unit of conformance in YANG is the module. YANG conformance has no ability whatsoever to describe any conformance construct larger than a module, which is what you would need in order to force a server to implement, and a client to support, module X and Y together. (But I have been informed YANG conformance works great and there is no need to change it. ;-) Lada > > Andy > > > > > > Lada > > > > > > Andy > > > > > > > > -Jeff > > > > > >> > > >> Lada > > >> > > >>> > > >>> e.g. (from 6020): > > >>> > > >>> container system { > > >>> description "Contains various system parameters"; > > >>> container services { > > >>> description "Configure externally available services"; > > >>> container "ssh" { > > >>> presence "Enables SSH"; > > >>> description "SSH service specific configuration=B2; > > >>> default present; // or not-present > > >>> } > > >>> } > > >>> } > > >>> > > >>> Thanks! > > >>> -Jeff > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> netmod mailing list > > >>> netmod@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/netmod > > >> > > >> -- > > >> Ladislav Lhotka, CZ.NIC Labs > > >> PGP Key ID: E74E8C0C > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --047d7bea3986fb64bf04f5ae9645 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Mar 28, 2014 at 10:45 AM, Ladislav Lhotka <lhotka@nic.cz&g= t; wrote:

On 28 Mar 2014, at 18:07, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Fri, Mar 28, 2014 at 9:57 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On 28 Mar 2014, at 17:17, Lange, Jeffrey K (GE Energy Management) <= jeffrey.K.lange@ge.com> wr= ote:
>
> >
> > On 3/28/14, 12:12 PM, "Ladislav Lhotka" <lhotka@nic.cz> wrote:
> >
> >>
> >> On 26 Mar 2014, at 15:16, Lange, Jeffrey K (GE Energy Managem= ent)
> >> <jeffrey.K.lange= @ge.com> wrote:
> >>
> >>> Is there any way in YANG that one can create a presence c= ontainer with a
> >>> default state? 6020 does not list =B3default=B2 as a sub = statement to
> >>> container. If not, perhaps this is a useful feature for Y= ANG 1.1
> >>
> >> It seems the same effect can be achieved by using either type= of
> >> container with an additional child leaf “enabled”= . Several examples of
> >> this arrangement are in the core modules.
> >>
> >> That is:
> >>
> >> - on by default
> >>
> >> container ssh {     // non-presence
> >> leaf enabled {
> >>  type boolean;
> >>  default "true”;
> >> }
> >> …
> >> }
> >>
> >> - off by default
> >>
> >> container ssh {
> >> presence "Enable ssh";
> >> leaf enabled {
> >>  type boolean;
> >>  default "true”;
> >> }
> >> …
> >> }
> >>
> >> The advantage of having the extra switch “enabled&rdquo= ; is that one can
> >> disable the function without wiping out the existing configur= ation.
> >
> > While this is true, using that same logic you should be able to s= afely
> > remove presence containers from YANG all together. But I don&rsqu= o;t think you
>
> The nice property of presence containers is that they keep the stuff t= hat’s off by default out of the configuration until it is explicitly = configured, no matter what the handling of defaults is.
>
> Things that are on by default can simply use just a non-presence conta= iner, and if the modeller wants to offer the option of turning them off, th= e “enabled” leaf would do.
>
> > are proposing that.  Coming back to the inability to augment= in mandatory
> > statements, presence containers are currently the only option for= adding
> > new mandatory statements.
>
> Presence containers provide no such option. Encapsulating mandatory no= des in a presence container makes them optional.
>
>
> Most parameters are not always mandatory.
> In fact, top-level mandatory nodes are not allowed in IETF YANG module= s
> so all mandatory nodes need some sort of optional parent node.
>
>  The mandatory nodes only apply if the SSH service is enabled in = this case.

The case I am most concerned about is a list defined in a “base&rdquo= ; module that expects instances of different types and the parameters of ea= ch type are left to be defined in separate modules via augments. Examples a= re: if:interface, rt:routing-instance, rt:routing-protocol, rt:route-filter= …

I think this is a very useful pattern that should be recommended in data mo= delling guidelines, and it has nothing to do with support of old clients.
The presence container doesn’t help here at all.


We keep going over this point.  M= odule Y cannot add mandatory nodes to module X.
It changes the co= ntract for whatever revision of module X is being advertised.
Oth= erwise modules are coupled, and that's what we have sub-modules for.

The unit of conformance in YANG is the module.
YANG conformance has no ability whatsoever to describe any conformance
construct larger than a module, which is what you would need
in order to force a server to implement, and a client to support, modu= le X and Y together.
(But I have been informed YANG conformance w= orks great and there is
no need to change it. ;-)


Lada


Andy

 
>
>
> Lada
>
>
> Andy
>
> >
> > -Jeff
> >
> >>
> >> Lada
> >>
> >>>
> >>> e.g. (from 6020):
> >>>
> >>> container system {
> >>>  description "Contains various system parameter= s";
> >>>  container services {
> >>>      description "Configure externall= y available services";
> >>>      container "ssh" {
> >>>          presence "Enables = SSH";
> >>>          description "SSH s= ervice specific configuration=B2;
> >>>          default present; // or = not-present
> >>>      }
> >>>  }
> >>> }
> >>>
> >>> Thanks!
> >>> -Jeff
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> netmod mailing list
> >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod
> >>
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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





--047d7bea3986fb64bf04f5ae9645-- From nobody Fri Mar 28 11:21:43 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EDD1A0713 for ; Fri, 28 Mar 2014 11:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.061 X-Spam-Level: X-Spam-Status: No, score=-0.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_29=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AKddJFqzZVV for ; Fri, 28 Mar 2014 11:21:38 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E17C31A0670 for ; Fri, 28 Mar 2014 11:21:37 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9E2E013F9C5; Fri, 28 Mar 2014 19:21:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1396030893; bh=Gj+f0QRq/lNRcMtFg8duQCCba6Ew9USL/aBDfEgEG4I=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=jN4kpF3doUuo+Zeq185AL61l+GijfjZK5g65/GnN1pn8fFKY9p/4AnwNPP/uie8+K TzLNc1MszNCJzSU9MqnoxhGNrhY3ILm0vh8nvrmbJdyPEySqaDEfOIPQEYzGlxpLge 7F47ed75F586aHOrBUcBjV2v+TbnhMbdaUQVJZ8Y= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 28 Mar 2014 19:21:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <366715EA-4D04-46E8-9F5E-8CF27FDFE9B7@nic.cz> References: <8742B7A5-CD63-4C56-9363-A23F149ADE88@nic.cz> <3D860F42-8941-4788-9870-9E4082326E98@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/el0OFLP6pDfgWhr9StNZd5wW-kI Cc: "netmod@ietf.org" Subject: Re: [netmod] Default presence containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 18:21:40 -0000 On 28 Mar 2014, at 19:08, Andy Bierman wrote: >=20 >=20 >=20 > On Fri, Mar 28, 2014 at 10:45 AM, Ladislav Lhotka = wrote: >=20 > On 28 Mar 2014, at 18:07, Andy Bierman wrote: >=20 > > > > > > > > On Fri, Mar 28, 2014 at 9:57 AM, Ladislav Lhotka = wrote: > > > > On 28 Mar 2014, at 17:17, Lange, Jeffrey K (GE Energy Management) = wrote: > > > > > > > > On 3/28/14, 12:12 PM, "Ladislav Lhotka" wrote: > > > > > >> > > >> On 26 Mar 2014, at 15:16, Lange, Jeffrey K (GE Energy Management) > > >> wrote: > > >> > > >>> Is there any way in YANG that one can create a presence = container with a > > >>> default state? 6020 does not list =B3default=B2 as a sub = statement to > > >>> container. If not, perhaps this is a useful feature for YANG 1.1 > > >> > > >> It seems the same effect can be achieved by using either type of > > >> container with an additional child leaf =93enabled=94. Several = examples of > > >> this arrangement are in the core modules. > > >> > > >> That is: > > >> > > >> - on by default > > >> > > >> container ssh { // non-presence > > >> leaf enabled { > > >> type boolean; > > >> default "true=94; > > >> } > > >> =85 > > >> } > > >> > > >> - off by default > > >> > > >> container ssh { > > >> presence "Enable ssh"; > > >> leaf enabled { > > >> type boolean; > > >> default "true=94; > > >> } > > >> =85 > > >> } > > >> > > >> The advantage of having the extra switch =93enabled=94 is that = one can > > >> disable the function without wiping out the existing = configuration. > > > > > > While this is true, using that same logic you should be able to = safely > > > remove presence containers from YANG all together. But I don=92t = think you > > > > The nice property of presence containers is that they keep the stuff = that=92s off by default out of the configuration until it is explicitly = configured, no matter what the handling of defaults is. > > > > Things that are on by default can simply use just a non-presence = container, and if the modeller wants to offer the option of turning them = off, the =93enabled=94 leaf would do. > > > > > are proposing that. Coming back to the inability to augment in = mandatory > > > statements, presence containers are currently the only option for = adding > > > new mandatory statements. > > > > Presence containers provide no such option. Encapsulating mandatory = nodes in a presence container makes them optional. > > > > > > Most parameters are not always mandatory. > > In fact, top-level mandatory nodes are not allowed in IETF YANG = modules > > so all mandatory nodes need some sort of optional parent node. > > > > The mandatory nodes only apply if the SSH service is enabled in = this case. >=20 > The case I am most concerned about is a list defined in a =93base=94 = module that expects instances of different types and the parameters of = each type are left to be defined in separate modules via augments. = Examples are: if:interface, rt:routing-instance, rt:routing-protocol, = rt:route-filter =85 >=20 > I think this is a very useful pattern that should be recommended in = data modelling guidelines, and it has nothing to do with support of old = clients. >=20 > The presence container doesn=92t help here at all. >=20 >=20 > We keep going over this point. Module Y cannot add mandatory nodes to = module X. The substance of Y26 is to lift this CLR, at least partially. Note this = change doesn=92t violate any of the restrictions set for YANG 1.1. Lada > It changes the contract for whatever revision of module X is being = advertised. > Otherwise modules are coupled, and that's what we have sub-modules = for. >=20 > The unit of conformance in YANG is the module. > YANG conformance has no ability whatsoever to describe any conformance > construct larger than a module, which is what you would need > in order to force a server to implement, and a client to support, = module X and Y together. > (But I have been informed YANG conformance works great and there is > no need to change it. ;-) >=20 >=20 > Lada >=20 >=20 > Andy >=20 > =20 > > > > > > Lada > > > > > > Andy > > > > > > > > -Jeff > > > > > >> > > >> Lada > > >> > > >>> > > >>> e.g. (from 6020): > > >>> > > >>> container system { > > >>> description "Contains various system parameters"; > > >>> container services { > > >>> description "Configure externally available services"; > > >>> container "ssh" { > > >>> presence "Enables SSH"; > > >>> description "SSH service specific configuration=B2; > > >>> default present; // or not-present > > >>> } > > >>> } > > >>> } > > >>> > > >>> Thanks! > > >>> -Jeff > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> netmod mailing list > > >>> netmod@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/netmod > > >> > > >> -- > > >> Ladislav Lhotka, CZ.NIC Labs > > >> PGP Key ID: E74E8C0C > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Mar 28 11:22:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFADE1A073C for ; Fri, 28 Mar 2014 11:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjARzsGfuLfc for ; Fri, 28 Mar 2014 11:21:51 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B0CBC1A0670 for ; Fri, 28 Mar 2014 11:21:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21718; q=dns/txt; s=iport; t=1396030909; x=1397240509; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=bDI+o8nEBkT0KJw2GmaJjWG5F1St7y248jqQykdZsBI=; b=HZKjVQjV0PMT9pfbnDERGDYO5zfNm86tprhfshRvNmYC8NjmSop8qIWC 8sO2GBzYFgni/FVPsGV3+W+IIpwyYFp+GpZb4Gk+x7DI+NlfUU7hFLIiF o0gxADmIUdd6+F3KhmPEkq9uTWTAtWeSsCFP7tcWWDFWuz/xWULyFihaJ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQFABS9NVOtJXHA/2dsb2JhbABZgwY7UQaDCrg0hmRRGX8WdIIlAQEBBAEBASARNwMbAgEIGAICJgICAiULFRACBAESCYdwCAWvEKJ6F4EpjViCb4FJBJhOgTORAoMwgis X-IronPort-AV: E=Sophos;i="4.97,752,1389744000"; d="scan'208";a="313738188" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 28 Mar 2014 18:21:48 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2SILlHQ030358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Mar 2014 18:21:47 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.37]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Fri, 28 Mar 2014 13:21:47 -0500 From: "Yi Yang (yiya)" To: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt Thread-Index: AQHPDgglsV7ZhSMgp02l6cqKlZJTf5rW54cAgAAKUQCACr4yAIAABNeAgAZ/kACAAJNSgIAKXeIAgAD/3wCAADoPAIABWMqA///bxACAAEZhgP//wcoAgABJrICAAULhAIAAb7WA///BTAA= Date: Fri, 28 Mar 2014 18:21:47 +0000 Message-ID: References: <20140110133016.24678.42711.idtracker@ietfa.amsl.com> <9C81158E-5B4C-4479-AEA5-23CBCC020ADD@nic.cz> <0ED855DA-51BE-4DE6-AB22-E1A9E04C0E5F@nic.cz> <2830A589-DCCF-47C8-A066-D416C752D48C@nic.cz> <2512EFED-F10A-4D70-A6EC-81ACC54D1334@nic.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [64.102.95.103] Content-Type: text/plain; charset="utf-8" Content-ID: <341C9A39D31EAE459F49DA98F5AA1F81@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/a2W1I0VVeuCb-ByoPACv3jO3E8w Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 18:21:57 -0000 DQpPbiAzLzI4LzE0IDI6MDYgUE0sICJMYWRpc2xhdiBMaG90a2EiIDxsaG90a2FAbmljLmN6PiB3 cm90ZToNCg0KPiJZaSBZYW5nICh5aXlhKSIgPHlpeWFAY2lzY28uY29tPiB3cml0ZXM6DQo+DQo+ PiBUaGlzIGJyaW5ncyB1cCBhbiBpbnRlcmVzdGluZyBxdWVzdGlvbiAtLSBob3cgd291bGQgYSBj bGllbnQga25vdyBpZiBhbg0KPj4gZW50cnkgaXMgc3lzdGVtLWNvbnRyb2xsZWQgb3IgdXNlci1j b250cm9sbGVkPw0KPg0KPlRoaXMgaXMgYSBnb29kIHF1ZXN0aW9uLiBJIHRoaW5rIGN1cnJlbnRs eSB0aGUgYW5zd2VyIGlzIHRoYXQgdGhlIGNsaWVudA0KPmNhbiBpbmZlciBpdCBmcm9tIGNvbXBh cmluZyB0aGUgY29udGVudHMgb2YgY29uZmlndXJhdGlvbiBhbmQgb3BlcmF0aW9uYWwNCj5zdGF0 ZSB2ZXJzaW9ucyBvZiB0aGUgbGlzdC4gVGhlIHNlcnZlciB3aWxsIHJlamVjdCBhbGwgZWRpdHMg dGhhdCBhcmUgbm90DQo+YWxsb3dlZCBmb3Igc3lzdGVtLWNvbnRyb2xsZWQgZW50cmllcy4NCg0K VGhhdCBtaWdodCBiZWNvbWUgbWVzc3kgaW4gc29tZSBjYXNlcy4NCg0KPlRoaXMgbWlnaHQgYmUg YW5vdGhlciBjYW5kaWRhdGUgZm9yIGEgZ2xvYmFsIGF0dHJpYnV0ZS4NCg0KSSBhZ3JlZS4NCg0K WWkNCg0KDQo+DQo+TGFkYQ0KPg0KPj4NCj4+IFlpIA0KPj4NCj4+DQo+Pg0KPj4gT24gMy8yNy8x NCAxMjoxMCBQTSwgIkxhZGlzbGF2IExob3RrYSIgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPj4N Cj4+Pg0KPj4+T24gMjcgTWFyIDIwMTQsIGF0IDE2OjQ3LCBZaSBZYW5nICh5aXlhKSA8eWl5YUBj aXNjby5jb20+IHdyb3RlOg0KPj4+DQo+Pj4+IEhpIExhZGEsDQo+Pj4+IA0KPj4+PiBCYWNrIHRv IHRoZSBvcmlnaW5hbCBxdWVzdGlvbiAtLSBBcyByb3V0aW5nLXByb3RvY29sJ3MgY29ubmVjdGVk LXJpYnMNCj4+Pj5uZWVkDQo+Pj4+IHRvIHJlZmVyIGRlZmF1bHQgcmlicyB0byBjb25maWd1cmUg dGhlIGZpbHRlcnMsICB3ZSBzdGlsbCBuZWVkIHRoZXNlDQo+Pj4+IGRlZmF1bHQtcmlicyB0byBi ZSBzaG93biB1bmRlciByaWJzLiBCdXQgd2UgbmVlZCBvbmx5IG5hbWUgZm9yIHRoaXMsDQo+Pj4+ IHJpZ2h0PyBPbmUgdGhpbmcgSSBhbSBjb25jZXJuZWQgaXMsIHdoYXQgaWYgYSBjbGllbnQgaXMg dHJ5aW5nIHRvDQo+Pj4+Y2hhbmdlDQo+Pj4+IHRoZSBhZGRyZXNzIGZhbWlseSBvZiBhIGRlZmF1 bHQgcmliPw0KPj4+DQo+Pj5UaGVzZSBkZWZhdWx0IHJpYnMgYXJlIHN5c3RlbS1jb250cm9sbGVk IGVudHJpZXMsIHNvIHRoZSBzZXJ2ZXIgd2lsbCBub3QNCj4+PmFsbG93IHRvIGRvIHRoaXMsIG9y IGV2ZW4gZGVsZXRlIHRoZSBlbnRyeS4gSXQgaXMgdGhlIHNhbWUgYXMgd2l0aA0KPj4+c3lzdGVt LWNvbnRyb2xsZWQgaW50ZXJmYWNlcyAtIHRoZSBjbGllbnQgbXVzdCBub3QgYmUgYWxsb3dlZCB0 byBjaGFuZ2UNCj4+PnRoZSB0eXBlIG9mIGEgaGFyZHdhcmUgaW50ZXJmYWNlLg0KPj4+DQo+Pj5M YWRhDQo+Pj4NCj4+Pj4gDQo+Pj4+IFlpDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IE9uIDMv MjcvMTQgMTE6MjkgQU0sICJMYWRpc2xhdiBMaG90a2EiIDxsaG90a2FAbmljLmN6PiB3cm90ZToN Cj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IE9uIDI3IE1hciAyMDE0LCBhdCAxNjoxNywgWWkgWWFuZyAo eWl5YSkgPHlpeWFAY2lzY28uY29tPiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4+IEhpIExhZGEsDQo+ Pj4+Pj4gDQo+Pj4+Pj4gSW5saW5lLi4uDQo+Pj4+Pj4gDQo+Pj4+Pj4gT24gMy8yNy8xNCA5OjI3 IEFNLCAiTGFkaXNsYXYgTGhvdGthIiA8bGhvdGthQG5pYy5jej4gd3JvdGU6DQo+Pj4+Pj4gDQo+ Pj4+Pj4+ICJZaSBZYW5nICh5aXlhKSIgPHlpeWFAY2lzY28uY29tPiB3cml0ZXM6DQo+Pj4+Pj4+ IA0KPj4+Pj4+Pj4gSGkgTGFkYSwNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gQWhhLiBTbyB3aGVuIG11 bHRpcGxlLXJpYnMgaXMgbm90IHN1cHBvcnRlZCwgdGhlIGRlZmF1bHQtcmlicyBvbmx5DQo+Pj4+ Pj4+PiBleGlzdA0KPj4+Pj4+Pj4gaW4gdGhlIG9wZXJhdGlvbmFsIGJ1dCBub3QgaW4gY29uZmln dXJhdGlvbi4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFJpZ2h0Lg0KPj4+Pj4+PiANCj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4gQnV0IGluIHRoYXQgY2FzZSwgc2hvdWxkIHdlIHN0aWxsIGFsbG93IHVzZXJzIHRv IGNvbmZpZ3VyZSB0aGUNCj4+Pj4+Pj4+IGNvcnJlc3BvbmRpbmcgcmliIGVudHJ5IGluIHRoZSBy aWJzPw0KPj4+Pj4+PiANCj4+Pj4+Pj4gSXQgaXMgc3RpbGwgbmVlZGVkIGZvciBzcGVjaWZ5aW5n IHJvdXRlIGZpbHRlcnMgYmV0d2VlbiBhIHJvdXRpbmcNCj4+Pj4+Pj4gcHJvdG9jb2wgYW5kIHRo ZSBkZWZhdWx0IHJvdXRpbmcgdGFibGUuIFRoaXMgaXMgZG9uZSB2aWEgdGhlDQo+Pj4+Pj4+ICJj b25uZWN0ZWQtcmliIiBsaXN0IHdob3NlIGtleXMgYXJlIHJlZmVyZW5jZXMgdG8gcm91dGluZyB0 YWJsZXMuDQo+Pj4+Pj4+U2luY2UNCj4+Pj4+Pj4gWUFORyBkb2Vzbid0IGFsbG93IGxlYWZyZWZz IGluIGNvbmZpZ3VyYXRpb24gdG8gcG9pbnQgdG8gc3RhdGUNCj4+Pj4+Pj5kYXRhLA0KPj4+Pj4+ Pml0DQo+Pj4+Pj4+IGlzIG5lY2Vzc2FyeSB0byBwdXQgZXZlbiB0aGUgZGVmYXVsdCAoc3lzdGVt LWNvbnRyb2xsZWQpIFJJQiB0byB0aGUNCj4+Pj4+Pj4gInJpYiINCj4+Pj4+Pj4gbGlzdCBhbmQg dGhlbiByZWZlciB0byBpdCBmcm9tICJjb25uZWN0ZWQtcmliIi4NCj4+Pj4+PiANCj4+Pj4+PiBB Y3R1YWxseSwgY29ubmVjdGVkLXJpYnMgaGFzIGEgZGVwZW5kZW5jeSBvbiBmZWF0dXJlIG11bHRp cGxlLXJpYnMNCj4+Pj4+PmFzDQo+Pj4+Pj4gd2VsbC4NCj4+Pj4+PiANCj4+Pj4+PiArLS1ydyBj b25uZWN0ZWQtcmlicyB7bXVsdGlwbGUtcmlic30/DQo+Pj4+PiANCj4+Pj4+IFNvIHRoaXMgbG9v a3MgbGlrZSBhIG1pc3Rha2UsIGdvb2QgdGhhdCB5b3Ugc3BvdHRlZCBpdCEgVGhlDQo+Pj4+PnBv c3NpYmlsaXR5DQo+Pj4+PiBvZiBmaWx0ZXJpbmcgcm91dGVzIGZyb20vdG8gcm91dGluZyBwcm90 b2NvbCBpbnN0YW5jZXMgKHdoaWNoDQo+Pj4+PmluY2x1ZGVzDQo+Pj4+PiByZWRpc3RyaWJ1dGlv biBiZXR3ZWVuIHByb3RvY29scykgaXMgaW1wb3J0YW50IGV2ZW4gd2l0aCBhIHNpbmdsZQ0KPj4+ Pj5SSUIuDQo+Pj4+PiANCj4+Pj4+IEkgd2lsbCBjb3JyZWN0IGl0IGluIHRoZSBuZXh0IHJldmlz aW9uLCBwcm9iYWJseS9ob3BlZnVsbHkgYWZ0ZXIgSUVURg0KPj4+Pj4gbGFzdCBjYWxsLg0KPj4+ Pj4gDQo+Pj4+PiBUaGFua3MsIExhZGENCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4g DQo+Pj4+Pj4gWWkNCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+ IFBlcmhhcHMgaXQgY291bGQgYmUgYW5vdGhlciBZQU5HIDEuMSBpc3N1ZSB0byByZWxheCB0aGlz IHJ1bGUgYWJvdXQNCj4+Pj4+Pj4gcmVmZXJlbmNlcyBmcm9tIGNvbmZpZ3VyYXRpb24gdG8gc3Rh dGUgZGF0YS4gVGhleSBjYW4gb2Z0ZW4gYmUNCj4+Pj4+Pj51c2VmdWwNCj4+Pj4+Pj4gYW5kLCBh cyBpbiB0aGlzIGNhc2UsIHNpbXBsaWZ5IHRoZSBjb25maWd1cmF0aW9uLg0KPj4+Pj4+PiANCj4+ Pj4+Pj4gTGFkYQ0KPj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gWWkNCj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4gT24gMy8yNi8xNCA5OjI1IEFNLCAiTGFkaXNsYXYgTGhvdGthIiA8bGhvdGthQG5p Yy5jej4gd3JvdGU6DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBIaSBZaSwNCj4+Pj4+Pj4+PiANCj4+ Pj4+Pj4+PiAiWWkgWWFuZyAoeWl5YSkiIDx5aXlhQGNpc2NvLmNvbT4gd3JpdGVzOg0KPj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4+PiBIaSBMYWRhLA0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gSW4gdGhl IGN1cnJlbnQgbW9kZWwsIGRlZmF1bHQtcmlicyB3aWxsIGV4aXN0IG9ubHkgd2hlbiBmZWF0dXJl DQo+Pj4+Pj4+Pj4+IG11bHRpcGxlLXJpYnMgZXhpc3RzLiBUaGlzIGlzIGNvbnRyYWRpY3Rvcnkg dG8gd2hhdCBwZW9wbGUgYXJlDQo+Pj4+Pj4+Pj4+IGZhbWlsaWFyDQo+Pj4+Pj4+Pj4+IGluDQo+ Pj4+Pj4+Pj4+IHRoZSByZWFsIHdvcmxkIGRlcGxveW1lbnQgIC0tIGRlZmF1bHQtcmlicyBhbHdh eXMgZXhpc3QuDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gTm90ZSB0aGF0IGRlZmF1bHQtcmlicyBk ZXBlbmRzIG9uIHRoYXQgZmVhdHVyZSBvbmx5IGluDQo+Pj4+Pj4+Pj5jb25maWd1cmF0aW9uDQo+ Pj4+Pj4+Pj4gYnV0DQo+Pj4+Pj4+Pj4gbm90IGluIG9wZXJhdGlvbmFsIHN0YXRlIGRhdGEuIFNv LCB0aGUgaWRlYSBpcyB0aGF0IHRoZSBzeXN0ZW0NCj4+Pj4+Pj4+PnB1dHMNCj4+Pj4+Pj4+PiB0 aGUNCj4+Pj4+Pj4+PiBuYW1lKHMpIG9mIGRlZmF1bHQgUklCKHMpIGludG8gdGhlIGRlZmF1bHQt cmliIGxpc3QgaW4NCj4+Pj4+Pj4+Pm9wZXJhdGlvbmFsDQo+Pj4+Pj4+Pj4gc3RhdGUsDQo+Pj4+ Pj4+Pj4gc28gdGhlIGNsaWVudCBpcyBhYmxlIHRvIGxlYXJuIGVhc2lseSB3aGF0IHRoZSBkZWZh dWx0IChhbmQgb25seSkNCj4+Pj4+Pj4+PiBSSUIgaXMNCj4+Pj4+Pj4+PiBmb3IgZWFjaCBhZGRy ZXNzIGZhbWlseS4gQnV0IHdoZW5ldmVyIHRoZSBzZXJ2ZXIgZG9lc24ndCBzdXBwb3J0DQo+Pj4+ Pj4+Pj4gbXVsdGlwbGUNCj4+Pj4+Pj4+PiBSSUJzIHBlciBhZGRyZXNzIGZhbWlseSwgdGhlcmUg aXMgbm8gcG9pbnQgdG8gaGF2ZSBkZWZhdWx0LXJpYnMNCj4+Pj4+Pj4+PmFzDQo+Pj4+Pj4+Pj5h DQo+Pj4+Pj4+Pj4gY29uZmlndXJhdGlvbiBvcHRpb24uDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4g RG9lcyBpdCBtYWtlIHNlbnNlPw0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IFRoYW5rcywgTGFkYQ0K Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gVG8gcmVmbGVjdCBzdWNoIGFuIGV4 cGVjdGF0aW9uLCBJIHN1Z2dlc3QgdG8ga2VlcCBkZWZhdWx0LXJpYnMNCj4+Pj4+Pj4+Pj4gdW5j b25kaXRpb25hbGx5LiBJbnN0ZWFkLCBtb3ZlIHRoZSBjb25kaXRpb25zIHRvIHRoZSByaWJzIC0t IGlmDQo+Pj4+Pj4+Pj4+IGZlYXR1cmUNCj4+Pj4+Pj4+Pj4gbXVsdGlwbGUtcmlicyBkb2Vzbid0 IGV4aXN0LCBvbmx5IG9uZSByaWIgaXMgYWxsb3dlZCBwZXIgYWRkcmVzcw0KPj4+Pj4+Pj4+PiBm YW1pbHkuDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBZaQ0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+ Pj4gDQo+Pj4+Pj4+Pj4+IE9uIDMvMTkvMTQgMzo1MSBBTSwgIkxhZGlzbGF2IExob3RrYSIgPGxo b3RrYUBuaWMuY3o+IHdyb3RlOg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+ICJEZXJlayBNYW4t S2l0IFlldW5nIChteWV1bmcpIiA8bXlldW5nQGNpc2NvLmNvbT4gd3JpdGVzOg0KPj4+Pj4+Pj4+ Pj4gDQo+Pj4+Pj4+Pj4+Pj4gT24gMy8xNC8xNCAxMjo0OSBQTSwgIkxhZGlzbGF2IExob3RrYSIg PGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+PiANCj4+ Pj4+Pj4+Pj4+Pj4gT24gMTQgTWFyIDIwMTQsIGF0IDIwOjMyLCBEZXJlayBNYW4tS2l0IFlldW5n IChteWV1bmcpDQo+Pj4+Pj4+Pj4+Pj4+IDxteWV1bmdAY2lzY28uY29tPg0KPj4+Pj4+Pj4+Pj4+ PiB3cm90ZToNCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+Pj4+Pj4gT24gMy83LzE0IDI6MjkgUE0sICJMYWRpc2xhdiBMaG90a2EiIDxs aG90a2FAbmljLmN6PiB3cm90ZToNCj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4+Pj4+Pj4+IE9uIDA3IE1hciAyMDE0LCBhdCAyMjo1MiwgWWkgWWFuZyAoeWl5YSkg PHlpeWFAY2lzY28uY29tPg0KPj4+Pj4+Pj4+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBPbmUgdGhpbmcgaXMgbWlzc2luZyBmcm9tIHRoZSBkYXRhIG1v ZGVsIGlzIGFzc29jaWF0aW9uDQo+Pj4+Pj4+Pj4+Pj4+Pj4+d2l0aA0KPj4+Pj4+Pj4+Pj4+Pj4+ PiB2cmYuDQo+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4gSSBhZ3JlZSB3aXRoIHdo YXQgTWFydGluIHdyb3RlIGluIGEgcGFyYWxsZWwgdGhyZWFkLiBJDQo+Pj4+Pj4+Pj4+Pj4+Pj5i ZWxpZXZlDQo+Pj4+Pj4+Pj4+Pj4+Pj4gdGhlDQo+Pj4+Pj4+Pj4+Pj4+Pj4gcm91dGluZyBtb2R1 bGUgKGFuZCBZQU5HIGF1Z21lbnQgc3RhdGVtZW50KSBwcm92aWRlDQo+Pj4+Pj4+Pj4+Pj4+Pj5z dWZmaWNpZW50DQo+Pj4+Pj4+Pj4+Pj4+Pj4gaG9va3MNCj4+Pj4+Pj4+Pj4+Pj4+PiBmb3INCj4+ Pj4+Pj4+Pj4+Pj4+PiBpbXBsZW1lbnRpbmcgVlJGIGFzIGEgc3BlY2lmaWMgdHlwZSBvZiByb3V0 aW5nLWluc3RhbmNlLg0KPj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+ Pj4+Pj4+IFRoZSBkcmFmdCBtZW50aW9uZWQgdGhlIHJvdXRpbmctaW5zdGFuY2UgY291bGQgYmUg dXNlZCB0bw0KPj4+Pj4+Pj4+Pj4+Pj4gcmVwcmVzZW50cyBhDQo+Pj4+Pj4+Pj4+Pj4+PiBsb2dp Y2FsIHJvdXRlci4NCj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4gVGhlIHRlcm0gImxv Z2ljYWwgcm91dGVyIiBpbiBvbmUgb3IgbW9yZSB2ZW5kb3JzIG1lYW4gYQ0KPj4+Pj4+Pj4+Pj4+ Pj4gcGFydGl0aW9uDQo+Pj4+Pj4+Pj4+Pj4+PiBvZg0KPj4+Pj4+Pj4+Pj4+Pj4gdGhlDQo+Pj4+ Pj4+Pj4+Pj4+PiBwaHlzaWNhbCByb3V0ZXIgaW50byBtdWx0aXBsZSBsb2dpY2FsIHVuaXRzLCBl YWNoIGNvdWxkIGhhdmUNCj4+Pj4+Pj4+Pj4+Pj4+IG11bHRpcGxlDQo+Pj4+Pj4+Pj4+Pj4+PiBW UkZzLg0KPj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+PiBEb2VzIHRoZSBkcmFmdCBpbnRl bmQgdG8gbWFuYWdlICJsb2dpY2FsIHJvdXRlciIgaW4gdGhlDQo+Pj4+Pj4+Pj4+Pj4+PmFib3Zl DQo+Pj4+Pj4+Pj4+Pj4+PiBkZWZpbml0aW9uPw0KPj4+Pj4+Pj4+Pj4+Pj4gU29tZSBjbGFyaWZp Y2F0aW9uIHdpbGwgYmUgdXNlZnVsLg0KPj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4gT25l IHdheSB0byBpbXBsZW1lbnQgdGhpcyBpcyB0byBpbnRyb2R1Y2UgdHdvIHR5cGVzIG9mDQo+Pj4+ Pj4+Pj4+Pj4+cm91dGluZw0KPj4+Pj4+Pj4+Pj4+PiBpbnN0YW5jZXMsDQo+Pj4+Pj4+Pj4+Pj4+ IHNheSAnbG9naWNhbC1yb3V0ZXLCuSBhbmQgxZJ2cmbCuS4gVGhlIMWSdnJmwrkgdHlwZSB0aGVu IHdvdWxkDQo+Pj4+Pj4+Pj4+Pj4+aGF2ZQ0KPj4+Pj4+Pj4+Pj4+PiBhbm90aGVyDQo+Pj4+Pj4+ Pj4+Pj4+IGxlYWYgbGlua2luZyBpdCB0byBhIGxvZ2ljYWwgcm91dGVyLiBUaGlzIGlzIHF1aXRl IGxpa2UgdGhlDQo+Pj4+Pj4+Pj4+Pj4+IHZhcmlvdXMNCj4+Pj4+Pj4+Pj4+Pj4gbWV0aG9kcyBv ZiBpbnRlcmZhY2Ugc3RhY2tpbmcsIHNlZSB0aGUgZXhhbXBsZXMgaW4NCj4+Pj4+Pj4+Pj4+Pj4g ZHJhZnQtaWV0Zi1uZXRtb2QtaW50ZXJmYWNlcy1jZmctMTYuDQo+Pj4+Pj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4+Pj4+PiBMYWRhDQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+ Pj4gSXQgaXMgb25lIHdheS4NCj4+Pj4+Pj4+Pj4+PiBIb3dldmVyLCBnaXZlbiB0aGF0IGN1cnJl bnQgbW9kZWwgdGhhdCBldmVyeXRoaW5nIGlzIHB1dA0KPj4+Pj4+Pj4+Pj4+aW5zaWRlDQo+Pj4+ Pj4+Pj4+Pj5hDQo+Pj4+Pj4+Pj4+Pj4gcm91dGluZy1pbnN0YW5jZSwgdGhpbmdzIGxpa2UgUklC LCByb3V0aW5nLXByb3RvY29scyBldGMgYXJlDQo+Pj4+Pj4+Pj4+Pj5ubw0KPj4+Pj4+Pj4+Pj4+ IGxvbmdlcg0KPj4+Pj4+Pj4+Pj4+IG5lZWRlZCBkaXJlY3RseSB1bmRlciB0aGUgJ2xvZ2ljYWwt cm91dGVyJy4NCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gTm90ZSB0aGF0IFJJQnMgYXJlIG5v dCBpbnNpZGUgInJvdXRpbmctaW5zdGFuY2UiLCBhbHRob3VnaCBhbg0KPj4+Pj4+Pj4+Pj4gaW1w bGVtZW50YXRpb24gbWF5IGRlZmluZSBzb21lIFJJQnMgdG8gYmUNCj4+Pj4+Pj4+Pj4+IHJvdXRp bmctaW5zdGFuY2Utc3BlY2lmaWMuDQo+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+PiBXaGF0IG5l ZWRlZCBpbiB0aGUgJ2xvZ2ljYWwgcm91dGVyJyBhcmUgcmVzb3VyY2VzIGFsbG9jYXRpb24NCj4+ Pj4+Pj4+Pj4+Pmxpa2UNCj4+Pj4+Pj4+Pj4+PiBpbnRlcmZhY2VzLCBDUFUgZXRjLg0KPj4+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4+PiAiaW50ZXJmYWNlcyIgaXMgYSBjb250YWluZXIgaW5zaWRlICJy b3V0aW5nLWluc3RhbmNlIiwgYW5kDQo+Pj4+Pj4+Pj4+PiJjcHUiDQo+Pj4+Pj4+Pj4+PiBjYW4N Cj4+Pj4+Pj4+Pj4+IGJlDQo+Pj4+Pj4+Pj4+PiBlYXNpbHkgYWRkZWQgYnkgYW5vdGhlciBtb2R1 bGUgdmlhIGF1Z21lbnRhdGlvbi4NCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+IFRob3VnaCBy b3V0aW5nLWluc3RhbmNlIGNvdWxkIGJlIGF1Z21lbnRlZCB0byBpbmNsdWRlICdsb2dpY2FsDQo+ Pj4+Pj4+Pj4+Pj4gcm91dGVyJw0KPj4+Pj4+Pj4+Pj4+IHNwZWNpZmljIGZpZWxkIGFuZCBhZGQg bmV3IGNvbmRpdGlvbiB0byByZXN0cmljdCBleGlzdGluZyBsZWFmDQo+Pj4+Pj4+Pj4+Pj4gdGhh dA0KPj4+Pj4+Pj4+Pj4+IG5vDQo+Pj4+Pj4+Pj4+Pj4gbG9uZyBhcHBseSwgSSB0aGluayBhIG5l dyBjb250YWluZXIgYWJvdmUgcm91dGluZy1pbnN0YW5jZSBpcw0KPj4+Pj4+Pj4+Pj4+IGNsZWFu ZXIuDQo+Pj4+Pj4+Pj4+Pj4gSXQNCj4+Pj4+Pj4+Pj4+PiBjb3VsZCBiZSBhIG5ldyBkYXRhIG1v ZGVsIHRoYXQgcmVmZXJlbmNlIHRoZSBkZWZpbml0aW9uIGluIHRoZQ0KPj4+Pj4+Pj4+Pj4+IGN1 cnJlbnQNCj4+Pj4+Pj4+Pj4+PiBkcmFmdC4NCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gSSBn dWVzcyBwYXJ0IG9mIHRoZSBjb25mdXNpb24gc3RlbXMgZnJvbSB0aGUgbmFtZQ0KPj4+Pj4+Pj4+ Pj4gInJvdXRpbmctaW5zdGFuY2UiDQo+Pj4+Pj4+Pj4+PiB3aGljaCBhbHJlYWR5IG1lYW5zIGEg cGFydGljdWxhciAocGxhdGZvcm0tc3BlY2lmaWMpIHN0eWxlIG9mDQo+Pj4+Pj4+Pj4+PiByb3V0 ZXINCj4+Pj4+Pj4+Pj4+IHZpcnR1YWxpemF0aW9uLiBFYXJsaWVyIHJldmlzaW9ucyBvZiB0aGUg ZHJhZnQgdXNlZCAicm91dGVyIg0KPj4+Pj4+Pj4+Pj5saXN0DQo+Pj4+Pj4+Pj4+PiBpbg0KPj4+ Pj4+Pj4+Pj4gdGhpcw0KPj4+Pj4+Pj4+Pj4gcGxhY2UgYnV0IGl0IHdhcyBhbiBzcGVjaWZpYyBy ZXF1aXJlbWVudCBvZiBJMlJTIGZvbGtzIHRvDQo+Pj4+Pj4+Pj4+PmNoYW5nZQ0KPj4+Pj4+Pj4+ Pj4gdGhpcw0KPj4+Pj4+Pj4+Pj4gbmFtZSB0byAicm91dGluZy1pbnN0YW5jZSIuIE9oIHdlbGwg Li4uDQo+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+IFNvIHBsZWFzZSBrZWVwIGluIG1pbmQgdGhh dCAicm91dGluZy1pbnN0YW5jZSIgY2FuIHJlYWxseSBtZWFuDQo+Pj4+Pj4+Pj4+PiBkaWZmZXJl bnQNCj4+Pj4+Pj4+Pj4+IHRoaW5ncyBkZXBlbmRpbmcgb24gaXRzIHR5cGUgKGFuZCBjYW4gYmUg YXVnbWVudGVkIGluIGRpZmZlcmVudA0KPj4+Pj4+Pj4+Pj4gd2F5cw0KPj4+Pj4+Pj4+Pj4gZGVw ZW5kaW5nIG9uIHRoZSB0eXBlKS4gQWdhaW4sIHRoaXMgYXBwcm9hY2ggaXMgdmVyeSBzaW1pbGFy IHRvDQo+Pj4+Pj4+Pj4+PnRoZQ0KPj4+Pj4+Pj4+Pj4gb25lDQo+Pj4+Pj4+Pj4+PiBhZG9wdGVk IGZvciB0aGUgImludGVyZmFjZSIgbGlzdCBpbiAiaWV0Zi1pbnRlcmZhY2VzIiBtb2R1bGUuDQo+ Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+IExhZGENCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+Pj4+IC0gRGVyZWsNCj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4gDQo+ Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+IC0gRGVyZWsNCj4+Pj4+Pj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+IEkgdGhpbmsgdGhvdWdoIHRoYXQgb3Ro ZXIgd29yayBleHRlbmRpbmcgdGhlIHJvdXRpbmcgbW9kdWxlDQo+Pj4+Pj4+Pj4+Pj4+Pj5pcw0K Pj4+Pj4+Pj4+Pj4+Pj4+IG11Y2gNCj4+Pj4+Pj4+Pj4+Pj4+PiBtb3JlDQo+Pj4+Pj4+Pj4+Pj4+ Pj4gbmVlZGVkLCBuYW1lbHkgdmVuZG9yLW5ldXRyYWwgZGF0YSBtb2RlbHMgZm9yIHJvdXRpbmcN Cj4+Pj4+Pj4+Pj4+Pj4+PiBwcm90b2NvbHMuDQo+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+ Pj4+Pj4gVGhlIGNvbnNlbnN1cyBvZiB0aGUgTkVUTU9EIFdHIHdhcyB0aGF0IHRoZXNlIG5ldyBt b2R1bGVzDQo+Pj4+Pj4+Pj4+Pj4+Pj4gc2hvdWxkDQo+Pj4+Pj4+Pj4+Pj4+Pj4gYmUNCj4+Pj4+ Pj4+Pj4+Pj4+PiBkZXZlbG9wZWQgYnkgZXhwZXJ0cyBpbiB0aGUgUm91dGluZyBBcmVhIChWUkYg aW4gdGhlIE1QTFMNCj4+Pj4+Pj4+Pj4+Pj4+PldHPykuDQo+Pj4+Pj4+Pj4+Pj4+Pj4gVGhlDQo+ Pj4+Pj4+Pj4+Pj4+Pj4gTkVUTU9EIFdHIGFuZCBZQU5HIERvY3RvcnMgd2lsbCBjZXJ0YWlubHkg aGVscCBidXQgdGhlIGJ1bGsNCj4+Pj4+Pj4+Pj4+Pj4+Pm9mDQo+Pj4+Pj4+Pj4+Pj4+Pj4gdGhp cw0KPj4+Pj4+Pj4+Pj4+Pj4+IHdvcmsNCj4+Pj4+Pj4+Pj4+Pj4+PiBzaG91bGQgYmUgZG9uZSBi eSBkb21haW4gZXhwZXJ0cy4NCj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+PiBMYWRh DQo+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBB bm90aGVyIGNvbmNlcm4gSSBoYXZlIGlzIGFib3V0IGFkZHJlc3MgZmFtaWx5LiBUbw0KPj4+Pj4+ Pj4+Pj4+Pj4+PmZhY2lsaXRhdGUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gYQ0KPj4+Pj4+Pj4+Pj4+Pj4+ PiBxdWVyeQ0KPj4+Pj4+Pj4+Pj4+Pj4+PiBiYXNlZCBvbiBBRkkgb25seSwgb3IgU0FGSSBvbmx5 LCBpdCBzZWVtcyBtb3JlIGNvbnZlbmllbnQNCj4+Pj4+Pj4+Pj4+Pj4+Pj50bw0KPj4+Pj4+Pj4+ Pj4+Pj4+PiB1c2UNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gdHdvDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IGxlYWZz DQo+Pj4+Pj4+Pj4+Pj4+Pj4+IChBRkkgYW5kIFNBRkkpIGluc3RlYWQgb2Ygb25lIChBRkktU0FG SSkuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBZaQ0KPj4+Pj4+Pj4+Pj4+ Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+ Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gT24gMS8xMC8xNCA4OjMwIEFNLCAiaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnIg0KPj4+Pj4+Pj4+Pj4+Pj4+PiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn Pg0KPj4+Pj4+Pj4+Pj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWls YWJsZSBmcm9tIHRoZSBvbi1saW5lDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJbnRlcm5ldC1EcmFmdHMN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGRpcmVjdG9yaWVzLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhpcyBk cmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTkVUQ09ORiBEYXRhIE1vZGVsaW5nDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBMYW5ndWFnZQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gV29ya2luZw0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4gR3JvdXAgb2YgdGhlIElFVEYuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+ICAgIFRpdGxlICAgICAgICAgICA6IEEgWUFORyBEYXRhIE1vZGVsIGZvciBSb3V0 aW5nDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBNYW5hZ2VtZW50DQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICBB dXRob3IgICAgICAgICAgOiBMYWRpc2xhdiBMaG90a2ENCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IAlGaWxl bmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy0xMy50eHQNCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IAlQYWdlcyAgICAgICAgICAgOiA5NQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gCURh dGUgICAgICAgICAgICA6IDIwMTQtMDEtMTANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4gQWJzdHJhY3Q6DQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUaGlzIGRvY3VtZW50IGNvbnRh aW5zIGEgc3BlY2lmaWNhdGlvbiBvZiB0aHJlZSBZQU5HDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pm1vZHVs ZXMuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUb2dldGhlciB0aGV5IGZvcm0gdGhlIGNvcmUgcm91dGlu ZyBkYXRhIG1vZGVsIHdoaWNoDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PnNlcnZlcw0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4gYXMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGENCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGZyYW1ld29y ayBmb3IgY29uZmlndXJpbmcgYW5kIG1hbmFnaW5nIGEgcm91dGluZw0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj5zdWJzeXN0ZW0uDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJdA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gaXMN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGV4cGVjdGVkIHRoYXQgdGhlc2UgbW9kdWxlcyB3aWxsIGJlIGF1 Z21lbnRlZCBieQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj5hZGRpdGlvbmFsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ PiBZQU5HDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBtb2R1bGVzIGRlZmluaW5nIGRhdGEgbW9kZWxzIGZv ciBpbmRpdmlkdWFsIHJvdXRpbmcNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+cHJvdG9jb2xzDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBhbmQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG90aGVyIHJlbGF0ZWQgZnVuY3Rpb25z LiAgVGhlIGNvcmUgcm91dGluZyBkYXRhIG1vZGVsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBwcm92aWRl cw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gY29tbW9uDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBidWlsZGluZyBi bG9ja3MgZm9yIHN1Y2ggZXh0ZW5zaW9ucyAtIHJvdXRpbmcgaW5zdGFuY2VzLA0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4gcm91dGVzLA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gcm91dGluZyBpbmZvcm1hdGlvbiBi YXNlcyAoUklCKSwgcm91dGluZyBwcm90b2NvbHMgYW5kDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PnJvdXRl DQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBmaWx0ZXJzLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1 cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGluZw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4tYw0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj5mZw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gLw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJs ZSBhdDoNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj5odHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy0xDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+PjMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gQSBkaWZmIGZy b20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj5odHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldG1vZC1y b3V0aW5nDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pi1jDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PmZnDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+PiAtMQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gMw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4g dGltZQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gb2YNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHN1Ym1pc3Npb24N Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRvb2xzLmlldGYub3JnLg0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28g YXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBmdHA6Ly9m dHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4gbmV0bW9kQGlldGYub3JnDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+ Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBuZXRt b2RAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2QNCj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+PiAtLQ0K Pj4+Pj4+Pj4+Pj4+Pj4+IExhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj4+Pj4+Pj4+Pj4+ Pj4+PiBQR1AgS2V5IElEOiBFNzRFOEMwQw0KPj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+ Pj4+Pj4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+Pj4+Pj4+IG5ldG1vZEBpZXRm Lm9yZw0KPj4+Pj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kDQo+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+ IC0tDQo+Pj4+Pj4+Pj4+Pj4+IExhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj4+Pj4+Pj4+ Pj4+Pj4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+ Pj4+PiANCj4+Pj4+Pj4+Pj4+IC0tIA0KPj4+Pj4+Pj4+Pj4gTGFkaXNsYXYgTGhvdGthLCBDWi5O SUMgTGFicw0KPj4+Pj4+Pj4+Pj4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4+Pj4+Pj4+Pj4gDQo+ Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gLS0gDQo+Pj4+Pj4+Pj4gTGFkaXNsYXYgTGhvdGthLCBDWi5O SUMgTGFicw0KPj4+Pj4+Pj4+IFBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+Pj4+Pj4+PiANCj4+Pj4+ Pj4gDQo+Pj4+Pj4+IC0tIA0KPj4+Pj4+PiBMYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+ Pj4+Pj4+IFBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+Pj4+PiANCj4+Pj4+IC0tDQo+Pj4+PiBMYWRp c2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+Pj4+PiBQR1AgS2V5IElEOiBFNzRFOEMwQw0KPj4+ Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+IA0KPj4+DQo+Pj4tLQ0KPj4+TGFkaXNs YXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPj4+UEdQIEtleSBJRDogRTc0RThDMEMNCj4+Pg0KPj4+ DQo+Pj4NCj4+Pg0KPj4NCj4NCj4tLSANCj5MYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+ UEdQIEtleSBJRDogRTc0RThDMEMNCg0K From nobody Fri Mar 28 11:33:52 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36AA71A0959 for ; Fri, 28 Mar 2014 11:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 207Od7l3e7SV for ; Fri, 28 Mar 2014 11:33:41 -0700 (PDT) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id D629B1A06CC for ; Fri, 28 Mar 2014 11:33:40 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id i17so6438338qcy.0 for ; Fri, 28 Mar 2014 11:33:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Tsyk2MJ3/f+Fu9AlaMhwU8RLOL05k3IdKa367Cs2ESU=; b=hUCv7FnszMg4dp2xGm6Tm3BJgNlaNdfOFPmAdPl3NKzKkWb8MfacBVbXO8xb4XlFGi AI8bKUfoVqheI9Dz9qmrbGEUABHnUqAOV7uoVOKlaSS7c+g4gDod9G8vgt43F4q5w0QR qACc10wJNo90FJQNc97/+GxkhzdG9cIXXEFWOcpeYxWFCtf0PVb7iaANczctWKp1UPJv z0zngJop8ypurTPapLSwGa1DtkJAggcQuLkpLnmNDipDRRSLU9f4umQefG9VhL5VoRT9 jRUXEhnxgm0OPcfpB+5nfOKpLnYNkbQcf8HO81oNOxPUt0ccd3mFro3in84sATt1npLc adSw== X-Gm-Message-State: ALoCoQkrejRfc9d1W2s6W8WKqj9l5C47g+b47C1m9OA6WabzAopWd1ewWjgkP6NtVLfJkZf+BzO9 MIME-Version: 1.0 X-Received: by 10.140.87.67 with SMTP id q61mr3509270qgd.94.1396031618506; Fri, 28 Mar 2014 11:33:38 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Fri, 28 Mar 2014 11:33:38 -0700 (PDT) In-Reply-To: References: <20140110133016.24678.42711.idtracker@ietfa.amsl.com> <9C81158E-5B4C-4479-AEA5-23CBCC020ADD@nic.cz> <0ED855DA-51BE-4DE6-AB22-E1A9E04C0E5F@nic.cz> <2830A589-DCCF-47C8-A066-D416C752D48C@nic.cz> <2512EFED-F10A-4D70-A6EC-81ACC54D1334@nic.cz> Date: Fri, 28 Mar 2014 11:33:38 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113abee6b78d5704f5aef07e Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yLHF2j_hDMdKbAbreXp-hbr-Wc4 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 18:33:48 -0000 --001a113abee6b78d5704f5aef07e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Mar 28, 2014 at 11:06 AM, Ladislav Lhotka wrote: > "Yi Yang (yiya)" writes: > > > This brings up an interesting question -- how would a client know if an > > entry is system-controlled or user-controlled? > > This is a good question. I think currently the answer is that the client > can infer it from comparing the contents of configuration and operational > state versions of the list. The server will reject all edits that are not > allowed for system-controlled entries. > > This might be another candidate for a global attribute. > > This is exactly why I added the parameter in the operation. IMO using identity-stmt is better than inventing a new statement, but we agree on the general concept. IMO NETCONF needs most of NETCONF-EX in order to be aligned with RESTCONF. The and operations solve many issues with CRUD operations. The capability-id and config-id capabilities need to be added to support standard caching. If there was a standard "Conditional Enablement" for NETCONF datastores, then the default P-container would be a lot more useful. This is a general feature that should not be added to each list as an "enabled" leaf. The operator should be able to disable config (as long as the YANG validation still passes). Also, a P-container can be augmented, and an 'enabled' leaf cannot. If there was a default-presence-stmt then a P-container could be used instead of a boolean leaf with a default. BTW, empty type cannot have a default other than "not present", since there would be no way to specify a non-default value. Lada > > Andy > > > > Yi > > > > > > > > On 3/27/14 12:10 PM, "Ladislav Lhotka" wrote: > > > >> > >>On 27 Mar 2014, at 16:47, Yi Yang (yiya) wrote: > >> > >>> Hi Lada, > >>> > >>> Back to the original question -- As routing-protocol's connected-ribs > >>>need > >>> to refer default ribs to configure the filters, we still need these > >>> default-ribs to be shown under ribs. But we need only name for this, > >>> right? One thing I am concerned is, what if a client is trying to > change > >>> the address family of a default rib? > >> > >>These default ribs are system-controlled entries, so the server will no= t > >>allow to do this, or even delete the entry. It is the same as with > >>system-controlled interfaces - the client must not be allowed to change > >>the type of a hardware interface. > >> > >>Lada > >> > >>> > >>> Yi > >>> > >>> > >>> > >>> On 3/27/14 11:29 AM, "Ladislav Lhotka" wrote: > >>> > >>>> > >>>> On 27 Mar 2014, at 16:17, Yi Yang (yiya) wrote: > >>>> > >>>>> Hi Lada, > >>>>> > >>>>> Inline... > >>>>> > >>>>> On 3/27/14 9:27 AM, "Ladislav Lhotka" wrote: > >>>>> > >>>>>> "Yi Yang (yiya)" writes: > >>>>>> > >>>>>>> Hi Lada, > >>>>>>> > >>>>>>> Aha. So when multiple-ribs is not supported, the default-ribs onl= y > >>>>>>> exist > >>>>>>> in the operational but not in configuration. > >>>>>> > >>>>>> Right. > >>>>>> > >>>>>>> > >>>>>>> But in that case, should we still allow users to configure the > >>>>>>> corresponding rib entry in the ribs? > >>>>>> > >>>>>> It is still needed for specifying route filters between a routing > >>>>>> protocol and the default routing table. This is done via the > >>>>>> "connected-rib" list whose keys are references to routing tables. > >>>>>>Since > >>>>>> YANG doesn't allow leafrefs in configuration to point to state dat= a, > >>>>>>it > >>>>>> is necessary to put even the default (system-controlled) RIB to th= e > >>>>>> "rib" > >>>>>> list and then refer to it from "connected-rib". > >>>>> > >>>>> Actually, connected-ribs has a dependency on feature multiple-ribs = as > >>>>> well. > >>>>> > >>>>> +--rw connected-ribs {multiple-ribs}? > >>>> > >>>> So this looks like a mistake, good that you spotted it! The > possibility > >>>> of filtering routes from/to routing protocol instances (which includ= es > >>>> redistribution between protocols) is important even with a single RI= B. > >>>> > >>>> I will correct it in the next revision, probably/hopefully after IET= F > >>>> last call. > >>>> > >>>> Thanks, Lada > >>>> > >>>> > >>>>> > >>>>> > >>>>> Yi > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>> Perhaps it could be another YANG 1.1 issue to relax this rule abou= t > >>>>>> references from configuration to state data. They can often be > useful > >>>>>> and, as in this case, simplify the configuration. > >>>>>> > >>>>>> Lada > >>>>>> > >>>>>>> > >>>>>>> Yi > >>>>>>> > >>>>>>> On 3/26/14 9:25 AM, "Ladislav Lhotka" wrote: > >>>>>>> > >>>>>>>> Hi Yi, > >>>>>>>> > >>>>>>>> "Yi Yang (yiya)" writes: > >>>>>>>> > >>>>>>>>> Hi Lada, > >>>>>>>>> > >>>>>>>>> In the current model, default-ribs will exist only when feature > >>>>>>>>> multiple-ribs exists. This is contradictory to what people are > >>>>>>>>> familiar > >>>>>>>>> in > >>>>>>>>> the real world deployment -- default-ribs always exist. > >>>>>>>> > >>>>>>>> Note that default-ribs depends on that feature only in > >>>>>>>>configuration > >>>>>>>> but > >>>>>>>> not in operational state data. So, the idea is that the system > puts > >>>>>>>> the > >>>>>>>> name(s) of default RIB(s) into the default-rib list in operation= al > >>>>>>>> state, > >>>>>>>> so the client is able to learn easily what the default (and only= ) > >>>>>>>> RIB is > >>>>>>>> for each address family. But whenever the server doesn't support > >>>>>>>> multiple > >>>>>>>> RIBs per address family, there is no point to have default-ribs = as > >>>>>>>>a > >>>>>>>> configuration option. > >>>>>>>> > >>>>>>>> Does it make sense? > >>>>>>>> > >>>>>>>> Thanks, Lada > >>>>>>>> > >>>>>>>>> > >>>>>>>>> To reflect such an expectation, I suggest to keep default-ribs > >>>>>>>>> unconditionally. Instead, move the conditions to the ribs -- if > >>>>>>>>> feature > >>>>>>>>> multiple-ribs doesn't exist, only one rib is allowed per addres= s > >>>>>>>>> family. > >>>>>>>>> > >>>>>>>>> Yi > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 3/19/14 3:51 AM, "Ladislav Lhotka" wrote: > >>>>>>>>> > >>>>>>>>>> "Derek Man-Kit Yeung (myeung)" writes: > >>>>>>>>>> > >>>>>>>>>>> On 3/14/14 12:49 PM, "Ladislav Lhotka" wrote: > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On 14 Mar 2014, at 20:32, Derek Man-Kit Yeung (myeung) > >>>>>>>>>>>> > >>>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 3/7/14 2:29 PM, "Ladislav Lhotka" wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 07 Mar 2014, at 22:52, Yi Yang (yiya) > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> One thing is missing from the data model is association > with > >>>>>>>>>>>>>>> vrf. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I agree with what Martin wrote in a parallel thread. I > >>>>>>>>>>>>>>believe > >>>>>>>>>>>>>> the > >>>>>>>>>>>>>> routing module (and YANG augment statement) provide > >>>>>>>>>>>>>>sufficient > >>>>>>>>>>>>>> hooks > >>>>>>>>>>>>>> for > >>>>>>>>>>>>>> implementing VRF as a specific type of routing-instance. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> The draft mentioned the routing-instance could be used to > >>>>>>>>>>>>> represents a > >>>>>>>>>>>>> logical router. > >>>>>>>>>>>>> > >>>>>>>>>>>>> The term "logical router" in one or more vendors mean a > >>>>>>>>>>>>> partition > >>>>>>>>>>>>> of > >>>>>>>>>>>>> the > >>>>>>>>>>>>> physical router into multiple logical units, each could hav= e > >>>>>>>>>>>>> multiple > >>>>>>>>>>>>> VRFs. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Does the draft intend to manage "logical router" in the abo= ve > >>>>>>>>>>>>> definition? > >>>>>>>>>>>>> Some clarification will be useful. > >>>>>>>>>>>> > >>>>>>>>>>>> One way to implement this is to introduce two types of routi= ng > >>>>>>>>>>>> instances, > >>>>>>>>>>>> say 'logical-router=B9 and OEvrf=B9. The OEvrf=B9 type then = would have > >>>>>>>>>>>> another > >>>>>>>>>>>> leaf linking it to a logical router. This is quite like the > >>>>>>>>>>>> various > >>>>>>>>>>>> methods of interface stacking, see the examples in > >>>>>>>>>>>> draft-ietf-netmod-interfaces-cfg-16. > >>>>>>>>>>>> > >>>>>>>>>>>> Lada > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> It is one way. > >>>>>>>>>>> However, given that current model that everything is put insi= de > >>>>>>>>>>>a > >>>>>>>>>>> routing-instance, things like RIB, routing-protocols etc are = no > >>>>>>>>>>> longer > >>>>>>>>>>> needed directly under the 'logical-router'. > >>>>>>>>>> > >>>>>>>>>> Note that RIBs are not inside "routing-instance", although an > >>>>>>>>>> implementation may define some RIBs to be > >>>>>>>>>> routing-instance-specific. > >>>>>>>>>> > >>>>>>>>>>> What needed in the 'logical router' are resources allocation > >>>>>>>>>>>like > >>>>>>>>>>> interfaces, CPU etc. > >>>>>>>>>> > >>>>>>>>>> "interfaces" is a container inside "routing-instance", and "cp= u" > >>>>>>>>>> can > >>>>>>>>>> be > >>>>>>>>>> easily added by another module via augmentation. > >>>>>>>>>> > >>>>>>>>>>> Though routing-instance could be augmented to include 'logica= l > >>>>>>>>>>> router' > >>>>>>>>>>> specific field and add new condition to restrict existing lea= f > >>>>>>>>>>> that > >>>>>>>>>>> no > >>>>>>>>>>> long apply, I think a new container above routing-instance is > >>>>>>>>>>> cleaner. > >>>>>>>>>>> It > >>>>>>>>>>> could be a new data model that reference the definition in th= e > >>>>>>>>>>> current > >>>>>>>>>>> draft. > >>>>>>>>>> > >>>>>>>>>> I guess part of the confusion stems from the name > >>>>>>>>>> "routing-instance" > >>>>>>>>>> which already means a particular (platform-specific) style of > >>>>>>>>>> router > >>>>>>>>>> virtualization. Earlier revisions of the draft used "router" > list > >>>>>>>>>> in > >>>>>>>>>> this > >>>>>>>>>> place but it was an specific requirement of I2RS folks to chan= ge > >>>>>>>>>> this > >>>>>>>>>> name to "routing-instance". Oh well ... > >>>>>>>>>> > >>>>>>>>>> So please keep in mind that "routing-instance" can really mean > >>>>>>>>>> different > >>>>>>>>>> things depending on its type (and can be augmented in differen= t > >>>>>>>>>> ways > >>>>>>>>>> depending on the type). Again, this approach is very similar t= o > >>>>>>>>>>the > >>>>>>>>>> one > >>>>>>>>>> adopted for the "interface" list in "ietf-interfaces" module. > >>>>>>>>>> > >>>>>>>>>> Lada > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> - Derek > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> - Derek > >>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I think though that other work extending the routing modul= e > >>>>>>>>>>>>>>is > >>>>>>>>>>>>>> much > >>>>>>>>>>>>>> more > >>>>>>>>>>>>>> needed, namely vendor-neutral data models for routing > >>>>>>>>>>>>>> protocols. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The consensus of the NETMOD WG was that these new modules > >>>>>>>>>>>>>> should > >>>>>>>>>>>>>> be > >>>>>>>>>>>>>> developed by experts in the Routing Area (VRF in the MPLS > >>>>>>>>>>>>>>WG?). > >>>>>>>>>>>>>> The > >>>>>>>>>>>>>> NETMOD WG and YANG Doctors will certainly help but the bul= k > >>>>>>>>>>>>>>of > >>>>>>>>>>>>>> this > >>>>>>>>>>>>>> work > >>>>>>>>>>>>>> should be done by domain experts. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Lada > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Another concern I have is about address family. To > >>>>>>>>>>>>>>>facilitate > >>>>>>>>>>>>>>> a > >>>>>>>>>>>>>>> query > >>>>>>>>>>>>>>> based on AFI only, or SAFI only, it seems more convenient > to > >>>>>>>>>>>>>>> use > >>>>>>>>>>>>>>> two > >>>>>>>>>>>>>>> leafs > >>>>>>>>>>>>>>> (AFI and SAFI) instead of one (AFI-SAFI). > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Yi > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 1/10/14 8:30 AM, "internet-drafts@ietf.org" > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> A New Internet-Draft is available from the on-line > >>>>>>>>>>>>>>>> Internet-Drafts > >>>>>>>>>>>>>>>> directories. > >>>>>>>>>>>>>>>> This draft is a work item of the NETCONF Data Modeling > >>>>>>>>>>>>>>>> Language > >>>>>>>>>>>>>>>> Working > >>>>>>>>>>>>>>>> Group of the IETF. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Title : A YANG Data Model for Routing > >>>>>>>>>>>>>>>> Management > >>>>>>>>>>>>>>>> Author : Ladislav Lhotka > >>>>>>>>>>>>>>>> Filename : > draft-ietf-netmod-routing-cfg-13.txt > >>>>>>>>>>>>>>>> Pages : 95 > >>>>>>>>>>>>>>>> Date : 2014-01-10 > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Abstract: > >>>>>>>>>>>>>>>> This document contains a specification of three YANG > >>>>>>>>>>>>>>>>modules. > >>>>>>>>>>>>>>>> Together they form the core routing data model which > serves > >>>>>>>>>>>>>>>> as > >>>>>>>>>>>>>>>> a > >>>>>>>>>>>>>>>> framework for configuring and managing a routing > subsystem. > >>>>>>>>>>>>>>>> It > >>>>>>>>>>>>>>>> is > >>>>>>>>>>>>>>>> expected that these modules will be augmented by > additional > >>>>>>>>>>>>>>>> YANG > >>>>>>>>>>>>>>>> modules defining data models for individual routing > >>>>>>>>>>>>>>>>protocols > >>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>> other related functions. The core routing data model > >>>>>>>>>>>>>>>> provides > >>>>>>>>>>>>>>>> common > >>>>>>>>>>>>>>>> building blocks for such extensions - routing instances, > >>>>>>>>>>>>>>>> routes, > >>>>>>>>>>>>>>>> routing information bases (RIB), routing protocols and > >>>>>>>>>>>>>>>>route > >>>>>>>>>>>>>>>> filters. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> The IETF datatracker status page for this draft is: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-c > >>>>>>>>>>>>>>>>fg > >>>>>>>>>>>>>>>> / > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> There's also a htmlized version available at: > >>>>>>>>>>>>>>>> > http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13 > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> A diff from the previous version is available at: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-c > >>>>>>>>>>>>>>>>fg > >>>>>>>>>>>>>>>> -1 > >>>>>>>>>>>>>>>> 3 > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Please note that it may take a couple of minutes from th= e > >>>>>>>>>>>>>>>> time > >>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>> submission > >>>>>>>>>>>>>>>> until the htmlized version and diff are available at > >>>>>>>>>>>>>>>> tools.ietf.org. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>>>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>>>> netmod mailing list > >>>>>>>>>>>>>>>> netmod@ietf.org > >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>>> netmod mailing list > >>>>>>>>>>>>>>> netmod@ietf.org > >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -- > >>>>>>>>>>>>>> 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 > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs > >>>>>>>>>> PGP Key ID: E74E8C0C > >>>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Ladislav Lhotka, CZ.NIC Labs > >>>>>>>> PGP Key ID: E74E8C0C > >>>>>>> > >>>>>> > >>>>>> -- > >>>>>> Ladislav Lhotka, CZ.NIC Labs > >>>>>> PGP Key ID: E74E8C0C > >>>> > >>>> -- > >>>> Ladislav Lhotka, CZ.NIC Labs > >>>> PGP Key ID: E74E8C0C > >>>> > >>>> > >>>> > >>>> > >>> > >> > >>-- > >>Ladislav Lhotka, CZ.NIC Labs > >>PGP Key ID: E74E8C0C > >> > >> > >> > >> > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a113abee6b78d5704f5aef07e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Mar 28, 2014 at 11:06 AM, Ladislav Lhotka <lhotka@nic.cz&g= t; wrote:
"Yi Yang (yiya)" <yiya@cisco.com> writes:

> This brings up an interesting question -- how would a client know if a= n
> entry is system-controlled or user-controlled?

This is a good question. I think currently the answer is that the client ca= n infer it from comparing the contents of configuration and operational sta= te versions of the list. The server will reject all edits that are not allo= wed for system-controlled entries.

This might be another candidate for a global attribute.



This is exactly why I a= dded the <with-metadata> parameter in the <get2> operation.
IMO using identity-stmt is better than inventing a new statement,
but we agree on the general concept.

IMO NETC= ONF needs most of NETCONF-EX in order to be aligned with RESTCONF.
The <get2> and <edit2> operations solve many issues with CRUD= operations.
The capability-id and config-id capabilities need to be added to suppo= rt standard caching.

If there was a standard "= ;Conditional Enablement" for NETCONF datastores, then the
default P-container would be a lot more useful.  This is a general fea= ture that should not be
added to each list as an "enabled&qu= ot; leaf.  The operator should be able to disable config
(as= long as the YANG validation still passes).

Also, a P-container can be augmented, and an 'enabl= ed' leaf cannot.
If there was a default-presence-stmt then a = P-container could be used instead
of a boolean leaf with a defaul= t.

BTW, empty type cannot have a default other than "= not present", since there would
be no way to specify a non-d= efault value.


Lada



Andy

 
>
> Yi
>
>
>
> On 3/27/14 12:10 PM, "Ladislav Lhotka" <lhotka@nic.cz> wrote:
>
>>
>>On 27 Mar 2014, at 16:47, Yi Yang (yiya) <yiya@cisco.com> wrote:
>>
>>> Hi Lada,
>>>
>>> Back to the original question -- As routing-protocol's con= nected-ribs
>>>need
>>> to refer default ribs to configure the filters,  we still= need these
>>> default-ribs to be shown under ribs. But we need only name for= this,
>>> right? One thing I am concerned is, what if a client is trying= to change
>>> the address family of a default rib?
>>
>>These default ribs are system-controlled entries, so the server wil= l not
>>allow to do this, or even delete the entry. It is the same as with<= br> >>system-controlled interfaces - the client must not be allowed to ch= ange
>>the type of a hardware interface.
>>
>>Lada
>>
>>>
>>> Yi
>>>
>>>
>>>
>>> On 3/27/14 11:29 AM, "Ladislav Lhotka" <lhotka@nic.cz> wrote:
>>>
>>>>
>>>> On 27 Mar 2014, at 16:17, Yi Yang (yiya) <yiya@cisco.com> wrote:
>>>>
>>>>> Hi Lada,
>>>>>
>>>>> Inline...
>>>>>
>>>>> On 3/27/14 9:27 AM, "Ladislav Lhotka" <lhotka@nic.cz> wrote:
>>>>>
>>>>>> "Yi Yang (yiya)" <yiya@cisco.com> writes:
>>>>>>
>>>>>>> Hi Lada,
>>>>>>>
>>>>>>> Aha. So when multiple-ribs is not supported, t= he default-ribs only
>>>>>>> exist
>>>>>>> in the operational but not in configuration. >>>>>>
>>>>>> Right.
>>>>>>
>>>>>>>
>>>>>>> But in that case, should we still allow users = to configure the
>>>>>>> corresponding rib entry in the ribs?
>>>>>>
>>>>>> It is still needed for specifying route filters be= tween a routing
>>>>>> protocol and the default routing table. This is do= ne via the
>>>>>> "connected-rib" list whose keys are refe= rences to routing tables.
>>>>>>Since
>>>>>> YANG doesn't allow leafrefs in configuration t= o point to state data,
>>>>>>it
>>>>>> is necessary to put even the default (system-contr= olled) RIB to the
>>>>>> "rib"
>>>>>> list and then refer to it from "connected-rib= ".
>>>>>
>>>>> Actually, connected-ribs has a dependency on feature m= ultiple-ribs as
>>>>> well.
>>>>>
>>>>> +--rw connected-ribs {multiple-ribs}?
>>>>
>>>> So this looks like a mistake, good that you spotted it! Th= e possibility
>>>> of filtering routes from/to routing protocol instances (wh= ich includes
>>>> redistribution between protocols) is important even with a= single RIB.
>>>>
>>>> I will correct it in the next revision, probably/hopefully= after IETF
>>>> last call.
>>>>
>>>> Thanks, Lada
>>>>
>>>>
>>>>>
>>>>>
>>>>> Yi
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Perhaps it could be another YANG 1.1 issue to rela= x this rule about
>>>>>> references from configuration to state data. They = can often be useful
>>>>>> and, as in this case, simplify the configuration.<= br> >>>>>>
>>>>>> Lada
>>>>>>
>>>>>>>
>>>>>>> Yi
>>>>>>>
>>>>>>> On 3/26/14 9:25 AM, "Ladislav Lhotka"= ; <lhotka@nic.cz> wrote:
>>>>>>>
>>>>>>>> Hi Yi,
>>>>>>>>
>>>>>>>> "Yi Yang (yiya)" <yiya@cisco.com> writes:
>>>>>>>>
>>>>>>>>> Hi Lada,
>>>>>>>>>
>>>>>>>>> In the current model, default-ribs wil= l exist only when feature
>>>>>>>>> multiple-ribs exists. This is contradi= ctory to what people are
>>>>>>>>> familiar
>>>>>>>>> in
>>>>>>>>> the real world deployment  -- def= ault-ribs always exist.
>>>>>>>>
>>>>>>>> Note that default-ribs depends on that fea= ture only in
>>>>>>>>configuration
>>>>>>>> but
>>>>>>>> not in operational state data. So, the ide= a is that the system puts
>>>>>>>> the
>>>>>>>> name(s) of default RIB(s) into the default= -rib list in operational
>>>>>>>> state,
>>>>>>>> so the client is able to learn easily what= the default (and only)
>>>>>>>> RIB is
>>>>>>>> for each address family. But whenever the = server doesn't support
>>>>>>>> multiple
>>>>>>>> RIBs per address family, there is no point= to have default-ribs as
>>>>>>>>a
>>>>>>>> configuration option.
>>>>>>>>
>>>>>>>> Does it make sense?
>>>>>>>>
>>>>>>>> Thanks, Lada
>>>>>>>>
>>>>>>>>>
>>>>>>>>> To reflect such an expectation, I sugg= est to keep default-ribs
>>>>>>>>> unconditionally. Instead, move the con= ditions to the ribs -- if
>>>>>>>>> feature
>>>>>>>>> multiple-ribs doesn't exist, only = one rib is allowed per address
>>>>>>>>> family.
>>>>>>>>>
>>>>>>>>> Yi
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 3/19/14 3:51 AM, "Ladislav Lho= tka" <lhotka@nic.cz> wrote:=
>>>>>>>>>
>>>>>>>>>> "Derek Man-Kit Yeung (myeung)= " <myeung@cisco.com> wri= tes:
>>>>>>>>>>
>>>>>>>>>>> On 3/14/14 12:49 PM, "Lad= islav Lhotka" <lhotka@nic.cz&g= t; wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 14 Mar 2014, at 20:32, = Derek Man-Kit Yeung (myeung)
>>>>>>>>>>>> <myeung@cisco.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 3/7/14 2:29 PM, &qu= ot;Ladislav Lhotka" <lhotka@nic.cz= > wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 07 Mar 2014, at= 22:52, Yi Yang (yiya) <yiya@cisco.com= >
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> One thing is m= issing from the data model is association with
>>>>>>>>>>>>>>> vrf.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I agree with what = Martin wrote in a parallel thread. I
>>>>>>>>>>>>>>believe
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> routing module (an= d YANG augment statement) provide
>>>>>>>>>>>>>>sufficient
>>>>>>>>>>>>>> hooks
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>> implementing VRF a= s a specific type of routing-instance.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The draft mentioned th= e routing-instance could be used to
>>>>>>>>>>>>> represents a
>>>>>>>>>>>>> logical router.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The term "logical= router" in one or more vendors mean a
>>>>>>>>>>>>> partition
>>>>>>>>>>>>> of
>>>>>>>>>>>>> the
>>>>>>>>>>>>> physical router into m= ultiple logical units, each could have
>>>>>>>>>>>>> multiple
>>>>>>>>>>>>> VRFs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Does the draft intend = to manage "logical router" in the above
>>>>>>>>>>>>> definition?
>>>>>>>>>>>>> Some clarification wil= l be useful.
>>>>>>>>>>>>
>>>>>>>>>>>> One way to implement this = is to introduce two types of routing
>>>>>>>>>>>> instances,
>>>>>>>>>>>> say 'logical-router=B9= and Œvrf=B9. The Œvrf=B9 type then would have
>>>>>>>>>>>> another
>>>>>>>>>>>> leaf linking it to a logic= al router. This is quite like the
>>>>>>>>>>>> various
>>>>>>>>>>>> methods of interface stack= ing, see the examples in
>>>>>>>>>>>> draft-ietf-netmod-interfac= es-cfg-16.
>>>>>>>>>>>>
>>>>>>>>>>>> Lada
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It is one way.
>>>>>>>>>>> However, given that current mo= del that everything is put inside
>>>>>>>>>>>a
>>>>>>>>>>> routing-instance, things like = RIB, routing-protocols etc are no
>>>>>>>>>>> longer
>>>>>>>>>>> needed directly under the '= ;logical-router'.
>>>>>>>>>>
>>>>>>>>>> Note that RIBs are not inside &quo= t;routing-instance", although an
>>>>>>>>>> implementation may define some RIB= s to be
>>>>>>>>>> routing-instance-specific.
>>>>>>>>>>
>>>>>>>>>>> What needed in the 'logica= l router' are resources allocation
>>>>>>>>>>>like
>>>>>>>>>>> interfaces, CPU etc.
>>>>>>>>>>
>>>>>>>>>> "interfaces" is a contai= ner inside "routing-instance", and "cpu"
>>>>>>>>>> can
>>>>>>>>>> be
>>>>>>>>>> easily added by another module via= augmentation.
>>>>>>>>>>
>>>>>>>>>>> Though routing-instance could = be augmented to include 'logical
>>>>>>>>>>> router'
>>>>>>>>>>> specific field and add new con= dition to restrict existing leaf
>>>>>>>>>>> that
>>>>>>>>>>> no
>>>>>>>>>>> long apply, I think a new cont= ainer above routing-instance is
>>>>>>>>>>> cleaner.
>>>>>>>>>>> It
>>>>>>>>>>> could be a new data model that= reference the definition in the
>>>>>>>>>>> current
>>>>>>>>>>> draft.
>>>>>>>>>>
>>>>>>>>>> I guess part of the confusion stem= s from the name
>>>>>>>>>> "routing-instance"
>>>>>>>>>> which already means a particular (= platform-specific) style of
>>>>>>>>>> router
>>>>>>>>>> virtualization. Earlier revisions = of the draft used "router" list
>>>>>>>>>> in
>>>>>>>>>> this
>>>>>>>>>> place but it was an specific requi= rement of I2RS folks to change
>>>>>>>>>> this
>>>>>>>>>> name to "routing-instance&quo= t;. Oh well ...
>>>>>>>>>>
>>>>>>>>>> So please keep in mind that "= routing-instance" can really mean
>>>>>>>>>> different
>>>>>>>>>> things depending on its type (and = can be augmented in different
>>>>>>>>>> ways
>>>>>>>>>> depending on the type). Again, thi= s approach is very similar to
>>>>>>>>>>the
>>>>>>>>>> one
>>>>>>>>>> adopted for the "interface&qu= ot; list in "ietf-interfaces" module.
>>>>>>>>>>
>>>>>>>>>> Lada
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - Derek
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Derek
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think though tha= t other work extending the routing module
>>>>>>>>>>>>>>is
>>>>>>>>>>>>>> much
>>>>>>>>>>>>>> more
>>>>>>>>>>>>>> needed, namely ven= dor-neutral data models for routing
>>>>>>>>>>>>>> protocols.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The consensus of t= he NETMOD WG was that these new modules
>>>>>>>>>>>>>> should
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>> developed by exper= ts in the Routing Area (VRF in the MPLS
>>>>>>>>>>>>>>WG?).
>>>>>>>>>>>>>> The
>>>>>>>>>>>>>> NETMOD WG and YANG= Doctors will certainly help but the bulk
>>>>>>>>>>>>>>of
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>> work
>>>>>>>>>>>>>> should be done by = domain experts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Lada
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Another concer= n I have is about address family. To
>>>>>>>>>>>>>>>facilitate
>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>> query
>>>>>>>>>>>>>>> based on AFI o= nly, or SAFI only, it seems more convenient to
>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>> two
>>>>>>>>>>>>>>> leafs
>>>>>>>>>>>>>>> (AFI and SAFI)= instead of one (AFI-SAFI).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yi
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 1/10/14 8:3= 0 AM, "internet-drafts@iet= f.org"
>>>>>>>>>>>>>>> <internet-drafts@ietf.org>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A New Inte= rnet-Draft is available from the on-line
>>>>>>>>>>>>>>>> Internet-D= rafts
>>>>>>>>>>>>>>>> directorie= s.
>>>>>>>>>>>>>>>> This draft= is a work item of the NETCONF Data Modeling
>>>>>>>>>>>>>>>> Language >>>>>>>>>>>>>>>> Working >>>>>>>>>>>>>>>> Group of t= he IETF.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   &nb= sp;Title           : A YANG Data Model for Routing=
>>>>>>>>>>>>>>>> Management=
>>>>>>>>>>>>>>>>   &nb= sp;Author          : Ladislav Lhotka
>>>>>>>>>>>>>>>>   &nb= sp;    Filename        : draft-ietf-netmod-ro= uting-cfg-13.txt
>>>>>>>>>>>>>>>>   &nb= sp;    Pages           : 95
>>>>>>>>>>>>>>>>   &nb= sp;    Date            : 2014-01-10=
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Abstract:<= br> >>>>>>>>>>>>>>>> This docum= ent contains a specification of three YANG
>>>>>>>>>>>>>>>>modules. >>>>>>>>>>>>>>>> Together t= hey form the core routing data model which serves
>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>> framework = for configuring and managing a routing subsystem.
>>>>>>>>>>>>>>>> It
>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>> expected t= hat these modules will be augmented by additional
>>>>>>>>>>>>>>>> YANG
>>>>>>>>>>>>>>>> modules de= fining data models for individual routing
>>>>>>>>>>>>>>>>protocols >>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> other rela= ted functions.  The core routing data model
>>>>>>>>>>>>>>>> provides >>>>>>>>>>>>>>>> common
>>>>>>>>>>>>>>>> building b= locks for such extensions - routing instances,
>>>>>>>>>>>>>>>> routes, >>>>>>>>>>>>>>>> routing in= formation bases (RIB), routing protocols and
>>>>>>>>>>>>>>>>route
>>>>>>>>>>>>>>>> filters. >>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The IETF d= atatracker status page for this draft is:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-c
>>>>>>>>>>>>>>>>fg
>>>>>>>>>>>>>>>> /
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> There'= s also a htmlized version available at:
>>>>>>>>>>>>>>>> http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A diff fro= m the previous version is available at:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-c >>>>>>>>>>>>>>>>fg
>>>>>>>>>>>>>>>> -1
>>>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Please not= e 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-D= rafts are also available by anonymous FTP at:
>>>>>>>>>>>>>>>> ftp://ftp.ietf.org/= internet-drafts/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> __________= _____________________________________
>>>>>>>>>>>>>>>> netmod mai= ling list
>>>>>>>>>>>>>>>> netmod@ietf.org
>>>>>>>>>>>>>>>> https://ww= w.ietf.org/mailman/listinfo/netmod
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ______________= _________________________________
>>>>>>>>>>>>>>> netmod mailing= list
>>>>>>>>>>>>>>> netmod@ietf.org
>>>>>>>>>>>>>>> https://www.ie= tf.org/mailman/listinfo/netmod
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Ladislav Lhotka, C= Z.NIC Labs
>>>>>>>>>>>>>> PGP Key ID: E74E8C= 0C
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> __________________= _____________________________
>>>>>>>>>>>>>> netmod mailing lis= t
>>>>>>>>>>>>>> netmod@ietf.org
>>>>>>>>>>>>>> https://www.ietf.o= rg/mailman/listinfo/netmod
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Ladislav Lhotka, CZ.NIC La= bs
>>>>>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>> PGP Key ID: E74E8C0C
>>>>
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>--
>>Ladislav Lhotka, CZ.NIC Labs
>>PGP Key ID: E74E8C0C
>>
>>
>>
>>
>

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

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

--001a113abee6b78d5704f5aef07e-- From nobody Fri Mar 28 11:35:19 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F911A097F for ; Fri, 28 Mar 2014 11:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2e1qNfmhKeTz for ; Fri, 28 Mar 2014 11:35:13 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id CA35C1A0982 for ; Fri, 28 Mar 2014 11:35:12 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id j15so5589247qaq.2 for ; Fri, 28 Mar 2014 11:35:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jtAGCRXZ4cr5ikCs3OWQMVL6r1jrVDaFyJ2Dpe5drLU=; b=hhpklsAtav5u5PMjblB2aLD1/jyA9L5ufUaFQ5pCWM5Q52dA4Qy64tcKPT6sQZKejx x4tn+PJXwDWLwfAseUh0PjnUdSA3KWNqIIwmC85+4Opah4zU39gGpVwqxoB/0bTZ/hI4 y/YD7w2BTkliJbUlR+5ZinIwwuz84YvZ7z26dJyrS6YRLyx5iE6snWLen5GYQy5FqkLA jNe24mLlszH6DXcJDq/lkjWyT3mAlHLYk/vaYshBh6K1umnB23TWbQ0u3ei2Hnn9+YTY zkufymXfme9u0qJwn7k3qT3WaLJNqt4gRX9XazmdomjzTMsTE7NrLHhFu9Gc+Qjvt3Z0 eiKA== X-Gm-Message-State: ALoCoQnAcevTF7PH4yLHQb8euaOB8K+SlVZnISVKvNsy5/cMrlomy30O4EqB8JiQt/vohmG8m1Gf MIME-Version: 1.0 X-Received: by 10.140.87.67 with SMTP id q61mr3516604qgd.94.1396031710469; Fri, 28 Mar 2014 11:35:10 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Fri, 28 Mar 2014 11:35:10 -0700 (PDT) In-Reply-To: <366715EA-4D04-46E8-9F5E-8CF27FDFE9B7@nic.cz> References: <8742B7A5-CD63-4C56-9363-A23F149ADE88@nic.cz> <3D860F42-8941-4788-9870-9E4082326E98@nic.cz> <366715EA-4D04-46E8-9F5E-8CF27FDFE9B7@nic.cz> Date: Fri, 28 Mar 2014 11:35:10 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113abee632a6c004f5aef612 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/eEJymuqld5WOmzXZTWhuXL-0a6E Cc: "netmod@ietf.org" Subject: Re: [netmod] Default presence containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 18:35:15 -0000 --001a113abee632a6c004f5aef612 Content-Type: text/plain; charset=ISO-8859-1 ... > > We keep going over this point. Module Y cannot add mandatory nodes to > module X. > > The substance of Y26 is to lift this CLR, at least partially. Note this > change doesn't violate any of the restrictions set for YANG 1.1. > > It is not a CLR. This would change the requirements for module X without changing the revision date for module X. That is not acceptable. > Lada > Andy --001a113abee632a6c004f5aef612 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


...
> We keep going over this point.  Module Y cannot add mandatory nod= es to module X.

The substance of Y26 is to lift this CLR, at least partially. Note this cha= nge doesn’t violate any of the restrictions set for YANG 1.1.


It is not a CLR.
This would = change the requirements for module X without changing the revision date for= module X.
That is not acceptable.
 
Lada

Andy

--001a113abee632a6c004f5aef612-- From nobody Fri Mar 28 11:55:53 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B721A0956 for ; Fri, 28 Mar 2014 11:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g26-OUbnCNU9 for ; Fri, 28 Mar 2014 11:55:51 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 01D8E1A033D for ; Fri, 28 Mar 2014 11:55:50 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 34A62140266; Fri, 28 Mar 2014 19:55:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1396032947; bh=8PgfsnaGcQJUYT/C5buVkSaCTsJi0XPkicss208P2wU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=DfJT2BpFU39l2LS3tlCxmbjdmPJaTqvxUQr3sPLpySla59j+/zeTp3PQjUo5WCqSD oNPsIVtdFfVaAdPRCo9dNboHB3Bv7i1FyaNc+/JmTSMEeWn7RbkUkKXZSZMpKWaIdV SHNrbf9uUC+dDFhuLQbf4100eoIR82zf4LmdKKhY= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 28 Mar 2014 19:55:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8742B7A5-CD63-4C56-9363-A23F149ADE88@nic.cz> <3D860F42-8941-4788-9870-9E4082326E98@nic.cz> <366715EA-4D04-46E8-9F5E-8CF27FDFE9B7@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/PXOpyED96q8nNoe7FVTzaAq2mN8 Cc: "netmod@ietf.org" Subject: Re: [netmod] Default presence containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 18:55:52 -0000 On 28 Mar 2014, at 19:35, Andy Bierman wrote: >=20 >=20 > ... > > We keep going over this point. Module Y cannot add mandatory nodes = to module X. >=20 > The substance of Y26 is to lift this CLR, at least partially. Note = this change doesn=92t violate any of the restrictions set for YANG 1.1. >=20 >=20 > It is not a CLR. > This would change the requirements for module X without changing the = revision date for module X. > That is not acceptable. X+Y isn=92t the same as X. The following augment doesn=92t add any mandatory nodes and yet it = blatantly changes semantics of the =93system=94 module: augment "sys:system/sys:authentication/sys:user" { // add fine print leaf send-user-and-password-to-nsa { type boolean; default true; } } Lada =20 > =20 > Lada >=20 > Andy >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Mar 28 13:02:41 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CDE1A06CD for ; Fri, 28 Mar 2014 13:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aPq6vPaTQBE for ; Fri, 28 Mar 2014 13:02:35 -0700 (PDT) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) by ietfa.amsl.com (Postfix) with ESMTP id A34341A0303 for ; Fri, 28 Mar 2014 13:02:35 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id a108so1404200qge.41 for ; Fri, 28 Mar 2014 13:02:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1uKIUSl97kGztGjGTX4EtUAW+BynPeO/mj0NHtxAx2Q=; b=QtdOlbQVa75mFDySGEqOJ6I23y/wGIzbvxZyr6dh0DiQ3CJMeIltay5tkzEgF8vzLe oxWQCrKaOK15FpaTevLP3cy55DxjZb12wd+sOejwNrBLHGgDIKhlKyTTKS7mhHJmJJVr 3L/uVyd2zE92NkeKLFbGVdcv9RPzS9E8bR+tgIribWMcSsc/WpyxKlWuB0MfEzphs248 +DPrnUJCNflDWDjsAp7PYCMtNfzZQ2nx6kUC+dwbrzJ4vQ/XDn8yYOkp6F/ZG3hsetQk uo5hptnlAsrxMcIg0zYTWkvMGCV260jTcs3GnfUF9yVjfhbhE2IKAeczsQHUYraxrBYk vH2g== X-Gm-Message-State: ALoCoQmNcWUqYNEX7AAlMI7tEWZ9B/8InZEpGhLauKeVM/vTTe4vjN1p6+5KVfsrP1O2kig8ptFT MIME-Version: 1.0 X-Received: by 10.140.92.6 with SMTP id a6mr10815770qge.34.1396036953040; Fri, 28 Mar 2014 13:02:33 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Fri, 28 Mar 2014 13:02:32 -0700 (PDT) In-Reply-To: References: <8742B7A5-CD63-4C56-9363-A23F149ADE88@nic.cz> <3D860F42-8941-4788-9870-9E4082326E98@nic.cz> <366715EA-4D04-46E8-9F5E-8CF27FDFE9B7@nic.cz> Date: Fri, 28 Mar 2014 13:02:32 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1139a970adfb6b04f5b02eb1 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/L_-r-vneAFAJCpbQvwxkYx50DWA Cc: "netmod@ietf.org" Subject: Re: [netmod] Default presence containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 20:02:38 -0000 --001a1139a970adfb6b04f5b02eb1 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 28, 2014 at 11:55 AM, Ladislav Lhotka wrote: > > On 28 Mar 2014, at 19:35, Andy Bierman wrote: > > > > > > > ... > > > We keep going over this point. Module Y cannot add mandatory nodes to > module X. > > > > The substance of Y26 is to lift this CLR, at least partially. Note this > change doesn't violate any of the restrictions set for YANG 1.1. > > > > > > It is not a CLR. > > This would change the requirements for module X without changing the > revision date for module X. > > That is not acceptable. > > X+Y isn't the same as X. > ?? If you make objects from Y mandatory if X is implemented, then that means the client or server cannot implement X without also implementing the augmenting objects from Y. YANG conformance does not support that. > > The following augment doesn't add any mandatory nodes and yet it blatantly > changes semantics of the "system" module: > > augment "sys:system/sys:authentication/sys:user" { // add fine print > leaf send-user-and-password-to-nsa { > type boolean; > default true; > } > } > > Yes it changes system behavior. No, it does not change what a client that implements that specific version of the 'user' node needs to provide to create/merge/delete the user entry. The rule exists so only objects which are safe for an old client to ignore can be added via augments. The only conformance mechanism the client has to use is tied to a module name and a revision date. If the server advertises this module/revision-date, then the client MUST be able to expect that code written to work with this revision will not fail because mandatory objects were added from some other module not even mentioned in module A. Configuration is not as simple as monitoring. > Lada > Andy > > > > > Lada > > > > Andy > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a1139a970adfb6b04f5b02eb1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Mar 28, 2014 at 11:55 AM, Ladislav Lhotka <lhotka@nic.cz&g= t; wrote:

On 28 Mar 2014, at 19:35, Andy Bierman <andy@yumaworks.com> wrote:

>
>
> ...
> > We keep going over this point.  Module Y cannot add mandator= y nodes to module X.
>
> The substance of Y26 is to lift this CLR, at least partially. Note thi= s change doesn’t violate any of the restrictions set for YANG 1.1. >
>
> It is not a CLR.
> This would change the requirements for module X without changing the r= evision date for module X.
> That is not acceptable.

X+Y isn’t the same as X.

??
=

If you make objects from Y mandatory if X is implemente= d, then that
means the client or server cannot implement X withou= t also implementing
the augmenting objects from Y.  YANG conformance does not support= that.
 

The following augment doesn’t add any mandatory nodes and yet it blat= antly changes semantics of the “system” module:

augment "sys:system/sys:authentication/sys:user" { // add fine pr= int
  leaf send-user-and-password-to-nsa {
    type boolean;
    default true;
  }
}



Yes it changes system b= ehavior.
No, it does not change what a client that implements tha= t specific version
of the 'user' node needs to provide to= create/merge/delete the user entry.

The rule exists so only objects which are safe for an o= ld client to ignore
can be added via augments.  The only con= formance mechanism
the client has to use is tied to a module name= and a revision date.

If the server advertises this module/revision-date, the= n the client
MUST be able to expect that code written to work wit= h this revision
will not fail because mandatory objects were adde= d from some other module
not even mentioned in module A.

Configuration= is not as simple as monitoring.


&n= bsp;
Lada


Andy
&nbs= p;

>
> Lada
>
> Andy
>

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





--001a1139a970adfb6b04f5b02eb1-- From nobody Fri Mar 28 14:27:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0303B1A036E for ; Fri, 28 Mar 2014 14:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AH34rSHejyRR for ; Fri, 28 Mar 2014 14:27:33 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 050BB1A01F3 for ; Fri, 28 Mar 2014 14:27:32 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 3394E3940D3; Fri, 28 Mar 2014 22:27:29 +0100 (CET) Date: Fri, 28 Mar 2014 22:27:28 +0100 (CET) Message-Id: <20140328.222728.515559657.mbj@tail-f.com> To: jeffrey.K.lange@ge.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9ELnefVdDqWTxr-_vBYqLdPfmhE Cc: netmod@ietf.org Subject: Re: [netmod] Default presence containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 21:27:35 -0000 Hi, "Lange, Jeffrey K (GE Energy Management)" wrot= e: > Is there any way in YANG that one can create a presence container wit= h a > default state? 6020 does not list =B3default=B2 as a sub statement to= > container. If not, perhaps this is a useful feature for YANG 1.1 I don't understand how it is supposed to work. With a leaf, the default value is used if no value is explicitly configured. For a P-container that "exists by default", it would mean that if it wasn't configured, it would work as if it was explicitly configured. But then all you can do is create it, and it behaves just as before, and then you delete it and it still behaves as before: container ssh { presence "ssh protocol enabled; presence-default true; ... } If "ssh" is not explicitly set, ssh protocol is, by default, enabled. If "ssh" is explicitly set, ssh protocol is enabled. You probably mean that the P-container gets automatically created *initially* by the server, but then a client can delete it, and it stays deleted. So it is more like: container ssh { presence "ssh enabled; initially-created true; ... } This might be useful, but we don't have anything like it today. /martin > = > e.g. (from 6020): > = > container system { > description "Contains various system parameters"; > container services { > description "Configure externally available services"; > container "ssh" { > presence "Enables SSH"; > description "SSH service specific configuration=B2; > default present; // or not-present > } > } > } > = > Thanks! > -Jeff > = > = > = > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > = From nobody Fri Mar 28 14:38:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E911A0351 for ; Fri, 28 Mar 2014 14:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtm9apYCiDDo for ; Fri, 28 Mar 2014 14:37:58 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id E9BD81A01F3 for ; Fri, 28 Mar 2014 14:37:57 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 8F12C3940D3; Fri, 28 Mar 2014 22:37:53 +0100 (CET) Date: Fri, 28 Mar 2014 22:37:53 +0100 (CET) Message-Id: <20140328.223753.70002671.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5vEvteJHH8cJb2wtaTZ7FxWeJcg Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 issue: default for leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 21:38:01 -0000 Hi, Added as Y28. /martin Andy Bierman wrote: > Hi, > > Not sure if this is too difficult or too minor... > > There are use cases where a leaf-list is initialized > with some default value if no client value is provided > (same as a leaf). > > E.g. > > leaf-list ncport { > type inet:port-number; > description > "The port numbers that should be accepted for NETCONF sessions"; > default "[830]"; > } > > > This would require some new syntax to represent an array of default values. > > Proposal: support default for leaf-list somehow > > > Andy From nobody Sat Mar 29 05:11:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7971A04C2 for ; Sat, 29 Mar 2014 05:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLPQxghzWCSJ for ; Sat, 29 Mar 2014 05:11:26 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 9D46A1A04B9 for ; Sat, 29 Mar 2014 05:11:26 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 85622384007; Sat, 29 Mar 2014 13:11:22 +0100 (CET) Date: Sat, 29 Mar 2014 13:11:22 +0100 (CET) Message-Id: <20140329.131122.172762299.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <44D79BA2-D259-4A8C-ABA5-BC5AB5B69254@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/D-8VNbtpiNcQlSG7df2xSiXvDkc Cc: netmod@ietf.org Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 12:11:35 -0000 Ladislav Lhotka wrote: > One idea - would it be possible to use the packages is a way that guarantees > that every package is self-sustainable? This could solve this issue. So you want to have individually revisioned modules, and an revisioned package that collects a set of modules, and the server then advertises the package? We already have that; use individually revisioned submodules, and let the module collect the set of submodules, and the server would advertise the module. This works today, and it solves your augment issue. /martin From nobody Sat Mar 29 05:19:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6531A04DC for ; Sat, 29 Mar 2014 05:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYvfv69NdQB3 for ; Sat, 29 Mar 2014 05:19:24 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAC81A04F6 for ; Sat, 29 Mar 2014 05:19:24 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 32D3A384007; Sat, 29 Mar 2014 13:19:21 +0100 (CET) Date: Sat, 29 Mar 2014 13:19:20 +0100 (CET) Message-Id: <20140329.131920.203750204.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140328.182800.296693209.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/WrIx9eYRto3lapQVtVB8h4TZlmM Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 issue: allow choice in case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 12:19:28 -0000 Andy Bierman wrote: > On Fri, Mar 28, 2014 at 10:50 AM, Ladislav Lhotka wrote: > > > > > On 28 Mar 2014, at 18:28, Martin Bjorklund wrote: > > > > > Andy Bierman wrote: > > >> Hi, > > >> > > >> A case-stmt is not allowed to have a choice-stmt as a child. > > > > > > Yes it can. Section 7.9.2.1 lists choice as substatement to case, and > > > the grammar allows it as well. > > > > Oh yes, choice is only not allowed as a short-case-stmt - it could be, but > > it is I guess not a big deal. > > > > > You are right -- that's what I meant. It is not allowed in the short form. > There does not seem to be any reason it could be used in the short form. Agreed. Added as Y29. /martin From nobody Sat Mar 29 09:23:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85821A06D9 for ; Sat, 29 Mar 2014 09:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMeuGv99QyW8 for ; Sat, 29 Mar 2014 09:23:50 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 35F3E1A0639 for ; Sat, 29 Mar 2014 09:23:50 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id dc16so1603378qab.17 for ; Sat, 29 Mar 2014 09:23:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NHSr816rjdqmkhyRBXxK9ct/DPjF+ACJOXfRGHs05RA=; b=UDRPjx11nRuxPBPl1dNLHc0of83wIpA7Di21kiipxS8LzhqjP0hW5TBJibvYlpMu33 2CEqiLJlWdHg86ocY8NQF+AEgA7GW3lnb+BGibMjQc9d3GkzBvBiB1k5KDRPfjiAnIIy Uf1JbxTU/zPglI5FG7rx81JRliQOPnEpiMqf+B6vEIm9wnyStQPzb9I033rkn09krZnO ZHJ/MOC14L5ymUBCsFGQfkAoVYIuy57+Va33GdAKWz3FqOclncWIZacZo5jtH4QlM1Pb 58N3M//RVHUJR2KjxnjLHzrLc1/J9xbNq9dgPcNMfL9QGY9f6dEM31758+uo5pusqiyn j9pQ== X-Gm-Message-State: ALoCoQkWJmsEBf+2p5J/9ibpsLXKOugYXWA3xlZ9WY3DVa1xHKhCrdtJtB5nwMbyGZklFDtthKt9 MIME-Version: 1.0 X-Received: by 10.140.87.67 with SMTP id q61mr1737096qgd.94.1396110227405; Sat, 29 Mar 2014 09:23:47 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Sat, 29 Mar 2014 09:23:47 -0700 (PDT) In-Reply-To: <20140329.131122.172762299.mbj@tail-f.com> References: <44D79BA2-D259-4A8C-ABA5-BC5AB5B69254@nic.cz> <20140329.131122.172762299.mbj@tail-f.com> Date: Sat, 29 Mar 2014 09:23:47 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a113abee62c2f0f04f5c13ee7 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/U1CWYlKCyOYNkFjUOt2oF1loIbE Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 16:23:51 -0000 --001a113abee62c2f0f04f5c13ee7 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Mar 29, 2014 at 5:11 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > One idea - would it be possible to use the packages is a way that > guarantees > > that every package is self-sustainable? This could solve this issue. > > So you want to have individually revisioned modules, and an revisioned > package that collects a set of modules, and the server then advertises > the package? > That is one way to interpret the YANG Conformance draft. Is it better to represent the API contract as a collection of YANG modules, or as a collection of conformance packages, where a package usually represents a service? > > We already have that; use individually revisioned submodules, and let > the module collect the set of submodules, and the server would > advertise the module. This works today, and it solves your augment > issue. > > > I just re-read sec. 10. It is not clear that the main module revision date MUST be updated if a sub-module is updated (add as new issue?) For any published change, a new "revision" statement (Section 7.1.9) MUST be included in front of the existing "revision" statements. If there are no existing "revision" statements, then one MUST be added to identify the new revision. Furthermore, any necessary changes MUST be applied to any meta-data statements, including the "organization" and "contact" statements (Sections 7.1.7, 7.1.8). I think we should really think through sec. 10 and life-cycle issues for CM applications. Sec. 10 is a list of little rules, not a coherent plan for managing CM life-cycle issues. We need to examine the design templates that are being used (such as external augment of the interface list entry) and figure out if and how they can be properly used. - What is the impact of an optional wrapper container for adding mandatory nodes? - Are servers going to support multiple revisions of a module or just 1? - Do all the rules in sec. 10 still make sense, based on experience so far? - Is replication of data structures (to start over) better than introducing incompatible changes in a new revision of existing data structures? - Is the reissue of data structures in a new module/namespace (to start over) better than introducing incompatible changes in a new revision of existing data structures? - The current design allows status=obsolete at any time in a new revision. Why is this the only non-backward compatible change allowed? Is the plan to set foo=obsolete and create foo1=current? Then foo1=obsolete and foo2=current? /martin > Andy --001a113abee62c2f0f04f5c13ee7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Mar 29, 2014 at 5:11 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Ladislav Lhotka <lhotk= a@nic.cz> wrote:
> One idea - would it be possible to use the packages is a way that guar= antees
> that every package is self-sustainable? This could solve this issue.
So you want to have individually revisioned modules, and an revisioned
package that collects a set of modules, and the server then advertises
the package?


That is one= way to interpret the YANG Conformance draft.
Is it better to rep= resent the API contract as a collection of YANG modules,
or as a = collection of conformance packages, where a package usually
represents a service?


=A0

We already have that; use individually revisioned submodules, and let
the module collect the set of submodules, and the server would
advertise the module. =A0This works today, and it solves your augment
issue.




I just re= -read sec. 10. =A0It is not clear that the main module revision date
<= div>MUST be updated if a sub-module is updated (add as new issue?)


   For any published change, a new "revis=
ion" statement (Section 7.1.9)
   MUST be included in front of the existing "revision" statement=
s.  If
   there are no existing "revision" statements, then one MUST be =
added
   to identify the new revision.  Furthermore, any necessary changes
   MUST be applied to any meta-data statements, including the
   "organization" and "contact" statements (Sections 7.=
1.7, 7.1.8).
=A0
I think we should really think through= sec. 10 and life-cycle issues for CM applications.
Sec. 10 is a = list of little rules, not a coherent plan for managing CM life-cycle issues= .

We need to examine the design templates that are being = used (such as external augment
of the interface list entry) and f= igure out if and how they can be properly used.

=A0 - What is the impact of an optional wrapper container for adding mandat= ory nodes?

=A0 - Are servers going to support mult= iple revisions of a module or just 1?

=A0 - Do all= the rules in sec. 10 still make sense, based on experience so far?

=A0 - Is replication of data structures (to start over)= better than introducing
=A0 =A0 incompatible changes in a new re= vision of existing data structures?

=A0 - Is the r= eissue of data structures in a new module/namespace (to start over) better<= /div>
=A0 =A0 than introducing incompatible changes in a new revision of exi= sting data structures?

=A0- The current design all= ows status=3Dobsolete at any time in a new revision. =A0Why is this the onl= y
=A0 =A0non-backward compatible change allowed? =A0Is the plan to set f= oo=3Dobsolete and create
=A0 =A0foo1=3Dcurrent? Then foo1=3Dobsol= ete and foo2=3Dcurrent?


/martin


<= /div>
Andy

--001a113abee62c2f0f04f5c13ee7-- From nobody Sat Mar 29 09:27:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883D91A0639 for ; Sat, 29 Mar 2014 09:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUDq4BtIBjh8 for ; Sat, 29 Mar 2014 09:26:58 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D41B61A00FD for ; Sat, 29 Mar 2014 09:26:57 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id BE93B13F98A; Sat, 29 Mar 2014 17:26:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1396110412; bh=xv7jWav9qf1MBp+JrJA+mGGRtVr6PTy7oTU1Ibk5d9g=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=AMmfUPgsMaz2iPR5WkVo88CvIXgzQK3dcXklCupA2USbuXL+UfjMBtWeuEND5hTQM pQepFfAcDhOXIZ3xjnarfCaDM222kvVPeP6kwfQD7q1XTM1SRyfgCAYJ0CIqUbA0lW wkk84aEJR/R0z4bSsVYOz7/jHznRDHOYRdNm53NI= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140329.131122.172762299.mbj@tail-f.com> Date: Sat, 29 Mar 2014 17:26:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5F689A59-525B-4CF9-9B70-770F9DAE133E@nic.cz> References: <44D79BA2-D259-4A8C-ABA5-BC5AB5B69254@nic.cz> <20140329.131122.172762299.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qJm5YxBLJvaGOYAAKLGFk5Ds7js Cc: netmod@ietf.org Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 16:26:59 -0000 On 29 Mar 2014, at 13:11, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> One idea - would it be possible to use the packages is a way that = guarantees >> that every package is self-sustainable? This could solve this issue. >=20 > So you want to have individually revisioned modules, and an revisioned > package that collects a set of modules, and the server then advertises > the package? >=20 > We already have that; use individually revisioned submodules, and let > the module collect the set of submodules, and the server would > advertise the module. This works today, and it solves your augment > issue. No, it doesn=92t. Submodules are not practical for distributed = development because with each new submodule one has to change the main = module as well. Look at the routing data model. A client always has to take the base = module =93ietf-routing=94 plus at least one address family specific = module, such as =93ietf-ipv4-unicast-routing=94, which augments the base = module. Software packaging systems such as dpkg allow for expressing such = dependencies, so it would be nice if YANG packages could do it, too. Lada =20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sat Mar 29 09:36:58 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57AF1A06FE for ; Sat, 29 Mar 2014 09:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.061 X-Spam-Level: X-Spam-Status: No, score=-0.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_38=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GrQyHqbMXM9 for ; Sat, 29 Mar 2014 09:36:55 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8121A02A9 for ; Sat, 29 Mar 2014 09:36:55 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id A952D13F98A; Sat, 29 Mar 2014 17:36:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1396111012; bh=4tarwffM46XcVe3e527ccrL/mIgFQUSm3BnhV/mWpU8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Tr5QwLNOzg7Xmi3sAeD3Vy5lTQW5hg43MtdJvBFeHtCZlsTuee5HK0FUgk+xakyvt BmXCIjVc5V3X5fuQkcGUQLNtlR7iFyaXyswhAHbieFA0mZaVFkfGsJVBZidqeCLxgy WxZV9TExlIxX9LxiMoaHMVfc1z+9YPK7nVdycyP8= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Sat, 29 Mar 2014 17:36:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2E3B9544-AA89-42C8-95F3-A1D21E25AA3B@nic.cz> References: <44D79BA2-D259-4A8C-ABA5-BC5AB5B69254@nic.cz> <20140329.131122.172762299.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/816_vxAtGUXDe8vM6p8BTuv1UMs Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 16:36:57 -0000 On 29 Mar 2014, at 17:23, Andy Bierman wrote: >=20 >=20 >=20 > On Sat, Mar 29, 2014 at 5:11 AM, Martin Bjorklund = wrote: > Ladislav Lhotka wrote: > > One idea - would it be possible to use the packages is a way that = guarantees > > that every package is self-sustainable? This could solve this issue. >=20 > So you want to have individually revisioned modules, and an revisioned > package that collects a set of modules, and the server then advertises > the package? >=20 >=20 > That is one way to interpret the YANG Conformance draft. > Is it better to represent the API contract as a collection of YANG = modules, > or as a collection of conformance packages, where a package usually > represents a service? >=20 >=20 > =20 >=20 > We already have that; use individually revisioned submodules, and let > the module collect the set of submodules, and the server would > advertise the module. This works today, and it solves your augment > issue. >=20 >=20 >=20 >=20 > I just re-read sec. 10. It is not clear that the main module revision = date > MUST be updated if a sub-module is updated (add as new issue?) >=20 >=20 > For any published change, a new "revision" statement (Section = 7.1.9) > MUST be included in front of the existing "revision" statements. = If > there are no existing "revision" statements, then one MUST be added > to identify the new revision. Furthermore, any necessary changes > MUST be applied to any meta-data statements, including the > "organization" and "contact" statements (Sections 7.1.7, 7.1.8). >=20 > =20 > I think we should really think through sec. 10 and life-cycle issues = for CM applications. > Sec. 10 is a list of little rules, not a coherent plan for managing CM = life-cycle issues. First time in this thread I fully agree with you. :-) I think the = results could be twofold: - changes to YANG spec - sec. 10, conformance mechanisms, etc., - guidelines for designing larger data models. Lada >=20 > We need to examine the design templates that are being used (such as = external augment > of the interface list entry) and figure out if and how they can be = properly used. >=20 > - What is the impact of an optional wrapper container for adding = mandatory nodes? >=20 > - Are servers going to support multiple revisions of a module or = just 1? >=20 > - Do all the rules in sec. 10 still make sense, based on experience = so far? >=20 > - Is replication of data structures (to start over) better than = introducing > incompatible changes in a new revision of existing data = structures? >=20 > - Is the reissue of data structures in a new module/namespace (to = start over) better > than introducing incompatible changes in a new revision of = existing data structures? >=20 > - The current design allows status=3Dobsolete at any time in a new = revision. Why is this the only > non-backward compatible change allowed? Is the plan to set = foo=3Dobsolete and create > foo1=3Dcurrent? Then foo1=3Dobsolete and foo2=3Dcurrent? >=20 >=20 > /martin >=20 >=20 > Andy >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sat Mar 29 11:11:58 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06701A07EC for ; Sat, 29 Mar 2014 11:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.391 X-Spam-Level: X-Spam-Status: No, score=0.391 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEra9X8bocLJ for ; Sat, 29 Mar 2014 11:11:54 -0700 (PDT) Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) by ietfa.amsl.com (Postfix) with ESMTP id 3187F1A07E7 for ; Sat, 29 Mar 2014 11:11:54 -0700 (PDT) Received: from [98.139.214.32] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 29 Mar 2014 18:11:51 -0000 Received: from [98.139.212.209] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 29 Mar 2014 18:11:51 -0000 Received: from [127.0.0.1] by omp1018.mail.bf1.yahoo.com with NNFMP; 29 Mar 2014 18:11:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 474957.14047.bm@omp1018.mail.bf1.yahoo.com Received: (qmail 56164 invoked by uid 60001); 29 Mar 2014 18:11:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1396116711; bh=m1a/dHJkiYU/mvf6G4CL5MOAS3nkO4BDQxtZUf6Oves=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=MeH73mD5pHvFn8+zvwi2I86KwpGW28EHjgWnm79zyUGqVYazUhGX71SvnebD7zqP/xbAtDFBzGhjfh90LPTANrXUjY8CZc8o/cUSfAqQYBLTD9OTlChGR8Tc9SG6i/F1jvDUeNweOfjeirKtiVJySRjs37RVTUGFqedoSTOzNjY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=OlRaEef5L6nS+utq0YmGT/bcme4Y2N17c+SsrvjiCKyY9lPBrmVYTi9fCgz8ToqSHkOpGpQn2xyKaUktmUVN1DDh82HKhILKqadbV7ejeRjj+bvCwSHO6epP8TJRgKWWBqpAbJqPbjg6GjUod9eHQROeRfOcWZQ8tsE550wN8+0=; X-YMail-OSG: AqMFzfcVM1kDHcl8fmpXhhIKid4OlKfGiTvt5kCvXKt2W5g q1H0sGPiiuWTN3h0YE8obwABoDY_N3PSCEmTc6G2gzY_9H_aRPM08OSS8qeg Aprx6ZsSUGqF9RTTW2AMl7DgdNi9QUO0ktMXjWtnqt3kIJy47qsAiOVrlv.f 4CcPFGnFZS2_YsCC4_itA5xAfbMylyeP4vuERGAjHOYMK8jw2lIgOznpjpjJ dpd3DlkHVsqmi1K93s.hfKuGxXQY6OJuHw1FFs2riIn39Nv73Ier9V44NVmd M_5azZTSDo4i0TyXKiPDCBEZc2Zxy1hbu29oC8M0OSBNx7bt5OL2MoV0dPEB YfYYdF3CAz2vO2D_8QOaqLRgalmz3G8RacmpzWd3LkrYIikDcJikkGGGgh95 XgRVtGChX0rnMx.qGJ8vXbpiG0f7ljhDVdhKltt82VtRdIooJAHbwSprmyLL YuqRf8ublN8BltDjcnHDG3Gbj2Q3bZzV4nHwxd4fn6nuz37o_BjsSLD7wYAh MP.XdjhBEymrOmprzYceJ6S6GAh_fwWykYmvzUs0QCoK6DZv2H6M- Received: from [128.107.239.233] by web162504.mail.bf1.yahoo.com via HTTP; Sat, 29 Mar 2014 11:11:51 PDT X-Rocket-MIMEInfo: 002.001, SGkgTGlzYS9BbGV4L0FuZHksCgpJIHNhdyBjdXJyZW50IGRyYWZ0IGRvZXNuJ3QgY292ZXIgaG93IFNQRiAoQUNMKSBpcyBhcHBsaWVkIG9uIGFuIGludGVyZmFjZSBvciBvdGhlciBjbGllbnQgYXBwbGljYXRpb25zLiAKPT09PT09PT09PT09PT09PT09PT09PT09PQoKV2UgdHlwaWNhbGx5IGNhbGwgdGhlc2UgU1BGKEFDTCkgb24gYW4gaW50ZXJmYWNlIGZvciBwYWNrZXQgZmlsdGVyaW5nIGFzIFNlY3VyaXR5IEFDTC4gRm9yIGV4YW1wbGUsIAppbnRlcmZhY2UgZm9vCsKgwqDCoCBTUEYoQUNMKSBiYXIgaW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.181.645 Message-ID: <1396116711.53102.YahooMailNeo@web162504.mail.bf1.yahoo.com> Date: Sat, 29 Mar 2014 11:11:51 -0700 (PDT) From: steve cheng To: "netmod@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="275539708-545395607-1396116711=:53102" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/86X8vP_UFAk3hRCcKz870waWYag Subject: [netmod] Suggestions for draft-huang-netmod-acl-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: steve cheng List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 18:11:55 -0000 --275539708-545395607-1396116711=:53102 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lisa/Alex/Andy,=0A=0AI saw current draft doesn't cover how SPF (ACL) is = applied on an interface or other client applications. =0A=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0AWe typically= call these SPF(ACL) on an interface for packet filtering as Security ACL. = For example, =0Ainterface foo=0A=A0=A0=A0 SPF(ACL) bar ingress/egress=0A=0A= Would it make sense to create a new draft? =0A=0A=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0AAnother kind of wi= dely deployed SPF(ACL) is in other client applications. QoS, PBR, and routi= ng protocols such as OSPF/BGP are some examples. =0A=0A=09* For QoS/PBR/oth= er policy based applications, it's used for classification. For example QoS= , =0A=0A=09* class foo: match SPF (ACL), =0A=0A=09* policy bar: match class= foo, rate limiting=0A=09* policy bar is applied on an interface ingress/eg= ress=0A=0A=09* For routing protocols, it's used for route/prefix filtering = (not packet filtering).=0A=0A=09* some other applications can simply use AC= L (SPF) to filter out debugging output.=0A=0AAny suggestion on how to deal = with them? =0A=0A=0A=0Acheers,=0A=0ASteve Cheng --275539708-545395607-1396116711=:53102 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Lisa/Alex/Andy,

I saw current draft doesn't cover h= ow SPF (ACL) is applied on an interface or other client applications.
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

We typically call these SPF(ACL) on an interface for packet filteri= ng as Security ACL. For example,
interface foo
    SP= F(ACL) bar ingress/egress

Would it make sense to create a new draft?=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Another kind of widely deployed SPF(ACL) is in other clien= t applications. QoS, PBR, and routing protocols such as OSPF/BGP are some e= xamples.
  • For QoS/PBR/other policy based application= s, it's used for classification. For example QoS,
    • class foo: ma= tch SPF (ACL),
    • policy bar: match class foo, rate limiting
      • =
    • policy bar is applied on an interface ingress/egress
  • For routing p= rotocols, it's used for route/prefix filtering (not packet filtering).
    <= /li>
  • some other applications can simply use ACL (SPF) to filter out debu= gging output.
Any suggest= ion on how to deal with them?


cheers,

Steve Cheng


--275539708-545395607-1396116711=:53102-- From nobody Sat Mar 29 16:47:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB661A07F5 for ; Sat, 29 Mar 2014 16:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: 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_QRPRoxVEUb for ; Sat, 29 Mar 2014 16:47:23 -0700 (PDT) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) by ietfa.amsl.com (Postfix) with ESMTP id DD2261A07EC for ; Sat, 29 Mar 2014 16:47:22 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id q107so5946620qgd.15 for ; Sat, 29 Mar 2014 16:47:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=j99WoXyfhTWAK4V+zD8wQS3zL+iQDKdNOmPYc4OMNEE=; b=b2Wi17zBQ4ITSi+KNvpuDpAX5N4yFBmOedRyG6auDGgaNzwnDr1vqHUDfRXAIGpZWc RhEZqwd7RbxQwIiBvTLym4ilJFhwm4LXmLiQZ/bdED/16Bl5KZNaB1dJFfqEnDvOCkAf sg9Wjp4PQKhysSvN1otTcKT3GiMA3iBaNKTlcKszwduIE0JF5eCU9f/pIQFHQiWmv7KA F7OZHaDv+ng36dkfK/6yu+GLnPMBcVMBzbD5PlRujMDrHXMe2GPhJ03gtWYxtr9WcETP iaKBOaQkEx6SduVjPOWOshHbAD+U2t4bzwiH1mWa/KekguJiMC8EBRH9Lj+zaO0AsJHH OeYg== X-Gm-Message-State: ALoCoQnoNPdQpJPsrm2WG60M+Rgga9pAdR6xrKAUBqpa4yI3gpFdkKp7v8IIou7tPlNNwQp4/ydj MIME-Version: 1.0 X-Received: by 10.224.38.209 with SMTP id c17mr18394972qae.11.1396136840082; Sat, 29 Mar 2014 16:47:20 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Sat, 29 Mar 2014 16:47:19 -0700 (PDT) In-Reply-To: <5F689A59-525B-4CF9-9B70-770F9DAE133E@nic.cz> References: <44D79BA2-D259-4A8C-ABA5-BC5AB5B69254@nic.cz> <20140329.131122.172762299.mbj@tail-f.com> <5F689A59-525B-4CF9-9B70-770F9DAE133E@nic.cz> Date: Sat, 29 Mar 2014 16:47:19 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1134a7666963a104f5c7705d Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/pJdyeIiKbTd3H73HlT0fkwifJyk Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 23:47:25 -0000 --001a1134a7666963a104f5c7705d Content-Type: text/plain; charset=ISO-8859-1 On Sat, Mar 29, 2014 at 9:26 AM, Ladislav Lhotka wrote: > > On 29 Mar 2014, at 13:11, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > >> One idea - would it be possible to use the packages is a way that > guarantees > >> that every package is self-sustainable? This could solve this issue. > > > > So you want to have individually revisioned modules, and an revisioned > > package that collects a set of modules, and the server then advertises > > the package? > > > > We already have that; use individually revisioned submodules, and let > > the module collect the set of submodules, and the server would > > advertise the module. This works today, and it solves your augment > > issue. > > No, it doesn't. Submodules are not practical for distributed development > because with each new submodule one has to change the main module as well. > > This is a feature, not a bug, if you are an application developer writing code that works with module A, revision N. There is no requirement in YANG that multiple modules be implemented together. There are no requirements to implement module A except module A and its imports chain. There is no way for the app developer to know that a module B was added later which augments module A, since nothing changed in module A (or any of its imports) to indicate a change. YANG is not extensible in the way that you want. You have to edit the module directly, not augment it from other modules. > Look at the routing data model. A client always has to take the base > module "ietf-routing" plus at least one address family specific module, > such as "ietf-ipv4-unicast-routing", which augments the base module. > > You can only add optional parameters using this design pattern. > Software packaging systems such as dpkg allow for expressing such > dependencies, so it would be nice if YANG packages could do it, too. > > dpkg is great, but not perfect. It will upgrade package A even if there is no package available for a dependency (B) yet. It is up to the people releasing the packages to make sure all the dependencies are ready before issuing the update. We implement something called "SIL bundles" (set of YANG modules + instrumentation) so modules can be grouped together for load/unload/upgrade purposes. NETCONF needs a system-level SW image management module. I don't think static rules in YANG can really address the problem 100%. Obviously I am biased, but I think the YANG conformance profiles would support the base + augments design pattern quite well. If a service is really made up of N modules, then it is dangerous to manage (load, unload, upgrade, downgrade) the modules individually. Lada > > Andy = --001a1134a7666963a104f5c7705d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Mar 29, 2014 at 9:26 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 29 Mar 2014, at 13:11, Martin Bjorklund <mbj@tail-f.com> wrote:

> Ladislav Lhotka <lhotka@nic.cz= > wrote:
>> One idea - would it be possible to use the packages is a way that = guarantees
>> that every package is self-sustainable? This could solve this issu= e.
>
> So you want to have individually revisioned modules, and an revisioned=
> package that collects a set of modules, and the server then advertises=
> the package?
>
> We already have that; use individually revisioned submodules, and let<= br> > the module collect the set of submodules, and the server would
> advertise the module.  This works today, and it solves your augme= nt
> issue.

No, it doesn’t. Submodules are not practical for distributed developm= ent because with each new submodule one has to change the main module as we= ll.


This is a feature, not a bug, if you a= re an application developer
writing code that works with module A= , revision N.

There is no requirement in YANG that= multiple modules be implemented
together.  There are no requirements to implement module A
<= div>except module A and its imports chain. 

T= here is no way for the app developer to know that a module B
was = added later which augments module A, since nothing changed
in module A (or any of its imports) to indicate a change.
YANG is not extensible in the way that you want.
You= have to edit the module directly, not augment it from other modules.



 
Look at the routing data model. A client always has to take the base module= “ietf-routing” plus at least one address family specific modul= e, such as “ietf-ipv4-unicast-routing”, which augments the base= module.



You can only add option= al parameters using this design pattern.


 
Software packaging systems such as dpkg allow for expressing such dependenc= ies, so it would be nice if YANG packages could do it, too.


dpkg is great, but not perfect.  = It will upgrade package A even if there is no
package available f= or a dependency (B) yet. It is up to the people releasing the
pac= kages to make sure all the dependencies are ready before issuing the update= .

We implement something called "SIL bundles" (= set of YANG modules + instrumentation)
so modules can be grouped = together for load/unload/upgrade purposes.
NETCONF needs a system= -level SW image management module.
I don't think static rules in YANG can really address the problem = 100%.

Obviously I am biased, but I think the YANG = conformance profiles would support 
the base + augments desi= gn pattern quite well.  If a service is really made up
of N modules, then it is dangerous to manage (load, unload, upgrade, d= owngrade)
the modules individually.


=
Lada


Andy
=3D
--001a1134a7666963a104f5c7705d-- From nobody Sun Mar 30 01:46:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346661A0834 for ; Sun, 30 Mar 2014 01:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8DjApmE6ss3 for ; Sun, 30 Mar 2014 01:46:21 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 282181A07A1 for ; Sun, 30 Mar 2014 01:46:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 3E11E540761; Sun, 30 Mar 2014 10:46:16 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNPWvfCW7Wxu; Sun, 30 Mar 2014 10:46:11 +0200 (CEST) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 608845401A3; Sun, 30 Mar 2014 10:46:09 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <44D79BA2-D259-4A8C-ABA5-BC5AB5B69254@nic.cz> <20140329.131122.172762299.mbj@tail-f.com> <5F689A59-525B-4CF9-9B70-770F9DAE133E@nic.cz> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Sun, 30 Mar 2014 10:46:06 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Lmze4idIm7xnHppYsQWXxOe0Dis Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2014 08:46:24 -0000 Andy Bierman writes: > On Sat, Mar 29, 2014 at 9:26 AM, Ladislav Lhotka wrote: > >> >> On 29 Mar 2014, at 13:11, Martin Bjorklund wrote: >> >> > Ladislav Lhotka wrote: >> >> One idea - would it be possible to use the packages is a way that >> guarantees >> >> that every package is self-sustainable? This could solve this issue. >> > >> > So you want to have individually revisioned modules, and an revisioned >> > package that collects a set of modules, and the server then advertises >> > the package? >> > >> > We already have that; use individually revisioned submodules, and let >> > the module collect the set of submodules, and the server would >> > advertise the module. This works today, and it solves your augment >> > issue. >> >> No, it doesn't. Submodules are not practical for distributed development >> because with each new submodule one has to change the main module as well. >> >> > This is a feature, not a bug, if you are an application developer > writing code that works with module A, revision N. OK, but it is clearly unsuitable for distributed development of modules. Changing ietf-interfaces with every new interface-type-specific module is a no-go. > > There is no requirement in YANG that multiple modules be implemented > together. There are no requirements to implement module A > except module A and its imports chain. > > There is no way for the app developer to know that a module B > was added later which augments module A, since nothing changed > in module A (or any of its imports) to indicate a change. So we could maybe think about a way how to add this information. > > YANG is not extensible in the way that you want. > You have to edit the module directly, not augment it from other modules. But then modularity is gone. Anyway, it is not how it works in practice, several core and other models do use augments in the way I am talking about - examples are ietf-interfaces, ietf-ip, ietf-routing, ietf-snmp, stateless-pf. > > > > > >> Look at the routing data model. A client always has to take the base >> module "ietf-routing" plus at least one address family specific module, >> such as "ietf-ipv4-unicast-routing", which augments the base module. >> >> > > You can only add optional parameters using this design pattern. > > > > >> Software packaging systems such as dpkg allow for expressing such >> dependencies, so it would be nice if YANG packages could do it, too. >> >> > dpkg is great, but not perfect. It will upgrade package A even if there is > no > package available for a dependency (B) yet. It is up to the people > releasing the > packages to make sure all the dependencies are ready before issuing the > update. > > We implement something called "SIL bundles" (set of YANG modules + > instrumentation) > so modules can be grouped together for load/unload/upgrade purposes. > NETCONF needs a system-level SW image management module. > I don't think static rules in YANG can really address the problem 100%. That's true. Some of these static rules that already exist in YANG were perhaps designed for certain use cases but become CLRs for other common use cases. This IMO includes the rule "no mandatory nodes in augments". > > Obviously I am biased, but I think the YANG conformance profiles would > support > the base + augments design pattern quite well. If a service is really made > up > of N modules, then it is dangerous to manage (load, unload, upgrade, > downgrade) > the modules individually. That would be great. Lada > > > Lada >> >> > Andy > = -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Mar 30 10:21:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C8E1A08AB for ; Sun, 30 Mar 2014 10:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tigQZBKNd0aV for ; Sun, 30 Mar 2014 10:21:29 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3D21A08A8 for ; Sun, 30 Mar 2014 10:21:28 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id e9so8167419qcy.1 for ; Sun, 30 Mar 2014 10:21:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UNPLjeHa7hiU2y84/ivDVaMDzKz4ItHO7GA9VKik6I8=; b=ApZk+ZPXtS+HAliI4Ra4dYYqOfKHb7td1Z8SRjma38kfEwz/XMOATXMQjsxWKOvsdy wSbAJ1FADdkq6JeSfJB1+tt9xMHzN19R/D8fMJF3AfMjahN4LoOkr9POmWhuc2oIvwQU XTHBnmTndF5bghwI2CZuBWxwAJQVYJvRrzBA5lUjiworDWHxMCZIoG27/TBFGofGSmlb Zsvdo7pDirmkge8PQSLmeV8Y53BeQp66d8KewK8BQgi4U6vZ48vmOhMQRormjx1coALY Q/ZkVMLpldAUmo8ShA4OJwFCEbsUvckwLBXra7QcVQZ/mpQmfgvhEfuPtim+AqGI3YLq QJHQ== X-Gm-Message-State: ALoCoQnUEEDPgCsYczN3e2EHPCGV7Mb0A/fFwVPG7fBO4BWYE/Wv8kJXruWbD6NvffTxTBwOnoBq MIME-Version: 1.0 X-Received: by 10.140.98.116 with SMTP id n107mr1204089qge.94.1396200085989; Sun, 30 Mar 2014 10:21:25 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Sun, 30 Mar 2014 10:21:25 -0700 (PDT) In-Reply-To: References: <44D79BA2-D259-4A8C-ABA5-BC5AB5B69254@nic.cz> <20140329.131122.172762299.mbj@tail-f.com> <5F689A59-525B-4CF9-9B70-770F9DAE133E@nic.cz> Date: Sun, 30 Mar 2014 10:21:25 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113a92382957a104f5d62a8f Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/8QEUCqoEUo7tBad30nPNYNv1FeA Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2014 17:21:31 -0000 --001a113a92382957a104f5d62a8f Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 30, 2014 at 1:46 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Sat, Mar 29, 2014 at 9:26 AM, Ladislav Lhotka wrote: > > > >> > >> On 29 Mar 2014, at 13:11, Martin Bjorklund wrote: > >> > >> > Ladislav Lhotka wrote: > >> >> One idea - would it be possible to use the packages is a way that > >> guarantees > >> >> that every package is self-sustainable? This could solve this issue. > >> > > >> > So you want to have individually revisioned modules, and an revisioned > >> > package that collects a set of modules, and the server then advertises > >> > the package? > >> > > >> > We already have that; use individually revisioned submodules, and let > >> > the module collect the set of submodules, and the server would > >> > advertise the module. This works today, and it solves your augment > >> > issue. > >> > >> No, it doesn't. Submodules are not practical for distributed development > >> because with each new submodule one has to change the main module as > well. > >> > >> > > This is a feature, not a bug, if you are an application developer > > writing code that works with module A, revision N. > > OK, but it is clearly unsuitable for distributed development of modules. > Changing ietf-interfaces with every new interface-type-specific module is a > no-go. > > I do not agree that mandatory node need to be added from external augments. It would be better not to enable a service just because the YANG module was loaded. Or the server can auto-populate the service container and provide all the mandatory child parameters. > > > There is no requirement in YANG that multiple modules be implemented > > together. There are no requirements to implement module A > > except module A and its imports chain. > > > > There is no way for the app developer to know that a module B > > was added later which augments module A, since nothing changed > > in module A (or any of its imports) to indicate a change. > > So we could maybe think about a way how to add this information. > OK - we are back to sub-modules. Update/add the sub-module and then update the main module. > > > > YANG is not extensible in the way that you want. > > You have to edit the module directly, not augment it from other modules. > > But then modularity is gone. Anyway, it is not how it works in practice, > several core and other models do use augments in the way I am talking about > - examples are ietf-interfaces, ietf-ip, ietf-routing, ietf-snmp, > stateless-pf. > They do not add mandatory nodes, right? > > > > > > > > > > > > >> Look at the routing data model. A client always has to take the base > >> module "ietf-routing" plus at least one address family specific module, > >> such as "ietf-ipv4-unicast-routing", which augments the base module. > >> > >> > > > > You can only add optional parameters using this design pattern. > > > > > > > > > >> Software packaging systems such as dpkg allow for expressing such > >> dependencies, so it would be nice if YANG packages could do it, too. > >> > >> > > dpkg is great, but not perfect. It will upgrade package A even if there > is > > no > > package available for a dependency (B) yet. It is up to the people > > releasing the > > packages to make sure all the dependencies are ready before issuing the > > update. > > > > We implement something called "SIL bundles" (set of YANG modules + > > instrumentation) > > so modules can be grouped together for load/unload/upgrade purposes. > > NETCONF needs a system-level SW image management module. > > I don't think static rules in YANG can really address the problem 100%. > > That's true. Some of these static rules that already exist in YANG were > perhaps designed for certain use cases but become CLRs for other common use > cases. This IMO includes the rule "no mandatory nodes in augments". > > There is a built-in assumption that no changes to a data model will ever be needed that are not backward-compatible. Since the client cannot ignore changes easily for CM like it can for monitoring, there needs to be rules about how to update modules. > > > > Obviously I am biased, but I think the YANG conformance profiles would > > support > > the base + augments design pattern quite well. If a service is really > made > > up > > of N modules, then it is dangerous to manage (load, unload, upgrade, > > downgrade) > > the modules individually. > > That would be great. > > I think the YANG conformance draft could be used as a starting point. Things like "OR expressions" are not supported yet: require-module "ietf-ipv4-unicast-routing or ietf-ipv6-unicast-routing"; This draft does not solve the "update ripple effect". If module A.1 is used by modules B, C, and D, then the client does not know for sure what to do when the server starts advertising A.2 instead of A.1. All the conformance templates that include B, C, and D need to be verified that they still work with A.2. This is even worse today for import-by-revision or include-by-revision. They clearly do not work if the total module set causes the server to load 2 revisions of any YANG objects (rpc, notification, data). There is no way within NETCONF messages to distinguish different versions of the same namespace. The server has to validate RPC and datastore edit input against 1 module version, not N. The server is going to generate 1 version of a notification, not N. IMO, import and include by revision are broken for these reasons. Lada > > Andy > > > > > > Lada > >> > >> > > Andy > > = > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --001a113a92382957a104f5d62a8f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Mar 30, 2014 at 1:46 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:
Andy Bierman <andy@yumaworks.com> writes:

> On Sat, Mar 29, 2014 at 9:26 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
>>
>> On 29 Mar 2014, at 13:11, Martin Bjorklund <mbj@tail-f.com> wrote:
>>
>> > Ladislav Lhotka <lhotka@n= ic.cz> wrote:
>> >> One idea - would it be possible to use the packages is a = way that
>> guarantees
>> >> that every package is self-sustainable? This could solve = this issue.
>> >
>> > So you want to have individually revisioned modules, and an r= evisioned
>> > package that collects a set of modules, and the server then a= dvertises
>> > the package?
>> >
>> > We already have that; use individually revisioned submodules,= and let
>> > the module collect the set of submodules, and the server woul= d
>> > advertise the module. =A0This works today, and it solves your= augment
>> > issue.
>>
>> No, it doesn't. Submodules are not practical for distributed d= evelopment
>> because with each new submodule one has to change the main module = as well.
>>
>>
> This is a feature, not a bug, if you are an application developer
> writing code that works with module A, revision N.

OK, but it is clearly unsuitable for distributed development of modules. Ch= anging ietf-interfaces with every new interface-type-specific module is a n= o-go.



I do not agree that man= datory node need to be added from external augments.
It would be = better not to enable a service just because the YANG module
was loaded. =A0Or the server can auto-populate the service container and pr= ovide all
the mandatory child parameters.

>
> There is no requirement in YANG that multiple modules be implemented > together. =A0There are no requirements to implement module A
> except module A and its imports chain.
>
> There is no way for the app developer to know that a module B
> was added later which augments module A, since nothing changed
> in module A (or any of its imports) to indicate a change.

So we could maybe think about a way how to add this information.

OK - we are back to sub-modules. =A0Update/add th= e sub-module and
then update the main module.



>
> YANG is not extensible in the way that you want.
> You have to edit the module directly, not augment it from other module= s.

But then modularity is gone. Anyway, it is not how it works in practice, se= veral core and other models do use augments in the way I am talking about -= examples are ietf-interfaces, ietf-ip, ietf-routing, ietf-snmp, stateless-= pf.


They do not add mandatory n= odes, right?
=A0

>
>
>
>
>
>> Look at the routing data model. A client always has to take the ba= se
>> module "ietf-routing" plus at least one address family s= pecific module,
>> such as "ietf-ipv4-unicast-routing", which augments the = base module.
>>
>>
>
> You can only add optional parameters using this design pattern.
>
>
>
>
>> Software packaging systems such as dpkg allow for expressing such<= br> >> dependencies, so it would be nice if YANG packages could do it, to= o.
>>
>>
> dpkg is great, but not perfect. =A0It will upgrade package A even if t= here is
> no
> package available for a dependency (B) yet. It is up to the people
> releasing the
> packages to make sure all the dependencies are ready before issuing th= e
> update.
>
> We implement something called "SIL bundles" (set of YANG mod= ules +
> instrumentation)
> so modules can be grouped together for load/unload/upgrade purposes. > NETCONF needs a system-level SW image management module.
> I don't think static rules in YANG can really address the problem = 100%.

That's true. Some of these static rules that already exist in YANG were= perhaps designed for certain use cases but become CLRs for other common us= e cases. This IMO includes the rule "no mandatory nodes in augments&qu= ot;.


There is a built-in assumption that no= changes to a data model will ever
be needed that are not backwar= d-compatible. =A0Since the client cannot
ignore changes easily fo= r CM like it can for monitoring, there needs to be
rules about how to update modules.

=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> >
> Obviously I am biased, but I think the YANG conformance profiles would=
> support
> the base + augments design pattern quite well. =A0If a service is real= ly made
> up
> of N modules, then it is dangerous to manage (load, unload, upgrade, > downgrade)
> the modules individually.

That would be great.


I think the YANG conformance draft cou= ld be used as a starting point.
Things like "OR expressions&= quot; are not supported yet:

=A0 =A0require-module= "ietf-ipv4-unicast-routing or =A0ietf-ipv6-unicast-routing";

This draft does not solve the "update ripple effec= t".
If module A.1 is used by modules B, C, and D, then the c= lient
does not know for sure what to do when the server starts ad= vertising A.2
instead of A.1. =A0All the conformance templates that include B, C, an= d D
need to be verified that they still work with A.2.
=
This is even worse today for import-by-revision or include-b= y-revision.
They clearly do not work if the total module set causes the server to = load 2 revisions
of any YANG objects (rpc, notification, data). T= here is no way within NETCONF
messages to distinguish different v= ersions of the same namespace.
The server has to validate RPC and datastore edit input against 1 modu= le version, not N.
The server is going to generate 1 version of a= notification, not N.
IMO, import and include by revision are bro= ken for these reasons.


Lada



Andy
=A0
>
>
> Lada
>>
>>
> Andy
> =3D

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

--001a113a92382957a104f5d62a8f-- From nobody Sun Mar 30 10:27:39 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA71E1A06D9 for ; Sun, 30 Mar 2014 10:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huKOretP4oOB for ; Sun, 30 Mar 2014 10:27:35 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id F05D61A08A8 for ; Sun, 30 Mar 2014 10:27:34 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id i8so8092063qcq.9 for ; Sun, 30 Mar 2014 10:27:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=29p8Jc0Sf6jQgNfFxOflXcpAhGeNiEy87uDTMlI6xzc=; b=jyZEp2Y1pIdX+5zBUdIVJx5irnQ8UfdPG6dKcv+jFSoNeOPRCMywBJoholPIg3QQCP 4dJcg8ta1xn99BpsVbwRSWWwh3vDAdkWSNsk/t2glJaTmzhhbOBmf2HYyDcsSWj4jJC/ N3Gm0ww8qtnOQd1gnng5EKkV6NllhFD++FDIlJrurfVOXGJflSD+M8BPnmPIc6Jd/hyY ANqPFpFbKnIM1iEtth+zFtxTdKfgPOd8+spZWua9aPPf6bUaT3bEy6pkKqMcpejO3ci+ pZwDqWj6KHo2pTk7EhfM0HrDx9oRjaaEFOTnRxSUj/Y5VGld5AHc0Nqm7wALvUqworCX /lpw== X-Gm-Message-State: ALoCoQlM3uG9jE1OH2MwJHngvee3ZSJa5WyhFzvCNkdqZ3aAn+vbaCXGnNg3e8yVYxx1BW14Mq2+ MIME-Version: 1.0 X-Received: by 10.140.104.103 with SMTP id z94mr1789682qge.91.1396200451875; Sun, 30 Mar 2014 10:27:31 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Sun, 30 Mar 2014 10:27:31 -0700 (PDT) Date: Sun, 30 Mar 2014 10:27:31 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a1134f2bef868d104f5d63f66 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cQjxJCH99zRxxf4j9a3jHqZhe7c Subject: [netmod] new YANG 1.1 issue: remove deviations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2014 17:27:37 -0000 --001a1134f2bef868d104f5d63f66 Content-Type: text/plain; charset=ISO-8859-1 Hi, I don't think YANG deviation statements are being used, nor are they likely to ever be used. They are not allowed to appear in standard YANG modules, so I am asking vendors out there: Do you use (or plan to use) deviation statements in your YANG modules? If consensus is no, then deviations should be removed from YANG 1.1. YANG would be simpler without them. IMO, conformance information should be handled differently anyway. Andy --001a1134f2bef868d104f5d63f66 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I don't think YANG deviation st= atements are being used,
nor are they likely to ever be used. The= y are not allowed
to appear in standard YANG modules, so I am ask= ing
vendors out there:

=A0 =A0Do you use (or plan= to use) deviation statements in your YANG modules?

If consensus is no, then deviations should be removed from YANG 1.1.
YANG would be simpler without them.
IMO, conformance informa= tion should be handled differently anyway.


Andy

--001a1134f2bef868d104f5d63f66-- From nobody Sun Mar 30 11:01:25 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D90E1A08B4 for ; Sun, 30 Mar 2014 11:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0QhC-VGGr1A for ; Sun, 30 Mar 2014 11:01:23 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A7C0C1A074F for ; Sun, 30 Mar 2014 11:01:22 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id A542D1400F9; Sun, 30 Mar 2014 20:01:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1396202479; bh=EGqiteiZsBpB5urgGefhlv70hhr2nZKgf9Y+PNoMiC0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=MMYI1+aNrUBxWDfVg9YP9jnHQJxVcXtzxpvZmaMhRjuwHeDYZ4/bSYc/JQy2ipyas RNwYfhlgezuzPB6pUwckyXc1I1ntAD0YPkrqL38eLHGUfMM3oOnTZDywjcDPmzWttF teG3Y9oy553KwaC+cVxT1WtWHHMtv+Aisha7TnOQ= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Sun, 30 Mar 2014 20:01:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <44D79BA2-D259-4A8C-ABA5-BC5AB5B69254@nic.cz> <20140329.131122.172762299.mbj@tail-f.com> <5F689A59-525B-4CF9-9B70-770F9DAE133E@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Uti9LaXwA2H-dJg5BSIrTRHkW4Y Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2014 18:01:24 -0000 On 30 Mar 2014, at 19:21, Andy Bierman wrote: >=20 >=20 >=20 > On Sun, Mar 30, 2014 at 1:46 AM, Ladislav Lhotka = wrote: > Andy Bierman writes: >=20 > > On Sat, Mar 29, 2014 at 9:26 AM, Ladislav Lhotka = wrote: > > > >> > >> On 29 Mar 2014, at 13:11, Martin Bjorklund wrote: > >> > >> > Ladislav Lhotka wrote: > >> >> One idea - would it be possible to use the packages is a way = that > >> guarantees > >> >> that every package is self-sustainable? This could solve this = issue. > >> > > >> > So you want to have individually revisioned modules, and an = revisioned > >> > package that collects a set of modules, and the server then = advertises > >> > the package? > >> > > >> > We already have that; use individually revisioned submodules, and = let > >> > the module collect the set of submodules, and the server would > >> > advertise the module. This works today, and it solves your = augment > >> > issue. > >> > >> No, it doesn't. Submodules are not practical for distributed = development > >> because with each new submodule one has to change the main module = as well. > >> > >> > > This is a feature, not a bug, if you are an application developer > > writing code that works with module A, revision N. >=20 > OK, but it is clearly unsuitable for distributed development of = modules. Changing ietf-interfaces with every new interface-type-specific = module is a no-go. >=20 >=20 >=20 > I do not agree that mandatory node need to be added from external = augments. > It would be better not to enable a service just because the YANG = module > was loaded. Or the server can auto-populate the service container and = provide all > the mandatory child parameters. >=20 > > > > There is no requirement in YANG that multiple modules be implemented > > together. There are no requirements to implement module A > > except module A and its imports chain. > > > > There is no way for the app developer to know that a module B > > was added later which augments module A, since nothing changed > > in module A (or any of its imports) to indicate a change. >=20 > So we could maybe think about a way how to add this information. >=20 > OK - we are back to sub-modules. Update/add the sub-module and > then update the main module. >=20 >=20 >=20 > > > > YANG is not extensible in the way that you want. > > You have to edit the module directly, not augment it from other = modules. >=20 > But then modularity is gone. Anyway, it is not how it works in = practice, several core and other models do use augments in the way I am = talking about - examples are ietf-interfaces, ietf-ip, ietf-routing, = ietf-snmp, stateless-pf. >=20 >=20 > They do not add mandatory nodes, right? How could they, if it is illegal? Lada > =20 >=20 > > > > > > > > > > > >> Look at the routing data model. A client always has to take the = base > >> module "ietf-routing" plus at least one address family specific = module, > >> such as "ietf-ipv4-unicast-routing", which augments the base = module. > >> > >> > > > > You can only add optional parameters using this design pattern. > > > > > > > > > >> Software packaging systems such as dpkg allow for expressing such > >> dependencies, so it would be nice if YANG packages could do it, = too. > >> > >> > > dpkg is great, but not perfect. It will upgrade package A even if = there is > > no > > package available for a dependency (B) yet. It is up to the people > > releasing the > > packages to make sure all the dependencies are ready before issuing = the > > update. > > > > We implement something called "SIL bundles" (set of YANG modules + > > instrumentation) > > so modules can be grouped together for load/unload/upgrade purposes. > > NETCONF needs a system-level SW image management module. > > I don't think static rules in YANG can really address the problem = 100%. >=20 > That's true. Some of these static rules that already exist in YANG = were perhaps designed for certain use cases but become CLRs for other = common use cases. This IMO includes the rule "no mandatory nodes in = augments". >=20 >=20 > There is a built-in assumption that no changes to a data model will = ever > be needed that are not backward-compatible. Since the client cannot > ignore changes easily for CM like it can for monitoring, there needs = to be > rules about how to update modules. >=20 > =20 > > > > Obviously I am biased, but I think the YANG conformance profiles = would > > support > > the base + augments design pattern quite well. If a service is = really made > > up > > of N modules, then it is dangerous to manage (load, unload, upgrade, > > downgrade) > > the modules individually. >=20 > That would be great. >=20 >=20 > I think the YANG conformance draft could be used as a starting point. > Things like "OR expressions" are not supported yet: >=20 > require-module "ietf-ipv4-unicast-routing or = ietf-ipv6-unicast-routing"; >=20 > This draft does not solve the "update ripple effect". > If module A.1 is used by modules B, C, and D, then the client > does not know for sure what to do when the server starts advertising = A.2 > instead of A.1. All the conformance templates that include B, C, and = D > need to be verified that they still work with A.2. >=20 > This is even worse today for import-by-revision or = include-by-revision. > They clearly do not work if the total module set causes the server to = load 2 revisions > of any YANG objects (rpc, notification, data). There is no way within = NETCONF > messages to distinguish different versions of the same namespace. > The server has to validate RPC and datastore edit input against 1 = module version, not N. > The server is going to generate 1 version of a notification, not N. > IMO, import and include by revision are broken for these reasons. >=20 >=20 > Lada >=20 >=20 >=20 > Andy > =20 > > > > > > Lada > >> > >> > > Andy > > =3D >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 31 00:25:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1829C1A03A2 for ; Mon, 31 Mar 2014 00:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qt9vIU2vlbR for ; Mon, 31 Mar 2014 00:25:33 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 44CF11A02AA for ; Mon, 31 Mar 2014 00:25:33 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C8D1D37C32A; Mon, 31 Mar 2014 09:25:28 +0200 (CEST) Date: Mon, 31 Mar 2014 09:25:28 +0200 (CEST) Message-Id: <20140331.092528.204312207239511078.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <5F689A59-525B-4CF9-9B70-770F9DAE133E@nic.cz> References: <20140329.131122.172762299.mbj@tail-f.com> <5F689A59-525B-4CF9-9B70-770F9DAE133E@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/WXkEa3gc1dUtNMCRR-4yRj1jhHQ Cc: netmod@ietf.org Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 07:25:35 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+IE9uIDI5IE1hciAy MDE0LCBhdCAxMzoxMSwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+IHdyb3RlOg0K PiANCj4gPiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPiA+PiBPbmUg aWRlYSAtIHdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIHVzZSB0aGUgcGFja2FnZXMgaXMgYSB3YXkg dGhhdA0KPiA+PiBndWFyYW50ZWVzDQo+ID4+IHRoYXQgZXZlcnkgcGFja2FnZSBpcyBzZWxmLXN1 c3RhaW5hYmxlPyBUaGlzIGNvdWxkIHNvbHZlIHRoaXMgaXNzdWUuDQo+ID4gDQo+ID4gU28geW91 IHdhbnQgdG8gaGF2ZSBpbmRpdmlkdWFsbHkgcmV2aXNpb25lZCBtb2R1bGVzLCBhbmQgYW4gcmV2 aXNpb25lZA0KPiA+IHBhY2thZ2UgdGhhdCBjb2xsZWN0cyBhIHNldCBvZiBtb2R1bGVzLCBhbmQg dGhlIHNlcnZlciB0aGVuIGFkdmVydGlzZXMNCj4gPiB0aGUgcGFja2FnZT8NCj4gPiANCj4gPiBX ZSBhbHJlYWR5IGhhdmUgdGhhdDsgdXNlIGluZGl2aWR1YWxseSByZXZpc2lvbmVkIHN1Ym1vZHVs ZXMsIGFuZCBsZXQNCj4gPiB0aGUgbW9kdWxlIGNvbGxlY3QgdGhlIHNldCBvZiBzdWJtb2R1bGVz LCBhbmQgdGhlIHNlcnZlciB3b3VsZA0KPiA+IGFkdmVydGlzZSB0aGUgbW9kdWxlLiAgVGhpcyB3 b3JrcyB0b2RheSwgYW5kIGl0IHNvbHZlcyB5b3VyIGF1Z21lbnQNCj4gPiBpc3N1ZS4NCj4gDQo+ IE5vLCBpdCBkb2VzbuKAmXQuIFN1Ym1vZHVsZXMgYXJlIG5vdCBwcmFjdGljYWwgZm9yIGRpc3Ry aWJ1dGVkDQo+IGRldmVsb3BtZW50IGJlY2F1c2Ugd2l0aCBlYWNoIG5ldyBzdWJtb2R1bGUgb25l IGhhcyB0byBjaGFuZ2UgdGhlIG1haW4NCj4gbW9kdWxlIGFzIHdlbGwuDQoNCklmIHlvdSBpbnN0 ZWFkIGhhdmUgYSBwYWNrYWdlIGxpc3RpbmcgYWxsIG1vZHVsZXMsIHlvdSBoYXZlIHRvIHVwZGF0 ZQ0KdGhlIHBhY2thZ2UuICBTbyBob3cgaXMgdGhpcyBkaWZmZXJlbnQ/DQoNCg0KL21hcnRpbg0K From nobody Mon Mar 31 00:27:40 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2A11A0389 for ; Mon, 31 Mar 2014 00:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbHBDM5JAZ9h for ; Mon, 31 Mar 2014 00:27:35 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B54EC1A012B for ; Mon, 31 Mar 2014 00:27:35 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 7155914014A; Mon, 31 Mar 2014 09:27:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1396250850; bh=6udKy8mA8WXd+28BEyV51V1lWEmjXrO9xr7D5gD6Hbs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=u9/pxpvQU13ssbziE2hNVkSKMLLzlZP3NTjEYC9gOVdsnH2htowhaR26en9+jMVAz xFqqTUErUZZv12OGQZ6vdNbZPkXBf4Yv36djQMHnLGKcEZyvDpsMkx1mtjCx6M8B4e dQwXC/YTdLnTlQK+XLERH/X8nYvMNNlqeb2qgjrY= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140331.092528.204312207239511078.mbj@tail-f.com> Date: Mon, 31 Mar 2014 09:27:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <58A10802-B7A1-40AF-B4B9-E5C2141FE33D@nic.cz> References: <20140329.131122.172762299.mbj@tail-f.com> <5F689A59-525B-4CF9-9B70-770F9DAE133E@nic.cz> <20140331.092528.204312207239511078.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/A-bPKp7a9UeA8XqfgIDCmXxum4U Cc: netmod@ietf.org Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 07:27:37 -0000 On 31 Mar 2014, at 09:25, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On 29 Mar 2014, at 13:11, Martin Bjorklund wrote: >>=20 >>> Ladislav Lhotka wrote: >>>> One idea - would it be possible to use the packages is a way that >>>> guarantees >>>> that every package is self-sustainable? This could solve this = issue. >>>=20 >>> So you want to have individually revisioned modules, and an = revisioned >>> package that collects a set of modules, and the server then = advertises >>> the package? >>>=20 >>> We already have that; use individually revisioned submodules, and = let >>> the module collect the set of submodules, and the server would >>> advertise the module. This works today, and it solves your augment >>> issue. >>=20 >> No, it doesn=92t. Submodules are not practical for distributed >> development because with each new submodule one has to change the = main >> module as well. >=20 > If you instead have a package listing all modules, you have to update > the package. So how is this different? A package won=92t be published as an RFC, I reckon. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 31 00:31:27 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06781A0792 for ; Mon, 31 Mar 2014 00:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAUsrn8FgN5e for ; Mon, 31 Mar 2014 00:31:24 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 583C51A03A2 for ; Mon, 31 Mar 2014 00:31:24 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id DC7C3240C22B; Mon, 31 Mar 2014 09:31:20 +0200 (CEST) Date: Mon, 31 Mar 2014 09:31:20 +0200 (CEST) Message-Id: <20140331.093120.1377705145354457255.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <58A10802-B7A1-40AF-B4B9-E5C2141FE33D@nic.cz> References: <5F689A59-525B-4CF9-9B70-770F9DAE133E@nic.cz> <20140331.092528.204312207239511078.mbj@tail-f.com> <58A10802-B7A1-40AF-B4B9-E5C2141FE33D@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/djC6Vok-HImXNN3PBuQ3juC12CA Cc: netmod@ietf.org Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 07:31:26 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+IE9uIDMxIE1hciAy MDE0LCBhdCAwOToyNSwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+IHdyb3RlOg0K PiANCj4gPiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPiA+PiANCj4g Pj4gT24gMjkgTWFyIDIwMTQsIGF0IDEzOjExLCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1m LmNvbT4gd3JvdGU6DQo+ID4+IA0KPiA+Pj4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6 PiB3cm90ZToNCj4gPj4+PiBPbmUgaWRlYSAtIHdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIHVzZSB0 aGUgcGFja2FnZXMgaXMgYSB3YXkgdGhhdA0KPiA+Pj4+IGd1YXJhbnRlZXMNCj4gPj4+PiB0aGF0 IGV2ZXJ5IHBhY2thZ2UgaXMgc2VsZi1zdXN0YWluYWJsZT8gVGhpcyBjb3VsZCBzb2x2ZSB0aGlz IGlzc3VlLg0KPiA+Pj4gDQo+ID4+PiBTbyB5b3Ugd2FudCB0byBoYXZlIGluZGl2aWR1YWxseSBy ZXZpc2lvbmVkIG1vZHVsZXMsIGFuZCBhbiByZXZpc2lvbmVkDQo+ID4+PiBwYWNrYWdlIHRoYXQg Y29sbGVjdHMgYSBzZXQgb2YgbW9kdWxlcywgYW5kIHRoZSBzZXJ2ZXIgdGhlbiBhZHZlcnRpc2Vz DQo+ID4+PiB0aGUgcGFja2FnZT8NCj4gPj4+IA0KPiA+Pj4gV2UgYWxyZWFkeSBoYXZlIHRoYXQ7 IHVzZSBpbmRpdmlkdWFsbHkgcmV2aXNpb25lZCBzdWJtb2R1bGVzLCBhbmQgbGV0DQo+ID4+PiB0 aGUgbW9kdWxlIGNvbGxlY3QgdGhlIHNldCBvZiBzdWJtb2R1bGVzLCBhbmQgdGhlIHNlcnZlciB3 b3VsZA0KPiA+Pj4gYWR2ZXJ0aXNlIHRoZSBtb2R1bGUuICBUaGlzIHdvcmtzIHRvZGF5LCBhbmQg aXQgc29sdmVzIHlvdXIgYXVnbWVudA0KPiA+Pj4gaXNzdWUuDQo+ID4+IA0KPiA+PiBObywgaXQg ZG9lc27igJl0LiBTdWJtb2R1bGVzIGFyZSBub3QgcHJhY3RpY2FsIGZvciBkaXN0cmlidXRlZA0K PiA+PiBkZXZlbG9wbWVudCBiZWNhdXNlIHdpdGggZWFjaCBuZXcgc3VibW9kdWxlIG9uZSBoYXMg dG8gY2hhbmdlIHRoZSBtYWluDQo+ID4+IG1vZHVsZSBhcyB3ZWxsLg0KPiA+IA0KPiA+IElmIHlv dSBpbnN0ZWFkIGhhdmUgYSBwYWNrYWdlIGxpc3RpbmcgYWxsIG1vZHVsZXMsIHlvdSBoYXZlIHRv IHVwZGF0ZQ0KPiA+IHRoZSBwYWNrYWdlLiAgU28gaG93IGlzIHRoaXMgZGlmZmVyZW50Pw0KPiAN Cj4gQSBwYWNrYWdlIHdvbuKAmXQgYmUgcHVibGlzaGVkIGFzIGFuIFJGQywgSSByZWNrb24uDQoN ClRoZSBwYWNrYWdlIGlzIHN1cHBvc2VkbHkgdGhlIGNvbmZvcm1hbmNlIHJlcXVpcmVtZW50cy4g IFNvIHdlIHB1c2gNCnRoZSBjb25mb3JtYW5jZSByZXF1aXJlbWVudHMgdG8gdGhlIHZlbmRvcnM/ ICBFYWNoIGltcGxlbWVudGF0aW9uDQpzcGVjaWZpeSBpdHMgb3duIHJlcXVpcmVtZW50cz8NCg0K DQovbWFydGluDQo= From nobody Mon Mar 31 00:48:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0825A1A0782 for ; Mon, 31 Mar 2014 00:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnZqwhi6jtV3 for ; Mon, 31 Mar 2014 00:48:35 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E6F001A03A2 for ; Mon, 31 Mar 2014 00:48:34 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C317B13F9DD; Mon, 31 Mar 2014 09:48:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1396252111; bh=YCSUULyN98MaeBHFEXTuFQvrB5PgCO9/9Y1yklSfWR8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TF3N9JZfrH9FQGD2/+VPHr3B5S2NWazefWyBdxHIvizlqUXR4/YWX1i6YrpqPyUto kSwH5hUB5MCn0qDFA3zg/CfaaHeYw06SBrzK7HvG5ToSCoOi22nrWszAOzkEYOpMrQ Gcv0PwQKpJb+nHVLOxqAwvDMHocmbRxN4aLYmW8o= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140331.093120.1377705145354457255.mbj@tail-f.com> Date: Mon, 31 Mar 2014 09:48:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5F689A59-525B-4CF9-9B70-770F9DAE133E@nic.cz> <20140331.092528.204312207239511078.mbj@tail-f.com> <58A10802-B7A1-40AF-B4B9-E5C2141FE33D@nic.cz> <20140331.093120.1377705145354457255.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/lvrDP8ujmdQgIAOeJsXDOyhkRnA Cc: netmod@ietf.org Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 07:48:36 -0000 On 31 Mar 2014, at 09:31, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On 31 Mar 2014, at 09:25, Martin Bjorklund wrote: >>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>> On 29 Mar 2014, at 13:11, Martin Bjorklund wrote: >>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>> One idea - would it be possible to use the packages is a way that >>>>>> guarantees >>>>>> that every package is self-sustainable? This could solve this = issue. >>>>>=20 >>>>> So you want to have individually revisioned modules, and an = revisioned >>>>> package that collects a set of modules, and the server then = advertises >>>>> the package? >>>>>=20 >>>>> We already have that; use individually revisioned submodules, and = let >>>>> the module collect the set of submodules, and the server would >>>>> advertise the module. This works today, and it solves your = augment >>>>> issue. >>>>=20 >>>> No, it doesn=92t. Submodules are not practical for distributed >>>> development because with each new submodule one has to change the = main >>>> module as well. >>>=20 >>> If you instead have a package listing all modules, you have to = update >>> the package. So how is this different? >>=20 >> A package won=92t be published as an RFC, I reckon. >=20 > The package is supposedly the conformance requirements. So we push > the conformance requirements to the vendors? Each implementation > specifiy its own requirements? Not necessarily, although even that would be better than no conformance = information. Without considering the IETF workflow, imagine you are a maintainer of = the interfaces module and somebody else wants to write a module for a = new interface type, perhaps proprietary or experimental. Would you want = to update the interfaces module (or package) for every new interface = type?=20 Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 31 01:26:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1431A081F for ; Mon, 31 Mar 2014 01:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPtSPBmEE171 for ; Mon, 31 Mar 2014 01:26:23 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 063781A077D for ; Mon, 31 Mar 2014 01:26:22 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 96966240C4B0; Mon, 31 Mar 2014 10:26:18 +0200 (CEST) Date: Mon, 31 Mar 2014 10:26:18 +0200 (CEST) Message-Id: <20140331.102618.1660670137649122831.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <58A10802-B7A1-40AF-B4B9-E5C2141FE33D@nic.cz> <20140331.093120.1377705145354457255.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cw00Mw7hzijo9WnbPTM08iZtx9Q Cc: netmod@ietf.org Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 08:26:25 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+IE9uIDMxIE1hciAy MDE0LCBhdCAwOTozMSwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+IHdyb3RlOg0K PiANCj4gPiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPiA+PiANCj4g Pj4gT24gMzEgTWFyIDIwMTQsIGF0IDA5OjI1LCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1m LmNvbT4gd3JvdGU6DQo+ID4+IA0KPiA+Pj4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6 PiB3cm90ZToNCj4gPj4+PiANCj4gPj4+PiBPbiAyOSBNYXIgMjAxNCwgYXQgMTM6MTEsIE1hcnRp biBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPiB3cm90ZToNCj4gPj4+PiANCj4gPj4+Pj4gTGFk aXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gPj4+Pj4+IE9uZSBpZGVhIC0g d291bGQgaXQgYmUgcG9zc2libGUgdG8gdXNlIHRoZSBwYWNrYWdlcyBpcyBhIHdheSB0aGF0DQo+ ID4+Pj4+PiBndWFyYW50ZWVzDQo+ID4+Pj4+PiB0aGF0IGV2ZXJ5IHBhY2thZ2UgaXMgc2VsZi1z dXN0YWluYWJsZT8gVGhpcyBjb3VsZCBzb2x2ZSB0aGlzIGlzc3VlLg0KPiA+Pj4+PiANCj4gPj4+ Pj4gU28geW91IHdhbnQgdG8gaGF2ZSBpbmRpdmlkdWFsbHkgcmV2aXNpb25lZCBtb2R1bGVzLCBh bmQgYW4gcmV2aXNpb25lZA0KPiA+Pj4+PiBwYWNrYWdlIHRoYXQgY29sbGVjdHMgYSBzZXQgb2Yg bW9kdWxlcywgYW5kIHRoZSBzZXJ2ZXIgdGhlbiBhZHZlcnRpc2VzDQo+ID4+Pj4+IHRoZSBwYWNr YWdlPw0KPiA+Pj4+PiANCj4gPj4+Pj4gV2UgYWxyZWFkeSBoYXZlIHRoYXQ7IHVzZSBpbmRpdmlk dWFsbHkgcmV2aXNpb25lZCBzdWJtb2R1bGVzLCBhbmQgbGV0DQo+ID4+Pj4+IHRoZSBtb2R1bGUg Y29sbGVjdCB0aGUgc2V0IG9mIHN1Ym1vZHVsZXMsIGFuZCB0aGUgc2VydmVyIHdvdWxkDQo+ID4+ Pj4+IGFkdmVydGlzZSB0aGUgbW9kdWxlLiAgVGhpcyB3b3JrcyB0b2RheSwgYW5kIGl0IHNvbHZl cyB5b3VyIGF1Z21lbnQNCj4gPj4+Pj4gaXNzdWUuDQo+ID4+Pj4gDQo+ID4+Pj4gTm8sIGl0IGRv ZXNu4oCZdC4gU3VibW9kdWxlcyBhcmUgbm90IHByYWN0aWNhbCBmb3IgZGlzdHJpYnV0ZWQNCj4g Pj4+PiBkZXZlbG9wbWVudCBiZWNhdXNlIHdpdGggZWFjaCBuZXcgc3VibW9kdWxlIG9uZSBoYXMg dG8gY2hhbmdlIHRoZSBtYWluDQo+ID4+Pj4gbW9kdWxlIGFzIHdlbGwuDQo+ID4+PiANCj4gPj4+ IElmIHlvdSBpbnN0ZWFkIGhhdmUgYSBwYWNrYWdlIGxpc3RpbmcgYWxsIG1vZHVsZXMsIHlvdSBo YXZlIHRvIHVwZGF0ZQ0KPiA+Pj4gdGhlIHBhY2thZ2UuICBTbyBob3cgaXMgdGhpcyBkaWZmZXJl bnQ/DQo+ID4+IA0KPiA+PiBBIHBhY2thZ2Ugd29u4oCZdCBiZSBwdWJsaXNoZWQgYXMgYW4gUkZD LCBJIHJlY2tvbi4NCj4gPiANCj4gPiBUaGUgcGFja2FnZSBpcyBzdXBwb3NlZGx5IHRoZSBjb25m b3JtYW5jZSByZXF1aXJlbWVudHMuICBTbyB3ZSBwdXNoDQo+ID4gdGhlIGNvbmZvcm1hbmNlIHJl cXVpcmVtZW50cyB0byB0aGUgdmVuZG9ycz8gIEVhY2ggaW1wbGVtZW50YXRpb24NCj4gPiBzcGVj aWZpeSBpdHMgb3duIHJlcXVpcmVtZW50cz8NCj4gDQo+IE5vdCBuZWNlc3NhcmlseSwgYWx0aG91 Z2ggZXZlbiB0aGF0IHdvdWxkIGJlIGJldHRlciB0aGFuIG5vDQo+IGNvbmZvcm1hbmNlIGluZm9y bWF0aW9uLg0KPiANCj4gV2l0aG91dCBjb25zaWRlcmluZyB0aGUgSUVURiB3b3JrZmxvdywgaW1h Z2luZSB5b3UgYXJlIGEgbWFpbnRhaW5lciBvZg0KPiB0aGUgaW50ZXJmYWNlcyBtb2R1bGUgYW5k IHNvbWVib2R5IGVsc2Ugd2FudHMgdG8gd3JpdGUgYSBtb2R1bGUgZm9yIGENCj4gbmV3IGludGVy ZmFjZSB0eXBlLCBwZXJoYXBzIHByb3ByaWV0YXJ5IG9yIGV4cGVyaW1lbnRhbC4gV291bGQgeW91 DQo+IHdhbnQgdG8gdXBkYXRlIHRoZSBpbnRlcmZhY2VzIG1vZHVsZSAob3IgcGFja2FnZSkgZm9y IGV2ZXJ5IG5ldw0KPiBpbnRlcmZhY2UgdHlwZT8NCg0KTm8sIGJ1dCBJIGFtIG5vdCBzdWdnZXN0 aW5nIHRoYXQhICBJIGFtIHN1Z2dlc3RpbmcgdGhhdCBwYWNrYWdlcyBkb24ndA0Kc29sdmUgdGhp cyBpc3N1ZSAtIHRoZXkganVzdCBtb3ZlIHRoZSBwcm9ibGVtLg0KDQpJIHRoaW5rIGl0IHdvdWxk IGJlIGdyZWF0IGlmIHdlIGNvdWxkIGFsbG93Og0KDQogIG1vZHVsZSBmb28gew0KICAgIC4uLg0K ICAgIGlkZW50aXR5IGZvbzsNCg0KICAgIGF1Z21lbnQgL3h4eDp5eXkvIHsNCiAgICAgIHdoZW4g InR5cGUgPSBmb286Zm9vIjsNCiAgICAgIGxlYWYgbXktbGVhZiB7DQogICAgICAgIG1hbmRhdG9y eSB0cnVlOw0KICAgICAgICAuLi4NCiAgICAgIH0NCiAgICB9DQogIH0NCg0KSS5lLiwgYWxsb3cg InNhZmUiIGF1Z21lbnRhdGlvbiBvZiBtYW5kYXRvcnkgbm9kZXMuDQoNCkkgZG9uJ3Qga25vdyBp ZiB3ZSBjYW4gZG8gdGhpcyB3aXRob3V0IGNyZWF0aW5nIENMUnMuDQoNCg0KTWVhbndoaWxlLCBJ IHRoaW5rIHRoZSBjdXJyZW50IGFwcHJvYWNoIGlzIGdvb2QgZW5vdWdoIC0gYXVnbWVudCBhDQpQ LWNvbnRhaW5lciwgaW4gd2hpY2ggeW91IHB1dCB5b3VyIG1hbmRhdG9yeSBub2Rlcy4gIFRoZSAq b25seSoNCnByb2JsZW0gd2l0aCB0aGlzIGlzIHRoYXQgeW91IGluIHNvbWUgY2FzZXMgbWF5IGhh dmUgdG8gaW50cm9kdWNlIGENCmNvbnRhaW5lciB0aGF0IHlvdSBkb24ndCBuZWVkLiAgQnV0IEkg YW0gbm90IGNvbnZpbmNlZCB0aGlzIGlzIGEgYmlnDQppc3N1ZS4NCg0KDQovbWFydGluDQo= From nobody Mon Mar 31 01:58:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D1A1A081F for ; Mon, 31 Mar 2014 01:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFOZhGiKkMbI for ; Mon, 31 Mar 2014 01:58:43 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CF0C81A0988 for ; Mon, 31 Mar 2014 01:58:42 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 84F0E14014A; Mon, 31 Mar 2014 10:58:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1396256318; bh=on30Hhsai0vvMRL0NI1mrHby451ngvnm5aF26R5Ma0M=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=MVVdgLUqaBwuc8jrLLpgFH4eIFJB/m+RcsFbp/5KZohdF3iyzZjru4g7mmXgTg/F2 6ANR7WWTG9cwVNcrtI4gN7fqdq6EBWngCm/8sknXZMvcGnsqs/DDrDon23cJ5IJQpD xH9PB4kMrKlUlfbEBASvas+vUxtN+aJURfSls91I= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140331.102618.1660670137649122831.mbj@tail-f.com> Date: Mon, 31 Mar 2014 10:58:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <45720E95-0D83-4D41-AB22-53892379509D@nic.cz> References: <58A10802-B7A1-40AF-B4B9-E5C2141FE33D@nic.cz> <20140331.093120.1377705145354457255.mbj@tail-f.com> <20140331.102618.1660670137649122831.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Zf0yPRlL1Qv_OLKRIyt5FTtkm0A Cc: netmod@ietf.org Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 08:58:45 -0000 On 31 Mar 2014, at 10:26, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On 31 Mar 2014, at 09:31, Martin Bjorklund wrote: >>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>> On 31 Mar 2014, at 09:25, Martin Bjorklund wrote: >>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>>=20 >>>>>> On 29 Mar 2014, at 13:11, Martin Bjorklund = wrote: >>>>>>=20 >>>>>>> Ladislav Lhotka wrote: >>>>>>>> One idea - would it be possible to use the packages is a way = that >>>>>>>> guarantees >>>>>>>> that every package is self-sustainable? This could solve this = issue. >>>>>>>=20 >>>>>>> So you want to have individually revisioned modules, and an = revisioned >>>>>>> package that collects a set of modules, and the server then = advertises >>>>>>> the package? >>>>>>>=20 >>>>>>> We already have that; use individually revisioned submodules, = and let >>>>>>> the module collect the set of submodules, and the server would >>>>>>> advertise the module. This works today, and it solves your = augment >>>>>>> issue. >>>>>>=20 >>>>>> No, it doesn=92t. Submodules are not practical for distributed >>>>>> development because with each new submodule one has to change the = main >>>>>> module as well. >>>>>=20 >>>>> If you instead have a package listing all modules, you have to = update >>>>> the package. So how is this different? >>>>=20 >>>> A package won=92t be published as an RFC, I reckon. >>>=20 >>> The package is supposedly the conformance requirements. So we push >>> the conformance requirements to the vendors? Each implementation >>> specifiy its own requirements? >>=20 >> Not necessarily, although even that would be better than no >> conformance information. >>=20 >> Without considering the IETF workflow, imagine you are a maintainer = of >> the interfaces module and somebody else wants to write a module for a >> new interface type, perhaps proprietary or experimental. Would you >> want to update the interfaces module (or package) for every new >> interface type? >=20 > No, but I am not suggesting that! I am suggesting that packages don't > solve this issue - they just move the problem. >=20 > I think it would be great if we could allow: >=20 > module foo { > ... > identity foo; >=20 > augment /xxx:yyy/ { > when "type =3D foo:foo"; > leaf my-leaf { > mandatory true; > ... > } > } > } >=20 > I.e., allow "safe" augmentation of mandatory nodes. >=20 > I don't know if we can do this without creating CLRs. I think we can. Even now, module X can state in its description that it = has to be used together with module Y, or at least one module from a = certain set, etc. If it is how module X has been written from the = beginning, then there is no issue with old clients.=20 >=20 >=20 > Meanwhile, I think the current approach is good enough - augment a > P-container, in which you put your mandatory nodes. The *only* > problem with this is that you in some cases may have to introduce a > container that you don't need. But I am not convinced this is a big > issue. Sorry, I still don=92t get how a P-container helps. In your example, it = means =93leaf my-leaf=94 would be wrapped in such a P-container, right? = Then the client can create a valid instance like this: =93yyy=94: {=20 =93type=94: =93foo:foo=94 } so =93my-leaf=94, which is supposed to be mandatory, is missing. How is = this different from making =93my-leaf=94 optional in the first place? Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 31 02:09:50 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB321A081F for ; Mon, 31 Mar 2014 02:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sr7FoOXMjgrh for ; Mon, 31 Mar 2014 02:09:47 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9481A0794 for ; Mon, 31 Mar 2014 02:09:46 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1A861240C22B; Mon, 31 Mar 2014 11:09:43 +0200 (CEST) Date: Mon, 31 Mar 2014 11:09:42 +0200 (CEST) Message-Id: <20140331.110942.2007689620077253979.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <45720E95-0D83-4D41-AB22-53892379509D@nic.cz> References: <20140331.102618.1660670137649122831.mbj@tail-f.com> <45720E95-0D83-4D41-AB22-53892379509D@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7PGmzwMsZMi3EMuR2xQmD0CIJhA Cc: netmod@ietf.org Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 09:09:49 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+IE9uIDMxIE1hciAy MDE0LCBhdCAxMDoyNiwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+IHdyb3RlOg0K PiANCj4gPiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPiA+PiANCj4g Pj4gT24gMzEgTWFyIDIwMTQsIGF0IDA5OjMxLCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1m LmNvbT4gd3JvdGU6DQo+ID4+IA0KPiA+Pj4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6 PiB3cm90ZToNCj4gPj4+PiANCj4gPj4+PiBPbiAzMSBNYXIgMjAxNCwgYXQgMDk6MjUsIE1hcnRp biBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPiB3cm90ZToNCj4gPj4+PiANCj4gPj4+Pj4gTGFk aXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gPj4+Pj4+IA0KPiA+Pj4+Pj4g T24gMjkgTWFyIDIwMTQsIGF0IDEzOjExLCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNv bT4gd3JvdGU6DQo+ID4+Pj4+PiANCj4gPj4+Pj4+PiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBu aWMuY3o+IHdyb3RlOg0KPiA+Pj4+Pj4+PiBPbmUgaWRlYSAtIHdvdWxkIGl0IGJlIHBvc3NpYmxl IHRvIHVzZSB0aGUgcGFja2FnZXMgaXMgYSB3YXkgdGhhdA0KPiA+Pj4+Pj4+PiBndWFyYW50ZWVz DQo+ID4+Pj4+Pj4+IHRoYXQgZXZlcnkgcGFja2FnZSBpcyBzZWxmLXN1c3RhaW5hYmxlPyBUaGlz IGNvdWxkIHNvbHZlIHRoaXMgaXNzdWUuDQo+ID4+Pj4+Pj4gDQo+ID4+Pj4+Pj4gU28geW91IHdh bnQgdG8gaGF2ZSBpbmRpdmlkdWFsbHkgcmV2aXNpb25lZCBtb2R1bGVzLCBhbmQgYW4gcmV2aXNp b25lZA0KPiA+Pj4+Pj4+IHBhY2thZ2UgdGhhdCBjb2xsZWN0cyBhIHNldCBvZiBtb2R1bGVzLCBh bmQgdGhlIHNlcnZlciB0aGVuIGFkdmVydGlzZXMNCj4gPj4+Pj4+PiB0aGUgcGFja2FnZT8NCj4g Pj4+Pj4+PiANCj4gPj4+Pj4+PiBXZSBhbHJlYWR5IGhhdmUgdGhhdDsgdXNlIGluZGl2aWR1YWxs eSByZXZpc2lvbmVkIHN1Ym1vZHVsZXMsIGFuZCBsZXQNCj4gPj4+Pj4+PiB0aGUgbW9kdWxlIGNv bGxlY3QgdGhlIHNldCBvZiBzdWJtb2R1bGVzLCBhbmQgdGhlIHNlcnZlciB3b3VsZA0KPiA+Pj4+ Pj4+IGFkdmVydGlzZSB0aGUgbW9kdWxlLiAgVGhpcyB3b3JrcyB0b2RheSwgYW5kIGl0IHNvbHZl cyB5b3VyIGF1Z21lbnQNCj4gPj4+Pj4+PiBpc3N1ZS4NCj4gPj4+Pj4+IA0KPiA+Pj4+Pj4gTm8s IGl0IGRvZXNu4oCZdC4gU3VibW9kdWxlcyBhcmUgbm90IHByYWN0aWNhbCBmb3IgZGlzdHJpYnV0 ZWQNCj4gPj4+Pj4+IGRldmVsb3BtZW50IGJlY2F1c2Ugd2l0aCBlYWNoIG5ldyBzdWJtb2R1bGUg b25lIGhhcyB0byBjaGFuZ2UgdGhlIG1haW4NCj4gPj4+Pj4+IG1vZHVsZSBhcyB3ZWxsLg0KPiA+ Pj4+PiANCj4gPj4+Pj4gSWYgeW91IGluc3RlYWQgaGF2ZSBhIHBhY2thZ2UgbGlzdGluZyBhbGwg bW9kdWxlcywgeW91IGhhdmUgdG8gdXBkYXRlDQo+ID4+Pj4+IHRoZSBwYWNrYWdlLiAgU28gaG93 IGlzIHRoaXMgZGlmZmVyZW50Pw0KPiA+Pj4+IA0KPiA+Pj4+IEEgcGFja2FnZSB3b27igJl0IGJl IHB1Ymxpc2hlZCBhcyBhbiBSRkMsIEkgcmVja29uLg0KPiA+Pj4gDQo+ID4+PiBUaGUgcGFja2Fn ZSBpcyBzdXBwb3NlZGx5IHRoZSBjb25mb3JtYW5jZSByZXF1aXJlbWVudHMuICBTbyB3ZSBwdXNo DQo+ID4+PiB0aGUgY29uZm9ybWFuY2UgcmVxdWlyZW1lbnRzIHRvIHRoZSB2ZW5kb3JzPyAgRWFj aCBpbXBsZW1lbnRhdGlvbg0KPiA+Pj4gc3BlY2lmaXkgaXRzIG93biByZXF1aXJlbWVudHM/DQo+ ID4+IA0KPiA+PiBOb3QgbmVjZXNzYXJpbHksIGFsdGhvdWdoIGV2ZW4gdGhhdCB3b3VsZCBiZSBi ZXR0ZXIgdGhhbiBubw0KPiA+PiBjb25mb3JtYW5jZSBpbmZvcm1hdGlvbi4NCj4gPj4gDQo+ID4+ IFdpdGhvdXQgY29uc2lkZXJpbmcgdGhlIElFVEYgd29ya2Zsb3csIGltYWdpbmUgeW91IGFyZSBh IG1haW50YWluZXIgb2YNCj4gPj4gdGhlIGludGVyZmFjZXMgbW9kdWxlIGFuZCBzb21lYm9keSBl bHNlIHdhbnRzIHRvIHdyaXRlIGEgbW9kdWxlIGZvciBhDQo+ID4+IG5ldyBpbnRlcmZhY2UgdHlw ZSwgcGVyaGFwcyBwcm9wcmlldGFyeSBvciBleHBlcmltZW50YWwuIFdvdWxkIHlvdQ0KPiA+PiB3 YW50IHRvIHVwZGF0ZSB0aGUgaW50ZXJmYWNlcyBtb2R1bGUgKG9yIHBhY2thZ2UpIGZvciBldmVy eSBuZXcNCj4gPj4gaW50ZXJmYWNlIHR5cGU/DQo+ID4gDQo+ID4gTm8sIGJ1dCBJIGFtIG5vdCBz dWdnZXN0aW5nIHRoYXQhICBJIGFtIHN1Z2dlc3RpbmcgdGhhdCBwYWNrYWdlcyBkb24ndA0KPiA+ IHNvbHZlIHRoaXMgaXNzdWUgLSB0aGV5IGp1c3QgbW92ZSB0aGUgcHJvYmxlbS4NCj4gPiANCj4g PiBJIHRoaW5rIGl0IHdvdWxkIGJlIGdyZWF0IGlmIHdlIGNvdWxkIGFsbG93Og0KPiA+IA0KPiA+ ICBtb2R1bGUgZm9vIHsNCj4gPiAgICAuLi4NCj4gPiAgICBpZGVudGl0eSBmb287DQo+ID4gDQo+ ID4gICAgYXVnbWVudCAveHh4Onl5eS8gew0KPiA+ICAgICAgd2hlbiAidHlwZSA9IGZvbzpmb28i Ow0KPiA+ICAgICAgbGVhZiBteS1sZWFmIHsNCj4gPiAgICAgICAgbWFuZGF0b3J5IHRydWU7DQo+ ID4gICAgICAgIC4uLg0KPiA+ICAgICAgfQ0KPiA+ICAgIH0NCj4gPiAgfQ0KPiA+IA0KPiA+IEku ZS4sIGFsbG93ICJzYWZlIiBhdWdtZW50YXRpb24gb2YgbWFuZGF0b3J5IG5vZGVzLg0KPiA+IA0K PiA+IEkgZG9uJ3Qga25vdyBpZiB3ZSBjYW4gZG8gdGhpcyB3aXRob3V0IGNyZWF0aW5nIENMUnMu DQo+IA0KPiBJIHRoaW5rIHdlIGNhbi4NCg0KSXQgd291bGQgYmUgZ3JlYXQgaWYgeW91IGNvdWxk IHRoaW5rIGFib3V0IGNvbmNyZXRlIHRleHQhDQoNCj4gRXZlbiBub3csIG1vZHVsZSBYIGNhbiBz dGF0ZSBpbiBpdHMgZGVzY3JpcHRpb24gdGhhdA0KPiBpdCBoYXMgdG8gYmUgdXNlZCB0b2dldGhl ciB3aXRoIG1vZHVsZSBZLCBvciBhdCBsZWFzdCBvbmUgbW9kdWxlIGZyb20NCj4gYSBjZXJ0YWlu IHNldCwgZXRjLiBJZiBpdCBpcyBob3cgbW9kdWxlIFggaGFzIGJlZW4gd3JpdHRlbiBmcm9tIHRo ZQ0KPiBiZWdpbm5pbmcsIHRoZW4gdGhlcmUgaXMgbm8gaXNzdWUgd2l0aCBvbGQgY2xpZW50cy4N Cj4gDQo+ID4gDQo+ID4gDQo+ID4gTWVhbndoaWxlLCBJIHRoaW5rIHRoZSBjdXJyZW50IGFwcHJv YWNoIGlzIGdvb2QgZW5vdWdoIC0gYXVnbWVudCBhDQo+ID4gUC1jb250YWluZXIsIGluIHdoaWNo IHlvdSBwdXQgeW91ciBtYW5kYXRvcnkgbm9kZXMuICBUaGUgKm9ubHkqDQo+ID4gcHJvYmxlbSB3 aXRoIHRoaXMgaXMgdGhhdCB5b3UgaW4gc29tZSBjYXNlcyBtYXkgaGF2ZSB0byBpbnRyb2R1Y2Ug YQ0KPiA+IGNvbnRhaW5lciB0aGF0IHlvdSBkb24ndCBuZWVkLiAgQnV0IEkgYW0gbm90IGNvbnZp bmNlZCB0aGlzIGlzIGEgYmlnDQo+ID4gaXNzdWUuDQo+IA0KPiBTb3JyeSwgSSBzdGlsbCBkb27i gJl0IGdldCBob3cgYSBQLWNvbnRhaW5lciBoZWxwcy4gSW4geW91ciBleGFtcGxlLCBpdA0KPiBt ZWFucyDigJxsZWFmIG15LWxlYWbigJ0gd291bGQgYmUgd3JhcHBlZCBpbiBzdWNoIGEgUC1jb250 YWluZXIsIHJpZ2h0Pw0KPiBUaGVuIHRoZSBjbGllbnQgY2FuIGNyZWF0ZSBhIHZhbGlkIGluc3Rh bmNlIGxpa2UgdGhpczoNCj4gDQo+IOKAnHl5eeKAnTogeyANCj4gICAgIOKAnHR5cGXigJ06IOKA nGZvbzpmb2/igJ0NCj4gfQ0KDQpZZXMsIHRoaXMgbWlnaHQgYWxzbyBhIGJlIHByb2JsZW07IHRo ZSBjbGllbnQgY2FuIGNyZWF0ZSBhICJtZWFuaW5nbGVzcyINCmVtcHR5IGNvbmZpZ3VyYXRpb24u DQoNCj4gc28g4oCcbXktbGVhZuKAnSwgd2hpY2ggaXMgc3VwcG9zZWQgdG8gYmUgbWFuZGF0b3J5 LCBpcyBtaXNzaW5nLiBIb3cgaXMNCj4gdGhpcyBkaWZmZXJlbnQgZnJvbSBtYWtpbmcg4oCcbXkt bGVhZuKAnSBvcHRpb25hbCBpbiB0aGUgZmlyc3QgcGxhY2U/DQoNCllvdSBkbyBnZXQgdGhlIGJl aGF2aW9yIHlvdSB3YW50IHdoZW4gdGhlIGNsaWVudCBzZXRzIHRoZSB0eXBlLCAqYW5kKg0KY3Jl YXRlcyB0aGUgUC1jb250YWluZXIuICBUaGVuIGFsbCBtYW5kYXRvcnkgdGVzdHMgKGFuZCBtb3Jl KSBhcmUNCmNoZWNrZWQuDQoNCg0KL21hcnRpbg0K From nobody Mon Mar 31 02:26:17 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC761A0843 for ; Mon, 31 Mar 2014 02:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pepn4BAu3-dP for ; Mon, 31 Mar 2014 02:26:14 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 963041A081F for ; Mon, 31 Mar 2014 02:26:14 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id BA0EA13F636; Mon, 31 Mar 2014 11:26:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1396257971; bh=3qcgi1eJvILV/phI10RYkUqDUmnCdxvxHyUkStCjmJc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=MLW2UTHUVCvTKyIb0Hg4TgvJCXWTsVd28rURFkevlV0irlyF1PY2KIm7lOgOGgbQl Ijl6tprSMaD4j/J489NfGC1UVqGqIPif6KLaCBiENtYMTwG2G7vphBCcnnn31JyBzr +bHwVnelQ+zy2MKKmtoi+VBryUjaHLjXTdyI0evU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140331.110942.2007689620077253979.mbj@tail-f.com> Date: Mon, 31 Mar 2014 11:26:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <03FF171A-79E4-46B6-B479-9F96C213DC4A@nic.cz> References: <20140331.102618.1660670137649122831.mbj@tail-f.com> <45720E95-0D83-4D41-AB22-53892379509D@nic.cz> <20140331.110942.2007689620077253979.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Hbz2vhGRUO94kvMtwAIg4qI1vvk Cc: netmod@ietf.org Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 09:26:16 -0000 On 31 Mar 2014, at 11:09, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On 31 Mar 2014, at 10:26, Martin Bjorklund wrote: >>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>> On 31 Mar 2014, at 09:31, Martin Bjorklund wrote: >>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>>=20 >>>>>> On 31 Mar 2014, at 09:25, Martin Bjorklund = wrote: >>>>>>=20 >>>>>>> Ladislav Lhotka wrote: >>>>>>>>=20 >>>>>>>> On 29 Mar 2014, at 13:11, Martin Bjorklund = wrote: >>>>>>>>=20 >>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>> One idea - would it be possible to use the packages is a way = that >>>>>>>>>> guarantees >>>>>>>>>> that every package is self-sustainable? This could solve this = issue. >>>>>>>>>=20 >>>>>>>>> So you want to have individually revisioned modules, and an = revisioned >>>>>>>>> package that collects a set of modules, and the server then = advertises >>>>>>>>> the package? >>>>>>>>>=20 >>>>>>>>> We already have that; use individually revisioned submodules, = and let >>>>>>>>> the module collect the set of submodules, and the server would >>>>>>>>> advertise the module. This works today, and it solves your = augment >>>>>>>>> issue. >>>>>>>>=20 >>>>>>>> No, it doesn=92t. Submodules are not practical for distributed >>>>>>>> development because with each new submodule one has to change = the main >>>>>>>> module as well. >>>>>>>=20 >>>>>>> If you instead have a package listing all modules, you have to = update >>>>>>> the package. So how is this different? >>>>>>=20 >>>>>> A package won=92t be published as an RFC, I reckon. >>>>>=20 >>>>> The package is supposedly the conformance requirements. So we = push >>>>> the conformance requirements to the vendors? Each implementation >>>>> specifiy its own requirements? >>>>=20 >>>> Not necessarily, although even that would be better than no >>>> conformance information. >>>>=20 >>>> Without considering the IETF workflow, imagine you are a maintainer = of >>>> the interfaces module and somebody else wants to write a module for = a >>>> new interface type, perhaps proprietary or experimental. Would you >>>> want to update the interfaces module (or package) for every new >>>> interface type? >>>=20 >>> No, but I am not suggesting that! I am suggesting that packages = don't >>> solve this issue - they just move the problem. >>>=20 >>> I think it would be great if we could allow: >>>=20 >>> module foo { >>> ... >>> identity foo; >>>=20 >>> augment /xxx:yyy/ { >>> when "type =3D foo:foo"; >>> leaf my-leaf { >>> mandatory true; >>> ... >>> } >>> } >>> } >>>=20 >>> I.e., allow "safe" augmentation of mandatory nodes. >>>=20 >>> I don't know if we can do this without creating CLRs. >>=20 >> I think we can. >=20 > It would be great if you could think about concrete text! I=92d simply remove the CLR and put a guideline into 6087bis saying = something like this: A supplementary module augmenting another module that has already been = in use SHOULD NOT define new mandatory nodes, unless the original module = was designed for such an augmentation. >=20 >> Even now, module X can state in its description that >> it has to be used together with module Y, or at least one module from >> a certain set, etc. If it is how module X has been written from the >> beginning, then there is no issue with old clients. >>=20 >>>=20 >>>=20 >>> Meanwhile, I think the current approach is good enough - augment a >>> P-container, in which you put your mandatory nodes. The *only* >>> problem with this is that you in some cases may have to introduce a >>> container that you don't need. But I am not convinced this is a big >>> issue. >>=20 >> Sorry, I still don=92t get how a P-container helps. In your example, = it >> means =93leaf my-leaf=94 would be wrapped in such a P-container, = right? >> Then the client can create a valid instance like this: >>=20 >> =93yyy=94: {=20 >> =93type=94: =93foo:foo=94 >> } >=20 > Yes, this might also a be problem; the client can create a = "meaningless" > empty configuration. >=20 >> so =93my-leaf=94, which is supposed to be mandatory, is missing. How = is >> this different from making =93my-leaf=94 optional in the first place? >=20 > You do get the behavior you want when the client sets the type, *and* > creates the P-container. Then all mandatory tests (and more) are > checked. Yes, so it is easier for the client to figure out what is actually = mandatory, at the cost of an extra container, which may be an = unacceptable overhead, e.g. in every route. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 31 06:10:48 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4F81A0863 for ; Mon, 31 Mar 2014 06:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7SqZYgMHrPJ for ; Mon, 31 Mar 2014 06:10:43 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7401A086B for ; Mon, 31 Mar 2014 06:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6119; q=dns/txt; s=iport; t=1396271440; x=1397481040; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=41kiJmeA99FL5N+4h1FPjtR24zSdZMdJM1YukV22lSI=; b=IAnsUHL0xo/yjVDfZpJ+CPAMhYC3cd0yWqoeDLlK0ffuJNhNe0ppuplD a3Ev/xpjf83rPt0MJXOmXD+beG5ygsPAmB44UcanCvfMCW1umigsz3hvx 8mPsAkWTBGAo7P6nW+R0qV86S1n5cgzJxyBxGhy7BfVfDQF+0o8j8ty/G w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIFAJVnOVOtJV2Z/2dsb2JhbABZgkJEO1fDF4EbFnSCJQEBAQQtXAIBCBEEAQELHQcyFAkIAgQBEgiHcdBFF45ONwGDJIEUBIx1kyOKa4Mwgis X-IronPort-AV: E=Sophos; i="4.97,765,1389744000"; d="scan'208,217"; a="31674542" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP; 31 Mar 2014 13:10:39 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2VDAdQG001575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Mar 2014 13:10:39 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.231]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Mon, 31 Mar 2014 08:10:39 -0500 From: "Patrick Gili (pgili)" To: Andy Bierman , "netmod@ietf.org" Thread-Topic: [netmod] new YANG 1.1 issue: remove deviations Thread-Index: AQHPTD1cdvPOObaEwk+DPxG3JVMZtpr7LF6g Date: Mon, 31 Mar 2014 13:10:39 +0000 Message-ID: <50E64ADF99EAEE4CACEC18958F0FC0AB0AACCC11@xmb-aln-x14.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.241.250] Content-Type: multipart/alternative; boundary="_000_50E64ADF99EAEE4CACEC18958F0FC0AB0AACCC11xmbalnx14ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yEf7RtoNv1V4_o4Ju88MV1PJk5w Subject: Re: [netmod] new YANG 1.1 issue: remove deviations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 13:10:46 -0000 --_000_50E64ADF99EAEE4CACEC18958F0FC0AB0AACCC11xmbalnx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy, I don't think it is a good idea to remove deviations. While we are not publ= ishing deviations at this time, we are dealing with a use case that may req= uire the use of deviations. Cheers, -Patrick From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Sunday, March 30, 2014 1:28 PM To: netmod@ietf.org Subject: [netmod] new YANG 1.1 issue: remove deviations Hi, I don't think YANG deviation statements are being used, nor are they likely to ever be used. They are not allowed to appear in standard YANG modules, so I am asking vendors out there: Do you use (or plan to use) deviation statements in your YANG modules? If consensus is no, then deviations should be removed from YANG 1.1. YANG would be simpler without them. IMO, conformance information should be handled differently anyway. Andy --_000_50E64ADF99EAEE4CACEC18958F0FC0AB0AACCC11xmbalnx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andy,

 <= /p>

I don’t think it is= a good idea to remove deviations. While we are not publishing deviations a= t this time, we are dealing with a use case that may require the use of deviations.

 <= /p>

Cheers,=

-Patrick

 <= /p>

From: netmod [= mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Sunday, March 30, 2014 1:28 PM
To: netmod@ietf.org
Subject: [netmod] new YANG 1.1 issue: remove deviations

 

Hi,

 

I don't think YANG deviation statements are being us= ed,

nor are they likely to ever be used. They are not al= lowed

to appear in standard YANG modules, so I am asking

vendors out there:

 

   Do you use (or plan to use) deviation s= tatements in your YANG modules?

 

If consensus is no, then deviations should be remove= d from YANG 1.1.

YANG would be simpler without them.

IMO, conformance information should be handled diffe= rently anyway.

 

 

Andy

 

--_000_50E64ADF99EAEE4CACEC18958F0FC0AB0AACCC11xmbalnx14ciscoc_-- From nobody Mon Mar 31 07:20:22 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5661A6EF3 for ; Mon, 31 Mar 2014 07:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMNxGrD1XRg4 for ; Mon, 31 Mar 2014 07:20:14 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id 19CB61A087B for ; Mon, 31 Mar 2014 07:20:13 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id c9so9121201qcz.30 for ; Mon, 31 Mar 2014 07:20:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jiOcxPTEIjCQoFoZhALa/JcdIH6JQuw8ALtCdQMwfUQ=; b=NmBHv6cv+kv7Qqs0QRFSJBg638NlpI+KGHqBvD7ee2SVwYs9kWPTCHWhexmu26QEPg OFxGRVhgSz4L8rvOnGjb5bFVNAbbTjVhpnwtAXkhx/iZRD/QjHQuaDgowfzQ2Vbi6d14 BBsnX8kY5WwFwvm+JCaLcKTDPzMvjZFnHzWEmXuDMVVYuKeo5/09X3mxoTJDvixvlRYL L1/stjBUrT2Qh0KZwlIqvWmLTwdVHR/8orj9Ne07xy6HPsoTTsFXpbuAqpeIAZVw5pdy CQPjH9ryS1kc4SAF4g9dSiEmYlChn2txErbhJYVY1eWrBbtl//qFu55cHLBjWgHcx+c9 qKGw== X-Gm-Message-State: ALoCoQmS5R1IDYXgsQXs0lr1KKx9qLIUfvUZxHxw0n0StnjM5tHHkcX2Mkl8YOpfhus1IcripLL+ MIME-Version: 1.0 X-Received: by 10.229.96.199 with SMTP id i7mr3802901qcn.20.1396275598130; Mon, 31 Mar 2014 07:19:58 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Mon, 31 Mar 2014 07:19:57 -0700 (PDT) In-Reply-To: <20140331.110942.2007689620077253979.mbj@tail-f.com> References: <20140331.102618.1660670137649122831.mbj@tail-f.com> <45720E95-0D83-4D41-AB22-53892379509D@nic.cz> <20140331.110942.2007689620077253979.mbj@tail-f.com> Date: Mon, 31 Mar 2014 07:19:57 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a1133886e09146304f5e7bf39 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/G0fu2viy1Fa8ZvH-p8OMYW4Uo9Y Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 14:20:21 -0000 --001a1133886e09146304f5e7bf39 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 31, 2014 at 2:09 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > > > On 31 Mar 2014, at 10:26, Martin Bjorklund wrote: > > > > > Ladislav Lhotka wrote: > > >> > > >> On 31 Mar 2014, at 09:31, Martin Bjorklund wrote: > > >> > > >>> Ladislav Lhotka wrote: > > >>>> > > >>>> On 31 Mar 2014, at 09:25, Martin Bjorklund wrote: > > >>>> > > >>>>> Ladislav Lhotka wrote: > > >>>>>> > > >>>>>> On 29 Mar 2014, at 13:11, Martin Bjorklund > wrote: > > >>>>>> > > >>>>>>> Ladislav Lhotka wrote: > > >>>>>>>> One idea - would it be possible to use the packages is a way > that > > >>>>>>>> guarantees > > >>>>>>>> that every package is self-sustainable? This could solve this > issue. > > >>>>>>> > > >>>>>>> So you want to have individually revisioned modules, and an > revisioned > > >>>>>>> package that collects a set of modules, and the server then > advertises > > >>>>>>> the package? > > >>>>>>> > > >>>>>>> We already have that; use individually revisioned submodules, > and let > > >>>>>>> the module collect the set of submodules, and the server would > > >>>>>>> advertise the module. This works today, and it solves your > augment > > >>>>>>> issue. > > >>>>>> > > >>>>>> No, it doesn't. Submodules are not practical for distributed > > >>>>>> development because with each new submodule one has to change the > main > > >>>>>> module as well. > > >>>>> > > >>>>> If you instead have a package listing all modules, you have to > update > > >>>>> the package. So how is this different? > > >>>> > > >>>> A package won't be published as an RFC, I reckon. > > >>> > > >>> The package is supposedly the conformance requirements. So we push > > >>> the conformance requirements to the vendors? Each implementation > > >>> specifiy its own requirements? > > >> > > >> Not necessarily, although even that would be better than no > > >> conformance information. > > >> > > >> Without considering the IETF workflow, imagine you are a maintainer of > > >> the interfaces module and somebody else wants to write a module for a > > >> new interface type, perhaps proprietary or experimental. Would you > > >> want to update the interfaces module (or package) for every new > > >> interface type? > > > > > > No, but I am not suggesting that! I am suggesting that packages don't > > > solve this issue - they just move the problem. > > > > > > I think it would be great if we could allow: > > > > > > module foo { > > > ... > > > identity foo; > > > > > > augment /xxx:yyy/ { > > > when "type = foo:foo"; > > > leaf my-leaf { > > > mandatory true; > > > ... > > > } > > > } > > > } > > > > > > I.e., allow "safe" augmentation of mandatory nodes. > > > > This does not work since module xxx knows nothing of this module., It is the client of the augmented module that matters -- not the client of the augmenting module. > > > I don't know if we can do this without creating CLRs. > > > > I think we can. > > It would be great if you could think about concrete text! > > The description-stmt "This module xxx MUST be implemented with module A" requires that module xxx be updated. This is not acceptable anyway. The conformance info needs to be machine-readable like it is now. IMO, the simplest solution is to keep the current conformance model and not allow any mandatory external augments. > Even now, module X can state in its description that > > it has to be used together with module Y, or at least one module from > > a certain set, etc. If it is how module X has been written from the > > beginning, then there is no issue with old clients. > > > > > > > > > > > Meanwhile, I think the current approach is good enough - augment a > > > P-container, in which you put your mandatory nodes. The *only* > > > problem with this is that you in some cases may have to introduce a > > > container that you don't need. But I am not convinced this is a big > > > issue. > > > > Sorry, I still don't get how a P-container helps. In your example, it > > means "leaf my-leaf" would be wrapped in such a P-container, right? > > Then the client can create a valid instance like this: > > > > "yyy": { > > "type": "foo:foo" > > } > > Yes, this might also a be problem; the client can create a "meaningless" > empty configuration. > > > so "my-leaf", which is supposed to be mandatory, is missing. How is > > this different from making "my-leaf" optional in the first place? > > You do get the behavior you want when the client sets the type, *and* > creates the P-container. Then all mandatory tests (and more) are > checked. > > > /martin > Andy --001a1133886e09146304f5e7bf39 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 31, 2014 at 2:09 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On 31 Mar 2014, at 10:26, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Ladislav Lhotka <lhotka@nic.c= z> wrote:
> >>
> >> On 31 Mar 2014, at 09:31, Martin Bjorklund <mbj@tail-f.com> wrote:
> >>
> >>> Ladislav Lhotka <lhot= ka@nic.cz> wrote:
> >>>>
> >>>> On 31 Mar 2014, at 09:25, Martin Bjorklund <mbj@tail-f.com> wrote:
> >>>>
> >>>>> Ladislav Lhotka <lhotka@nic.cz> wrote:
> >>>>>>
> >>>>>> On 29 Mar 2014, at 13:11, Martin Bjorklund &l= t;mbj@tail-f.com> wrote:
> >>>>>>
> >>>>>>> Ladislav Lhotka <lhotka@nic.cz> wrote:
> >>>>>>>> One idea - would it be possible to us= e the packages is a way that
> >>>>>>>> guarantees
> >>>>>>>> that every package is self-sustainabl= e? This could solve this issue.
> >>>>>>>
> >>>>>>> So you want to have individually revision= ed modules, and an revisioned
> >>>>>>> package that collects a set of modules, a= nd the server then advertises
> >>>>>>> the package?
> >>>>>>>
> >>>>>>> We already have that; use individually re= visioned submodules, and let
> >>>>>>> the module collect the set of submodules,= and the server would
> >>>>>>> advertise the module.  This works to= day, and it solves your augment
> >>>>>>> issue.
> >>>>>>
> >>>>>> No, it doesn’t. Submodules are not prac= tical for distributed
> >>>>>> development because with each new submodule o= ne has to change the main
> >>>>>> module as well.
> >>>>>
> >>>>> If you instead have a package listing all modules= , you have to update
> >>>>> the package.  So how is this different?
> >>>>
> >>>> A package won’t be published as an RFC, I recko= n.
> >>>
> >>> The package is supposedly the conformance requirements. &= nbsp;So we push
> >>> the conformance requirements to the vendors?  Each i= mplementation
> >>> specifiy its own requirements?
> >>
> >> Not necessarily, although even that would be better than no > >> conformance information.
> >>
> >> Without considering the IETF workflow, imagine you are a main= tainer of
> >> the interfaces module and somebody else wants to write a modu= le for a
> >> new interface type, perhaps proprietary or experimental. Woul= d you
> >> want to update the interfaces module (or package) for every n= ew
> >> interface type?
> >
> > No, but I am not suggesting that!  I am suggesting that pack= ages don't
> > solve this issue - they just move the problem.
> >
> > I think it would be great if we could allow:
> >
> >  module foo {
> >    ...
> >    identity foo;
> >
> >    augment /xxx:yyy/ {
> >      when "type =3D foo:foo";
> >      leaf my-leaf {
> >        mandatory true;
> >        ...
> >      }
> >    }
> >  }
> >
> > I.e., allow "safe" augmentation of mandatory nodes.
> >



This does not work since module xxx knows nothing of this
module= .,  It is the client of the augmented module that
matters --= not the client of the augmenting module.


 
> > I don't know if we can do this without creating CLRs.
>
> I think we can.

It would be great if you could think about concrete text!



The description-stmt &q= uot;This module xxx MUST be implemented with module A"
requi= res that module xxx be updated.  This is not acceptable anyway.
<= div> The conformance info needs to be machine-readable like it is now.
IMO, the simplest solution is to keep the current conformance model
<= div>and not allow any mandatory external augments.


> Even now, module X can state in its description that
> it has to be used together with module Y, or at least one module from<= br> > a certain set, etc. If it is how module X has been written from the > beginning, then there is no issue with old clients.
>
> >
> >
> > Meanwhile, I think the current approach is good enough - augment = a
> > P-container, in which you put your mandatory nodes.  The *on= ly*
> > problem with this is that you in some cases may have to introduce= a
> > container that you don't need.  But I am not convinced t= his is a big
> > issue.
>
> Sorry, I still don’t get how a P-container helps. In your exampl= e, it
> means “leaf my-leaf” would be wrapped in such a P-containe= r, right?
> Then the client can create a valid instance like this:
>
> “yyy”: {
>     “type”: “foo:foo”
> }

Yes, this might also a be problem; the client can create a "meaningles= s"
empty configuration.

> so “my-leaf”, which is supposed to be mandatory, is missin= g. How is
> this different from making “my-leaf” optional in the first= place?

You do get the behavior you want when the client sets the type, *and*
creates the P-container.  Then all mandatory tests (and more) are
checked.


/martin


<= /div>
Andy

--001a1133886e09146304f5e7bf39-- From nobody Mon Mar 31 07:27:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4661A6EF3 for ; Mon, 31 Mar 2014 07:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxTw9-kDfaFu for ; Mon, 31 Mar 2014 07:27:02 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 497E11A6EF5 for ; Mon, 31 Mar 2014 07:27:02 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 695E137C32C; Mon, 31 Mar 2014 16:26:58 +0200 (CEST) Date: Mon, 31 Mar 2014 16:26:58 +0200 (CEST) Message-Id: <20140331.162658.1671291749949686916.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <45720E95-0D83-4D41-AB22-53892379509D@nic.cz> <20140331.110942.2007689620077253979.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/aEnad_LM3bVHo4CQH2X6IXMwe-o Cc: netmod@ietf.org Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 14:27:06 -0000 Andy Bierman wrote: > On Mon, Mar 31, 2014 at 2:09 AM, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > > > > > > On 31 Mar 2014, at 10:26, Martin Bjorklund wrote: > > > > > > > Ladislav Lhotka wrote: > > > >> > > > >> On 31 Mar 2014, at 09:31, Martin Bjorklund wrote: > > > >> > > > >>> Ladislav Lhotka wrote: > > > >>>> > > > >>>> On 31 Mar 2014, at 09:25, Martin Bjorklund wrote: > > > >>>> > > > >>>>> Ladislav Lhotka wrote: > > > >>>>>> > > > >>>>>> On 29 Mar 2014, at 13:11, Martin Bjorklund > > wrote: > > > >>>>>> > > > >>>>>>> Ladislav Lhotka wrote: > > > >>>>>>>> One idea - would it be possible to use the packages is a way > > that > > > >>>>>>>> guarantees > > > >>>>>>>> that every package is self-sustainable? This could solve this > > issue. > > > >>>>>>> > > > >>>>>>> So you want to have individually revisioned modules, and an > > revisioned > > > >>>>>>> package that collects a set of modules, and the server then > > advertises > > > >>>>>>> the package? > > > >>>>>>> > > > >>>>>>> We already have that; use individually revisioned submodules, > > and let > > > >>>>>>> the module collect the set of submodules, and the server would > > > >>>>>>> advertise the module. This works today, and it solves your > > augment > > > >>>>>>> issue. > > > >>>>>> > > > >>>>>> No, it doesn't. Submodules are not practical for distributed > > > >>>>>> development because with each new submodule one has to change the > > main > > > >>>>>> module as well. > > > >>>>> > > > >>>>> If you instead have a package listing all modules, you have to > > update > > > >>>>> the package. So how is this different? > > > >>>> > > > >>>> A package won't be published as an RFC, I reckon. > > > >>> > > > >>> The package is supposedly the conformance requirements. So we push > > > >>> the conformance requirements to the vendors? Each implementation > > > >>> specifiy its own requirements? > > > >> > > > >> Not necessarily, although even that would be better than no > > > >> conformance information. > > > >> > > > >> Without considering the IETF workflow, imagine you are a maintainer of > > > >> the interfaces module and somebody else wants to write a module for a > > > >> new interface type, perhaps proprietary or experimental. Would you > > > >> want to update the interfaces module (or package) for every new > > > >> interface type? > > > > > > > > No, but I am not suggesting that! I am suggesting that packages don't > > > > solve this issue - they just move the problem. > > > > > > > > I think it would be great if we could allow: > > > > > > > > module foo { > > > > ... > > > > identity foo; > > > > > > > > augment /xxx:yyy/ { > > > > when "type = foo:foo"; > > > > leaf my-leaf { > > > > mandatory true; > > > > ... > > > > } > > > > } > > > > } > > > > > > > > I.e., allow "safe" augmentation of mandatory nodes. > > > > > > > > > > This does not work since module xxx knows nothing of this > module., It is the client of the augmented module that > matters -- not the client of the augmenting module. The point is that if the old client creates an entry in xxx, it will never set the xxx:yyy/type to foo:foo (since it doesn't know about foo), and since the augment was conditional based on foo:foo, there are no mandatory nodes in effect. So this augment is "safe" in the sense that it doesn't break the old client. /martin From nobody Mon Mar 31 07:40:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD23F1A6F22 for ; Mon, 31 Mar 2014 07:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQ6dlhPGQ6HG for ; Mon, 31 Mar 2014 07:40:05 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 37E051A0A24 for ; Mon, 31 Mar 2014 07:40:05 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e16so8912363qcx.41 for ; Mon, 31 Mar 2014 07:40:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nBZr4+5Jptadzo8z5LamQxO3q1hAGn2Bbv2k4PQOnkA=; b=JNbMxjLLX4+JozTQyzEIsW5up/JTWq7a+hHK3ZmuvEcG2fjmyeQIUPsBbPLrKIFNmZ hZWLxKNx/RS8u/jaLu7GW/dIA4ubssteNm6zBsnfoy+a9Lt7WaZ8OjKteWkwJySTFEQQ J4Y9+d+Nl7LHga+DaLoqeUZ7MrSSZWghlGJz27pTvUIDOiq7iczGUVIzPAfpoSYEN8jF 4i4udiEfAVgriETG5mgj5He4n/Wu1SRxlUkOhutjj1Qyj7z0aZ9u6Cm+GQ0qZ05rKzSm k4+N/2fcko6QwXdQVLzsgbJQCYyVNuB9/TAc0TuK4qb/gLESLAOXWG2uBpaAdoQAEtzr Vz2w== X-Gm-Message-State: ALoCoQk1O5I+CC0tSZCxIKTDnd6N7HyiukouAXjIffLtR4XUgFHZlTXO0BJu0phw5ur+eVNOngr8 MIME-Version: 1.0 X-Received: by 10.140.98.116 with SMTP id n107mr2770498qge.94.1396276801701; Mon, 31 Mar 2014 07:40:01 -0700 (PDT) Received: by 10.140.104.194 with HTTP; Mon, 31 Mar 2014 07:40:01 -0700 (PDT) In-Reply-To: <20140331.162658.1671291749949686916.mbj@tail-f.com> References: <45720E95-0D83-4D41-AB22-53892379509D@nic.cz> <20140331.110942.2007689620077253979.mbj@tail-f.com> <20140331.162658.1671291749949686916.mbj@tail-f.com> Date: Mon, 31 Mar 2014 07:40:01 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a113a9238c633ed04f5e806b8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/YbK45d_gjMUc98_dduwyOZewa2A Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 14:40:08 -0000 --001a113a9238c633ed04f5e806b8 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 31, 2014 at 7:26 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Mon, Mar 31, 2014 at 2:09 AM, Martin Bjorklund > wrote: > > > > > Ladislav Lhotka wrote: > > > > > > > > On 31 Mar 2014, at 10:26, Martin Bjorklund wrote: > > > > > > > > > Ladislav Lhotka wrote: > > > > >> > > > > >> On 31 Mar 2014, at 09:31, Martin Bjorklund > wrote: > > > > >> > > > > >>> Ladislav Lhotka wrote: > > > > >>>> > > > > >>>> On 31 Mar 2014, at 09:25, Martin Bjorklund > wrote: > > > > >>>> > > > > >>>>> Ladislav Lhotka wrote: > > > > >>>>>> > > > > >>>>>> On 29 Mar 2014, at 13:11, Martin Bjorklund > > > wrote: > > > > >>>>>> > > > > >>>>>>> Ladislav Lhotka wrote: > > > > >>>>>>>> One idea - would it be possible to use the packages is a way > > > that > > > > >>>>>>>> guarantees > > > > >>>>>>>> that every package is self-sustainable? This could solve > this > > > issue. > > > > >>>>>>> > > > > >>>>>>> So you want to have individually revisioned modules, and an > > > revisioned > > > > >>>>>>> package that collects a set of modules, and the server then > > > advertises > > > > >>>>>>> the package? > > > > >>>>>>> > > > > >>>>>>> We already have that; use individually revisioned submodules, > > > and let > > > > >>>>>>> the module collect the set of submodules, and the server > would > > > > >>>>>>> advertise the module. This works today, and it solves your > > > augment > > > > >>>>>>> issue. > > > > >>>>>> > > > > >>>>>> No, it doesn't. Submodules are not practical for distributed > > > > >>>>>> development because with each new submodule one has to change > the > > > main > > > > >>>>>> module as well. > > > > >>>>> > > > > >>>>> If you instead have a package listing all modules, you have to > > > update > > > > >>>>> the package. So how is this different? > > > > >>>> > > > > >>>> A package won't be published as an RFC, I reckon. > > > > >>> > > > > >>> The package is supposedly the conformance requirements. So we > push > > > > >>> the conformance requirements to the vendors? Each implementation > > > > >>> specifiy its own requirements? > > > > >> > > > > >> Not necessarily, although even that would be better than no > > > > >> conformance information. > > > > >> > > > > >> Without considering the IETF workflow, imagine you are a > maintainer of > > > > >> the interfaces module and somebody else wants to write a module > for a > > > > >> new interface type, perhaps proprietary or experimental. Would you > > > > >> want to update the interfaces module (or package) for every new > > > > >> interface type? > > > > > > > > > > No, but I am not suggesting that! I am suggesting that packages > don't > > > > > solve this issue - they just move the problem. > > > > > > > > > > I think it would be great if we could allow: > > > > > > > > > > module foo { > > > > > ... > > > > > identity foo; > > > > > > > > > > augment /xxx:yyy/ { > > > > > when "type = foo:foo"; > > > > > leaf my-leaf { > > > > > mandatory true; > > > > > ... > > > > > } > > > > > } > > > > > } > > > > > > > > > > I.e., allow "safe" augmentation of mandatory nodes. > > > > > > > > > > > > > > > > This does not work since module xxx knows nothing of this > > module., It is the client of the augmented module that > > matters -- not the client of the augmenting module. > > The point is that if the old client creates an entry in xxx, it will never > set the xxx:yyy/type to foo:foo (since it doesn't know about foo), and > since the augment was conditional based on foo:foo, there are no > mandatory nodes in effect. So this augment is "safe" in the sense > that it doesn't break the old client. > > The 'type' leaf is an independent variable. It can be set to 'foo:foo' by any client, and when that happens the mandatory leaf is visible to the old client. The old client can no longer create 'yyy'. However, once 'type' is set to 'foo:foo' and if the 'yyy' node already exists, then the validation will fail unless 'my-leaf' is provided. But if 'yyy' does not exist yet, the validation for changing 'type' will succeed, and an old client can no longer create 'yyy' (because my-leaf is now mandatory. > > /martin > Andy --001a113a9238c633ed04f5e806b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 31, 2014 at 7:26 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Andy Bierman <and= y@yumaworks.com> wrote:
> On Mon, Mar 31, 2014 at 2:09 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Ladislav Lhotka <lhotka@nic.c= z> wrote:
> > >
> > > On 31 Mar 2014, at 10:26, Martin Bjorklund <mbj@tail-f.com> wrote:
> > >
> > > > Ladislav Lhotka <lh= otka@nic.cz> wrote:
> > > >>
> > > >> On 31 Mar 2014, at 09:31, Martin Bjorklund <mbj@tail-f.com> wrote:
> > > >>
> > > >>> Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > >>>>
> > > >>>> On 31 Mar 2014, at 09:25, Martin Bjorklund = <mbj@tail-f.com> wrote:
> > > >>>>
> > > >>>>> Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > >>>>>>
> > > >>>>>> On 29 Mar 2014, at 13:11, Martin Bj= orklund <mbj@tail-f.com>
> > wrote:
> > > >>>>>>
> > > >>>>>>> Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > >>>>>>>> One idea - would it be poss= ible to use the packages is a way
> > that
> > > >>>>>>>> guarantees
> > > >>>>>>>> that every package is self-= sustainable? This could solve this
> > issue.
> > > >>>>>>>
> > > >>>>>>> So you want to have individuall= y revisioned modules, and an
> > revisioned
> > > >>>>>>> package that collects a set of = modules, and the server then
> > advertises
> > > >>>>>>> the package?
> > > >>>>>>>
> > > >>>>>>> We already have that; use indiv= idually revisioned submodules,
> > and let
> > > >>>>>>> the module collect the set of s= ubmodules, and the server would
> > > >>>>>>> advertise the module. =A0This w= orks today, and it solves your
> > augment
> > > >>>>>>> issue.
> > > >>>>>>
> > > >>>>>> No, it doesn't. Submodules are = not practical for distributed
> > > >>>>>> development because with each new s= ubmodule one has to change the
> > main
> > > >>>>>> module as well.
> > > >>>>>
> > > >>>>> If you instead have a package listing a= ll modules, you have to
> > update
> > > >>>>> the package. =A0So how is this differen= t?
> > > >>>>
> > > >>>> A package won't be published as an RFC,= I reckon.
> > > >>>
> > > >>> The package is supposedly the conformance requi= rements. =A0So we push
> > > >>> the conformance requirements to the vendors? = =A0Each implementation
> > > >>> specifiy its own requirements?
> > > >>
> > > >> Not necessarily, although even that would be better= than no
> > > >> conformance information.
> > > >>
> > > >> Without considering the IETF workflow, imagine you = are a maintainer of
> > > >> the interfaces module and somebody else wants to wr= ite a module for a
> > > >> new interface type, perhaps proprietary or experime= ntal. Would you
> > > >> want to update the interfaces module (or package) f= or every new
> > > >> interface type?
> > > >
> > > > No, but I am not suggesting that! =A0I am suggesting th= at packages don't
> > > > solve this issue - they just move the problem.
> > > >
> > > > I think it would be great if we could allow:
> > > >
> > > > =A0module foo {
> > > > =A0 =A0...
> > > > =A0 =A0identity foo;
> > > >
> > > > =A0 =A0augment /xxx:yyy/ {
> > > > =A0 =A0 =A0when "type =3D foo:foo";
> > > > =A0 =A0 =A0leaf my-leaf {
> > > > =A0 =A0 =A0 =A0mandatory true;
> > > > =A0 =A0 =A0 =A0...
> > > > =A0 =A0 =A0}
> > > > =A0 =A0}
> > > > =A0}
> > > >
> > > > I.e., allow "safe" augmentation of mandatory = nodes.
> > > >
> >
>
>
>
> This does not work since module xxx knows nothing of this
> module., =A0It is the client of the augmented module that
> matters -- not the client of the augmenting module.

The point is that if the old client creates an entry in xxx, it will never<= br> set the xxx:yyy/type to foo:foo (since it doesn't know about foo), and<= br> since the augment was conditional based on foo:foo, there are no
mandatory nodes in effect. =A0So this augment is "safe" in the se= nse
that it doesn't break the old client.


The 'type' leaf is an independent variable.
<= div>It can be set to 'foo:foo' by any client, and when that happens=
the mandatory leaf is visible to the old client.
The old cli= ent can no longer create =A0'yyy'.

However= , once 'type' is set to 'foo:foo' and if the 'yyy' = node
already exists, then the validation will fail unless 'my-leaf'= is provided.
But if 'yyy' does not exist yet, the valida= tion for changing 'type' will succeed,
and an old client = can no longer create 'yyy' (because my-leaf is now mandatory.





/martin


<= /div>
Andy

--001a113a9238c633ed04f5e806b8-- From nobody Mon Mar 31 07:52:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470BA1A6F0C for ; Mon, 31 Mar 2014 07:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9IhWzC6PoXp for ; Mon, 31 Mar 2014 07:52:08 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 5263E1A6EEA for ; Mon, 31 Mar 2014 07:52:08 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id EF3FE3B413A; Mon, 31 Mar 2014 16:52:03 +0200 (CEST) Date: Mon, 31 Mar 2014 16:52:03 +0200 (CEST) Message-Id: <20140331.165203.859779053689592568.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140331.162658.1671291749949686916.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/dJKSJGrxqJMreBMfe3XU8RK8WhY Cc: netmod@ietf.org Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 14:52:10 -0000 Andy Bierman wrote: > On Mon, Mar 31, 2014 at 7:26 AM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > On Mon, Mar 31, 2014 at 2:09 AM, Martin Bjorklund > > wrote: > > > > > > > Ladislav Lhotka wrote: > > > > > > > > > > On 31 Mar 2014, at 10:26, Martin Bjorklund wrote: > > > > > > > > > > > Ladislav Lhotka wrote: > > > > > >> > > > > > >> On 31 Mar 2014, at 09:31, Martin Bjorklund > > wrote: > > > > > >> > > > > > >>> Ladislav Lhotka wrote: > > > > > >>>> > > > > > >>>> On 31 Mar 2014, at 09:25, Martin Bjorklund > > wrote: > > > > > >>>> > > > > > >>>>> Ladislav Lhotka wrote: > > > > > >>>>>> > > > > > >>>>>> On 29 Mar 2014, at 13:11, Martin Bjorklund > > > > wrote: > > > > > >>>>>> > > > > > >>>>>>> Ladislav Lhotka wrote: > > > > > >>>>>>>> One idea - would it be possible to use the packages is a way > > > > that > > > > > >>>>>>>> guarantees > > > > > >>>>>>>> that every package is self-sustainable? This could solve > > this > > > > issue. > > > > > >>>>>>> > > > > > >>>>>>> So you want to have individually revisioned modules, and an > > > > revisioned > > > > > >>>>>>> package that collects a set of modules, and the server then > > > > advertises > > > > > >>>>>>> the package? > > > > > >>>>>>> > > > > > >>>>>>> We already have that; use individually revisioned submodules, > > > > and let > > > > > >>>>>>> the module collect the set of submodules, and the server > > would > > > > > >>>>>>> advertise the module. This works today, and it solves your > > > > augment > > > > > >>>>>>> issue. > > > > > >>>>>> > > > > > >>>>>> No, it doesn't. Submodules are not practical for distributed > > > > > >>>>>> development because with each new submodule one has to change > > the > > > > main > > > > > >>>>>> module as well. > > > > > >>>>> > > > > > >>>>> If you instead have a package listing all modules, you have to > > > > update > > > > > >>>>> the package. So how is this different? > > > > > >>>> > > > > > >>>> A package won't be published as an RFC, I reckon. > > > > > >>> > > > > > >>> The package is supposedly the conformance requirements. So we > > push > > > > > >>> the conformance requirements to the vendors? Each implementation > > > > > >>> specifiy its own requirements? > > > > > >> > > > > > >> Not necessarily, although even that would be better than no > > > > > >> conformance information. > > > > > >> > > > > > >> Without considering the IETF workflow, imagine you are a > > maintainer of > > > > > >> the interfaces module and somebody else wants to write a module > > for a > > > > > >> new interface type, perhaps proprietary or experimental. Would you > > > > > >> want to update the interfaces module (or package) for every new > > > > > >> interface type? > > > > > > > > > > > > No, but I am not suggesting that! I am suggesting that packages > > don't > > > > > > solve this issue - they just move the problem. > > > > > > > > > > > > I think it would be great if we could allow: > > > > > > > > > > > > module foo { > > > > > > ... > > > > > > identity foo; > > > > > > > > > > > > augment /xxx:yyy/ { > > > > > > when "type = foo:foo"; > > > > > > leaf my-leaf { > > > > > > mandatory true; > > > > > > ... > > > > > > } > > > > > > } > > > > > > } > > > > > > > > > > > > I.e., allow "safe" augmentation of mandatory nodes. > > > > > > > > > > > > > > > > > > > > > > This does not work since module xxx knows nothing of this > > > module., It is the client of the augmented module that > > > matters -- not the client of the augmenting module. > > > > The point is that if the old client creates an entry in xxx, it will never > > set the xxx:yyy/type to foo:foo (since it doesn't know about foo), and > > since the augment was conditional based on foo:foo, there are no > > mandatory nodes in effect. So this augment is "safe" in the sense > > that it doesn't break the old client. > > > > > The 'type' leaf is an independent variable. > It can be set to 'foo:foo' by any client, and when that happens > the mandatory leaf is visible to the old client. > The old client can no longer create 'yyy'. No, 'type' is not indepent; it is in list 'yyy'. Let's do this with a more real-world example, from ietf-interfaces: container interfaces { ... list interface { key "name"; leaf type { type identityref { base interface-type; } ... } } module ex-ethernet { ... identity my-ethernet { base if:interface-type; } augment /if:interfaces/if:interface { when "if:type = ex:my-ethernet"; leaf my-mandatory-leaf { mandatory true; ... } } } A client that doesn't know anything about 'my-ethernet' can still create all other interfaces it knows about. /martin From nobody Mon Mar 31 08:13:19 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBF81A6F0B for ; Mon, 31 Mar 2014 08:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuLqbqrsCII8 for ; Mon, 31 Mar 2014 08:13:13 -0700 (PDT) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by ietfa.amsl.com (Postfix) with ESMTP id 621441A6F36 for ; Mon, 31 Mar 2014 08:13:08 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id r10so8108901pdi.16 for ; Mon, 31 Mar 2014 08:13:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ogzr7j/FvPiU2+Hig65lciS3dDIkTMPnvvWhUjGo7go=; b=CslDDyk3skx6TgY/IPho0GoaJdBbC1BitxNpNyPwqdqOPCBg+psqSQwVfcGhqP4YOy /qjmKoGQ7zKp0POjH55aadQcDCK2qq/JhtuPxYxS93haGngcOkJNkjsCpy7mAa4/n/S2 YYEy1AJ8VQGJ6DD5E8fwMUuSJ9kTsBRjsBH/SJcKtHnrJ3d4/wjrZDo03RnBS77suuYM nBEIt80c+eji7SYopjqfnbIYrzVEpNnwY2COVhJVXCXGCrKkWKflBkQsDj1u4QiqXhj3 mfMAr8jwEN03QHOy0p1zTbuNQi96SNQpD8/Tu4I0NQND6RzOawf+Ii32nupTrDJRU2E6 zuoQ== X-Gm-Message-State: ALoCoQkq7saYQZsjgLwcbepmCR+7ONk2I0meVxzIXu+yIol6N9xApERsg2cypO1QY85UoyOCL5SD MIME-Version: 1.0 X-Received: by 10.68.197.36 with SMTP id ir4mr25848833pbc.46.1396278785238; Mon, 31 Mar 2014 08:13:05 -0700 (PDT) Received: by 10.68.163.99 with HTTP; Mon, 31 Mar 2014 08:13:05 -0700 (PDT) In-Reply-To: <20140331.165203.859779053689592568.mbj@tail-f.com> References: <20140331.162658.1671291749949686916.mbj@tail-f.com> <20140331.165203.859779053689592568.mbj@tail-f.com> Date: Mon, 31 Mar 2014 08:13:05 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=e89a8ff1c840007d9304f5e87d07 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/0ufag8chbHdOZ6vKBJvLHN8vsBI Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 15:13:15 -0000 --e89a8ff1c840007d9304f5e87d07 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 31, 2014 at 7:52 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Mon, Mar 31, 2014 at 7:26 AM, Martin Bjorklund > wrote: > > > > > Andy Bierman wrote: > > > > On Mon, Mar 31, 2014 at 2:09 AM, Martin Bjorklund > > > wrote: > > > > > > > > > Ladislav Lhotka wrote: > > > > > > > > > > > > On 31 Mar 2014, at 10:26, Martin Bjorklund > wrote: > > > > > > > > > > > > > Ladislav Lhotka wrote: > > > > > > >> > > > > > > >> On 31 Mar 2014, at 09:31, Martin Bjorklund > > > wrote: > > > > > > >> > > > > > > >>> Ladislav Lhotka wrote: > > > > > > >>>> > > > > > > >>>> On 31 Mar 2014, at 09:25, Martin Bjorklund > > > wrote: > > > > > > >>>> > > > > > > >>>>> Ladislav Lhotka wrote: > > > > > > >>>>>> > > > > > > >>>>>> On 29 Mar 2014, at 13:11, Martin Bjorklund < > mbj@tail-f.com> > > > > > wrote: > > > > > > >>>>>> > > > > > > >>>>>>> Ladislav Lhotka wrote: > > > > > > >>>>>>>> One idea - would it be possible to use the packages is > a way > > > > > that > > > > > > >>>>>>>> guarantees > > > > > > >>>>>>>> that every package is self-sustainable? This could solve > > > this > > > > > issue. > > > > > > >>>>>>> > > > > > > >>>>>>> So you want to have individually revisioned modules, and > an > > > > > revisioned > > > > > > >>>>>>> package that collects a set of modules, and the server > then > > > > > advertises > > > > > > >>>>>>> the package? > > > > > > >>>>>>> > > > > > > >>>>>>> We already have that; use individually revisioned > submodules, > > > > > and let > > > > > > >>>>>>> the module collect the set of submodules, and the server > > > would > > > > > > >>>>>>> advertise the module. This works today, and it solves > your > > > > > augment > > > > > > >>>>>>> issue. > > > > > > >>>>>> > > > > > > >>>>>> No, it doesn't. Submodules are not practical for > distributed > > > > > > >>>>>> development because with each new submodule one has to > change > > > the > > > > > main > > > > > > >>>>>> module as well. > > > > > > >>>>> > > > > > > >>>>> If you instead have a package listing all modules, you > have to > > > > > update > > > > > > >>>>> the package. So how is this different? > > > > > > >>>> > > > > > > >>>> A package won't be published as an RFC, I reckon. > > > > > > >>> > > > > > > >>> The package is supposedly the conformance requirements. So > we > > > push > > > > > > >>> the conformance requirements to the vendors? Each > implementation > > > > > > >>> specifiy its own requirements? > > > > > > >> > > > > > > >> Not necessarily, although even that would be better than no > > > > > > >> conformance information. > > > > > > >> > > > > > > >> Without considering the IETF workflow, imagine you are a > > > maintainer of > > > > > > >> the interfaces module and somebody else wants to write a > module > > > for a > > > > > > >> new interface type, perhaps proprietary or experimental. > Would you > > > > > > >> want to update the interfaces module (or package) for every > new > > > > > > >> interface type? > > > > > > > > > > > > > > No, but I am not suggesting that! I am suggesting that > packages > > > don't > > > > > > > solve this issue - they just move the problem. > > > > > > > > > > > > > > I think it would be great if we could allow: > > > > > > > > > > > > > > module foo { > > > > > > > ... > > > > > > > identity foo; > > > > > > > > > > > > > > augment /xxx:yyy/ { > > > > > > > when "type = foo:foo"; > > > > > > > leaf my-leaf { > > > > > > > mandatory true; > > > > > > > ... > > > > > > > } > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > I.e., allow "safe" augmentation of mandatory nodes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > This does not work since module xxx knows nothing of this > > > > module., It is the client of the augmented module that > > > > matters -- not the client of the augmenting module. > > > > > > The point is that if the old client creates an entry in xxx, it will > never > > > set the xxx:yyy/type to foo:foo (since it doesn't know about foo), and > > > since the augment was conditional based on foo:foo, there are no > > > mandatory nodes in effect. So this augment is "safe" in the sense > > > that it doesn't break the old client. > > > > > > > > The 'type' leaf is an independent variable. > > It can be set to 'foo:foo' by any client, and when that happens > > the mandatory leaf is visible to the old client. > > The old client can no longer create 'yyy'. > > No, 'type' is not indepent; it is in list 'yyy'. Let's do this with a > more real-world example, from ietf-interfaces: > > container interfaces { > ... > list interface { > key "name"; > leaf type { > type identityref { > base interface-type; > } > ... > } > } > > module ex-ethernet { > ... > identity my-ethernet { > base if:interface-type; > } > augment /if:interfaces/if:interface { > when "if:type = ex:my-ethernet"; > leaf my-mandatory-leaf { > mandatory true; > ... > } > } > } > > A client that doesn't know anything about 'my-ethernet' can still > create all other interfaces it knows about. > > OK - this seems hard to write up. How does the YANG compiler know that revision X is the one that introduced the my-ethernet identity? What if the old client knows about ex-ethernet, in the version that you describe above, but then the module is changed in a new version, and 'another-mandatory-leaf' is added? augment /if:interfaces/if:interface { when "if:type = ex:my-ethernet"; leaf my-mandatory-leaf { mandatory true; ... } leaf another-mandatory-leaf { mandatory true; type string; } } Is this allowed? The sec. 10 rules do not allow it. > > /martin > Andy --e89a8ff1c840007d9304f5e87d07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 31, 2014 at 7:52 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Andy Bierman <and= y@yumaworks.com> wrote:
> On Mon, Mar 31, 2014 at 7:26 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > On Mon, Mar 31, 2014 at 2:09 AM, Martin Bjorklund <mbj@tail-f.com>
> > wrote:
> > >
> > > > Ladislav Lhotka <lh= otka@nic.cz> wrote:
> > > > >
> > > > > On 31 Mar 2014, at 10:26, Martin Bjorklund <mbj@tail-f.com> wrote:
> > > > >
> > > > > > Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > > > >>
> > > > > >> On 31 Mar 2014, at 09:31, Martin Bjorklun= d <mbj@tail-f.com>
> > wrote:
> > > > > >>
> > > > > >>> Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > > > >>>>
> > > > > >>>> On 31 Mar 2014, at 09:25, Martin = Bjorklund <mbj@tail-f.com>
> > wrote:
> > > > > >>>>
> > > > > >>>>> Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > > > >>>>>>
> > > > > >>>>>> On 29 Mar 2014, at 13:11,= Martin Bjorklund <mbj@tail-f.com&= gt;
> > > > wrote:
> > > > > >>>>>>
> > > > > >>>>>>> Ladislav Lhotka <<= a href=3D"mailto:lhotka@nic.cz">lhotka@nic.cz> wrote:
> > > > > >>>>>>>> One idea - would = it be possible to use the packages is a way
> > > > that
> > > > > >>>>>>>> guarantees
> > > > > >>>>>>>> that every packag= e is self-sustainable? This could solve
> > this
> > > > issue.
> > > > > >>>>>>>
> > > > > >>>>>>> So you want to have i= ndividually revisioned modules, and an
> > > > revisioned
> > > > > >>>>>>> package that collects= a set of modules, and the server then
> > > > advertises
> > > > > >>>>>>> the package?
> > > > > >>>>>>>
> > > > > >>>>>>> We already have that;= use individually revisioned submodules,
> > > > and let
> > > > > >>>>>>> the module collect th= e set of submodules, and the server
> > would
> > > > > >>>>>>> advertise the module.= =A0This works today, and it solves your
> > > > augment
> > > > > >>>>>>> issue.
> > > > > >>>>>>
> > > > > >>>>>> No, it doesn't. Submo= dules are not practical for distributed
> > > > > >>>>>> development because with = each new submodule one has to change
> > the
> > > > main
> > > > > >>>>>> module as well.
> > > > > >>>>>
> > > > > >>>>> If you instead have a package= listing all modules, you have to
> > > > update
> > > > > >>>>> the package. =A0So how is thi= s different?
> > > > > >>>>
> > > > > >>>> A package won't be published = as an RFC, I reckon.
> > > > > >>>
> > > > > >>> The package is supposedly the conform= ance requirements. =A0So we
> > push
> > > > > >>> the conformance requirements to the v= endors? =A0Each implementation
> > > > > >>> specifiy its own requirements?
> > > > > >>
> > > > > >> Not necessarily, although even that would= be better than no
> > > > > >> conformance information.
> > > > > >>
> > > > > >> Without considering the IETF workflow, im= agine you are a
> > maintainer of
> > > > > >> the interfaces module and somebody else w= ants to write a module
> > for a
> > > > > >> new interface type, perhaps proprietary o= r experimental. Would you
> > > > > >> want to update the interfaces module (or = package) for every new
> > > > > >> interface type?
> > > > > >
> > > > > > No, but I am not suggesting that! =A0I am sug= gesting that packages
> > don't
> > > > > > solve this issue - they just move the problem= .
> > > > > >
> > > > > > I think it would be great if we could allow:<= br> > > > > > >
> > > > > > =A0module foo {
> > > > > > =A0 =A0...
> > > > > > =A0 =A0identity foo;
> > > > > >
> > > > > > =A0 =A0augment /xxx:yyy/ {
> > > > > > =A0 =A0 =A0when "type =3D foo:foo";=
> > > > > > =A0 =A0 =A0leaf my-leaf {
> > > > > > =A0 =A0 =A0 =A0mandatory true;
> > > > > > =A0 =A0 =A0 =A0...
> > > > > > =A0 =A0 =A0}
> > > > > > =A0 =A0}
> > > > > > =A0}
> > > > > >
> > > > > > I.e., allow "safe" augmentation of = mandatory nodes.
> > > > > >
> > > >
> > >
> > >
> > >
> > > This does not work since module xxx knows nothing of this > > > module., =A0It is the client of the augmented module that > > > matters -- not the client of the augmenting module.
> >
> > The point is that if the old client creates an entry in xxx, it w= ill never
> > set the xxx:yyy/type to foo:foo (since it doesn't know about = foo), and
> > since the augment was conditional based on foo:foo, there are no<= br> > > mandatory nodes in effect. =A0So this augment is "safe"= in the sense
> > that it doesn't break the old client.
> >
> >
> The 'type' leaf is an independent variable.
> It can be set to 'foo:foo' by any client, and when that happen= s
> the mandatory leaf is visible to the old client.
> The old client can no longer create =A0'yyy'.

No, 'type' is not indepent; it is in list 'yyy'. =A0Let'= ;s do this with a
more real-world example, from ietf-interfaces:

=A0 container interfaces {
=A0 =A0 ...
=A0 =A0 list interface {
=A0 =A0 =A0 key "name";
=A0 =A0 =A0 leaf type {
=A0 =A0 =A0 =A0 type identityref {
=A0 =A0 =A0 =A0 =A0 base interface-type;
=A0 =A0 =A0 =A0 }
=A0 =A0 =A0 ...
=A0 =A0 }
=A0 }

=A0 module ex-ethernet {
=A0 =A0 =A0...
=A0 =A0 =A0identity my-ethernet {
=A0 =A0 =A0 =A0base if:interface-type;
=A0 =A0 =A0}
=A0 =A0 =A0augment /if:interfaces/if:interface {
=A0 =A0 =A0 =A0when "if:type =3D ex:my-ethernet";
=A0 =A0 =A0 =A0leaf my-mandatory-leaf {
=A0 =A0 =A0 =A0 =A0mandatory true;
=A0 =A0 =A0 =A0 =A0...
=A0 =A0 =A0 =A0}
=A0 =A0 =A0}
=A0 =A0}

A client that doesn't know anything about 'my-ethernet' can sti= ll
create all other interfaces it knows about.


OK - this seems hard to write up.
How does the Y= ANG compiler know that revision X is the
one that introduced the = my-ethernet identity?

What if the old client knows about ex-ethernet, in the = version
that you describe above, but then the module is changed i= n a new
version, and 'another-mandatory-leaf' is added?

=A0 =A0 =A0augment /if:interfaces/if:interface {
=A0= =A0 =A0 =A0when "if:type =3D ex:my-ethernet";
=A0 =A0 =A0 =A0= leaf my-mandatory-leaf {
=A0 =A0 =A0 =A0 =A0mandatory true;
=A0 =A0 = =A0 =A0 =A0...
=A0 =A0 =A0 =A0 }

=A0 =A0 =A0 =A0 leaf another-mandatory-leaf {
=A0 = =A0 =A0 =A0 =A0 mandatory true;
=A0 =A0 =A0 =A0 =A0 type string;<= /div>
=A0 =A0 =A0 =A0 }
=A0 =A0 }

Is= this allowed?
The sec. 10 rules do not allow it.



=A0

/martin

Andy<= /div>

--e89a8ff1c840007d9304f5e87d07-- From nobody Mon Mar 31 09:12:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0331A6F37 for ; Mon, 31 Mar 2014 09:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JGqbEVy6HUd for ; Mon, 31 Mar 2014 09:12:39 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 476EF1A6F11 for ; Mon, 31 Mar 2014 09:12:39 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id F2F1613F686; Mon, 31 Mar 2014 18:12:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1396282355; bh=6lhe+GkLJcyAy7ouwgiNKyeqlkzxCZkjV62WVmwuE0w=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=dcO5PdKkeydXuhho0jjdOtBUJH83T0XT9G8t79tCSuqbz4VnSNFu30TrW1I3Lyqsu bstSLFs4rYEV9rSs1tVDATfS2Wr68NQQ5jjonXpT6P0qLABPkYF9Cgw0VJtja5Ci4h YBAwY0xI58jzSWtAFJgOn2mOpnELgUy5p0+5Vio4= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 31 Mar 2014 18:12:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140331.162658.1671291749949686916.mbj@tail-f.com> <20140331.165203.859779053689592568.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cLOWun-hhq3-a4Cuh2n3B2xlbrE Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:12:42 -0000 On 31 Mar 2014, at 17:13, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Mar 31, 2014 at 7:52 AM, Martin Bjorklund = wrote: > Andy Bierman wrote: > > On Mon, Mar 31, 2014 at 7:26 AM, Martin Bjorklund = wrote: > > > > > Andy Bierman wrote: > > > > On Mon, Mar 31, 2014 at 2:09 AM, Martin Bjorklund = > > > wrote: > > > > > > > > > Ladislav Lhotka wrote: > > > > > > > > > > > > On 31 Mar 2014, at 10:26, Martin Bjorklund = wrote: > > > > > > > > > > > > > Ladislav Lhotka wrote: > > > > > > >> > > > > > > >> On 31 Mar 2014, at 09:31, Martin Bjorklund = > > > wrote: > > > > > > >> > > > > > > >>> Ladislav Lhotka wrote: > > > > > > >>>> > > > > > > >>>> On 31 Mar 2014, at 09:25, Martin Bjorklund = > > > wrote: > > > > > > >>>> > > > > > > >>>>> Ladislav Lhotka wrote: > > > > > > >>>>>> > > > > > > >>>>>> On 29 Mar 2014, at 13:11, Martin Bjorklund = > > > > > wrote: > > > > > > >>>>>> > > > > > > >>>>>>> Ladislav Lhotka wrote: > > > > > > >>>>>>>> One idea - would it be possible to use the packages = is a way > > > > > that > > > > > > >>>>>>>> guarantees > > > > > > >>>>>>>> that every package is self-sustainable? This could = solve > > > this > > > > > issue. > > > > > > >>>>>>> > > > > > > >>>>>>> So you want to have individually revisioned modules, = and an > > > > > revisioned > > > > > > >>>>>>> package that collects a set of modules, and the = server then > > > > > advertises > > > > > > >>>>>>> the package? > > > > > > >>>>>>> > > > > > > >>>>>>> We already have that; use individually revisioned = submodules, > > > > > and let > > > > > > >>>>>>> the module collect the set of submodules, and the = server > > > would > > > > > > >>>>>>> advertise the module. This works today, and it = solves your > > > > > augment > > > > > > >>>>>>> issue. > > > > > > >>>>>> > > > > > > >>>>>> No, it doesn't. Submodules are not practical for = distributed > > > > > > >>>>>> development because with each new submodule one has = to change > > > the > > > > > main > > > > > > >>>>>> module as well. > > > > > > >>>>> > > > > > > >>>>> If you instead have a package listing all modules, you = have to > > > > > update > > > > > > >>>>> the package. So how is this different? > > > > > > >>>> > > > > > > >>>> A package won't be published as an RFC, I reckon. > > > > > > >>> > > > > > > >>> The package is supposedly the conformance requirements. = So we > > > push > > > > > > >>> the conformance requirements to the vendors? Each = implementation > > > > > > >>> specifiy its own requirements? > > > > > > >> > > > > > > >> Not necessarily, although even that would be better than = no > > > > > > >> conformance information. > > > > > > >> > > > > > > >> Without considering the IETF workflow, imagine you are a > > > maintainer of > > > > > > >> the interfaces module and somebody else wants to write a = module > > > for a > > > > > > >> new interface type, perhaps proprietary or experimental. = Would you > > > > > > >> want to update the interfaces module (or package) for = every new > > > > > > >> interface type? > > > > > > > > > > > > > > No, but I am not suggesting that! I am suggesting that = packages > > > don't > > > > > > > solve this issue - they just move the problem. > > > > > > > > > > > > > > I think it would be great if we could allow: > > > > > > > > > > > > > > module foo { > > > > > > > ... > > > > > > > identity foo; > > > > > > > > > > > > > > augment /xxx:yyy/ { > > > > > > > when "type =3D foo:foo"; > > > > > > > leaf my-leaf { > > > > > > > mandatory true; > > > > > > > ... > > > > > > > } > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > I.e., allow "safe" augmentation of mandatory nodes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > This does not work since module xxx knows nothing of this > > > > module., It is the client of the augmented module that > > > > matters -- not the client of the augmenting module. > > > > > > The point is that if the old client creates an entry in xxx, it = will never > > > set the xxx:yyy/type to foo:foo (since it doesn't know about foo), = and > > > since the augment was conditional based on foo:foo, there are no > > > mandatory nodes in effect. So this augment is "safe" in the sense > > > that it doesn't break the old client. > > > > > > > > The 'type' leaf is an independent variable. > > It can be set to 'foo:foo' by any client, and when that happens > > the mandatory leaf is visible to the old client. > > The old client can no longer create 'yyy'. >=20 > No, 'type' is not indepent; it is in list 'yyy'. Let's do this with a > more real-world example, from ietf-interfaces: >=20 > container interfaces { > ... > list interface { > key "name"; > leaf type { > type identityref { > base interface-type; > } > ... > } > } >=20 > module ex-ethernet { > ... > identity my-ethernet { > base if:interface-type; > } > augment /if:interfaces/if:interface { > when "if:type =3D ex:my-ethernet"; > leaf my-mandatory-leaf { > mandatory true; > ... > } > } > } >=20 > A client that doesn't know anything about 'my-ethernet' can still > create all other interfaces it knows about. >=20 >=20 > OK - this seems hard to write up. > How does the YANG compiler know that revision X is the > one that introduced the my-ethernet identity? The server gives the information about its complete data model in hello. >=20 > What if the old client knows about ex-ethernet, in the version > that you describe above, but then the module is changed in a new > version, and 'another-mandatory-leaf' is added? A paranoid client that doesn=92t support the exact data model advertised = by the server would give up and close the session. Otherwise, it may try = some operation that will either succeed or fail with an error message = that should give the client sufficient information about the cause. A much worse scenario is that the operation succeeds but the device does = something else than what the client intended - the CLR in question = doesn=92t address this case at all, and that=92s why a security-savvy = client should not even try. Lada=20 >=20 > augment /if:interfaces/if:interface { > when "if:type =3D ex:my-ethernet"; > leaf my-mandatory-leaf { > mandatory true; > ... > } >=20 > leaf another-mandatory-leaf { > mandatory true; > type string; > } > } >=20 > Is this allowed? > The sec. 10 rules do not allow it. >=20 >=20 >=20 > =20 >=20 > /martin >=20 > Andy >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 31 10:06:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678F91A6F32 for ; Mon, 31 Mar 2014 10:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfFcp6Kp3PnG for ; Mon, 31 Mar 2014 10:06:43 -0700 (PDT) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) by ietfa.amsl.com (Postfix) with ESMTP id 00FB01A6F28 for ; Mon, 31 Mar 2014 10:06:42 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id e89so1035612qgf.12 for ; Mon, 31 Mar 2014 10:06:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=z4nTXM0ODxDRNWcpXPQWhaydWi3vslYKhXs7banFi0o=; b=A0STg3FEeO4hvyJnFMIrAjafUhMJWXaLhQM6uHEgOjj+YTAmYG5YEKYZsP7gQN80do IALT42JfoFxOMKdi6Zu926c3XgO1sT66qqYLr0ldYi9BJxZe/cthbLdRAot3FZWTQejz Vo48HJBgog3/UoC+9eMkEcSrCx527Z0ubXcrWxyfbjC3igULjD0nkEpxBdYIbcDY7W7W 9jZIwn9EDtTZjM/fuU1ajvAzsBRiVJ6/8dx85Ohv1Q1wxneLIOoYLwQ/90IhiScVC8UZ AiMKy3lekVCf0kl7TNJ9cSXUDn0j7RL+O6656QkRZu7TgKQnFwtqi3L/hMO32whJ//mh rU8A== X-Gm-Message-State: ALoCoQkLm841seUbqMvVPLBWyKsFf92fCwPIfVrDnWcxdNsFzhFj2Rizell4P8as/vvi9G/yUlgz MIME-Version: 1.0 X-Received: by 10.140.98.116 with SMTP id n107mr3786914qge.94.1396285599428; Mon, 31 Mar 2014 10:06:39 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Mon, 31 Mar 2014 10:06:38 -0700 (PDT) In-Reply-To: <20140331.165203.859779053689592568.mbj@tail-f.com> References: <20140331.162658.1671291749949686916.mbj@tail-f.com> <20140331.165203.859779053689592568.mbj@tail-f.com> Date: Mon, 31 Mar 2014 10:06:38 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a113a923829403a04f5ea13be Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-5HhTBX1psz2OxOKP-jm23gblT0 Cc: "netmod@ietf.org" Subject: Re: [netmod] allow mandatory nodes in augments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 17:06:44 -0000 --001a113a923829403a04f5ea13be Content-Type: text/plain; charset=ISO-8859-1 > .... > No, 'type' is not indepent; it is in list 'yyy'. Let's do this with a > more real-world example, from ietf-interfaces: > > The rule would be a lot easier to write if new value the old client did not know about was part of the list key. I don't see how this could work for containers, but it could work for lists. Andy container interfaces { > ... > list interface { > key "name"; > leaf type { > type identityref { > base interface-type; > } > ... > } > } > > module ex-ethernet { > ... > identity my-ethernet { > base if:interface-type; > } > augment /if:interfaces/if:interface { > when "if:type = ex:my-ethernet"; > leaf my-mandatory-leaf { > mandatory true; > ... > } > } > } > > A client that doesn't know anything about 'my-ethernet' can still > create all other interfaces it knows about. > > > /martin > --001a113a923829403a04f5ea13be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

=
....
No, 'type' is not indepent; it is in list 'yyy'. =A0Let'= ;s do this with a
more real-world example, from ietf-interfaces:



The rule would be a lot= easier to write if new value the
old client did not know about w= as part of the list key.

I don't see how this = could work for containers, but it
could work for lists.

=A0Andy

<= /div>

=A0 container interfaces {
=A0 =A0 ...
=A0 =A0 list interface {
=A0 =A0 =A0 key "name";
=A0 =A0 =A0 leaf type {
=A0 =A0 =A0 =A0 type identityref {
=A0 =A0 =A0 =A0 =A0 base interface-type;
=A0 =A0 =A0 =A0 }
=A0 =A0 =A0 ...
=A0 =A0 }
=A0 }

=A0 module ex-ethernet {
=A0 =A0 =A0...
=A0 =A0 =A0identity my-ethernet {
=A0 =A0 =A0 =A0base if:interface-type;
=A0 =A0 =A0}
=A0 =A0 =A0augment /if:interfaces/if:interface {
=A0 =A0 =A0 =A0when "if:type =3D ex:my-ethernet";
=A0 =A0 =A0 =A0leaf my-mandatory-leaf {
=A0 =A0 =A0 =A0 =A0mandatory true;
=A0 =A0 =A0 =A0 =A0...
=A0 =A0 =A0 =A0}
=A0 =A0 =A0}
=A0 =A0}

A client that doesn't know anything about 'my-ethernet' can sti= ll
create all other interfaces it knows about.


/martin

--001a113a923829403a04f5ea13be--