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