From nobody Fri Aug 1 01:03: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 978771A045B for ; Fri, 1 Aug 2014 01:03:52 -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 4j1YyaSXe4W3 for ; Fri, 1 Aug 2014 01:03:49 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DFC01A0442 for ; Fri, 1 Aug 2014 01:03:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id BA17C540854; Fri, 1 Aug 2014 10:03:46 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0tpwReQM3xV; Fri, 1 Aug 2014 10:03:41 +0200 (CEST) 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 26B3C540704; Fri, 1 Aug 2014 10:03:40 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , Benoit Claise In-Reply-To: <20140731160335.GA65079@elstar.local> References: <20140731160335.GA65079@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Fri, 01 Aug 2014 10:03:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6WNOEP_ATSXnYqjfRH-zgOUs2qA Cc: netmod@ietf.org Subject: Re: [netmod] NETMOD WG Interim Meeting, September 17-18, 2014 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Aug 2014 08:03:52 -0000 Hi, looking at booking.com, NY hotel prices seem to be outrageously expensive at that time. Is there any chance to get a reasonably priced hotel room? Thanks, Lada Juergen Schoenwaelder writes: > The IETF NETMOD WG will hold an Interim Meeting on September 17-18, > 2014. The meeting will take place at One Penn Plaza, 9th Floor New > York, NY 10119 USA. > > The agenda of the meeting is to work on YANG 1.1 open issues and in > particular on > > - issues related to YANG 1.1 conformance; > - issues related to YANG 1.1 datastores and I2RS support; > - any remaining open YANG 1.1 issues. > > If you'd like to attend, please register by sending an email to the > NETMOD WG chairs. The meeting details with further information about > the participants and meeting logistics will be maintained in the SVN > of the NETMOD working group > > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ > > and also posted on the NETMOD mailing list. A preliminary list of > participants is on the following Doodle poll: > > http://doodle.com/7eptxb7mggtdhwmc > > /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 Fri Aug 1 01:33:21 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD631A010D for ; Fri, 1 Aug 2014 01:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-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 7l3RE-ajGJaL for ; Fri, 1 Aug 2014 01:33:17 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB5C11A00EA for ; Fri, 1 Aug 2014 01:33:16 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1F251753; Fri, 1 Aug 2014 10:33:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id G4uEYmDDCPqF; Fri, 1 Aug 2014 10:33:13 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 1 Aug 2014 10:33:14 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8BF5020017; Fri, 1 Aug 2014 10:33:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9uBgfGZLdSvL; Fri, 1 Aug 2014 10:33:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B41620031; Fri, 1 Aug 2014 10:33:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6A9422E01769; Fri, 1 Aug 2014 10:33:13 +0200 (CEST) Date: Fri, 1 Aug 2014 10:33:13 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140801083313.GD66818@elstar.local> Mail-Followup-To: Ladislav Lhotka , Benoit Claise , netmod@ietf.org References: <20140731160335.GA65079@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/sN2CufUj6lmq3sONE8BAh75z0gw Cc: netmod@ietf.org Subject: Re: [netmod] NETMOD WG Interim Meeting, September 17-18, 2014 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 08:33:19 -0000 On Fri, Aug 01, 2014 at 10:03:40AM +0200, Ladislav Lhotka wrote: > Hi, > > looking at booking.com, NY hotel prices seem to be outrageously expensive > at that time. Is there any chance to get a reasonably priced hotel room? > I assume reasonably priced options likely require you to stay somewhere in Newark and to commute into the city. Does someone who knows the area better have any recommendations? Note: Before you make fixed travel plans, please note that the interim still needs approval - so wait for the official announcement. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Aug 1 01:39: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 694121A03F7 for ; Fri, 1 Aug 2014 01:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 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.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 S_1vNq5UOyyE for ; Fri, 1 Aug 2014 01:39:18 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6ECA1A010D for ; Fri, 1 Aug 2014 01:39:17 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 7945A140445; Fri, 1 Aug 2014 10:39:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1406882355; bh=fG+1aNZcRWsx7J5x9PXSr/UCdLw0Ak4BFdyA7+kXg58=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nOMWACXjEDuL7AjvoNw6VDMaYQr9TqKTjsU63RvWJzCgxVeu51ln3ZnDuFPt5dyeB fqnIaTD6FnjgdQvY20oy1SnMw7S0u1ol0ySCoYF6G8BjI9zW1y6PG66dIcTTWRaaI6 9Flx9pZ7s7WBVuV1zU08zLhLgkJWcTxuzy8lo43I= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140801083313.GD66818@elstar.local> Date: Fri, 1 Aug 2014 10:39:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140731160335.GA65079@elstar.local> <20140801083313.GD66818@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/be7kHlWfPbqgBTiv3Z82on5IUuE Cc: netmod@ietf.org Subject: Re: [netmod] NETMOD WG Interim Meeting, September 17-18, 2014 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Aug 2014 08:39:20 -0000 On 01 Aug 2014, at 10:33, Juergen Schoenwaelder = wrote: > On Fri, Aug 01, 2014 at 10:03:40AM +0200, Ladislav Lhotka wrote: >> Hi, >>=20 >> looking at booking.com, NY hotel prices seem to be outrageously = expensive >> at that time. Is there any chance to get a reasonably priced hotel = room? >>=20 >=20 > I assume reasonably priced options likely require you to stay > somewhere in Newark and to commute into the city. Does someone who > knows the area better have any recommendations? Yes, I don=92t mind commuting but I need some advice in order to avoid = troubles. >=20 > Note: Before you make fixed travel plans, please note that the interim > still needs approval - so wait for the official announcement. Sure, I just need a preliminary approval from my bosses, so I have to = provide an estimate of the expenses. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Aug 1 04:34: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 90DD81A0A8B; Fri, 1 Aug 2014 04:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 6QVDrPP4veMK; Fri, 1 Aug 2014 04:18:03 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC081A0658; Fri, 1 Aug 2014 04:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=134; q=dns/txt; s=iport; t=1406891884; x=1408101484; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=sTr/p5H8m5XWtgyT7z2WVP/r5mMRuAffVfehEzQ9fFc=; b=hE/Ilt5/WSjKhlMuqJHuTkYQMr2i2zJs7N3WlMIBZXRXgmjDJl4jHyVr Uhj5bZgAMnvWjxdad8uPEdc67efMV0WObaKONIwMwDGGy8nENZJZiJd48 NUqnAyMcp4Rzn/o2s9eU6aHBXfzE5t66CPDXNpXAjJUBNC1QdXnIpFElK E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsLADh321OtJssW/2dsb2JhbABbg18aPoJ3ijW+X4hod4QtFUA2AgUWCwILAwIBAgFLDQgBAQWIOQ2iRI8rl3IXgSyRIIFSAQSbdYchjTeDSzs X-IronPort-AV: E=Sophos;i="5.01,779,1400025600"; d="scan'208";a="129684896" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 01 Aug 2014 11:17:45 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s71BHhmf013670; Fri, 1 Aug 2014 11:17:43 GMT Message-ID: <53DB7757.8000600@cisco.com> Date: Fri, 01 Aug 2014 13:17:43 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: IETF-Discussion list Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/lbseBVbFlJppkMnQVRJrmZSJU5w X-Mailman-Approved-At: Fri, 01 Aug 2014 04:34:35 -0700 Subject: [netmod] Blog: YANG Takes Off in the Industry X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Aug 2014 11:18:04 -0000 Dear all, [netmod WG list is bcc'ed] Enjoy http://www.ietf.org/blog/2014/07/yang-takes-off-in-the-industry/ Regards, Benoit From nobody Fri Aug 1 05:42: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 215431A0AE9 for ; Fri, 1 Aug 2014 05:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.877 X-Spam-Level: X-Spam-Status: No, score=-0.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=0.723, 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 e-EOcf_PZAlD for ; Fri, 1 Aug 2014 05:42:39 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BAC81A0AE8 for ; Fri, 1 Aug 2014 05:42:37 -0700 (PDT) X-AuditID: c1b4fb3a-f79a36d000000ffa-f2-53db8b3be5ef Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 93.BA.04090.B3B8BD35; Fri, 1 Aug 2014 14:42:35 +0200 (CEST) Received: from [159.107.198.99] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.174.1; Fri, 1 Aug 2014 14:42:34 +0200 Message-ID: <53DB8B39.6090805@ericsson.com> Date: Fri, 1 Aug 2014 14:42:33 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ladislav Lhotka , =?windows-1252?Q?J=FCrgen_Sch=F6nw?= =?windows-1252?Q?=E4lder?= References: <20140731160335.GA65079@elstar.local> <20140801083313.GD66818@elstar.local> In-Reply-To: Content-Type: multipart/related; boundary="------------030202030406030505000900" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCIsWRmVeSWpSXmKPExsUyM+Jvja519+1gg3sThS2ubvzJaHFh1Vw2 i/kXG1kdmD2WLPnJ5LHhgKfHpst3GAOYo7hsUlJzMstSi/TtErgyTk9tYSyYfJCtYlvXBZYG xoPvWboYOTgkBEwk5v3J7GLkBDLFJC7cW8/WxcjFISRwlFFi9elrLBDOakaJ/7/fsYNU8Qpo S+x+1sIKYrMIqEi8utrBAmKzCRhJTO0/D2aLCkRJ3LnUzwpRLyhxcuYTsEEiAr2MEusXHWIC STALiEqsv3gJzBYWcJNY9qafGWLbXEaJW7cawbZxClhJPDn2hgnkVGaBIIkL921BwkICGhIP L/xlncAoMAvJjlkIVbPANuhLXL9znxXClpdo3jqbGcIWl9h/pQ3KVpSY0v2QHcI2lph0YwIr ITU7O58xEVKz7sE+dkJqOh5MZiSk5vKTZpYFjMKrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2 MQKTxcEtv612MB587niIUYCDUYmHV6HlVrAQa2JZcWXuIUZpDhYlcd6F5+YFCwmkJ5akZqem FqQWxReV5qQWH2Jk4uCUamBct3zurEC+eaf+d7EphzVvvWB0QGr5otAva70e+LyaJGVj//vR 1dxN+yd5rjtxkq/xp83Rv9u6etN6lRl33fM6apzhWR3h55wXuC/tRPGU2mUXA6UY1y6Ybman vJVN/WIGW6rf1Yp9N1Zy378XKDjxsood294tR6OfL8u3Oz77fYvBRrXaw5niSizFGYmGWsxF xYkAf+1nxPcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fQ24F6bQi-gpXtc0nzv8ZcJDHZI Cc: netmod@ietf.org Subject: Re: [netmod] NETMOD WG Interim Meeting, September 17-18, 2014 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Aug 2014 12:42:41 -0000 --------------030202030406030505000900 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Hello Lada,
I would be most interested in some reasonable hotel. It would be very nice to be in the same place and travel together.

I got the following recommendations: ( I know nothing about them yet). However they are all 40-60 kms away.

Preference 1

Hotel Name

Postal City

GDS rates from

Rates from

ES

BS

 

Distance (km)

Classif.

 

 

https://www.cwtharp.com/HarpAgency/media/rond_vvg.gif

radisson hotel piscataway

piscataway



USD

99.00




48.0

3

https://www.cwtharp.com/HarpAgency/media/Galileo.gif

https://www.cwtharp.com/HarpAgency/media/Transparent.gif

https://www.cwtharp.com/HarpAgency/media/rond_vvg.gif

holiday inn parsippany

parsippany



USD

109.00



https://www.cwtharp.com/HarpAgency/media/IC_GreenLabel.gif

35.2

3

https://www.cwtharp.com/HarpAgency/media/Galileo.gif

https://www.cwtharp.com/HarpAgency/media/Transparent.gif

https://www.cwtharp.com/HarpAgency/media/rond_vvg.gif

esa piscataway rutgers university

piscataway



USD

110.00



https://www.cwtharp.com/HarpAgency/media/IC_GreenLabel.gif

25.0

2

https://www.cwtharp.com/HarpAgency/media/Galileo.gif

https://www.cwtharp.com/HarpAgency/media/Transparent.gif

https://www.cwtharp.com/HarpAgency/media/rond_vvg.gif

sheraton new york times square hotel

new york

USD

429.00



https://www.cwtharp.com/HarpAgency/media/IC_GreenLabel.gif

6.2

4

https://www.cwtharp.com/HarpAgency/media/Galileo.gif

https://www.cwtharp.com/HarpAgency/media/Transparent.gif

Preference 2

Hotel Name

Postal City

GDS rates from

Rates from

ES

BS

 

Distance (km)

Classif.

 

 

https://www.cwtharp.com/HarpAgency/media/rond_gvg.gif

sheraton edison

edison



USD

123.00



https://www.cwtharp.com/HarpAgency/media/IC_GreenLabel.gif

40.0

3

https://www.cwtharp.com/HarpAgency/media/Galileo.gif

https://www.cwtharp.com/HarpAgency/media/Transparent.gif

https://www.cwtharp.com/HarpAgency/media/rond_gvg.gif

fairfield inn & suites

parsippany



USD

129.00




48.0

2

https://www.cwtharp.com/HarpAgency/media/Galileo.gif

https://www.cwtharp.com/HarpAgency/media/Transparent.gif














Preference 3

Hotel Name

Postal City

GDS rates from

Rates from

ES

BS

 

Distance (km)

Classif.

 

 

https://www.cwtharp.com/HarpAgency/media/rond_vvg.gif

embassy suites piscataway

piscataway



USD

131.00



https://www.cwtharp.com/HarpAgency/media/IC_GreenLabel.gif

30.0

3

https://www.cwtharp.com/HarpAgency/media/Galileo.gif

https://www.cwtharp.com/HarpAgency/media/Transparent.gif

https://www.cwtharp.com/HarpAgency/media/rond_vvg.gif

residence inn parsippany

parsippany



USD

178.00



https://www.cwtharp.com/HarpAgency/media/IC_GreenLabel.gif

64.0

3

https://www.cwtharp.com/HarpAgency/media/Galileo.gif

https://www.cwtharp.com/HarpAgency/media/Transparent.gif

regards Balazs

On 2014-08-01 10:39, Ladislav Lhotka wrote:
On 01 Aug 2014, at 10:33, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:


On Fri, Aug 01, 2014 at 10:03:40AM +0200, Ladislav Lhotka wrote:

Hi,

looking at booking.com, NY hotel prices seem to be outrageously expensive
at that time. Is there any chance to get a reasonably priced hotel room?


I assume reasonably priced options likely require you to stay
somewhere in Newark and to commute into the city. Does someone who
knows the area better have any recommendations?

Yes, I don’t mind commuting but I need some advice in order to avoid troubles.


Note: Before you make fixed travel plans, please note that the interim
still needs approval - so wait for the official announcement.

Sure, I just need a preliminary approval from my bosses, so I have to provide an estimate of the expenses.

Lada


/js

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

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




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



-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
--------------030202030406030505000900 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlhKQANAIcAAAJueANyewFxfQByfAByfQBzfAB3fwF1ggJ3gAR0gAR2gAR2gQB7ggB7 gwF6gwF5hwB6hQF6hQJ7hgB8hAN7iwB/iAF/iwJ+iAt3gQx3gQt9hw18gxZ7hRl5hQGAhwCA iQCAiwCDjQCDjwCEjQKFjQSAigCJjgaKjwCDkAGDkACEkAeHkACJkACIkgCJkwCKkQKIkwCI lAGKlACPlQCOlgCPlwONmAONmgGQmACSmQCSmgCTmwGQngOTngCVnAGUngCXnxmOlR+LlxqV nR6UngKUoQOVogCZoQyZoA6ZoA+YohKYoRyiqx6kr2ClqmSjqGeusmqttmO+wWu6wWu8wGXA wZ+fn6GhoaampqioqKurq6ysrLCwsLGxsbKysre3t7i4uLm5ubq6uru7u7y8vL29vbTS1LbT 2bXf3rbb4cDAwMHBwcLCwsPDw8TExMbGxsfHx8nJycrKysvLy8zMzNLS0tPT09nZ2dra2t/f 39bk5dfl5dbo6NXo7Nnt7Nrs7Nns8Nrs8OLi4uPj4+fp5ufp6Ojo5urp5+jo6Onp6e/v7e7u 7u/v7+3u8O7v8e/x8PDv6/Dw7vHw7vHx7/Dw8PHx8fDw8vLy8vPz8/P09vT09PX19fT19/X1 9/X39PX39vf19vb29vf39/b2+Pj49vn49vj4+Pn5+fr6+vv7+/z8/AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAMAAJcALAAAAAApAA0AAAj/AC8JRGSJEylP lhAJXDiw4MGEDBdqMpVKVSpRmyJGAlSlyREmUvw40sjRI0iREUWFymOHTp08okwtfJQGSREf Rn4ASYIG0syaN3Pu7LnQ1KI5cuIojTNnkUxDf5bo2LEjRw8ePpQEOnQJqlSqVrFq5YopVBw4 b9KqjRNKE6UpOGrQuFFjRl0bVChdeht3bt27eS+ZusNmzZrCagyzwWNq1BAZLWKYgNGChYsX REJdcgxZMmXLmDWjajOmTJkxZFKTGdMmVakVJEaMQKFChIoQKU7IfB17du3buWWmEgPmy5fi xo2LUQVKyIcKFUpUAGHBw4UgoC41fx59evXr2VWFtunSxQt58ly8iEn1CAoFCQwiOJgAocGD KJMutX8ff379+/mZQocWW2yhxYEEakHHKYnwscEBBihwQAIILKBBH4Zc0uCDEU5Y4YUZbkKJ FliUaCIWWlCSkSRnZFDAAAIEQAAGZiiyEIsuwigjjTYKZMogWFwhpJBYCCKTQJHo4UQHAHDw xB6NaKQkk05CGZEplLiRhRVZuMHIKRERQkkmn3RiSSERCSQmmWaimeYmolSUiikZCRQQADs= --------------030202030406030505000900 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlhDwAPAPcAAAAAABBC1sDAwP////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////yH5BAEAAAIALAAAAAAPAA8AAAhcAAUIFBggAICC AxMKKDigYICGARQCGNCw4sMBAAY+3IjRYkOCFCdW7PjxIseTFBmOdJgy5UGDDl/ChNkSosmU N1GaXBiypsiIPDlOPDnwp0eMChmyRKiQ4EyFAQEAOw== --------------030202030406030505000900 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlhDwAPAIcAAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAMAAAAALAAAAAAPAA8AAAgaAAEIHEiwoMGD CBMqXMiwocOHECNKnEjxYUAAOw== --------------030202030406030505000900 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlhEAAPAPcAAAR6BGSyhLzWxESSRByCJJTKjNTuxNzu5ASCBKTCpFSqTPT+5ByOJKzO rOz69Iy+hAR2FJy+lFymZDyaPPT6/DyOPMzixMzerIzGlMzi1AR6DIzKnASCFCSSLLzWvPz6 9HS2dGSiZNTu3FSuXByKLCx2FISuZPz6/NTq1BR6BFSiRDR2PLzGtLTWrOz+9JTGjAx+FJTC nDSSNIzGnKTWnByCFAR+BDSWVCyCJKTKlKzGpFSuVPT67CyOJLzStJTCjBR6HGymdOz+/Mzq zJzGlMzm3AR+DOT61Ax6BEyWRCSCJIzKlMz2zPz2/AyCDJzGpEymVCSOJKzSrPT69IzChAR6 FKTClGyqbEyKPMTizLTavJTGlNzm1KTOpBSCFMTWvPz+9Nzy3GSqXCSOLHSqbPz+/OTq3PT+ 9KTCnESSPJzSpCSGHPT+7PT+/Ax+DP8AAAAwgQDqfgAS8QAAdwCMIAABMAAA9QAAdwDoAAD1 ABUSAAAAAA1nYKgEngDXgAB3fJBgWOnVHhLUGwB3AJ//AOv/AIH/AHz/AEpZB+PVAIHUAHx3 AEAHAHiLAFBGAAAAAFjYAF4GEAEQGwAAAGwgAAAAAAAAAAAAAMwNAOioABIAAAAAADSoAADq AAASAMAAAAiFAPwrABKDAAB8ABgAaO4AnpAAgHwAfHAA/wUA/5EA/3wA//8AYP8Anv8AgP8A fG0AKgUBAJEAAHwAAErpKvQrAICDAHx8AADMWADq8RUSEgAAAADE/wAr/wCD/wB8/1gAAF4A ABUAAAAAAABY1AEe6wAbEgAAAAA0xgBkPACDTAB8AFf/tPT/64D/Enz/ALjQd+rrEBISTwAA AFht6F5k6xWDEgB8AC1gNLQtZNRPg3cAfNh0jgY27RBPEgAAACAA1AAB/wAA/wAAf97MZAbq 7Q8SEgAAABIAWAABHgAAGwIAAACINABkZACDgwB8fJ4BWAIAHgAAGwAAAAEADQAwqAAAAAD/ AMwAAPUAABIAAAAAAHD0tibs6kYSRwAAACH5BAAAAAAALAAAAAAQAA8ABwjNAMsIHFjmhBAK JygQXFgQzAIpUs4wXDjlQgkgWk5MFNhmiokURgIo3NiGSxIERm4UabORTY41NtwoWUKBZZkz bD4INBOBSpoKP2JYaKPxSxAWAhKQEaMgSocREkJ4ONHGygAmXa5MGEOCAAw3SCBsAHOGCAQc UHaA6JLhzBAaKpBsAVPmBQIAGgAg0LDiwIkPR3q80FkAAUoAThhgINrEgpstJ068sIEEhowH Ij5QYGMAi4bFJ7gkaBBGokAwPHzEeMLljEacDMmemQ0mIAA7 --------------030202030406030505000900 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlhKQANAIcAAAJueANyewFxfQByfAByfQBzfAB3fwF1ggJ3gAR0gAR2gAR2gQB7ggB7 gwF6gwF5hwB6hQF6hQJ7hgB8hAN7iwB/iAF/iwJ+iAt3gQx3gQt9hw18gxZ7hRl5hQGAhwCA iQCAiwCDjQCDjwCEjQKFjQSAigCJjgaKjwCDkAGDkACEkAeHkACJkACIkgCJkwCKkQKIkwCI lAGKlACPlQCOlgCPlwONmAONmgGQmACSmQCSmgCTmwGQngOTngCVnAGUngCXnxmOlR+LlxqV nR6UngKUoQOVogCZoQyZoA6ZoA+YohKYoRyiqx6kr2ClqmSjqGeusmqttmO+wWu6wWu8wGXA wZ+fn6GhoaampqioqKurq6ysrLCwsLGxsbKysre3t7i4uLm5ubq6uru7u7y8vL29vbTS1LbT 2bXf3rbb4cDAwMHBwcLCwsPDw8TExMbGxsfHx8nJycrKysvLy8zMzNLS0tPT09nZ2dra2t/f 39bk5dfl5dbo6NXo7Nnt7Nrs7Nns8Nrs8OLi4uPj4+fp5ufp6Ojo5urp5+jo6Onp6e/v7e7u 7u/v7+3u8O7v8e/x8PDv6/Dw7vHw7vHx7/Dw8PHx8fDw8vLy8vPz8/P09vT09PX19fT19/X1 9/X39PX39vf19vb29vf39/b2+Pj49vn49vj4+Pn5+fr6+vv7+/z8/AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAMAAJcALAAAAAApAA0AAAj/AC8J1GQqlapU ojYJXCgQkSVOpDxZQsRwIUGDCBUyFBUqjx06dfKIMlUxEqAqTY4wkeLHUUWOHkGKJCnQ1KI5 cuLojDNnEc1Lj9IgKeLDyA8gSdBAWmgT506ePi9hChUHzpurWOOE0nTJ0J8lOnbsyNGDhw8l gQ5JpWoV61WtBO+wWbNmrhq6bPCQpDQFRw0aN2rMEGyDCqVLpuTiXXO3rl5UbcaUKTOGjGUy Y9qkujRqiIwWMUzAaMHCxQsioS5Blkz5MmbNqcSA+fJlNm3aYlRdKrWCxIgRKFSIUBEixQmS sW3bvp1bVZguXbxAh87Fi5jNoIR8qFChRAUQFjxcqwgC6pJz6NKnV79uio6WLVu0yH+vhc4p oFAoSGAQwcEECA08EMUkiLkH33z02bcJJVpg4eCDWGhBiUKJ8LHBAQYocEACCCygQR+GXLJg gxA6KKFCpgyCxRUssoiFID9JckYGBQwgQAAEYGCGIkyp2KKLMDJFiRtZWJGFG4zcx1AkejjR AQAcPLFHIxWZMmSRRyZZ0SaiYGSKRhURQkkmn3RiSSEVCcSll2AGBAA7 --------------030202030406030505000900-- From nobody Fri Aug 1 06:32: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 7D4261A0B06 for ; Fri, 1 Aug 2014 06:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 D9fdsVBn1-yT for ; Fri, 1 Aug 2014 06:32:02 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B7CE1A0B03 for ; Fri, 1 Aug 2014 06:32:02 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id fp1so5549166pdb.19 for ; Fri, 01 Aug 2014 06:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=KYjygN5p9gemyBnS9e6dVgL1XGLzhaHL04emD9XWaqE=; b=Fdh+ikHh6txy62aHniQBO7BoUh+wINeuTuxBZ0Ughm8FrDMlk+PFUSIqYu/vgNjyS2 Khx4cW7o7DP532r+tf76TlymE142dKZg8Ew/A1JzaT1uhDQ8z/BbloXTv0WoA70nLlqf tY7M5ZduBcPEZOP1XGAP9j6J6LR10dyTd2AA+7cVN/yUoEvNSGYXBlP1/dik8eDXfI8k 0x1cJfGbOMMzGxoJYk82ysrpB1xYC9wrPX5XOqIlzaPNDLz+oQurRVyiNZSWOPj2Du2q np1gW1p2mOy1RKHC2WXc3/n6lxw+XFq3MeNGEkHlxL0t3IaPjeTh9ZhxGgIbrH988+N8 i6/A== X-Received: by 10.70.135.130 with SMTP id ps2mr6131717pdb.0.1406899921672; Fri, 01 Aug 2014 06:32:01 -0700 (PDT) Received: from [10.17.218.49] ([166.176.123.151]) by mx.google.com with ESMTPSA id y1sm8729136pbw.87.2014.08.01.06.31.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Aug 2014 06:32:00 -0700 (PDT) References: <20140731160335.GA65079@elstar.local> <20140801083313.GD66818@elstar.local> <53DB8B39.6090805@ericsson.com> Mime-Version: 1.0 (1.0) In-Reply-To: <53DB8B39.6090805@ericsson.com> Content-Type: multipart/alternative; boundary=Apple-Mail-6DB52041-3A7C-4E43-B8B2-37E063CA097D Content-Transfer-Encoding: 7bit Message-Id: <98CC8308-016A-478C-99CC-44C4E0618DFA@gmail.com> X-Mailer: iPhone Mail (10B329) From: Mahesh Jethanandani Date: Fri, 1 Aug 2014 08:31:54 -0500 To: Balazs Lengyel Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OLg1cX5121cN34S9UQUNln7EdAk Cc: "netmod@ietf.org" Subject: Re: [netmod] NETMOD WG Interim Meeting, September 17-18, 2014 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Aug 2014 13:32:05 -0000 --Apple-Mail-6DB52041-3A7C-4E43-B8B2-37E063CA097D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Just a note. None of the $100-$200 priced hotels are in the class of ietf ho= tels we are so used to staying in. They might be reasonable but do not expec= t much from them.=20 Is the venue location fixed? Mahesh Jethanandani mjethanandani@gmail.com On Aug 1, 2014, at 7:42 AM, Balazs Lengyel wro= te: > Hello Lada, > I would be most interested in some reasonable hotel. It would be very nice= to be in the same place and travel together.=20 >=20 > I got the following recommendations: ( I know nothing about them yet). How= ever they are all 40-60 kms away. > Preference 1 >=20 > P > R > O=20 >=20 > C > L > I >=20 > C > W > T >=20 > Hotel Name =20 >=20 > Postal City >=20 > GDS rates from >=20 > Rates from =20 >=20 > ES >=20 > BS >=20 > =20 >=20 > Distance (km) >=20 > Classif. >=20 > =20 >=20 > =20 >=20 > >=20 > radisson hotel piscataway >=20 > piscataway =20 >=20 >=20 >=20 > USD >=20 > 99.00 =20 >=20 >=20 >=20 >=20 > 48.0 >=20 > 3 >=20 > >=20 > >=20 > >=20 > holiday inn parsippany >=20 > parsippany =20 >=20 >=20 >=20 > USD >=20 > 109.00 >=20 >=20 >=20 > >=20 > 35.2 >=20 > 3 >=20 > >=20 > >=20 > >=20 > esa piscataway rutgers university=20 >=20 > piscataway =20 >=20 >=20 >=20 > USD >=20 > 110.00 >=20 >=20 >=20 > >=20 > 25.0 >=20 > 2 >=20 > >=20 > >=20 > >=20 > sheraton new york times square hotel=20 >=20 > new york >=20 >=20 >=20 > USD >=20 > 429.00 >=20 >=20 >=20 > >=20 > 6.2 >=20 > 4 >=20 > >=20 > >=20 > Preference 2 >=20 > P > R > O=20 >=20 > C > L > I >=20 > C > W > T >=20 > Hotel Name =20 >=20 > Postal City >=20 > GDS rates from >=20 > Rates from =20 >=20 > ES >=20 > BS >=20 > =20 >=20 > Distance (km) >=20 > Classif. >=20 > =20 >=20 > =20 >=20 > >=20 > sheraton edison >=20 > edison >=20 >=20 >=20 > USD >=20 > 123.00 >=20 >=20 >=20 > >=20 > 40.0 >=20 > 3 >=20 > >=20 > >=20 > >=20 > fairfield inn & suites >=20 > parsippany =20 >=20 >=20 >=20 > USD >=20 > 129.00 >=20 >=20 >=20 >=20 > 48.0 >=20 > 2 >=20 > >=20 > >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Preference 3 >=20 > P > R > O=20 >=20 > C > L > I >=20 > C > W > T >=20 > Hotel Name =20 >=20 > Postal City >=20 > GDS rates from >=20 > Rates from =20 >=20 > ES >=20 > BS >=20 > =20 >=20 > Distance (km) >=20 > Classif. >=20 > =20 >=20 > =20 >=20 > >=20 > embassy suites piscataway >=20 > piscataway =20 >=20 >=20 >=20 > USD >=20 > 131.00 >=20 >=20 >=20 > >=20 > 30.0 >=20 > 3 >=20 > >=20 > >=20 > >=20 > residence inn parsippany >=20 > parsippany =20 >=20 >=20 >=20 > USD >=20 > 178.00 >=20 >=20 >=20 > >=20 > 64.0 >=20 > 3 >=20 > >=20 > >=20 >=20 > regards Balazs >=20 > On 2014-08-01 10:39, Ladislav Lhotka wrote: >> On 01 Aug 2014, at 10:33, Juergen Schoenwaelder wrote: >>=20 >>> On Fri, Aug 01, 2014 at 10:03:40AM +0200, Ladislav Lhotka wrote: >>>> Hi, >>>>=20 >>>> looking at booking.com, NY hotel prices seem to be outrageously expensi= ve >>>> at that time. Is there any chance to get a reasonably priced hotel room= ? >>>>=20 >>> I assume reasonably priced options likely require you to stay >>> somewhere in Newark and to commute into the city. Does someone who >>> knows the area better have any recommendations? >> Yes, I don=E2=80=99t mind commuting but I need some advice in order to av= oid troubles. >>=20 >>> Note: Before you make fixed travel plans, please note that the interim >>> still needs approval - so wait for the official announcement. >> Sure, I just need a preliminary approval from my bosses, so I have to pro= vide an estimate of the expenses. >>=20 >> 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 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com=20= > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail-6DB52041-3A7C-4E43-B8B2-37E063CA097D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Just a note. None of the $100-$200 pri= ced hotels are in the class of ietf hotels we are so used to staying in. The= y might be reasonable but do not expect much from them. 

=
Is the venue location fixed?

Mahesh Jethanandani

On Aug 1, 2014, at 7:42 AM, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:
=20 =20 =20 Hello Lada,
I would be most interested in some reasonable hotel. It would be very nice to be in the same place and travel together.

I got the following recommendations: ( I know nothing about them yet). However they are all 40-60 kms away.

Preference 1

Hotel Name

Postal City

GDS rates from

Rates from

ES

BS

 

Distance (km)

Classif.

 

 

<mime-attachment.gif>

radisson hotel piscataway <= /p>

piscataway



USD

99.00




48.0

3

<mime-attachment.gif>

<mime-attachment.gif>

<mime-attachment.gif>

holiday inn parsippany

parsippany



USD

109.00



<mime-attachment.gif>

35.2

3

<mime-attachment.gif>

<mime-attachment.gif>

<mime-attachment.gif>

esa piscataway rutgers university <= /o:p>

piscataway



USD

110.00



<mime-attachment.gif>

25.0

2

<mime-attachment.gif>

<mime-attachment.gif>

<mime-attachment.gif>

sheraton new york times square hotel

new york

USD

429.00



<mime-attachment.gif>

6.2

4

<mime-attachment.gif>

<mime-attachment.gif>

Preference 2

Hotel Name

Postal City

GDS rates from

Rates from

ES

BS

 

Distance (km)

Classif.

 

 

<mime-attachment.gif>

sheraton edison

edison



USD

123.00



<mime-attachment.gif>

40.0

3

<mime-attachment.gif>

<mime-attachment.gif>

<mime-attachment.gif>

fairfield inn & suites <= /p>

parsippany



USD

129.00




48.0

2

<mime-attachment.gif>

<mime-attachment.gif>














Preference 3

Hotel Name

Postal City

GDS rates from

Rates from

ES

BS

 

Distance (km)

Classif.

 

 

<mime-attachment.gif>

embassy suites piscataway =

piscataway



USD

131.00



<mime-attachment.gif>

30.0

3

<mime-attachment.gif>

<mime-attachment.gif>

<mime-attachment.gif>

residence inn parsippany

parsippany



USD

178.00



<mime-attachment.gif>

64.0

3

<mime-attachment.gif>

<mime-attachment.gif>

regards Balazs

On 2014-08-01 10:39, Ladislav Lhotka wrote:
On 01 Aug 2014, at 10:33, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:


On Fri, Aug 01, 2014 at 10:03:40AM +0200, Ladislav Lh=
otka wrote:

Hi,

looking at booking.com, NY hotel prices s=
eem to be outrageously expensive
at that time. Is there any chance to get a reasonably priced hotel room?


I assume reasonably priced options likely require you=
 to stay
somewhere in Newark and to commute into the city. Does someone who
knows the area better have any recommendations?

Yes, I don=E2=80=99t mind commuting but I need some adv=
ice in order to avoid troubles.


Note: Before you make fixed travel plans, please note=
 that the interim
still needs approval - so wait for the official announcement.

Sure, I just need a preliminary approval from my bosses=
, so I have to provide an estimate of the expenses.

Lada


/js

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

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




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



--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.co=
m=20
=20
____________________= ___________________________
netmod mailing list
netmod@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/netmod">https://www.ietf.org= /mailman/listinfo/netmod
= --Apple-Mail-6DB52041-3A7C-4E43-B8B2-37E063CA097D-- From nobody Fri Aug 1 08:04: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 0CB261B27C3; Fri, 1 Aug 2014 08:04:13 -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 ybgYNMeBFOxV; Fri, 1 Aug 2014 08:04:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 296FA1B27B6; Fri, 1 Aug 2014 08:04:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140801150411.14577.32922.idtracker@ietfa.amsl.com> Date: Fri, 01 Aug 2014 08:04:11 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/NU2wq4TsxqTn3IcR5FQOT-o6ajU Cc: netmod@ietf.org Subject: [netmod] NETMOD WG Interim Meeting, September 17-18, 2014 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 15:04:13 -0000 The IETF NETMOD WG will hold an Interim Meeting on September 17-18, 2014. The meeting will take place at One Penn Plaza, 9th Floor New York, NY 10119 USA. The agenda of the meeting is to work on YANG 1.1 open issues and in particular on - issues related to YANG 1.1 conformance; - issues related to YANG 1.1 datastores and I2RS support; - any remaining open YANG 1.1 issues. If you'd like to attend, please register by sending an email to the NETMOD WG chairs. The meeting details with further information about the participants and meeting logistics will be maintained in the SVN of the NETMOD working group http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ and also posted on the NETMOD mailing list. A preliminary list of participants is on the following Doodle poll: http://doodle.com/7eptxb7mggtdhwmc From nobody Fri Aug 1 08:04: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 980D11B27D6 for ; Fri, 1 Aug 2014 08:04: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 aMbK8LHzhlA3 for ; Fri, 1 Aug 2014 08:04:25 -0700 (PDT) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E5EC1B27C6 for ; Fri, 1 Aug 2014 08:04:24 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id q107so5895633qgd.26 for ; Fri, 01 Aug 2014 08:04:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Id/w/VJ3TnKAKRJPcRFvQxP2I2uQyCUpaxi7PUA7laQ=; b=FMJpQJnu5uexQoV6MVpm1OFRlwP/FQHBDxxoSKCISoCdM6jnoZxC7wL2mpl3jKPHoy +DPpZYqGKj3hxDDEd/NWv2hf7mqLp2ObnZ4uovbjXihgmcxN3N979rKhmu+IGLgDgr55 Rw46UbGcz3swwK6BSpRe0X29JKcBvRmzHj+FLxkAWfTdlpiGd9jrwzXFTrFlBHr1ZauA ugrY7WNUwtWx8M/+ubpFb+79mz8dfv4QAWkiNq9UcImM53fweLNlUIgi/YQS3QxlW1Bg ueR9NQ2CXf3WkD9yRsyB2iTv4/TAcOXrR/r4B+KV6/hhRFH/kjKw8WaTKydBcTOWu2v6 gPrA== X-Gm-Message-State: ALoCoQk/Sd+PgVuZ/eNklmOiAV4lpAczy1bhBASugWz9jIIDzdqtp9PA02Vl34/SWA8SMY/4o3v4 MIME-Version: 1.0 X-Received: by 10.140.80.74 with SMTP id b68mr9403073qgd.21.1406905464122; Fri, 01 Aug 2014 08:04:24 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Fri, 1 Aug 2014 08:04:24 -0700 (PDT) In-Reply-To: <98CC8308-016A-478C-99CC-44C4E0618DFA@gmail.com> References: <20140731160335.GA65079@elstar.local> <20140801083313.GD66818@elstar.local> <53DB8B39.6090805@ericsson.com> <98CC8308-016A-478C-99CC-44C4E0618DFA@gmail.com> Date: Fri, 1 Aug 2014 08:04:24 -0700 Message-ID: From: Andy Bierman To: Mahesh Jethanandani Content-Type: multipart/alternative; boundary=001a11c125106c0f2f04ff92b45d Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_6_A7j0DGgqNhGaBwBxA8j0kDmw Cc: "netmod@ietf.org" Subject: Re: [netmod] NETMOD WG Interim Meeting, September 17-18, 2014 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Aug 2014 15:04:33 -0000 --001a11c125106c0f2f04ff92b45d Content-Type: text/plain; charset=ISO-8859-1 Hi, Did you mean to select 'No' on all 3 days on the doodle poll? http://doodle.com/7eptxb7mggtdhwmc There are not that many people signed up. I hope more WG members will add an entry to the poll indicating they plan to attend the interim. Since we have been debating real vs. virtual interim meetings offline, I am curious how many people would attend a virtual interim on the same days (but cannot go to New York for a real interim)? thanks, Andy On Fri, Aug 1, 2014 at 6:31 AM, Mahesh Jethanandani wrote: > Just a note. None of the $100-$200 priced hotels are in the class of ietf > hotels we are so used to staying in. They might be reasonable but do not > expect much from them. > > Is the venue location fixed? > > Mahesh Jethanandani > mjethanandani@gmail.com > > On Aug 1, 2014, at 7:42 AM, Balazs Lengyel > wrote: > > Hello Lada, > I would be most interested in some reasonable hotel. It would be very nice > to be in the same place and travel together. > > I got the following recommendations: ( I know nothing about them yet). > However they are all 40-60 kms away. > > *Preference 1* > > P > R > O > > > C > L > I > > > C > W > T > > > *Hotel Name > * > > *Postal City > * > > *GDS rates from > > * > > *Rates from > * > > *ES* > > *BS* > > > > *Distance (km) > * > > *Classif. > * > > > > > > > > > radisson hotel piscataway > > > piscataway > > > USD > > 99.00 > > > > 48.0 > > 3 > > > > > > > > > > holiday inn parsippany > > > parsippany > > > USD > > 109.00 > > > > > 35.2 > > 3 > > > > > > > > > > esa piscataway rutgers university > > > piscataway > > > USD > > 110.00 > > > > > 25.0 > > 2 > > > > > > > > > > sheraton new york times square hotel > > > new york > > > USD > > 429.00 > > > > > 6.2 > > 4 > > > > > > > *Preference 2* > > P > R > O > > > C > L > I > > > C > W > T > > > *Hotel Name > * > > *Postal City > * > > *GDS rates from > > * > > *Rates from > * > > *ES* > > *BS* > > > > *Distance (km) > * > > *Classif. > * > > > > > > > > > sheraton edison > > > edison > > > USD > > 123.00 > > > > > 40.0 > > 3 > > > > > > > > > > fairfield inn & suites > > > parsippany > > > USD > > 129.00 > > > > 48.0 > > 2 > > > > > > > > > > > > > > > > > > > > *Preference 3* > > P > R > O > > > C > L > I > > > C > W > T > > > *Hotel Name > * > > *Postal City > * > > *GDS rates from > > * > > *Rates from > * > > *ES* > > *BS* > > > > *Distance (km) > * > > *Classif. > * > > > > > > > > > embassy suites piscataway > > > piscataway > > > USD > > 131.00 > > > > > 30.0 > > 3 > > > > > > > > > > residence inn parsippany > > > parsippany > > > USD > > 178.00 > > > > > 64.0 > > 3 > > > > > > > regards Balazs > > On 2014-08-01 10:39, Ladislav Lhotka wrote: > > On 01 Aug 2014, at 10:33, Juergen Schoenwaelder wrote: > > > On Fri, Aug 01, 2014 at 10:03:40AM +0200, Ladislav Lhotka wrote: > > Hi, > > looking at booking.com, NY hotel prices seem to be outrageously expensive > at that time. Is there any chance to get a reasonably priced hotel room? > > > I assume reasonably priced options likely require you to stay > somewhere in Newark and to commute into the city. Does someone who > knows the area better have any recommendations? > > Yes, I don't mind commuting but I need some advice in order to avoid troubles. > > > Note: Before you make fixed travel plans, please note that the interim > still needs approval - so wait for the official announcement. > > Sure, I just need a preliminary approval from my bosses, so I have to provide an estimate of the expenses. > > 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 > > > > > _______________________________________________ > netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > _______________________________________________ > 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 > > --001a11c125106c0f2f04ff92b45d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Did you mean to select 'No'= on all 3 days on the doodle poll?

http://doodle.com/7eptxb7mggtdhwmc
<= /div>


There are not that many people signed up= .  I hope more WG members
will add an entry to the poll indi= cating they plan to attend the interim.

Since we h= ave been debating real vs. virtual interim meetings offline,
I am curious how many people would attend a virtual interim on the
same days (but cannot go to New York for a real interim)?
=

thanks,
Andy




On Fri, Aug 1, 2014 at 6:31 AM, Mahesh Jethanandani <mjethan= andani@gmail.com> wrote:
Just a note. None of = the $100-$200 priced hotels are in the class of ietf hotels we are so used = to staying in. They might be reasonable but do not expect much from them.&n= bsp;

Is the venue location fixed?

Mahesh Jethanandani=

On Aug 1, 2014, at 7:42 AM, Balazs L= engyel <balazs.lengyel@ericsson.com> wrote:

=20 =20 =20 =20 Hello Lada,
I would be most interested in some reasonable hotel. It would be very nice to be in the same place and travel together.

I got the following recommendations: ( I know nothing about them yet). However they are all 40-60 kms away.

Preference 1

H= otel Name

P= ostal City

GDS rates from

R= ates from

ES

BS

 <= /p>

D= istance (km)

C= lassif.

 <= /p>

 <= /p>

<mime-attachment.gif><= span style=3D"font-size:8.5pt;font-family:"Verdana","sans-se= rif";color:#797979">

radi= sson hotel piscataway

piscataway



USD

99.00




48.0

3

<mime-attachm= ent.gif>

<mime-attachment.gif>

<mime-attachment.gif>

holida= y inn parsippany

parsippany



USD

109.00



<mime-attachment.gif><= span style=3D"font-size:8.5pt;font-family:"Verdana","sans-se= rif";color:#797979">

35.2

3

<mime-attachm= ent.gif>

<mime-attachment.gif>

<mime-attachment.gif><= span style=3D"font-size:8.5pt;font-family:"Verdana","sans-se= rif";color:#797979">

esa piscataway rutgers university

piscataway



USD

110.00



<mime-attachment.gif><= span style=3D"font-size:8.5pt;font-family:"Verdana","sans-se= rif";color:#797979">

25.0

2

<mime-attachm= ent.gif>

<mime-attachment.gif>

<mime-attachment.gif>

sherat= on new york times square hotel =

new york

USD

429.00



<mime-attachment.gif><= span style=3D"font-size:8.5pt;font-family:"Verdana","sans-se= rif";color:#797979">

6.2

4

<mime-attachment= .gif>

<mime-attachment.gif>

Preference 2

H= otel Name

P= ostal City

GDS rates from

R= ates from

ES

BS

 <= /p>

D= istance (km)

C= lassif.

 <= /p>

 <= /p>

<mime-attachment.gif>

sherat= on edison

edison



USD

123.00



<mime-attachment.gif><= span style=3D"font-size:8.5pt;font-family:"Verdana","sans-se= rif";color:#797979">

40.0

3

<mime-attachm= ent.gif>

<mime-attachment.gif>

<mime-attachment.gif><= span style=3D"font-size:8.5pt;font-family:"Verdana","sans-se= rif";color:#797979">

fair= field inn & suites

parsippany



USD

129.00




48.0

2

<mime-attachm= ent.gif>

<mime-attachment.gif>














Preference 3

H= otel Name

P= ostal City

GDS rates from

R= ates from

ES

BS

 <= /p>

D= istance (km)

C= lassif.

 <= /p>

 <= /p>

<mime-attachment.gif>

embass= y suites piscataway

piscataway



USD

131.00



<mime-attachment.gif><= span style=3D"font-size:8.5pt;font-family:"Verdana","sans-se= rif";color:#797979">

30.0

3

<mime-attachm= ent.gif>

<mime-attachment.gif>

<mime-attachment.gif><= span style=3D"font-size:8.5pt;font-family:"Verdana","sans-se= rif";color:#797979">

resid= ence inn parsippany

parsippany



USD

178.00



<mime-attachment.gif><= span style=3D"font-size:8.5pt;font-family:"Verdana","sans-se= rif";color:#797979">

64.0

3

<mime-attachm= ent.gif>

<mime-attachment.gif>

regards Balazs

On 2014-08-01 10:39, Ladislav Lhotka wrote:
On 01 Aug 2014, at 10:33, Juergen Schoenwaelder <j.schoenwaeld=
er@jacobs-university.de> wrote:


On Fri, Aug 01, 2014 at 10:03:40AM +0200, Ladislav Lhotka wrot=
e:

Hi,

looking at booking.com=
, NY hotel prices seem to be outrageously expensive
at that time. Is there any chance to get a reasonably priced hotel room?


I assume reasonably priced options likely require you to stay
somewhere in Newark and to commute into the city. Does someone who
knows the area better have any recommendations?

Yes, I don’t mind commuting but I need some advice in orde=
r to avoid troubles.


Note: Before you make fixed travel plans, please note that the=
 interim
still needs approval - so wait for the official announcement.

Sure, I just need a preliminary approval from my bosses, so I ha=
ve to provide an estimate of the expenses.

Lada


/js

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

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




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



--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com=20
=20
_________________________________= ______________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

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


--001a11c125106c0f2f04ff92b45d-- From nobody Fri Aug 1 08:32: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 3A65B1B27DF for ; Fri, 1 Aug 2014 08:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.88 X-Spam-Level: X-Spam-Status: No, score=-5.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 9A35nR3ZsulX for ; Fri, 1 Aug 2014 08:32:30 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA9C81B27D9 for ; Fri, 1 Aug 2014 08:32:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcNAA6y21PGmAcV/2dsb2JhbABbgmojUlcEgnSrUwEBAQEBB505h0wBGQxmFneDewgBAQEBAxIREToLDAQCAQgNBAQBAQMCBh0DAgICMBQBCAgCEgUIGoVUgkwBDKdDikiXcBeBLIRQhiFsgWERAR8xBwaCcw8ngRwFnU6FdoQoiGiDSWwBAYEKOQ X-IronPort-AV: E=Sophos;i="5.01,780,1400040000"; d="scan'208";a="67214279" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Aug 2014 11:32:27 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 01 Aug 2014 11:32:25 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Fri, 1 Aug 2014 17:32:24 +0200 From: "Romascanu, Dan (Dan)" CC: "netmod@ietf.org" Thread-Topic: NETMOD WG Interim Meeting, September 17-18, 2014 Thread-Index: AQHPrZno/9qdkkjb/UyPITQOsUgpSJu74C7Q Date: Fri, 1 Aug 2014 15:32:24 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C85AF56@AZ-FFEXMB04.global.avaya.com> References: <20140801150411.14577.32922.idtracker@ietfa.amsl.com> In-Reply-To: <20140801150411.14577.32922.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Q5KypZPNTP7-pFM0RdoBZpmA37w Subject: Re: [netmod] NETMOD WG Interim Meeting, September 17-18, 2014 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Aug 2014 15:32:32 -0000 V2lsbCByZW1vdGUgcGFydGljaXBhdGlvbiBiZSBhdmFpbGFibGU/IA0KDQpJZiB5ZXMgLSBkbyBy ZW1vdGUgcGFydGljaXBhbnRzIG5lZWQgdG8gcmVnaXN0ZXI/IA0KDQpUaGFua3MgYW5kIFJlZ2Fy ZHMsDQoNCkRhbg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSUVU Ri1Bbm5vdW5jZSBbbWFpbHRvOmlldGYtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mDQo+IElFU0cgU2VjcmV0YXJ5DQo+IFNlbnQ6IEZyaWRheSwgQXVndXN0IDAxLCAyMDE0 IDY6MDQgUE0NCj4gVG86IElFVEYgQW5ub3VuY2VtZW50IExpc3QNCj4gQ2M6IG5ldG1vZEBpZXRm Lm9yZw0KPiBTdWJqZWN0OiBORVRNT0QgV0cgSW50ZXJpbSBNZWV0aW5nLCBTZXB0ZW1iZXIgMTct MTgsIDIwMTQNCj4gDQo+IFRoZSBJRVRGIE5FVE1PRCBXRyB3aWxsIGhvbGQgYW4gSW50ZXJpbSBN ZWV0aW5nIG9uIFNlcHRlbWJlciAxNy0xOCwNCj4gMjAxNC4gVGhlIG1lZXRpbmcgd2lsbCB0YWtl IHBsYWNlIGF0IE9uZSBQZW5uIFBsYXphLCA5dGggRmxvb3IgTmV3IFlvcmssIE5ZDQo+IDEwMTE5 IFVTQS4NCj4gDQo+IFRoZSBhZ2VuZGEgb2YgdGhlIG1lZXRpbmcgaXMgdG8gd29yayBvbiBZQU5H IDEuMSBvcGVuIGlzc3VlcyBhbmQgaW4NCj4gcGFydGljdWxhciBvbg0KPiANCj4gLSBpc3N1ZXMg cmVsYXRlZCB0byBZQU5HIDEuMSBjb25mb3JtYW5jZTsNCj4gLSBpc3N1ZXMgcmVsYXRlZCB0byBZ QU5HIDEuMSBkYXRhc3RvcmVzIGFuZCBJMlJTIHN1cHBvcnQ7DQo+IC0gYW55IHJlbWFpbmluZyBv cGVuIFlBTkcgMS4xIGlzc3Vlcy4NCj4gDQo+IElmIHlvdSdkIGxpa2UgdG8gYXR0ZW5kLCBwbGVh c2UgcmVnaXN0ZXIgYnkgc2VuZGluZyBhbiBlbWFpbCB0byB0aGUgTkVUTU9EDQo+IFdHIGNoYWly cy4gVGhlIG1lZXRpbmcgZGV0YWlscyB3aXRoIGZ1cnRoZXIgaW5mb3JtYXRpb24gYWJvdXQgdGhl DQo+IHBhcnRpY2lwYW50cyBhbmQgbWVldGluZyBsb2dpc3RpY3Mgd2lsbCBiZSBtYWludGFpbmVk IGluIHRoZSBTVk4gb2YgdGhlDQo+IE5FVE1PRCB3b3JraW5nIGdyb3VwDQo+IA0KPiBodHRwOi8v c3ZuLnRvb2xzLmlldGYub3JnL3N2bi93Zy9uZXRtb2QveWFuZy0xLjEvDQo+IA0KPiBhbmQgYWxz byBwb3N0ZWQgb24gdGhlIE5FVE1PRCBtYWlsaW5nIGxpc3QuIEEgcHJlbGltaW5hcnkgbGlzdCBv ZiBwYXJ0aWNpcGFudHMNCj4gaXMgb24gdGhlIGZvbGxvd2luZyBEb29kbGUgcG9sbDoNCj4gDQo+ IGh0dHA6Ly9kb29kbGUuY29tLzdlcHR4YjdtZ2d0ZGh3bWMNCg0K From nobody Fri Aug 1 09:04: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 2C7DA1B2793 for ; Fri, 1 Aug 2014 09:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbiN2LU41lR7 for ; Fri, 1 Aug 2014 09:04:04 -0700 (PDT) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A442D1A0B0C for ; Fri, 1 Aug 2014 09:04:04 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id q107so6110658qgd.28 for ; Fri, 01 Aug 2014 09:04: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=EZ7qxHbmQxLRmt/YqOh94UeRS+2o3beH2rzh1TUu1iw=; b=VZAIPDiv/RCXqnvCzZdvlPDq6rl1S2Gxnl9+Ee3Z+BA0RxqrpUuBy/zKj9JKfgnLi+ ETYgP7ei2XDSieGMqbbRNHj+ue8e4CSg9pGk8Y5WgfG/uqx0bAQ0x7eG0eFW3EgUKGJe RhHu/sbSZMTji8R43yjJeVAD5XgCRoDpifzdzuY7js41UE4c4awb1XnMY40MvabN3hTW CduCvMdkJ7HluRUlrhzVp/v1gf27K84sKsaSSzdOV5xR7A8oTw2v74MI459GvNKdLudr Y0c/lCH5JhknXJ6hzQmuB0V75SiInP9z18MLhRYhGfDUsoAQ6nTfme/QaiZ/44DxsmgN dQpQ== X-Gm-Message-State: ALoCoQkXz6f4FkVQ0ddYfCJFtTbd/AYyyJorAOnlGgHps1EaLR9avSzWa+GCMnXZv4n9XUAKfISa MIME-Version: 1.0 X-Received: by 10.224.112.1 with SMTP id u1mr10393522qap.7.1406909041204; Fri, 01 Aug 2014 09:04:01 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Fri, 1 Aug 2014 09:04:01 -0700 (PDT) In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C85AF56@AZ-FFEXMB04.global.avaya.com> References: <20140801150411.14577.32922.idtracker@ietfa.amsl.com> <9904FB1B0159DA42B0B887B7FA8119CA5C85AF56@AZ-FFEXMB04.global.avaya.com> Date: Fri, 1 Aug 2014 09:04:01 -0700 Message-ID: From: Andy Bierman To: "Romascanu, Dan (Dan)" Content-Type: multipart/alternative; boundary=047d7b673a4ea1f9f304ff9389ac Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Papapq3cWxsjn8jcSqS_4wtZXFw Cc: "netmod@ietf.org" Subject: Re: [netmod] NETMOD WG Interim Meeting, September 17-18, 2014 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Aug 2014 16:04:08 -0000 --047d7b673a4ea1f9f304ff9389ac Content-Type: text/plain; charset=ISO-8859-1 Hi, The doodle poll comments say Tom is trying to arrange remote participation. I think Benoit said in Toronto that remote participation should not be allowed because whiteboard meetings should be f2f only. Some people have frozen travel budgets right now. We sometimes use WebEx and point a WebCam at the whiteboard, and stream the video at 4 frames per second over the WEB. (Poor man's video-conferencing :-) Clearly f2f meetings can be more productive, but only if the right people are in the room. Andy On Fri, Aug 1, 2014 at 8:32 AM, Romascanu, Dan (Dan) wrote: > Will remote participation be available? > > If yes - do remote participants need to register? > > Thanks and Regards, > > Dan > > > > -----Original Message----- > > From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of > > IESG Secretary > > Sent: Friday, August 01, 2014 6:04 PM > > To: IETF Announcement List > > Cc: netmod@ietf.org > > Subject: NETMOD WG Interim Meeting, September 17-18, 2014 > > > > The IETF NETMOD WG will hold an Interim Meeting on September 17-18, > > 2014. The meeting will take place at One Penn Plaza, 9th Floor New York, > NY > > 10119 USA. > > > > The agenda of the meeting is to work on YANG 1.1 open issues and in > > particular on > > > > - issues related to YANG 1.1 conformance; > > - issues related to YANG 1.1 datastores and I2RS support; > > - any remaining open YANG 1.1 issues. > > > > If you'd like to attend, please register by sending an email to the > NETMOD > > WG chairs. The meeting details with further information about the > > participants and meeting logistics will be maintained in the SVN of the > > NETMOD working group > > > > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ > > > > and also posted on the NETMOD mailing list. A preliminary list of > participants > > is on the following Doodle poll: > > > > http://doodle.com/7eptxb7mggtdhwmc > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --047d7b673a4ea1f9f304ff9389ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

The doodle poll comments say Tom is= trying to arrange remote participation.
I think Benoit said in T= oronto that remote participation should not be allowed
because wh= iteboard meetings should be f2f only.

Some people have frozen travel budgets right now.
=
We sometimes use WebEx and point a WebCam at the whiteboard,
and stream the video at 4 frames per second over the WEB.
(Poor = man's video-conferencing :-)

Clearly f2f meetings can be more productive, but only i= f the right people are in the room.


Andy



On Fri, Aug 1, 2014 at 8:32 AM, Romascanu, Dan (Dan) <= dromasca@avaya.com<= /a>> wrote:
Will remote participation be available?

If yes - do remote participants need to register?

Thanks and Regards,

Dan


> -----Original Message-----
> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of
> IESG Secretary
> Sent: Friday, August 01, 2014 6:04 PM
> To: IETF Announcement List
> Cc: netmod@ietf.org
> Subject: NETMOD WG Interim Meeting, September 17-18, 2014
>
> The IETF NETMOD WG will hold an Interim Meeting on September 17-18, > 2014. The meeting will take place at One Penn Plaza, 9th Floor New Yor= k, NY
> 10119 USA.
>
> The agenda of the meeting is to work on YANG 1.1 open issues and in > particular on
>
> - issues related to YANG 1.1 conformance;
> - issues related to YANG 1.1 datastores and I2RS support;
> - any remaining open YANG 1.1 issues.
>
> If you'd like to attend, please register by sending an email to th= e NETMOD
> WG chairs. The meeting details with further information about the
> participants and meeting logistics will be maintained in the SVN of th= e
> NETMOD working group
>
> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/
>
> and also posted on the NETMOD mailing list. A preliminary list of part= icipants
> is on the following Doodle poll:
>
> http:= //doodle.com/7eptxb7mggtdhwmc

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

--047d7b673a4ea1f9f304ff9389ac-- From nobody Fri Aug 1 09:05:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEB21B27EB for ; Fri, 1 Aug 2014 09:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 Lr74QyLPOZ8Y for ; Fri, 1 Aug 2014 09:05:29 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 850BB1B2791 for ; Fri, 1 Aug 2014 09:05:28 -0700 (PDT) Received: from [192.168.1.145] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 01A262841A17; Fri, 1 Aug 2014 12:05:27 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_56E315C3-F596-4698-9A7D-DA1C90B217B2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <53DB8B39.6090805@ericsson.com> Date: Fri, 1 Aug 2014 12:05:25 -0400 Message-Id: <31B8228A-ACB5-45AF-A79A-C074DA117CD5@lucidvision.com> References: <20140731160335.GA65079@elstar.local> <20140801083313.GD66818@elstar.local> <53DB8B39.6090805@ericsson.com> To: Balazs Lengyel X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/VZlhdSroglIFpbrzxEEzVi6ESYY Cc: netmod@ietf.org Subject: Re: [netmod] NETMOD WG Interim Meeting, September 17-18, 2014 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Aug 2014 16:05:32 -0000 --Apple-Mail=_56E315C3-F596-4698-9A7D-DA1C90B217B2 Content-Type: multipart/alternative; boundary="Apple-Mail=_055CCF5B-8407-49AA-A104-1972FE0F01CB" --Apple-Mail=_055CCF5B-8407-49AA-A104-1972FE0F01CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Check your map. Edison and Parisippany are quite a bit south of = EWR (where the Path train takes you to Manhattan). There is a train = that you can take but it might be a pain in the neck depending on where = your hotel is.=20 --Tom On Aug 1, 2014:8:42 AM, at 8:42 AM, Balazs Lengyel = wrote: > Hello Lada, > I would be most interested in some reasonable hotel. It would be very = nice to be in the same place and travel together.=20 >=20 > I got the following recommendations: ( I know nothing about them yet). = However they are all 40-60 kms away. > Preference 1 >=20 > P > R > O >=20 > C > L > I >=20 > C > W > T >=20 > Hotel Name >=20 > Postal City >=20 > GDS rates from >=20 > Rates from >=20 > ES >=20 > BS >=20 > =20 >=20 > Distance (km) >=20 > Classif. >=20 > =20 >=20 > =20 >=20 > >=20 > radisson hotel piscataway >=20 > piscataway >=20 >=20 >=20 > USD >=20 > 99.00 >=20 >=20 >=20 >=20 > 48.0 >=20 > 3 >=20 > >=20 > >=20 > >=20 > holiday inn parsippany >=20 > parsippany >=20 >=20 >=20 > USD >=20 > 109.00 >=20 >=20 >=20 > >=20 > 35.2 >=20 > 3 >=20 > >=20 > >=20 > >=20 > esa piscataway rutgers university >=20 > piscataway >=20 >=20 >=20 > USD >=20 > 110.00 >=20 >=20 >=20 > >=20 > 25.0 >=20 > 2 >=20 > >=20 > >=20 > >=20 > sheraton new york times square hotel >=20 > new york >=20 >=20 >=20 > USD >=20 > 429.00 >=20 >=20 >=20 > >=20 > 6.2 >=20 > 4 >=20 > >=20 > >=20 > Preference 2 >=20 > P > R > O >=20 > C > L > I >=20 > C > W > T >=20 > Hotel Name >=20 > Postal City >=20 > GDS rates from >=20 > Rates from >=20 > ES >=20 > BS >=20 > =20 >=20 > Distance (km) >=20 > Classif. >=20 > =20 >=20 > =20 >=20 > >=20 > sheraton edison >=20 > edison >=20 >=20 >=20 > USD >=20 > 123.00 >=20 >=20 >=20 > >=20 > 40.0 >=20 > 3 >=20 > >=20 > >=20 > >=20 > fairfield inn & suites >=20 > parsippany >=20 >=20 >=20 > USD >=20 > 129.00 >=20 >=20 >=20 >=20 > 48.0 >=20 > 2 >=20 > >=20 > >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Preference 3 >=20 > P > R > O >=20 > C > L > I >=20 > C > W > T >=20 > Hotel Name >=20 > Postal City >=20 > GDS rates from >=20 > Rates from >=20 > ES >=20 > BS >=20 > =20 >=20 > Distance (km) >=20 > Classif. >=20 > =20 >=20 > =20 >=20 > >=20 > embassy suites piscataway >=20 > piscataway >=20 >=20 >=20 > USD >=20 > 131.00 >=20 >=20 >=20 > >=20 > 30.0 >=20 > 3 >=20 > >=20 > >=20 > >=20 > residence inn parsippany >=20 > parsippany >=20 >=20 >=20 > USD >=20 > 178.00 >=20 >=20 >=20 > >=20 > 64.0 >=20 > 3 >=20 > >=20 > >=20 >=20 > regards Balazs >=20 > On 2014-08-01 10:39, Ladislav Lhotka wrote: >> On 01 Aug 2014, at 10:33, Juergen Schoenwaelder = wrote: >>=20 >>> On Fri, Aug 01, 2014 at 10:03:40AM +0200, Ladislav Lhotka wrote: >>>> Hi, >>>>=20 >>>> looking at booking.com, NY hotel prices seem to be outrageously = expensive >>>> at that time. Is there any chance to get a reasonably priced hotel = room? >>>>=20 >>> I assume reasonably priced options likely require you to stay >>> somewhere in Newark and to commute into the city. Does someone who >>> knows the area better have any recommendations? >> Yes, I don=92t mind commuting but I need some advice in order to = avoid troubles. >>=20 >>> Note: Before you make fixed travel plans, please note that the = interim >>> still needs approval - so wait for the official announcement. >> Sure, I just need a preliminary approval from my bosses, so I have to = provide an estimate of the expenses. >>=20 >> 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 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_055CCF5B-8407-49AA-A104-1972FE0F01CB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Check your map. Edison and = Parisippany are quite a bit south of EWR (where the Path train takes you = to Manhattan).  There is a train that you can take but it might be = a pain in the neck depending on where your hotel is. =  

= --Tom


On Aug 1, 2014:8:42 AM, at = 8:42 AM, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:

=20 =20
Hello Lada,
I would be most interested in some reasonable hotel. It would be very nice to be in the same place and travel together.

I got the following recommendations: ( I know nothing about them yet). However they are all 40-60 kms away.

Preference 1

Hotel Name

Postal City

GDS rates from

Rates from

ES

BS

 

Distance (km)

Classif.

 

 

<Mail = Attachment.gif>

radisson hotel piscataway =

piscataway



USD

99.00




48.0

3

<Mail = Attachment.gif>

<Mail Attachment.gif>

<Mail = Attachment.gif>

holiday inn parsippany =

parsippany



USD

109.00



<Mail Attachment.gif>

35.2

3

<Mail = Attachment.gif>

<Mail Attachment.gif>

<Mail = Attachment.gif>

esa piscataway rutgers university =

piscataway



USD

110.00



<Mail Attachment.gif>

25.0

2

<Mail = Attachment.gif>

<Mail Attachment.gif>

<Mail = Attachment.gif>

sheraton new york times square hotel =

new york

USD

429.00



<Mail Attachment.gif>

6.2

4

<Mail = Attachment.gif>

<Mail Attachment.gif>

Preference 2

Hotel Name

Postal City

GDS rates from

Rates from

ES

BS

 

Distance (km)

Classif.

 

 

<Mail = Attachment.gif>

sheraton edison

edison



USD

123.00



<Mail Attachment.gif>

40.0

3

<Mail = Attachment.gif>

<Mail Attachment.gif>

<Mail = Attachment.gif>

fairfield inn & suites =

parsippany



USD

129.00




48.0

2

<Mail = Attachment.gif>

<Mail Attachment.gif>














Preference 3

Hotel Name

Postal City

GDS rates from

Rates from

ES

BS

 

Distance (km)

Classif.

 

 

<Mail = Attachment.gif>

embassy suites piscataway =

piscataway



USD

131.00



<Mail Attachment.gif>

30.0

3

<Mail = Attachment.gif>

<Mail Attachment.gif>

<Mail = Attachment.gif>

residence inn parsippany =

parsippany



USD

178.00



<Mail Attachment.gif>

64.0

3

<Mail = Attachment.gif>

<Mail Attachment.gif>

regards Balazs

On 2014-08-01 10:39, Ladislav Lhotka wrote:
On 01 Aug 2014, at 10:33, Juergen Schoenwaelder <j.schoenwaelder@j=
acobs-university.de> wrote:


On Fri, Aug 01, 2014 at 10:03:40AM +0200, =
Ladislav Lhotka wrote:

Hi,

looking at booking.com, NY hotel =
prices seem to be outrageously expensive
at that time. Is there any chance to get a reasonably priced hotel room?


I assume reasonably priced options likely require =
you to stay
somewhere in Newark and to commute into the city. Does someone who
knows the area better have any recommendations?

Yes, I don=92t mind commuting but I need some =
advice in order to avoid troubles.


Note: Before you make fixed travel plans, please =
note that the interim
still needs approval - so wait for the official announcement.

Sure, I just need a preliminary approval from my =
bosses, so I have to provide an estimate of the expenses.

Lada


/js

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

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




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



--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com=20
_______________________________________________
netmod mailing = list
netmod@ietf.org
https://www.ietf.or= g/mailman/listinfo/netmod

= --Apple-Mail=_055CCF5B-8407-49AA-A104-1972FE0F01CB-- --Apple-Mail=_56E315C3-F596-4698-9A7D-DA1C90B217B2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT27rFAAoJEPcO+I7eiUJZP78QAK8ivfsQGyV7ZvNFWSItOCzS xCqkvqM49d/G36srvLAd+KUJl0EZYGRJJLkYKlPKPgxmHNIb6n0OmDIlATQn0L/V d77vh097Iz7t4qDvRz3kGkeFkztClMlT4Meg+oJfj574s8n7skyE6Z/g+URJRTUu qcbZ7SNDexiIP7RdNxSW6kUzTbiyhS5hJUsvrnfPWxpwWpmv4YpI2l/oTcugUYLq yOzB6ngLsNpuMBdxIQSR0hFzT/ZMBnGfvCkHDl8VE/is9DJWy8KOyQCC/xNUQmqt P/9a+gEI66r/D7cO6cAAexHIxgea8Hd299A5GBtFRw7WN7UGf+bxkHVzkQmmnhor FCl/IsVgSX3eutkGuj7v7ij1HLz1OJbOyo+WhWcaWdmVzWohnURWb9frpFS6W+du IwenJpzqUIaYmKBAyRBT/btYpByPHxciCWvCh+yq4LKfAIXtYPNRNMA76qM3sRUQ kNxobA5jf60veXF3RIvGyoNA514z1GCyy27+1YjZr1t3rOofmIUCqu6HEAsttu90 HkU3ZMWUwd6Jbe8l0eaV0HOJR2YkChrpJFURref495olprRQeJngd2SdwB5hjtXK xKRMRONIQ5T5PuiKyRIBwWOT9xbglry6rgea9wMxnKFqK8eTdQVYpQvlxWiZ1fH4 TruWhItksHqq58FB/Q1Z =nF4Z -----END PGP SIGNATURE----- --Apple-Mail=_56E315C3-F596-4698-9A7D-DA1C90B217B2-- From nobody Fri Aug 1 09:26: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 DF9951ABB26 for ; Fri, 1 Aug 2014 09:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 8gxqJ-iodQ_w for ; Fri, 1 Aug 2014 09:26:47 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 15E3D1A01D8 for ; Fri, 1 Aug 2014 09:26:47 -0700 (PDT) Received: from [192.168.1.145] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id A05A42841A88; Fri, 1 Aug 2014 12:26:46 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8F5BC254-CF1E-42D5-9613-2DB6F57DAD5D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C85AF56@AZ-FFEXMB04.global.avaya.com> Date: Fri, 1 Aug 2014 12:26:46 -0400 Message-Id: <5A37AEEB-1F19-4B0D-A06C-DBA7E3BB9360@lucidvision.com> References: <20140801150411.14577.32922.idtracker@ietfa.amsl.com> <9904FB1B0159DA42B0B887B7FA8119CA5C85AF56@AZ-FFEXMB04.global.avaya.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/j_Q_wqdZujLHdygjowahFQS-A6E Cc: "netmod@ietf.org" Subject: Re: [netmod] NETMOD WG Interim Meeting, September 17-18, 2014 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Aug 2014 16:26:49 -0000 --Apple-Mail=_8F5BC254-CF1E-42D5-9613-2DB6F57DAD5D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes and Yes please register so we can size the Webex = accordingly.=20 --Tom On Aug 1, 2014:11:32 AM, at 11:32 AM, Romascanu, Dan (Dan) = wrote: > Will remote participation be available?=20 >=20 > If yes - do remote participants need to register?=20 >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >> -----Original Message----- >> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf = Of >> IESG Secretary >> Sent: Friday, August 01, 2014 6:04 PM >> To: IETF Announcement List >> Cc: netmod@ietf.org >> Subject: NETMOD WG Interim Meeting, September 17-18, 2014 >>=20 >> The IETF NETMOD WG will hold an Interim Meeting on September 17-18, >> 2014. The meeting will take place at One Penn Plaza, 9th Floor New = York, NY >> 10119 USA. >>=20 >> The agenda of the meeting is to work on YANG 1.1 open issues and in >> particular on >>=20 >> - issues related to YANG 1.1 conformance; >> - issues related to YANG 1.1 datastores and I2RS support; >> - any remaining open YANG 1.1 issues. >>=20 >> If you'd like to attend, please register by sending an email to the = NETMOD >> WG chairs. The meeting details with further information about the >> participants and meeting logistics will be maintained in the SVN of = the >> NETMOD working group >>=20 >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ >>=20 >> and also posted on the NETMOD mailing list. A preliminary list of = participants >> is on the following Doodle poll: >>=20 >> http://doodle.com/7eptxb7mggtdhwmc >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 --Apple-Mail=_8F5BC254-CF1E-42D5-9613-2DB6F57DAD5D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT27/GAAoJEPcO+I7eiUJZBrUP/3t3EnpZVKu9IH6zCFoEFdea cO0qo5qGqChLxIzdx7LgUbhQBl5WF//jmd9VgZSEmv9Mo3X5xgKFPS504nMr7XkA XQIqu7BUaMmk4y2aii9X7wnHqZdx4zwS+Rp5IxPrLbhS2otBdt+lRK/kFAxB9DFY sk7z8lH/WxThrYrP/n3niaCmJN0aI+vNIDjw4YE/dX2C0qa2OU3LDFbhFfTaOP6d rBSebt9HO/Czm1K34Jth9xuItFQ8o9rzIxq1DLChfCPG0RUeN76YgkjeSeUoAsoF Tzni3GWTXIUXNGb/+9dbCLkwLvQKgOK5NpBT4ZDvtkO3jWz+eF4AHiW0FmE67irD YV4oGGP2HajwBH/h7FLOrn/WO1zccicI25UFjvvBnJLu80igPrynO7YgvjGiwCyQ TFQJ7Hg/XZ3xANJr6oSbMJ3XnQOeYAOaVd1r90Z0bmPxjDKsmOA4OIed2OYNPnOq VvijijXc8hXIBVTHzwhBzNth+ZDuEnLI0dtpN5qQ8tdtbD0oQuPyQmqBvQiCAUE4 hgmLpIez6ftjbaB6ae43xRwfLRKJjrtOtsfO+q4MBX+m7GDtiic+HOt3UhQwhVEM Ma3uDrLRM2xOKEcs1dONIyyol2oCF+92t2HO/n+PqsqyJj0Cv4Kn2W/LQVoWPXtY nzDJ/XnN8ahSNq+cxjLx =tTv8 -----END PGP SIGNATURE----- --Apple-Mail=_8F5BC254-CF1E-42D5-9613-2DB6F57DAD5D-- From nobody Fri Aug 1 09:31: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 8AF581B2814 for ; Fri, 1 Aug 2014 09:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfJijp2jCSWa for ; Fri, 1 Aug 2014 09:31:15 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5821A0100 for ; Fri, 1 Aug 2014 09:31:15 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id w8so4208748qac.30 for ; Fri, 01 Aug 2014 09:31:13 -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=GNMUj+RipQKAkZKqJ18Lh2WGC9GHQf0cJ2LpdZgMNZ4=; b=H9WQZ6zGFW2855LAVhNSHKw3XTrR7dws5jiHVgBDoSL9G56AQtkOoqAVjQjXVfESbw 7vcHg8OddBDKaCqply7pBcsp4AeFYz0vIq/QjW0acaPcs+J/g50rf08zjdmSUIHVeMnx i1SEnWTLRSi6mzY957JohMOXQwfaGiBRBTWKTRI20JrZBNrHuoMKEXSVvkbefIeNwhGI TUsuFkOB4nKOCuHmZ2viRXxRBokW2pFDH/zvTiRtBZb+0FlYDMrSsyKXyZxKvS5eE3qn 0sXWJFcjfvpqpFH9ycGF+MbVLZSCP0BpmIiasrVdfUMeZQnsmWevvxPy3rx4mYfZ5C6W i84w== X-Gm-Message-State: ALoCoQk3+vnJz6Jmx3mWkgIY1voQe8t/u10gQ20E3WcuVLphWf/FNf4wp2C5WGFx41fVdiR6EImn MIME-Version: 1.0 X-Received: by 10.224.126.66 with SMTP id b2mr10773247qas.99.1406910673622; Fri, 01 Aug 2014 09:31:13 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Fri, 1 Aug 2014 09:31:13 -0700 (PDT) In-Reply-To: <5A37AEEB-1F19-4B0D-A06C-DBA7E3BB9360@lucidvision.com> References: <20140801150411.14577.32922.idtracker@ietfa.amsl.com> <9904FB1B0159DA42B0B887B7FA8119CA5C85AF56@AZ-FFEXMB04.global.avaya.com> <5A37AEEB-1F19-4B0D-A06C-DBA7E3BB9360@lucidvision.com> Date: Fri, 1 Aug 2014 09:31:13 -0700 Message-ID: From: Andy Bierman To: "Thomas D. Nadeau" Content-Type: multipart/alternative; boundary=001a11c2f98eeecdcb04ff93ea16 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/k9WGirKurwj2yJdmIZnfGt3C2k8 Cc: "netmod@ietf.org" Subject: Re: [netmod] NETMOD WG Interim Meeting, September 17-18, 2014 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Aug 2014 16:31:17 -0000 --001a11c2f98eeecdcb04ff93ea16 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 1, 2014 at 9:26 AM, Thomas D. Nadeau wrote: > > Yes and Yes please register so we can size the Webex accordingly. > > There is no way to indicate remote attendance on the poll. --Tom > Andy > > On Aug 1, 2014:11:32 AM, at 11:32 AM, Romascanu, Dan (Dan) < > dromasca@avaya.com> wrote: > > > Will remote participation be available? > > > > If yes - do remote participants need to register? > > > > Thanks and Regards, > > > > Dan > > > > > >> -----Original Message----- > >> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf > Of > >> IESG Secretary > >> Sent: Friday, August 01, 2014 6:04 PM > >> To: IETF Announcement List > >> Cc: netmod@ietf.org > >> Subject: NETMOD WG Interim Meeting, September 17-18, 2014 > >> > >> The IETF NETMOD WG will hold an Interim Meeting on September 17-18, > >> 2014. The meeting will take place at One Penn Plaza, 9th Floor New > York, NY > >> 10119 USA. > >> > >> The agenda of the meeting is to work on YANG 1.1 open issues and in > >> particular on > >> > >> - issues related to YANG 1.1 conformance; > >> - issues related to YANG 1.1 datastores and I2RS support; > >> - any remaining open YANG 1.1 issues. > >> > >> If you'd like to attend, please register by sending an email to the > NETMOD > >> WG chairs. The meeting details with further information about the > >> participants and meeting logistics will be maintained in the SVN of the > >> NETMOD working group > >> > >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ > >> > >> and also posted on the NETMOD mailing list. A preliminary list of > participants > >> is on the following Doodle poll: > >> > >> http://doodle.com/7eptxb7mggtdhwmc > > > > _______________________________________________ > > 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 > > --001a11c2f98eeecdcb04ff93ea16 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Aug 1, 2014 at 9:26 AM, Thomas D. Nadeau = <tnadeau@lu= cidvision.com> wrote:

=A0 =A0 =A0 =A0 Yes and Yes please register so we can size the Webex accord= ingly.


There is no way to indicate remote att= endance on the poll.


=A0 =A0 =A0 =A0 --Tom

Andy
= =A0

On Aug 1, 2014:11:32 AM, at 11:32 AM, Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:

> Will remote participation be available?
>
> If yes - do remote participants need to register?
>
> Thanks and Regards,
>
> Dan
>
>
>> -----Original Message-----
>> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of
>> IESG Secretary
>> Sent: Friday, August 01, 2014 6:04 PM
>> To: IETF Announcement List
>> Cc: netmod@ietf.org
>> Subject: NETMOD WG Interim Meeting, September 17-18, 2014
>>
>> The IETF NETMOD WG will hold an Interim Meeting on September 17-18= ,
>> 2014. The meeting will take place at One Penn Plaza, 9th Floor New= York, NY
>> 10119 USA.
>>
>> The agenda of the meeting is to work on YANG 1.1 open issues and i= n
>> particular on
>>
>> - issues related to YANG 1.1 conformance;
>> - issues related to YANG 1.1 datastores and I2RS support;
>> - any remaining open YANG 1.1 issues.
>>
>> If you'd like to attend, please register by sending an email t= o the NETMOD
>> WG chairs. The meeting details with further information about the<= br> >> participants and meeting logistics will be maintained in the SVN o= f the
>> NETMOD working group
>>
>> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/
>>
>> and also posted on the NETMOD mailing list. A preliminary list of = participants
>> is on the following Doodle poll:
>>
>> h= ttp://doodle.com/7eptxb7mggtdhwmc
>
> _______________________________________________
> 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


--001a11c2f98eeecdcb04ff93ea16-- From nobody Fri Aug 1 09:33: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 2F5DB1B2814 for ; Fri, 1 Aug 2014 09:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 Gl9SUj15wSBQ for ; Fri, 1 Aug 2014 09:33:17 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id EBAA51B2803 for ; Fri, 1 Aug 2014 09:33:16 -0700 (PDT) Received: from [192.168.1.145] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 2E6182841AFD; Fri, 1 Aug 2014 12:33:16 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_D23A079A-534C-4780-B594-51F441DBC36B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Fri, 1 Aug 2014 12:33:16 -0400 Message-Id: References: <20140801150411.14577.32922.idtracker@ietfa.amsl.com> <9904FB1B0159DA42B0B887B7FA8119CA5C85AF56@AZ-FFEXMB04.global.avaya.com> <5A37AEEB-1F19-4B0D-A06C-DBA7E3BB9360@lucidvision.com> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BKqJPfKtTruGjG0ab1epvdXGykw Cc: "netmod@ietf.org" Subject: Re: [netmod] NETMOD WG Interim Meeting, September 17-18, 2014 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Aug 2014 16:33:19 -0000 --Apple-Mail=_D23A079A-534C-4780-B594-51F441DBC36B Content-Type: multipart/alternative; boundary="Apple-Mail=_327262CE-A324-4389-9113-D680D97B4179" --Apple-Mail=_327262CE-A324-4389-9113-D680D97B4179 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I know. We can simply plan for the worst case where EVERYONE = that votes is remote. I guess that borks the physical space planning = though... --Tom On Aug 1, 2014:12:31 PM, at 12:31 PM, Andy Bierman = wrote: >=20 >=20 >=20 > On Fri, Aug 1, 2014 at 9:26 AM, Thomas D. Nadeau = wrote: >=20 > Yes and Yes please register so we can size the Webex = accordingly. >=20 >=20 > There is no way to indicate remote attendance on the poll. >=20 >=20 > --Tom >=20 > Andy > =20 >=20 > On Aug 1, 2014:11:32 AM, at 11:32 AM, Romascanu, Dan (Dan) = wrote: >=20 > > Will remote participation be available? > > > > If yes - do remote participants need to register? > > > > Thanks and Regards, > > > > Dan > > > > > >> -----Original Message----- > >> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On = Behalf Of > >> IESG Secretary > >> Sent: Friday, August 01, 2014 6:04 PM > >> To: IETF Announcement List > >> Cc: netmod@ietf.org > >> Subject: NETMOD WG Interim Meeting, September 17-18, 2014 > >> > >> The IETF NETMOD WG will hold an Interim Meeting on September 17-18, > >> 2014. The meeting will take place at One Penn Plaza, 9th Floor New = York, NY > >> 10119 USA. > >> > >> The agenda of the meeting is to work on YANG 1.1 open issues and in > >> particular on > >> > >> - issues related to YANG 1.1 conformance; > >> - issues related to YANG 1.1 datastores and I2RS support; > >> - any remaining open YANG 1.1 issues. > >> > >> If you'd like to attend, please register by sending an email to the = NETMOD > >> WG chairs. The meeting details with further information about the > >> participants and meeting logistics will be maintained in the SVN of = the > >> NETMOD working group > >> > >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ > >> > >> and also posted on the NETMOD mailing list. A preliminary list of = participants > >> is on the following Doodle poll: > >> > >> http://doodle.com/7eptxb7mggtdhwmc > > > > _______________________________________________ > > 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 >=20 --Apple-Mail=_327262CE-A324-4389-9113-D680D97B4179 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1

I know. We can simply plan for the worst case where EVERYONE that votes is remote.   I guess that borks the physical space planning though...

--Tom


On Aug 1, 2014:12:31 PM, at 12:31 PM, Andy Bierman <andy@yumaworks.com> wrote:




On Fri, Aug 1, 2014 at 9:26 AM, Thomas D. Nadeau <tnadeau@lucidvision.com> wrote:

        Yes and Yes please register so we can size the Webex accordingly.


There is no way to indicate remote attendance on the poll.


        --Tom

Andy
 

On Aug 1, 2014:11:32 AM, at 11:32 AM, Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:

> Will remote participation be available?
>
> If yes - do remote participants need to register?
>
> Thanks and Regards,
>
> Dan
>
>
>> -----Original Message-----
>> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of
>> IESG Secretary
>> Sent: Friday, August 01, 2014 6:04 PM
>> To: IETF Announcement List
>> Cc: netmod@ietf.org
>> Subject: NETMOD WG Interim Meeting, September 17-18, 2014
>>
>> The IETF NETMOD WG will hold an Interim Meeting on September 17-18,
>> 2014. The meeting will take place at One Penn Plaza, 9th Floor New York, NY
>> 10119 USA.
>>
>> The agenda of the meeting is to work on YANG 1.1 open issues and in
>> particular on
>>
>> - issues related to YANG 1.1 conformance;
>> - issues related to YANG 1.1 datastores and I2RS support;
>> - any remaining open YANG 1.1 issues.
>>
>> If you'd like to attend, please register by sending an email to the NETMOD
>> WG chairs. The meeting details with further information about the
>> participants and meeting logistics will be maintained in the SVN of the
>> NETMOD working group
>>
>> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/
>>
>> and also posted on the NETMOD mailing list. A preliminary list of participants
>> is on the following Doodle poll:
>>
>> http://doodle.com/7eptxb7mggtdhwmc
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


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



--Apple-Mail=_327262CE-A324-4389-9113-D680D97B4179-- --Apple-Mail=_D23A079A-534C-4780-B594-51F441DBC36B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT28FMAAoJEPcO+I7eiUJZJ8cP/RQ+yLyW2Mt4Xq1datM36Rjn NEG8Ll79IDfXc17uU+XkEbxeGT1gqZ+UpPPQfQjrAzOsO+hmUeV7FqLtqxnbtIfS gToXR+n+Qg8d/KWsCSLCfYcPJcf2tm141YFaAZSK8xFK/8uD0QPYnOhJNj9RJNZX 8pQmwtaJOdUK08QsYMz7CxMUlHUp0tAe+GE3G6u/jAU46E2Dnvhzi02kRCNQP808 uzaI+SuM6CMx44ciglWjyARt94tXXkrbH589gP4WdsVj0hYzR8KgiQD9O36UmKZ/ OWXjcF+z2ThGu2Vd4ySs9K1tNzCQJwmVrCuEu3cRipFh5zCNQ0tHbamp9JTMWvh/ qq5coMuacKQPzf4smALBrnfbEq4umqpMipcooh0kjrGKEplgl/s3U0jmtPaalV9P jKxHUJxRvuqXN6+72dbRGekuxhXR5x9UOUIt4qKBattmNCSMH9OpXYWzmzaaJjPJ dXzzTd42bCvp+6ZL28XMLl0I8HzIGBUu/1DymstW3FnjW56y/82iDQO9k5aLZBVj wDUXARX59CY19loNut3QSpq6uWPJZJH5Rs4QSHF7xtGrcKt7aBjXM3Vi9WJt6WCK BSRY3UdsCPJ9RijtFQql/PN2nsNXKuYiRreTMtSDYbe+WudV9MkQoAXJy6tlyl0F 3kJZgEsTX2Sh/zA8OV/p =5Kma -----END PGP SIGNATURE----- --Apple-Mail=_D23A079A-534C-4780-B594-51F441DBC36B-- From nobody Fri Aug 1 12:07: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 124241A0067 for ; Fri, 1 Aug 2014 11:01: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 AM41YIx3VBAB for ; Fri, 1 Aug 2014 11:01:32 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69B411B2885 for ; Fri, 1 Aug 2014 11:01:30 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id f8so1791092wiw.6 for ; Fri, 01 Aug 2014 11:01: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:date:message-id:subject:from:to :content-type; bh=C+61nQdv/Ky0L5q0ySKM384bWHridY8XS/f2S/svCiI=; b=dc3B9i6XiO06VzcAbJxhB99L5a9qw/R49CTStgUpKhXO+IurO5yEXQEOhByyrCps+Z anyifdDknYrQPlgCzOy5PGEwBBZret1qOFjH9C966Wgxq7v0j6e22w097p2cNFFv/IBI O/lRApjqJkv33Wq3dlNHSSb2MU5P1/B1222WtjON+GFjnSQW0L+Qi1TVcwR4T9cKJwj0 eHowvGng+4M0KZLzbcdPiaUqsTbfC60ObWgy0XkjYzANi7oUbLGPgVNlE4MvrCzOamh9 Paiz5b4ThUJmvhkeLJG5xerqbKuD46ZlFq/+BK/1WFzzdXvBd/0PxbCb35d0Czb/LV/H xKZA== X-Gm-Message-State: ALoCoQnva9rBg2aZQLIYVWIUpnI8uVfF250pAX4/ItDtFHeSGLoV8sVRg9sAZCdxpc8cEVGHfqRQ MIME-Version: 1.0 X-Received: by 10.180.149.161 with SMTP id ub1mr124617wib.32.1406916088837; Fri, 01 Aug 2014 11:01:28 -0700 (PDT) Received: by 10.194.43.100 with HTTP; Fri, 1 Aug 2014 11:01:28 -0700 (PDT) Received: by 10.194.43.100 with HTTP; Fri, 1 Aug 2014 11:01:28 -0700 (PDT) Date: Fri, 1 Aug 2014 20:01:28 +0200 Message-ID: From: Rainer Gerhards To: netmod@ietf.org Content-Type: multipart/alternative; boundary=001a11c37e56b4552704ff952dd3 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/uIXpbzLeOhR_1LZORPxwqF7msEE X-Mailman-Approved-At: Fri, 01 Aug 2014 12:07:07 -0700 Subject: [netmod] Fwd: draft-wilde-netmod-syslog-model-02 - some initial comments X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Aug 2014 18:01:35 -0000 --001a11c37e56b4552704ff952dd3 Content-Type: text/plain; charset=UTF-8 Sorry, typo in mail address. .. Sent from phone, thus brief. ---------- Weitergeleitete Nachricht ---------- Von: "Rainer Gerhards" Datum: 31.07.2014 18:44 Betreff: draft-wildes-netmod-syslog-model-02 - some initial comments An: Cc: Hi list, Juergen and Tom asked my to have a look at this effort. It's very useful for syslog, so I am happy to see it. Due to my upcoming vacation I could only have a quick initial read at the doc, but I thought I provide some feedback. As the document says, it has a least common denominator approach, which probably is good (I have not yet checked the extensibility options). However, to me it looks like it primarily addresses syslog clients, and much less the servers. As you may know, I am the author of rsyslog and also involved in WinSyslog. I know syslog-ng good enough to see some similarity in both configuration methods (I have also notified the syslog-ng guys, so they may chime in -- or they actually already have). Today's syslogd's have become quite complex, and I know of almost NO enterprise deployment that can go along with simple PRI (facility&severity) based filters. There are also many more destinations (or "actions" as called in rsyslog) as well as log targets. A quick overview of rsyslog's config data model is in [1], it may be interesting to see some of the more verbose config methods. Out of them, especially the scripting-like features are important and very frequently used in enterprise deployments. >From what I understand from netmod-syslog-model so far, it could be used to configure low-end rsyslog instances, especially in SOHO environments. But enterprise operators will probably not be able to actually use it. I would assume the same is true for syslog-ng and many other syslog servers. Thus I think the scope must be well defined. If the target is primarily message originators, that's definitely something that matches commonly used config options AND is extremely useful in enterprise deployments. IMHO, the doc should be limited to that scope, and maybe another one for syslog servers. It could be based on the "originator model", but needs heavy extensions. I would strongly suggest not to aim for both in a single document. Besides fine details which I could not yet check, the document looks very well and usable to me for the originator case. I hope these comments are of some value for the WG. I am now subscribed and will follow any responses. Just note that I am on vacation and so I may respond a bit sluggish. Rainer --001a11c37e56b4552704ff952dd3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Sorry, typo in mail address. ..

Sent from phone, thus brief.

---------- Weitergeleitete Nachricht ----------<= br>Von: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
Datum: 31.07.2014 18:44
Bet= reff: draft-wildes-netmod-syslog-model-02 - some initial comments
An: <netmod@ietf.com>
Cc: =

Hi list,

Juergen and Tom asked my to have a look at this effor= t. It's very useful for syslog, so I am happy to see it.

Due to my upcoming vacation I could only have a quick initial read at t= he doc, but I thought I provide some feedback.

As the document says, it has a least common denominator approach,= which probably is good (I have not yet checked the extensibility options).= However, to me it looks like it primarily addresses syslog clients, and mu= ch less the servers.

As you may know, I am the author of rsyslog and also involved in = WinSyslog. I know syslog-ng good enough to see some similarity in both conf= iguration methods (I have also notified the syslog-ng guys, so they may chi= me in -- or they actually already have).

Today's syslogd's have become quite complex, and I know o= f almost NO enterprise deployment that can go along with simple PRI (facili= ty&severity) based filters. There are also many more destinations (or &= quot;actions" as called in rsyslog) as well as log targets. A quick ov= erview of rsyslog's config data model is in [1], it may be interesting = to see some of the more verbose config methods. Out of them, especially the= scripting-like features are important and very frequently used in enterpri= se deployments.

From what I understand from netmod-syslog-model so far, it could = be used to configure low-end rsyslog instances, especially in SOHO environm= ents. But enterprise operators will probably not be able to actually use it= . I would assume the same is true for syslog-ng and many other syslog serve= rs.

Thus I think the scope must be well defined. If the target is primarily= message originators, that's definitely something that matches commonly= used config options AND is extremely useful in enterprise deployments.

IMHO, the doc should be limited to that scope, and maybe another = one for syslog servers. It could be based on the "originator model&quo= t;, but needs heavy extensions. I would strongly suggest not to aim for bot= h in a single document.

Besides fine details which I could not yet check, the document looks ve= ry well and usable to me for the originator case.

I hope these= comments are of some value for the WG. I am now subscribed and will follow= any responses. Just note that I am on vacation and so I may respond a bit = sluggish.

Rainer
--001a11c37e56b4552704ff952dd3-- From nobody Fri Aug 1 12:56: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 48ABE1A00E7 for ; Fri, 1 Aug 2014 12:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 PZR86piIWQ_i for ; Fri, 1 Aug 2014 12:56:30 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DE171A008C for ; Fri, 1 Aug 2014 12:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8636; q=dns/txt; s=iport; t=1406922990; x=1408132590; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Wc4acpm9jFYpvtmAIIp5mh63pMIlzlV2/oDuAsMwDPU=; b=Ixsm8Ns/twMHwQydyWgx1cJDrhuNhalREHIOmUAgdyCGBeh7+uHiQ5sP o/+kuBr+oDUhfxZqd8RwRwEZbF6hy7IKNtbTFcu3dwcKLl7AY/uj7c6rI t4ij6/ij+mHT5K6ASCSiCp5KSCo2AgZAFpc6gUuclTquWfQPLXcbWARLv g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAPHv21OtJA2J/2dsb2JhbABbgkcjI4EpBNNdAYELFneEAwEBAQR5EAIBCA4DAwECKAcyFAkIAgQOBYhCAchfF450AQYBAT4RBwaERQWGBohojQyUWoNJbIEDAQgXIg X-IronPort-AV: E=Sophos;i="5.01,781,1400025600"; d="scan'208,217";a="344297819" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-1.cisco.com with ESMTP; 01 Aug 2014 19:56:29 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s71JuTV6013964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 19:56:29 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 14:56:29 -0500 From: "Clyde Wildes (cwildes)" To: Rainer Gerhards Thread-Topic: [netmod] Fwd: draft-wilde-netmod-syslog-model-02 - some initial comments Thread-Index: AQHPrcKuY4fAGkYS9ki6U7s3lVCuXw== Date: Fri, 1 Aug 2014 19:56:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.27.7.178] Content-Type: multipart/alternative; boundary="_000_D0013DDF8CEBFcwildesciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZfyICxRy_tpMNWdePh9nf_M4I2w Cc: Kiran Agrahara Sreenivasa , "netmod@ietf.org" Subject: Re: [netmod] Fwd: draft-wilde-netmod-syslog-model-02 - some initial comments X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Aug 2014 19:56:33 -0000 --_000_D0013DDF8CEBFcwildesciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rainer, Thanks for your review. I agree that we should limit the scope of this effort to syslog originators= , and treat syslog servers as a separate effort. We will review the rsyslog implementation to learn about the additional act= ions, and the extended message filtering implementation. Thanks, Clyde From: Rainer Gerhards > Date: Friday, August 1, 2014 at 11:01 AM To: "netmod@ietf.org" > Subject: [netmod] Fwd: draft-wilde-netmod-syslog-model-02 - some initial co= mments Sorry, typo in mail address. .. Sent from phone, thus brief. ---------- Weitergeleitete Nachricht ---------- Von: "Rainer Gerhards" > Datum: 31.07.2014 18:44 Betreff: draft-wildes-netmod-syslog-model-02 - some initial comments An: > Cc: Hi list, Juergen and Tom asked my to have a look at this effort. It's very useful fo= r syslog, so I am happy to see it. Due to my upcoming vacation I could only have a quick initial read at the d= oc, but I thought I provide some feedback. As the document says, it has a least common denominator approach, which pro= bably is good (I have not yet checked the extensibility options). However, = to me it looks like it primarily addresses syslog clients, and much less th= e servers. As you may know, I am the author of rsyslog and also involved in WinSyslog.= I know syslog-ng good enough to see some similarity in both configuration = methods (I have also notified the syslog-ng guys, so they may chime in -- o= r they actually already have). Today's syslogd's have become quite complex, and I know of almost NO enterp= rise deployment that can go along with simple PRI (facility&severity) based= filters. There are also many more destinations (or "actions" as called in = rsyslog) as well as log targets. A quick overview of rsyslog's config data = model is in [1], it may be interesting to see some of the more verbose conf= ig methods. Out of them, especially the scripting-like features are importa= nt and very frequently used in enterprise deployments. >From what I understand from netmod-syslog-model so far, it could be used to= configure low-end rsyslog instances, especially in SOHO environments. But = enterprise operators will probably not be able to actually use it. I would = assume the same is true for syslog-ng and many other syslog servers. Thus I think the scope must be well defined. If the target is primarily mes= sage originators, that's definitely something that matches commonly used co= nfig options AND is extremely useful in enterprise deployments. IMHO, the doc should be limited to that scope, and maybe another one for sy= slog servers. It could be based on the "originator model", but needs heavy = extensions. I would strongly suggest not to aim for both in a single docume= nt. Besides fine details which I could not yet check, the document looks very w= ell and usable to me for the originator case. I hope these comments are of some value for the WG. I am now subscribed and= will follow any responses. Just note that I am on vacation and so I may re= spond a bit sluggish. Rainer --_000_D0013DDF8CEBFcwildesciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5984B15C7F18794790B92F2251A6B7C9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Rainer,

Thanks for your review.

I agree that we should limit the scope of this effort to syslog origin= ators, and treat syslog servers as a separate effort.

We will review the rsyslog implementation to learn about the additiona= l actions, and the extended message filtering implementation.

Thanks,

Clyde

From: Rainer Gerhards <rgerhards@hq.adiscon.com>
Date: Friday, August 1, 2014 at 11:= 01 AM
To: "netmod@ietf.org" <= netmod@ietf.org>
Subject: [netmod] Fwd: draft-wilde-= netmod-syslog-model-02 - some initial comments

Sorry, typo in mail address. ..

Sent from phone, thus brief.

---------- Weitergeleitete Nachricht ----------<= br> Von: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
Datum: 31.07.2014 18:44
Betreff: draft-wildes-netmod-syslog-model-02 - some initial comments
An: <netmod@ietf.com>
Cc:

Hi list,

Juergen and Tom asked my to have a look at this effort. It's very useful fo= r syslog, so I am happy to see it.

Due to my upcoming vacation I could only have a quick initial read at the d= oc, but I thought I provide some feedback.

As the document says, it has a least common denominator approach, which pro= bably is good (I have not yet checked the extensibility options). However, = to me it looks like it primarily addresses syslog clients, and much less th= e servers.

As you may know, I am the author of rsyslog and also involved in WinSyslog.= I know syslog-ng good enough to see some similarity in both configuration = methods (I have also notified the syslog-ng guys, so they may chime in -- o= r they actually already have).

Today's syslogd's have become quite complex, and I know of almost NO enterp= rise deployment that can go along with simple PRI (facility&severity) b= ased filters. There are also many more destinations (or "actions"= as called in rsyslog) as well as log targets. A quick overview of rsyslog's config data model is in [1], it may be inter= esting to see some of the more verbose config methods. Out of them, especia= lly the scripting-like features are important and very frequently used in e= nterprise deployments.

>From what I understand from netmod-syslog-model so far, it could be used to= configure low-end rsyslog instances, especially in SOHO environments. But = enterprise operators will probably not be able to actually use it. I would = assume the same is true for syslog-ng and many other syslog servers.

Thus I think the scope must be well defined. If the target is primarily mes= sage originators, that's definitely something that matches commonly used co= nfig options AND is extremely useful in enterprise deployments.

IMHO, the doc should be limited to that scope, and maybe another one for sy= slog servers. It could be based on the "originator model", but ne= eds heavy extensions. I would strongly suggest not to aim for both in a sin= gle document.

Besides fine details which I could not yet check, the document looks very w= ell and usable to me for the originator case.

I hope these comments are of some value for the WG. I am now subscribed and= will follow any responses. Just note that I am on vacation and so I may re= spond a bit sluggish.

Rainer
 --_000_D0013DDF8CEBFcwildesciscocom_-- From nobody Fri Aug 1 13:00: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 2B9221B28B3; Fri, 1 Aug 2014 13:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 ZsEYoBOi2jpM; Fri, 1 Aug 2014 13:00:51 -0700 (PDT) Received: from fncnmp04.fnc.fujitsu.com (fncnmp04.fnc.fujitsu.com [168.127.0.57]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 899811A0467; Fri, 1 Aug 2014 13:00:50 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.01,781,1400043600"; d="scan'208,217"; a="54335056" Received: from rchexhcp2.fnc.net.local ([168.127.134.76]) by fncnmp02.fnc.fujitsu.com with ESMTP/TLS/AES128-SHA; 01 Aug 2014 15:00:49 -0500 Received: from RCHEXMBP1.fnc.net.local ([169.254.2.63]) by RCHEXHCP2.fnc.net.local ([168.127.134.76]) with mapi id 14.03.0181.006; Fri, 1 Aug 2014 15:00:48 -0500 From: "O'Connor, Don" To: Greg Mirsky Thread-Topic: [nvo3] YANG models for OAM Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edAoWIbcAAAE6agAACU5iwP//xQ4A//8BvNA= Date: Fri, 1 Aug 2014 20:00:48 +0000 Message-ID: <7DFA7869D33BD44A9A84BA24AD75BDE6D9E46A72@RCHEXMBP1.fnc.net.local> References: <1406847186.16320.YahooMailNeo@web162805.mail.bf1.yahoo.com> <7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645D@RCHEXMBP1.fnc.net.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [168.127.136.253] x-tm-as-product-ver: SMEX-10.2.0.3176-7.500.1018-20854.002 x-tm-as-result: No--56.649100-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_7DFA7869D33BD44A9A84BA24AD75BDE6D9E46A72RCHEXMBP1fncnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ivUeERkG6JBGGw8Hh0-Z53c7dVI Cc: "l2vpn@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "netmod@ietf.org" , "trill@ietf.org" Subject: Re: [netmod] [nvo3] YANG models for OAM X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Aug 2014 20:00:57 -0000 --_000_7DFA7869D33BD44A9A84BA24AD75BDE6D9E46A72RCHEXMBP1fncnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlZw0KDQpUaGUgc2NvcGUgb2YgdGhlIE1FRiBzcGVjaWZpY2F0aW9ucyBpcyB0aGUgRXRoZXJu ZXQgU2VydmljZSBMYXllciBmb3IgQ2FycmllciBFdGhlcm5ldCBTZXJ2aWNlcyDigJMgRmF1bHQg TWFuYWdlbWVudCBhbmQgUGVyZm9ybWFuY2UgTWFuYWdlbWVudA0KDQpSZWdhcmRzDQoNCkRvbg0K DQpGcm9tOiBMMnZwbiBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBHcmVnIE1pcnNreQ0KU2VudDogVGh1cnNkYXksIEp1bHkgMzEsIDIwMTQgNjo0OSBQTQ0KVG86 IE8nQ29ubm9yLCBEb24NCkNjOiBsMnZwbkBpZXRmLm9yZzsgbmV0bW9kQGlldGYub3JnOyBudm8z QGlldGYub3JnOyB0cmlsbEBpZXRmLm9yZzsgb3BzYXdnQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W252bzNdIFlBTkcgbW9kZWxzIGZvciBPQU0NCg0KSGkgRG9uLA0KdGhhbmsgeW91IGZvciB0aGUg cmVmZXJlbmNlLiBBbmQgSSdkIHBvaW50IHRoYXQgSVRVIFNHMTUgaXMgd29ya2luZyBvbiBzdGFu ZGFyZGl6aW5nICJnZW5lcmljIHByb3RvY29sLW5ldXRyYWwgbWFuYWdlbWVudCBpbmZvcm1hdGlv biBtb2RlbCIgZm9yIHRyYW5zcG9ydCBuZXR3b3JrLCBpbmNsdWRpbmcgT0FNLiBIZW5jZSBteSBx dWVzdGlvbiwgV2hhdCBpcyB0aGUgc2NvcGUgb2YgdGhlc2UgZG9jdW1lbnRzPw0KUmVnYXJkcywN CkdyZWcNCg0KT24gVGh1LCBKdWwgMzEsIDIwMTQgYXQgNDozMSBQTSwgTydDb25ub3IsIERvbiA8 ZG9uLm9jb25ub3JAdXMuZnVqaXRzdS5jb208bWFpbHRvOmRvbi5vY29ubm9yQHVzLmZ1aml0c3Uu Y29tPj4gd3JvdGU6DQpUaXNzYSwgR3JlZywgYWxsDQoNCk1ldHJvIEV0aGVybmV0IEZvcnVtIGhh cyBhbHJlYWR5IHN0YW5kYXJkaXplZCBZYW5nIE1vZHVsZXMgZm9yIEV0aGVybmV0IFNlcnZpY2Ug T0FNIFBlcmZvcm1hbmNlIE1vbml0b3JpbmcgYW5kIEZhdWx0IE1hbmFnZW1lbnQuIFBsZWFzZSBz ZWUgTUVGIDM4IGFuZCAzOQ0KDQpodHRwOi8vbWV0cm9ldGhlcm5ldGZvcnVtLm9yZy9jYXJyaWVy LWV0aGVybmV0L3RlY2huaWNhbC1zcGVjaWZpY2F0aW9ucw0KDQpSZWdhcmRzDQoNCkRvbg0KDQpG cm9tOiBMMnZwbiBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJv dW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgVGlzc2EgU2VuZXZpcmF0aG5lDQpTZW50OiBU aHVyc2RheSwgSnVseSAzMSwgMjAxNCA1OjUzIFBNDQpUbzogR3JlZyBNaXJza3k7IFRpc3NhIFNl bmV2aXJhdGhuZSAodHNlbmV2aXIpDQoNCkNjOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5A aWV0Zi5vcmc+OyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz47IG52bzNA aWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+OyBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5l dG1vZEBpZXRmLm9yZz47IHRyaWxsQGlldGYub3JnPG1haWx0bzp0cmlsbEBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbbnZvM10gWUFORyBtb2RlbHMgZm9yIE9BTQ0KDQpHcmVnDQoNClllcyBpdCBp cywgZ2VuZXJpYyBZQU5HIG1vZGVsIHN0ZXVwIHRoZSBiYXNlIGZyYW1ld29yay4gSXQgY2FuIGJl IGV4dGVuZGVkIHRvIGFkZCB0b29scyBhcyB3ZWxsIGFzIG90aGVyIGVsZW1lbnRzIGFzIHdlbGwg dGVjaG5vbG9neSBkZXZpYXRpb25zLiBBbGFybXMgZXRjIGVpdGhlciBiZSBwYXJ0IG9mIHRoaXMg ZG9jdW1lbnQgd2lsbCBiZSBhIHNlcGFyYXRlIGRvY3VtZW50IHRoYXQgc3BlY2lmaWVzIHRoZW0u IFRoYXQgaXMgdGhlIHJlYXNvbiB3ZSBoYXZlIGRlc2lnbmVkIHRoZSBtb2RlbCBhcyBtb2R1bGFy IGFzIHBvc3NpYmxlIGFuZCBleHRlbnNpYmxlIGFzIHBvc3NpYmxlLg0KDQpQbGVhc2UgbGV0IHVz IGtub3cgaWYgYW55IG9mIHRoZSBwYXJ0cyBhcmUgbm90IGV4dGVuc2libGUgb3Igbm90IG1vZHVs YXIgZW5vdWdoLg0KDQpUaGFua3MNClRpc3NhDQoNCk9uIFRodXJzZGF5LCBKdWx5IDMxLCAyMDE0 IDM6MTcgUE0sIEdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb208bWFpbHRvOmdyZWdp bWlyc2t5QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIaSBUaXNzYSwgYXV0aG9ycywgZXQuIGFsLA0K SSd2ZSByZWFkIGRvY3VtZW50cyBhbmQgd291bGQgbGlrZSB0byBjbGFyaWZ5IHNjb3BlIG9mIHRo ZXNlIGRvY3VtZW50cy4gT0FNIGlzIG5vdCBsaW1pdGVkIHRvIHBpbmcgYW5kIHRyYWNlcm91dGUg ZnVuY3Rpb25zLiBJdCBldmVuIG5vdCBsaW1pdGVkIHRvIGNvbnRpbnVpdHkgY2hlY2suIEFuZCBp biBjb25uZWN0aW9ubGVzcyBuZXR3b3JrcyB0aGVyZSB3b3VsZCBub3QgYmUgY29ubmVjdGl2aXR5 IHZlcmlmaWNhdGlvbi4gQW5kIHRoZSBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCBpcyB0aGUgYmln IHBhcnQgb2YgT0FNIGFzIHdlbGwgYXMgcHJvdGVjdGlvbiBjb29yZGluYXRpb24sIGRlZmVjdCBh bGFybXMsIGFuZCBldGMuIEhlbmNlIG15IHF1ZXN0aW9uLCBpcyBpdCBpbiBwbGFucyBvZiB0aGUg YXV0aG9ycyB0byBhZGRyZXNzIGFsbCBvZiBPQU0gaW4gcmVzcGVjdGl2ZSBkb2N1bWVudHM/DQpS ZWdhcmRzLA0KR3JlZw0KDQpPbiBUdWUsIEp1biAxMCwgMjAxNCBhdCAxMjowMyBQTSwgVGlzc2Eg U2VuZXZpcmF0aG5lICh0c2VuZXZpcikgPHRzZW5ldmlyQGNpc2NvLmNvbTxtYWlsdG86dHNlbmV2 aXJAY2lzY28uY29tPj4gd3JvdGU6DQpBbGwNCg0KV2UgaGF2ZSBwdWJsaXNoZWQgWUFORyBtb2Rl bCBmb3IgT0FNLiAjMSBkcmFmdCBiZWxvdyBwbGFjZSB0aGUgZ2VuZXJpYyBmcmFtZXdvcmsgZm9y IE9BTSwgdGhhdCBjYW4gYmUgYXVnbWVudGVkIGZvciBkaWZmZXJlbnQgdGVjaG5vbG9naWVzLiAj MiBhbmQgIzMgYXJlIGFwcGxpY2F0aW9uIG9mIHRoZSBjb25jZXB0IHRvIE5WTzMgYW5kIFRSSUxM LA0KDQoxLiAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGlzc2Et bmV0bW9kLW9hbS8NCjIuICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC10aXNzYS1udm8zLXlhbmctb2FtLw0KMy4gICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LXRpc3NhLXRyaWxsLXlhbmctb2FtLw0KDQpQbGVhc2UgcmV2aWV3IGFuZCBz aGFyZSB5b3VyIGNvbW1lbnRzDQoNClRoYW5rcw0KVGlzc2ENCg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpudm8zIG1haWxpbmcgbGlzdA0KbnZv M0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbnZvMw0KDQoNCg0K --_000_7DFA7869D33BD44A9A84BA24AD75BDE6D9E46A72RCHEXMBP1fncnet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRp di5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g VGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxT dHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7DQoJZm9udC13ZWlnaHQ6bm9ybWFs Ow0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5H cmVnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlRoZSBzY29wZSBvZiB0aGUgTUVGIHNwZWNpZmljYXRpb25zIGlzIHRoZSBFdGhl cm5ldCBTZXJ2aWNlIExheWVyIGZvciBDYXJyaWVyIEV0aGVybmV0IFNlcnZpY2VzIOKAkyBGYXVs dCBNYW5hZ2VtZW50IGFuZCBQZXJmb3JtYW5jZSBNYW5hZ2VtZW50PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+RG9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gTDJ2cG4gW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5HcmVnIE1pcnNreTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2Rh eSwgSnVseSAzMSwgMjAxNCA2OjQ5IFBNPGJyPg0KPGI+VG86PC9iPiBPJ0Nvbm5vciwgRG9uPGJy Pg0KPGI+Q2M6PC9iPiBsMnZwbkBpZXRmLm9yZzsgbmV0bW9kQGlldGYub3JnOyBudm8zQGlldGYu b3JnOyB0cmlsbEBpZXRmLm9yZzsgb3BzYXdnQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbbnZvM10gWUFORyBtb2RlbHMgZm9yIE9BTTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgRG9uLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPnRoYW5rIHlvdSBmb3IgdGhlIHJlZmVyZW5jZS4gQW5kIEknZCBwb2ludCB0aGF0 IElUVSBTRzE1IGlzIHdvcmtpbmcgb24gc3RhbmRhcmRpemluZyAmcXVvdDtnZW5lcmljIHByb3Rv Y29sLW5ldXRyYWwgbWFuYWdlbWVudCBpbmZvcm1hdGlvbiBtb2RlbCZxdW90OyBmb3IgdHJhbnNw b3J0IG5ldHdvcmssIGluY2x1ZGluZyBPQU0uIEhlbmNlIG15IHF1ZXN0aW9uLCBXaGF0IGlzIHRo ZQ0KIHNjb3BlIG9mIHRoZXNlIGRvY3VtZW50cz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+R3JlZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1bCAzMSwgMjAx NCBhdCA0OjMxIFBNLCBPJ0Nvbm5vciwgRG9uICZsdDs8YSBocmVmPSJtYWlsdG86ZG9uLm9jb25u b3JAdXMuZnVqaXRzdS5jb20iIHRhcmdldD0iX2JsYW5rIj5kb24ub2Nvbm5vckB1cy5mdWppdHN1 LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGlzc2EsIEdyZWcsIGFsbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWV0cm8gRXRoZXJuZXQgRm9ydW0gaGFzIGFscmVh ZHkgc3RhbmRhcmRpemVkIFlhbmcgTW9kdWxlcyBmb3IgRXRoZXJuZXQgU2VydmljZSBPQU0gUGVy Zm9ybWFuY2UgTW9uaXRvcmluZw0KIGFuZCBGYXVsdCBNYW5hZ2VtZW50LiBQbGVhc2Ugc2VlIE1F RiAzOCBhbmQgMzk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHA6Ly9tZXRyb2V0aGVybmV0Zm9ydW0u b3JnL2NhcnJpZXItZXRoZXJuZXQvdGVjaG5pY2FsLXNwZWNpZmljYXRpb25zIiB0YXJnZXQ9Il9i bGFuayI+aHR0cDovL21ldHJvZXRoZXJuZXRmb3J1bS5vcmcvY2Fycmllci1ldGhlcm5ldC90ZWNo bmljYWwtc3BlY2lmaWNhdGlvbnM8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Eb248 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEwydnBuIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmwydnBu LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5sMnZwbi1ib3VuY2VzQGlldGYub3Jn PC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VGlzc2EgU2VuZXZpcmF0aG5lPGJyPg0KPGI+U2Vu dDo8L2I+IFRodXJzZGF5LCBKdWx5IDMxLCAyMDE0IDU6NTMgUE08YnI+DQo8Yj5Ubzo8L2I+IEdy ZWcgTWlyc2t5OyBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5DYzo8L2I+IDxhIGhy ZWY9Im1haWx0bzpsMnZwbkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmwydnBuQGlldGYub3Jn PC9hPjsgPGEgaHJlZj0ibWFpbHRvOm9wc2F3Z0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0K b3BzYXdnQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm52bzNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5udm8zQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2RAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWls dG86dHJpbGxAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnRyaWxsQGlldGYub3JnPC9hPjxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW252bzNdIFlBTkcgbW9kZWxzIGZvciBPQU08bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+R3JlZzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5ZZXMgaXQgaXMsIGdlbmVyaWMgWUFORyBtb2RlbCBzdGV1cCB0 aGUgYmFzZSBmcmFtZXdvcmsuIEl0IGNhbiBiZSBleHRlbmRlZCB0byBhZGQgdG9vbHMgYXMgd2Vs bCBhcyBvdGhlciBlbGVtZW50cw0KIGFzIHdlbGwgdGVjaG5vbG9neSBkZXZpYXRpb25zLiBBbGFy bXMgZXRjIGVpdGhlciBiZSBwYXJ0IG9mIHRoaXMgZG9jdW1lbnQgd2lsbCBiZSBhIHNlcGFyYXRl IGRvY3VtZW50IHRoYXQgc3BlY2lmaWVzIHRoZW0uIFRoYXQgaXMgdGhlIHJlYXNvbiB3ZSBoYXZl IGRlc2lnbmVkIHRoZSBtb2RlbCBhcyBtb2R1bGFyIGFzIHBvc3NpYmxlIGFuZCBleHRlbnNpYmxl IGFzIHBvc3NpYmxlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UGxlYXNlIGxldCB1cyBrbm93IGlmIGFueSBvZiB0aGUg cGFydHMgYXJlIG5vdCBleHRlbnNpYmxlIG9yIG5vdCBtb2R1bGFyIGVub3VnaC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PlRoYW5rczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaXNzYTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRl Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+T24gVGh1cnNkYXksIEp1bHkgMzEsIDIwMTQgMzoxNyBQTSwgR3JlZyBNaXJza3kgJmx0 OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5n cmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SGkgVGlzc2Es IGF1dGhvcnMsIGV0LiBhbCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SSd2 ZSByZWFkIGRvY3VtZW50cyBhbmQgd291bGQgbGlrZSB0byBjbGFyaWZ5IHNjb3BlIG9mIHRoZXNl IGRvY3VtZW50cy4gT0FNIGlzIG5vdCBsaW1pdGVkIHRvIHBpbmcgYW5kIHRyYWNlcm91dGUgZnVu Y3Rpb25zLiBJdCBldmVuIG5vdCBsaW1pdGVkIHRvIGNvbnRpbnVpdHkgY2hlY2suIEFuZCBpbiBj b25uZWN0aW9ubGVzcyBuZXR3b3Jrcw0KIHRoZXJlIHdvdWxkIG5vdCBiZSBjb25uZWN0aXZpdHkg dmVyaWZpY2F0aW9uLiBBbmQgdGhlIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IGlzIHRoZSBiaWcg cGFydCBvZiBPQU0gYXMgd2VsbCBhcyBwcm90ZWN0aW9uIGNvb3JkaW5hdGlvbiwgZGVmZWN0IGFs YXJtcywgYW5kIGV0Yy4gSGVuY2UgbXkgcXVlc3Rpb24sIGlzIGl0IGluIHBsYW5zIG9mIHRoZSBh dXRob3JzIHRvIGFkZHJlc3MgYWxsIG9mIE9BTSBpbiByZXNwZWN0aXZlIGRvY3VtZW50cz88L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3Jv dW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UmVnYXJkcyw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndo aXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+R3JlZzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+T24gVHVlLCBKdW4gMTAsIDIwMTQgYXQgMTI6MDMgUE0sIFRpc3NhIFNl bmV2aXJhdGhuZSAodHNlbmV2aXIpICZsdDs8YSBocmVmPSJtYWlsdG86dHNlbmV2aXJAY2lzY28u Y29tIiB0YXJnZXQ9Il9ibGFuayI+dHNlbmV2aXJAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+QWxsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPldl IGhhdmUgcHVibGlzaGVkIFlBTkcgbW9kZWwgZm9yIE9BTS4gIzEgZHJhZnQgYmVsb3cgcGxhY2Ug dGhlIGdlbmVyaWMgZnJhbWV3b3JrIGZvciBPQU0sIHRoYXQgY2FuIGJlIGF1Z21lbnRlZCBmb3Ig ZGlmZmVyZW50IHRlY2hub2xvZ2llcy4gIzIgYW5kICMzIGFyZSBhcHBsaWNhdGlvbiBvZiB0aGUg Y29uY2VwdCB0byBOVk8zIGFuZCBUUklMTCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+MS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXRpc3NhLW5ldG1vZC1vYW0vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aXNzYS1uZXRtb2Qtb2FtLzwvYT48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dy b3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjIuPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aXNzYS1udm8zLXlhbmctb2FtLyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGlzc2Et bnZvMy15YW5nLW9hbS88L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj4zLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtdGlzc2EtdHJpbGwteWFuZy1vYW0vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC10aXNzYS10cmlsbC15YW5nLW9hbS88L2E+PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tn cm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dy b3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlBsZWFzZSByZXZpZXcgYW5k IHNoYXJlIHlvdXIgY29tbWVudHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+VGhhbmtzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5UaXNzYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpudm8zIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpudm8zQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bnZvM0BpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzMiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzM8L2E+ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFj a2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDti YWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_7DFA7869D33BD44A9A84BA24AD75BDE6D9E46A72RCHEXMBP1fncnet_-- From nobody Fri Aug 1 13: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 BAFA71ABC74; Fri, 1 Aug 2014 13:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 g7eXYO4DbZTr; Fri, 1 Aug 2014 13:08:24 -0700 (PDT) Received: from fncnmp03.fnc.fujitsu.com (fncnmp03.fnc.fujitsu.com [168.127.0.56]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5F201A0467; Fri, 1 Aug 2014 13:08:23 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.01,781,1400043600"; d="scan'208,217"; a="52769688" Received: from rchexhcp1.fnc.net.local ([168.127.134.75]) by fncnmp01.fnc.fujitsu.com with ESMTP/TLS/AES128-SHA; 01 Aug 2014 15:08:23 -0500 Received: from RCHEXMBP1.fnc.net.local ([169.254.2.63]) by RCHEXHCP1.fnc.net.local ([168.127.134.75]) with mapi id 14.03.0181.006; Fri, 1 Aug 2014 15:08:22 -0500 From: "O'Connor, Don" To: "Tissa Senevirathne (tsenevir)" , Tissa Senevirathne , Greg Mirsky Thread-Topic: [nvo3] YANG models for OAM Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edAoWIbcAAAE6agAACU5iwAAR6gcAAAadH3A= Date: Fri, 1 Aug 2014 20:08:22 +0000 Message-ID: <7DFA7869D33BD44A9A84BA24AD75BDE6D9E46AA6@RCHEXMBP1.fnc.net.local> References: <1406847186.16320.YahooMailNeo@web162805.mail.bf1.yahoo.com> <7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645D@RCHEXMBP1.fnc.net.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [168.127.136.253] x-tm-as-product-ver: SMEX-10.2.0.3176-7.500.1018-20854.002 x-tm-as-result: No--51.982500-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_7DFA7869D33BD44A9A84BA24AD75BDE6D9E46AA6RCHEXMBP1fncnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KG3qRYWEFYEaJ37ZbdhmQWSgPdA Cc: "l2vpn@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "netmod@ietf.org" , "trill@ietf.org" Subject: Re: [netmod] [nvo3] YANG models for OAM X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Aug 2014 20:08:26 -0000 --_000_7DFA7869D33BD44A9A84BA24AD75BDE6D9E46AA6RCHEXMBP1fncnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tissa The MEF standards apply to the Ethernet Service Layer of Carrier Ethernet S= ervices. Are the IDs in your email constrained to layers below the Ethernet= Service Layer for Carrier Ethernet Service? Or are they not applicable to = Carrier Ethernet Service? Regards Don From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Tissa Senevirathne= (tsenevir) Sent: Thursday, July 31, 2014 6:49 PM To: O'Connor, Don; Tissa Senevirathne; Greg Mirsky Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@= ietf.org Subject: RE: [nvo3] YANG models for OAM Don I am aware of that, but this is different, MEF YANG model is specifically f= or Ethernet and structure does not allow to bring different addressing sche= mes other than MAC address. Additionally the proposed standard allow to add= flow entropies and facilitate nested OAM between different technologies. Y= ou may have to read in to the details to see the actual differences. From: O'Connor, Don [mailto:don.oconnor@us.fujitsu.com] Sent: Thursday, July 31, 2014 4:32 PM To: Tissa Senevirathne; Greg Mirsky; Tissa Senevirathne (tsenevir) Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@ietf.org Subject: RE: [nvo3] YANG models for OAM Tissa, Greg, all Metro Ethernet Forum has already standardized Yang Modules for Ethernet Ser= vice OAM Performance Monitoring and Fault Management. Please see MEF 38 and= 39 http://metroethernetforum.org/carrier-ethernet/technical-specifications Regards Don From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Tissa Senevirathne Sent: Thursday, July 31, 2014 5:53 PM To: Greg Mirsky; Tissa Senevirathne (tsenevir) Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@ietf.org Subject: Re: [nvo3] YANG models for OAM Greg Yes it is, generic YANG model steup the base framework. It can be extended = to add tools as well as other elements as well technology deviations. Alarm= s etc either be part of this document will be a separate document that spec= ifies them. That is the reason we have designed the model as modular as pos= sible and extensible as possible. Please let us know if any of the parts are not extensible or not modular en= ough. Thanks Tissa On Thursday, July 31, 2014 3:17 PM, Greg Mirsky > wrote: Hi Tissa, authors, et. al, I've read documents and would like to clarify scope of these documents. OAM= is not limited to ping and traceroute functions. It even not limited to co= ntinuity check. And in connectionless networks there would not be connectiv= ity verification. And the performance measurement is the big part of OAM as= well as protection coordination, defect alarms, and etc. Hence my question= , is it in plans of the authors to address all of OAM in respective documen= ts? Regards, Greg On Tue, Jun 10, 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) > wrote: All We have published YANG model for OAM. #1 draft below place the generic fram= ework for OAM, that can be augmented for different technologies. #2 and #3 = are application of the concept to NVO3 and TRILL, 1. http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/ 2. http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-oam/ 3. http://datatracker.ietf.org/doc/draft-tissa-trill-yang-oam/ Please review and share your comments Thanks Tissa _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 --_000_7DFA7869D33BD44A9A84BA24AD75BDE6D9E46AA6RCHEXMBP1fncnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tissa

 

The MEF standards apply to = the Ethernet Service Layer of Carrier Ethernet Services. Are the IDs in you= r email constrained to layers below the Ethernet Service Layer for Carrier Ethernet Service? Or are they not applicable to Carrier = Ethernet Service?

 

Regards

 

Don

 

From: L2vpn [m= ailto:l2vpn-bounces@ietf.org] On Behalf Of Tissa Senevirathne (tsenevir)
Sent: Thursday, July 31, 2014 6:49 PM
To: O'Connor, Don; Tissa Senevirathne; Greg Mirsky
Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org;= trill@ietf.org
Subject: RE: [nvo3] YANG models for OAM

 

Don


I am aware of that, but this is different, MEF YANG model is specifically f= or Ethernet and structure does not allow to bring different addressing sche= mes other than MAC address. Additionally the proposed standard allow to add= flow entropies and facilitate nested OAM between different technologies. You may have to read in to the details= to see the actual differences.

 <= /p>

From: O'Connor= , Don [mailto:don.oconnor@us.= fujitsu.com]
Sent: Thursday, July 31, 2014 4:32 PM
To: Tissa Senevirathne; Greg Mirsky; Tissa Senevirathne (tsenevir) Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@ietf.org Subject: RE: [nvo3] YANG models for OAM

 

Tissa, Greg, all=

 

Metro Ethernet Forum has al= ready standardized Yang Modules for Ethernet Service OAM Performance Monito= ring and Fault Management. Please see MEF 38 and 39

 

http://metroethern= etforum.org/carrier-ethernet/technical-specifications=

 

Regards

 

Don

 

From: L2vpn [<= a href=3D"mailto:l2vpn-bounces@ietf.org">mailto:l2vpn-bounces@ietf.org] On Behalf Of Tissa Senevirathne
Sent: Thursday, July 31, 2014 5:53 PM
To: Greg Mirsky; Tissa Senevirathne (tsenevir)
Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@ietf.org Subject: Re: [nvo3] YANG models for OAM

 

Greg=

 

Yes it is, generic YANG model steup the ba= se framework. It can be extended to add tools as well as other elements as = well technology deviations. Alarms etc either be part of this document will be a separate document that specifies them. That is the= reason we have designed the model as modular as possible and extensible as= possible.

 

Please let us know if any of the parts are= not extensible or not modular enough.

 

Thanks

Tissa

 

On= Thursday, July 31, 2014 3:17 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:<= /o:p>

 

Hi Tissa, autho= rs, et. al,

I've read documents and would like to clarify scope of these document= s. OAM is not limited to ping and traceroute functions. It even not limited to continuity check. And in connectionless networks there= would not be connectivity verification. And the performance measurement is= the big part of OAM as well as protection coordination, defect alarms, and= etc. Hence my question, is it in plans of the authors to address all of OAM in respective documents?

Regards,

Greg=

 

On Tue, Jun 10,= 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) <tsenevir@cisco.com> wrote:

All<= /span>

 

We have publish= ed YANG model for OAM. #1 draft below place the generic framework for OAM, = that can be augmented for different technologies. #2 and #3 are application of the concept to NVO3 and TRILL,

 

 

Please review a= nd share your comments

 

Thanks

Tissa

 

 


_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

 

 

--_000_7DFA7869D33BD44A9A84BA24AD75BDE6D9E46AA6RCHEXMBP1fncnet_-- From nobody Fri Aug 1 13:59: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 B09A31A008B for ; Fri, 1 Aug 2014 13:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 p0aueTXihCx1 for ; Fri, 1 Aug 2014 13:59:48 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AD991A007C for ; Fri, 1 Aug 2014 13:59:48 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id rd3so6453254pab.28 for ; Fri, 01 Aug 2014 13:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=kguIuXqAn+5jhwm4l8jf7jqbRgpl3/qWgeephjUbK/8=; b=yXus+/c5ki0Pd+N4bhB52FSZM1fLppF+eu2ZakG6J9+NnGs2l7g9kgTI97TMpIe/1F e51C49AsTs/YD0SpQrdUzc4577HUJOgjgfjdeU6n9NDwG3fey2Ohzbnq/3T7u7ipDHnf TqtFS0MySL0q6HtLUbuWuYGQMdixlj6wak0BXI5EuN/We3UJW418HqwGn1e5LAweH2lc aVg5X5sGJcxqBNn0104vWVuKQqGPHl4OXinSr4AGi06wNx2nCmtYQqvq4pPlbohezlV8 K0U+eQbobXFwtrXz/KAVEWd1MSN6h6UVCcu+9S3dRM3iTGTCIJHYorIHjN4V/QsJtipd IMoQ== X-Received: by 10.70.88.205 with SMTP id bi13mr1972469pdb.43.1406926787658; Fri, 01 Aug 2014 13:59:47 -0700 (PDT) Received: from [10.17.218.49] ([166.176.123.151]) by mx.google.com with ESMTPSA id fx5sm9621157pbb.62.2014.08.01.13.59.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Aug 2014 13:59:46 -0700 (PDT) References: <20140731160335.GA65079@elstar.local> <20140801083313.GD66818@elstar.local> <53DB8B39.6090805@ericsson.com> <98CC8308-016A-478C-99CC-44C4E0618DFA@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-7D23164A-EDDF-4BAC-8F09-BEC598777FF4 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B329) From: Mahesh Jethanandani Date: Fri, 1 Aug 2014 15:59:41 -0500 To: Andy Bierman Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OmmFvIvE96Jbs8zC_LrhaIpjTJE Cc: "netmod@ietf.org" Subject: Re: [netmod] NETMOD WG Interim Meeting, September 17-18, 2014 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Aug 2014 20:59:51 -0000 --Apple-Mail-7D23164A-EDDF-4BAC-8F09-BEC598777FF4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Just updated the poll.=20 Mahesh Jethanandani=20 mjethanandani@gmail.com On Aug 1, 2014, at 10:04 AM, Andy Bierman wrote: > Hi, >=20 > Did you mean to select 'No' on all 3 days on the doodle poll? >=20 > http://doodle.com/7eptxb7mggtdhwmc >=20 >=20 > There are not that many people signed up. I hope more WG members > will add an entry to the poll indicating they plan to attend the interim. >=20 > Since we have been debating real vs. virtual interim meetings offline, > I am curious how many people would attend a virtual interim on the > same days (but cannot go to New York for a real interim)? >=20 >=20 > thanks, > Andy >=20 >=20 >=20 >=20 > On Fri, Aug 1, 2014 at 6:31 AM, Mahesh Jethanandani wrote: >> Just a note. None of the $100-$200 priced hotels are in the class of ietf= hotels we are so used to staying in. They might be reasonable but do not ex= pect much from them.=20 >>=20 >> Is the venue location fixed? >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >>=20 >> On Aug 1, 2014, at 7:42 AM, Balazs Lengyel w= rote: >>=20 >>> Hello Lada, >>> I would be most interested in some reasonable hotel. It would be very ni= ce to be in the same place and travel together.=20 >>>=20 >>> I got the following recommendations: ( I know nothing about them yet). H= owever they are all 40-60 kms away. >>> Preference 1 >>>=20 >>> P >>> R >>> O=20 >>>=20 >>> C >>> L >>> I=20 >>>=20 >>> C >>> W >>> T >>>=20 >>> Hotel Name =20 >>>=20 >>> Postal City >>>=20 >>> GDS rates from =20 >>>=20 >>> Rates from =20 >>>=20 >>> ES >>>=20 >>> BS >>>=20 >>> =20 >>>=20 >>> Distance (km) >>>=20 >>> Classif. =20 >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> >>>=20 >>> radisson hotel piscataway >>>=20 >>> piscataway =20 >>>=20 >>>=20 >>>=20 >>> USD >>>=20 >>> 99.00 =20 >>>=20 >>>=20 >>>=20 >>>=20 >>> 48.0 >>>=20 >>> 3 >>>=20 >>> >>>=20 >>> >>>=20 >>> >>>=20 >>> holiday inn parsippany >>>=20 >>> parsippany =20 >>>=20 >>>=20 >>>=20 >>> USD >>>=20 >>> 109.00 >>>=20 >>>=20 >>>=20 >>> >>>=20 >>> 35.2 >>>=20 >>> 3 >>>=20 >>> >>>=20 >>> >>>=20 >>> >>>=20 >>> esa piscataway rutgers university=20 >>>=20 >>> piscataway =20 >>>=20 >>>=20 >>>=20 >>> USD >>>=20 >>> 110.00 >>>=20 >>>=20 >>>=20 >>> >>>=20 >>> 25.0 >>>=20 >>> 2 >>>=20 >>> >>>=20 >>> >>>=20 >>> >>>=20 >>> sheraton new york times square hotel=20 >>>=20 >>> new york >>>=20 >>>=20 >>>=20 >>> USD >>>=20 >>> 429.00 >>>=20 >>>=20 >>>=20 >>> >>>=20 >>> 6.2 =20 >>>=20 >>> 4 >>>=20 >>> >>>=20 >>> >>>=20 >>> Preference 2 >>>=20 >>> P >>> R >>> O=20 >>>=20 >>> C >>> L >>> I=20 >>>=20 >>> C >>> W >>> T >>>=20 >>> Hotel Name =20 >>>=20 >>> Postal City >>>=20 >>> GDS rates from =20 >>>=20 >>> Rates from =20 >>>=20 >>> ES >>>=20 >>> BS >>>=20 >>> =20 >>>=20 >>> Distance (km) >>>=20 >>> Classif. =20 >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> >>>=20 >>> sheraton edison >>>=20 >>> edison >>>=20 >>>=20 >>>=20 --Apple-Mail-7D23164A-EDDF-4BAC-8F09-BEC598777FF4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Just updated the poll. 

Mahesh Jethanandani 

On Aug 1, 2014, at 10:04 AM, Andy Bierman <andy@yumaworks.com> wrote:

Hi,

Did you mean to select 'No' on all 3 days on the doodle poll?



There are not that many people signed up.  I hope more WG members
will add an entry to the poll indicating they plan to attend the interim.

Since we have been debating real vs. virtual interim meetings offline,
I am curious how many people would attend a virtual interim on the
same days (but cannot go to New York for a real interim)?


thanks,
Andy




On Fri, Aug 1, 2014 at 6:31 AM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
Just a note. None of the $100-$200 priced hotels are in the class of ietf hotels we are so used to staying in. They might be reasonable but do not expect much from them. 

Is the venue location fixed?

Mahesh Jethanandani

On Aug 1, 2014, at 7:42 AM, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:

Hello Lada,
I would be most interested in some reasonable hotel. It would be very nice to be in the same place and travel together.

I got the following recommendations: ( I know nothing about them yet). However they are all 40-60 kms away.

Preference 1

Hotel Name

Postal City

GDS rates from

Rates from

ES

BS

 

Distance (km)

Classif.

 

 

<mime-attachment.gif>

radisson hotel piscataway

piscataway



USD

99.00




48.0

3

<mime-attachment.gif>

<mime-attachment.gif>

<mime-attachment.gif>

holiday inn parsippany

parsippany



USD

109.00



<mime-attachment.gif>

35.2

3

<mime-attachment.gif>

<mime-attachment.gif>

<mime-attachment.gif>

esa piscataway rutgers university

piscataway



USD

110.00



<mime-attachment.gif>

25.0

2

<mime-attachment.gif>

<mime-attachment.gif>

<mime-attachment.gif>

sheraton new york times square hotel

new york

USD

429.00



<mime-attachment.gif>

6.2

4

<mime-attachment.gif>

<mime-attachment.gif>

Preference 2

Hotel Name

Postal City

GDS rates from

Rates from

ES

BS

 

Distance (km)

Classif.

 

 

<mime-attachment.gif>

sheraton edison

edison



--Apple-Mail-7D23164A-EDDF-4BAC-8F09-BEC598777FF4-- From nobody Sun Aug 3 14:57:01 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E5D1B27A9 for ; Sun, 3 Aug 2014 14:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 lYLpJD3dr_pR for ; Sun, 3 Aug 2014 14:56:55 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74331B27A2 for ; Sun, 3 Aug 2014 14:56:54 -0700 (PDT) X-AuditID: c1b4fb2d-f798a6d000000e9b-1c-53deb023ed6d Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 37.98.03739.320BED35; Sun, 3 Aug 2014 23:56:52 +0200 (CEST) Received: from ESESSMB103.ericsson.se ([169.254.3.143]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0174.001; Sun, 3 Aug 2014 23:56:51 +0200 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: "netmod@ietf.org" Thread-Topic: Issue Y36: associate RPCs AND notification with a data node Thread-Index: Ac+vZUxZihDr2jF8Q6+dD2GXEYtHqQ== Date: Sun, 3 Aug 2014 21:56:51 +0000 Message-ID: <971D4B790EC8B846BE223DD23AF72FF11EB7FF02@ESESSMB103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/mixed; boundary="_004_971D4B790EC8B846BE223DD23AF72FF11EB7FF02ESESSMB103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM+Jvja7KhnvBBlPm8VjMv9jI6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujFnftrEXNC1krPg44QdjA+PKiYxdjJwcEgImErN/zIGyxSQu 3FvP1sXIxSEkcJRRYs7uA6wQzmJGib0/bzODVLEJuEoc+/SdBcQWEVCXmLkTpIODQ1jARWLa s2KIsKdE59rvTBC2nsTBefvBylkEVCT2TLkIZvMK+Epc27sRzGYEWvz91BqwemYBcYlbT+Yz QRwkIvHw4mk2CFtU4uXjf6wQtpJE45InrBD1mRKXvj+DmikocXLmE5YJjEKzkIyahaRsFpIy iHi+xNkX09khbD2JG1OnsEHY2hLLFr5mhrB1JWb8O8SCKW4i8ePvDKi4hsSZFX1QvRsYJRY1 JELYihJTuh+yL2DkWcUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGI8Ht/zW3cG4+rXjIUYB DkYlHt4H5+8GC7EmlhVX5h5ilOZgURLnXXRuXrCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkG Rgt3sRZDPxMpU4n/J88GT5lUb2DC03s+YN3brcErPjXyG5yWtftprvtA/NMuv60Xd1Z16rI/ +PBL9ojt3Y4qUabNa5fvVwtw+7Bi2wLpJQESAcnyfZcvG25satS7fn/iBJ6UZ/VSH+xWnss+ aZvad+6I8/3F0Qdt+R7+nlzQm5d8zubwYdmPEkosxRmJhlrMRcWJACLVWJuoAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ppG8R22TVxD8S-j-cY9hNQxT01o Subject: [netmod] Issue Y36: associate RPCs AND notification with a data node X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 03 Aug 2014 21:56:59 -0000 --_004_971D4B790EC8B846BE223DD23AF72FF11EB7FF02ESESSMB103erics_ Content-Type: multipart/alternative; boundary="_000_971D4B790EC8B846BE223DD23AF72FF11EB7FF02ESESSMB103erics_" --_000_971D4B790EC8B846BE223DD23AF72FF11EB7FF02ESESSMB103erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello I attached my proposal for the action statement in YANG. Please comment. Regards Balazs On 2014-07-29 15:40, Balazs Lengyel wrote: Hello Juergen, We should declare this issue alive because IETF is about rough consensus an= d running code: - Rough consensus: Major players (Martin, Andy :-) ) and myself for Ericsso= n indicated strong interest and support (at least for connecting RPCs, a.k.= a. actions, to data nodes). That is at least a begining for a consensus. - Running code: Tail-f, Ericsson, and probably Huawei already has implement= ations of actions. I have a reasonable proposal, which I will publish hopefully this week, but= want to check with Martin first. Also, actions are similar in many ways to RPCs so IMHO they are not a major= new feature, no need to wait for a major YANG version: 2.0. regards Balazs On 2014-07-23 21:16, Juergen Schoenwaelder wrote: On Wed, Jul 23, 2014 at 02:58:58PM -0400, Martin Bjorklund wrote: In NACM, you can have a rule that looks like this: xx /system/authentication/user[name=3D$USER] exec accept (this would give a user access to any inline operations available for a user, maybe 'generate-ssh-keys') So while the NACM procedure defined in RFC 6536 doesn't spell out how to handle inline operations (not surpringsly...) the data model supports them. I support Balazs in this; I think especially inline operations (a.k.a. actions) have proven to be very useful. We support them in our software, and a majority of our customers use them. Lets see what has happened. We discussed Y36 on 2014-06-04. Below is the excerpt from the minutes. A call was made on the mailing list on Fri, 27 Jun 2014 and nobody objected against the proposal to move this to DEAD. Why do we reconsider this now? What makes this a YANG 1.1 issue now? /js * Y36 associate a notification with a data node MB says that he did not have customers asking for this but Tail-f has something similar called actions (inlined rpcs). If we do this, it makes sense to add inline RPCs as well. AZ sees a use case. PO sees value in notification source properties attached to leafs. PO says that this is essentially about associating a notification with a resource object. MB says this is a nice to have feature because you can do without. Sounds more like a YANG 2.0 issue. AB agrees that this is an optimization, perhaps this can also be dealt with by certain design patterns. JS suggests that one could also think about guidelines on how to structure notifications to make resource identification easier. Proposal: Reject this issue. May be considered for YANG 2.0. -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com --_000_971D4B790EC8B846BE223DD23AF72FF11EB7FF02ESESSMB103erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello

I attached my proposal for the actio= n statement in YANG. Please comment.

Regards Balazs

 

 

On 2014-07-29 15:40, Balazs Lengyel = wrote:

Hello Juergen,
We should declare this issue alive because IETF is about rough consensus an= d running code:
- Rough consensus: Major players (Martin, Andy :-) ) and myself for Ericsso= n indicated strong interest and support (at least for connecting RPCs, a.k.= a. actions, to data nodes). That is at least a begining for a consensus.
- Running code: Tail-f, Ericsson, and probably Huawei already has implement= ations of actions.

I have a reasonable proposal, which I will publish hopefully this week, but= want to check with Martin first.
Also, actions are similar in many ways to RPCs so IMHO they are not a major= new feature, no need to wait for a major YANG version: 2.0.
regards Balazs

On 2014-07-23 21:16, Juergen Schoenwaelder wrote:

On Wed, Jul 23, 2014 at 02:58:58PM -= 0400, Martin Bjorklund wrote:

In NA= CM, you can have a rule that looks like this:

   <rule>
     <name>xx</name>
     <path>/system/authentication/user[name=3D$US= ER]</path>
     <access-operations>exec</access-operation= s>
     <action>accept</accept>
   </rule>

(this would give a user access to any inline operations available for
a user, maybe 'generate-ssh-keys')

So while the NACM procedure defined in RFC 6536 doesn't spell out how
to handle inline operations (not surpringsly...) the data model
supports them.

I support Balazs in this; I think especially inline operations
(a.k.a. actions) have proven to be very useful.  We support them in our software, and a majority of our customers use them. <= /p>

Lets = see what has happened. We discussed Y36 on 2014-06-04. Below is
the excerpt from the minutes. A call was made on the mailing list on
Fri, 27 Jun 2014 and nobody objected against the proposal to move this
to DEAD.

Why do we reconsider this now? What makes this a YANG 1.1 issue now?

/js

* Y36 associate a notification with a data node

   MB says that he did not have customers asking for this but Tai= l-f
   has something similar called actions (inlined rpcs). If we do = this,
   it makes sense to add inline RPCs as well.

   AZ sees a use case.

   PO sees value in notification source properties attached to le= afs.

   PO says that this is essentially about associating a notificat= ion
   with a resource object.

   MB says this is a nice to have feature because you can do
   without. Sounds more like a YANG 2.0 issue.

   AB agrees that this is an optimization, perhaps this can also = be
   dealt with by certain design patterns.

   JS suggests that one could also think about guidelines on how = to
   structure notifications to make resource identification easier= .

   Proposal: Reject this issue. May be considered for YANG 2.0. <= o:p>

 



--

Balazs Lengyel       &n= bsp;            = ;   Ericsson Hungary Ltd.

Senior Specialist

ECN: 831 7320       &nb= sp;            =     Tel: +36-1-437-7320

Mobile: +36-70-330-7909     &= nbsp;        email: Balazs.Lengyel@erics= son.com

 

--_000_971D4B790EC8B846BE223DD23AF72FF11EB7FF02ESESSMB103erics_-- --_004_971D4B790EC8B846BE223DD23AF72FF11EB7FF02ESESSMB103erics_ Content-Type: text/plain; name="actionProposal2.txt" Content-Description: actionProposal2.txt Content-Disposition: attachment; filename="actionProposal2.txt"; size=5965; creation-date="Sun, 03 Aug 2014 21:18:33 GMT"; modification-date="Sun, 03 Aug 2014 21:54:47 GMT" Content-Transfer-Encoding: base64 dmVyc2lvbiAxDQoNCkFjdGlvbiBTdGF0ZW1lbnQ6DQoNCiFDaGFuZ2UgbmFtZSBvZiBjaGFwdGVy IDQuMi45IHRvOiBSUEMgYW5kIEFjdGlvbiBkZWZpbml0aW9ucw0KIUFkZCB0byBjaGFwdGVyIDQu Mi45IA0KICAgWUFORyBhbHNvIGFsbG93cyB0aGUgZGVmaW5pdGlvbiBvZiBhY3Rpb25zOiBORVRD T05GIFJQQ3MgdGhhdCBhcmUgY29ubmVjdGVkIA0KICAgdG8gdGhlIGRhdGEgbW9kZWwuIFNvbWUg b3BlcmF0aW9uIGFyZSBuYXR1cmFsbHkgY29ubmVjdGVkIHRvIGRhdGEgaXRlbXMgDQogICBlLmcu IGEgcmVzdGFydGluZyBhbiBpbnRlcmZhY2Ugb3IgZmx1c2hpbmcgYSBkeW5hbWljIGZvcndhcmRp bmcgdGFibGUuIA0KICAgQWN0aW9ucyBhcmUgc2ltaWxhciB0byBSUENzIGJ1dCB0aGV5IGFyZSBt b2RlbGVkIHdpdGhpbiBhIGNvbnRhaW5lciBvciBhIGxpc3QuDQoNCi0tLW5vdGU6IElNSE8gd2Ug ZG8gbm90IG5lZWQgdG8gYWRkIGV4YW1wbGVzIGhlcmUsIGl0IHdvdWxkIGJlIGVub3VnaCB0byBo YXZlIHRoZW0gaW4gY2hhcHRlciA3Lg0KDQohQWRkIGEgbmV3IGNoYXB0ZXIgYWZ0ZXIgdGhlIGN1 cnJlbnQgNy4xMw0KDQoNCjcuMTMtQi4gVGhlIGFjdGlvbiBTdGF0ZW1lbnQNCg0KDQogICBUaGUg ImFjdGlvbiIgc3RhdGVtZW50IGlzIHVzZWQgdG8gZGVmaW5lIGEgTkVUQ09ORiBSUEMgb3BlcmF0 aW9uIGNvbm5lY3RlZCANCiAgIHRvIGEgc3BlY2lmaWMgZGF0YSBub2RlLiBJdCBjYW4gYmUgdGhl IHN1YnN0YXRlbWVudCBvZiBjb250YWluZXIsIGxpc3QsIA0KICAgZ3JvdXBpbmcgb3IgYXVnbWVu dC4gDQogICANCiAgIEl0IHRha2VzIG9uZSBhcmd1bWVudCwgd2hpY2ggaXMgYW4gaWRlbnRpZmll ciwgZm9sbG93ZWQgYnkgYSBibG9jayBvZg0KICAgc3Vic3RhdGVtZW50cyB0aGF0IGhvbGRzIGRl dGFpbGVkIGFjdGlvbiBpbmZvcm1hdGlvbi4gIFRoZSBhcmd1bWVudCBpcw0KICAgdGhlIG5hbWUg b2YgdGhlIGFjdGlvbi4NCiAgICAgIA0KICAgVGhlICJhY3Rpb24iIHN0YXRlbWVudCBkZWZpbmVz IGFuIGFjdGlvbiBub2RlIGluIHRoZSBzY2hlbWEgdHJlZS4gIFVuZGVyDQogICB0aGUgYWN0aW9u IG5vZGUsIGEgc2NoZW1hIG5vZGUgd2l0aCB0aGUgbmFtZSAiaW5wdXQiLCBhbmQgYSBzY2hlbWEg bm9kZQ0KICAgd2l0aCB0aGUgbmFtZSAib3V0cHV0IiBNQVkgYWxzbyBkZWZpbmVkLiAgVGhlIG5v ZGVzICJpbnB1dCIgYW5kDQogICAib3V0cHV0IiBhcmUgZGVmaW5lZCBpbiB0aGUgbW9kdWxlJ3Mg bmFtZXNwYWNlLiAgICANCiAgICAgIA0KICAgQW4gYWN0aW9uIE1VU1QgTk9UIGJlIGRlZmluZWQg d2l0aGluIGFuIHJwYywgYW5vdGhlciBhY3Rpb24gb3IgYSBub3RpZmljYXRpb24sIA0KICAgdGhh dCBpcyB0aGUgYWN0aW9uIHN0YXRlbWVudCBNVVNUIE5PVCBoYXZlIGFuIHJwYywgYW5vdGhlciBh Y3Rpb24gb3IgYSBub3RpZmljYXRpb24gDQogICBzdGF0ZW1lbnQgYXMgb25lIG9mIGl0cyBhbmNl c3RvcnMgaW4gdGhlIHNjaGVtYSB0cmVlLiANCiAgIFRoZSBhY3Rpb24gc3RhdGVtZW50IE1VU1Qg Tk9UIGhhdmUgYW4gcnBjLCBhbm90aGVyIGFjdGlvbiBvciBhIG5vdGlmaWNhdGlvbiANCiAgIHN0 YXRlbWVudCBhcyBvbmUgb2YgaXRzIGFuY2VzdG9ycyBldmVuIGluIGEgY29uY2VwdHVhbHkgZmxh dHRlbmVkIHNjaGVtYSANCiAgIHRyZWUgd2hlcmUgYWxsIGF1Z21lbnRzIGFyZSBpbnNlcnRlZCBh dCB0aGVpciB0YXJnZXQgcG9pbnRzIGFuZCBhbGwgdXNlcyANCiAgIHN0YXRlbWVudHMgYXJlIHJl cGxhY2VkIGJ5IHRoZSByZWZlcmVuY2VkIGdyb3VwaW5nLiAgICAgICAgICAgICANCiAgICAgIA0K Ny4xMy1CLjEuIFRoZSBhY3Rpb24ncyBTdWJzdGF0ZW1lbnRzDQoNCg0KICAgICAgICAgICAgICAg ICArLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAg ICAgIHwgc3Vic3RhdGVtZW50IHwgc2VjdGlvbiB8IGNhcmRpbmFsaXR5IHwNCiAgICAgICAgICAg ICAgICAgKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKw0KICAgICAgICAg ICAgICAgICB8IGRlc2NyaXB0aW9uICB8IDcuMTkuMyAgfCAwLi4xICAgICAgICB8DQogICAgICAg ICAgICAgICAgIHwgZ3JvdXBpbmcgICAgIHwgNy4xMSAgICB8IDAuLm4gICAgICAgIHwNCiAgICAg ICAgICAgICAgICAgfCBpZi1mZWF0dXJlICAgfCA3LjE4LjIgIHwgMC4ubiAgICAgICAgfA0KICAg ICAgICAgICAgICAgICB8IGlucHV0ICAgICAgICB8IDcuMTMuMiAgfCAwLi4xICAgICAgICB8DQog ICAgICAgICAgICAgICAgIHwgb3V0cHV0ICAgICAgIHwgNy4xMy4zICB8IDAuLjEgICAgICAgIHwN CiAgICAgICAgICAgICAgICAgfCByZWZlcmVuY2UgICAgfCA3LjE5LjQgIHwgMC4uMSAgICAgICAg fA0KICAgICAgICAgICAgICAgICB8IHN0YXR1cyAgICAgICB8IDcuMTkuMiAgfCAwLi4xICAgICAg ICB8DQogICAgICAgICAgICAgICAgIHwgdHlwZWRlZiAgICAgIHwgNy4zICAgICB8IDAuLm4gICAg ICAgIHwNCiAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0t LS0tLS0tKw0KICAgICAgDQogICAgICAtLS0tbm90ZTogVGhlIGlucHV0IGFuZCB0aGUgb3V0cHV0 IHN0YXRlbWVudHMgc2hvdWxkIGJlIG1vdmVkIGluIHRoZSBkb2N1bWVudCBzdHJ1Y3R1cmUuIFRo ZXkgc2hvdWxkIG5vdCBiZSB1bmRlciBhY3Rpb24sIGJ1dCBiZWNvbWUgYSBzZXBhcmF0ZSBsZXZl bCAyIGhlYWRpbmcuIFRoZWlyIHRleHQgc2hvdWxkIGJlIGNoYW5nZWQgdG8gc2F0IHJwYyBvciBh Y3Rpb24uDQogICAgICANCg0KNy4xMy1CLjQuIFhNTCBNYXBwaW5nIFJ1bGVzDQoNCg0KICAgRm9y IGFuIGFjdGlvbiByZXF1ZXN0LCBhbiBhY3Rpb24gbm9kZSAod2hpY2ggaXMgcGFydCBvZiB0aGUg WUFORyBYTUwgDQogICBuYW1lc3BhY2UgU2VjdGlvbiA1LjMuMSkgaXMgZW5jb2RlZCBhcyBhIGNo aWxkIFhNTCBlbGVtZW50IHRvIHRoZSANCiAgIHJwYyBlbGVtZW50LCBhbmQgY29udGFpbnMgYSBz aW5nbGUgZGF0YSBYTUwgZWxlbWVudC4gVGhlIGRhdGEgZWxlbWVudCANCiAgIFNIQUxMIGNvbnRh aW4gYW55IGFuZCBhbGwgY29udGFpbmVycyBhbmQgbGlzdCBub2RlcyBmcm9tIHRoZSB0b3AgDQog ICBsZXZlbCB0aWxsIHRoZSBsaXN0L2NvbnRhaW5lciBjb250YWluaW5nIHRoZSBhY3Rpb24gZGVm aW5lZCBpbiBZQU5HLiANCiAgIEZvciBsaXN0cyBhbGwga2V5IGxlYWZzIGFyZSBhbHNvIGluY2x1 ZGVkLg0KICAgVGhlIGxhc3QgY29udGFpbmVyL2xpc3QgY29udGFpbmVzIGFuIFhNTCBlbGVtZW50 IHRoYXQgY2FycmllcyB0aGUgbmFtZSANCiAgIG9mIHRoZSBkZWZpbmVkIGFjdGlvbi4gV2l0aGlu IGl0IHRoZSBpbnB1dCBwYXJhbWV0ZXJzIGFyZSBlbmNvZGVkIHRoZSANCiAgIHNhbWUgd2F5IGFz IGZvciBZQU5HIGRlZmluZWQgcnBjIG9wZXJhdGlvbnMuDQogICANCiAgIElmIHRoZSBhY3Rpb24g b3BlcmF0aW9uIGludm9jYXRpb24gc3VjY2VlZGVkLCBhbmQgbm8gb3V0cHV0IHBhcmFtZXRlcnMN CiAgIGFyZSByZXR1cm5lZCwgdGhlIDxycGMtcmVwbHk+IGNvbnRhaW5zIGEgc2luZ2xlIDxvay8+ IGVsZW1lbnQgZGVmaW5lZA0KICAgaW4gW1JGQzQ3NDFdLiAgDQogICBJZiBvdXRwdXQgcGFyYW1l dGVycyBhcmUgcmV0dXJuZWQsIGEgc2luZ2xlIGRhdGEgZWxlbWVudCANCiAgIGlzIHJldHVybmVk IHdpdGhpbiB0aGUgcnBjLXJlcGx5IGp1c3QgYXMgYWZ0ZXIgYSA8Z2V0PiBvcGVyYXRpb24uIA0K ICAgVGhlIGRhdGEgZWxlbWVudCBTSEFMTCBjb250YWluIGFueSBhbmQgYWxsIGNvbnRhaW5lcnMg YW5kIGxpc3Qgbm9kZXMgDQogICBmcm9tIHRoZSB0b3AgbGV2ZWwgdGlsbCB0aGUgbGlzdC9jb250 YWluZXIgY29udGFpbmluZyB0aGUgYWN0aW9uIGRlZmluZWQgDQogICBpbiBZQU5HLiBGb3IgbGlz dHMgYWxsIGtleSBsZWFmcyBhcmUgYWxzbyBpbmNsdWRlZC4NCiAgIFRoZSBsYXN0IGNvbnRhaW5l ci9saXN0IGNvbnRhaW5lcyBhbiBYTUwgZWxlbWVudCB0aGF0IGNhcnJpZXMgdGhlIG5hbWUgDQog ICBvZiB0aGUgZGVmaW5lZCBhY3Rpb24uIFdpdGhpbiBpdCB0aGUgb3V0cHV0IHBhcmFtZXRlcnMg YXJlIGVuY29kZWQgdGhlIA0KICAgc2FtZSB3YXkgYXMgZm9yIFlBTkcgZGVmaW5lZCBycGMgb3Bl cmF0aW9ucy4NCiAgIA0KICAgDQoNCjcuMTMtQi41LiBVc2FnZSBFeGFtcGxlDQoNCg0KICAgVGhl IGZvbGxvd2luZyBleGFtcGxlIGRlZmluZXMgYW4gYWN0aW9uIHRvIHJlc2V0IG9uZSBzZXJ2ZXIg YXQgYSBzZXJ2ZXIgZmFybToNCg0KICAgICBtb2R1bGUgc2VydmVyLWZhcm0gew0KICAgICAgICAg bmFtZXNwYWNlICJodHRwOi8vZXhhbXBsZS5uZXQvc2VydmVyLWZhcm0iOw0KICAgICAgICAgcHJl Zml4ICJzZmFybSI7DQogICAgICAgICANCiAgICAgICAgIGxpc3Qgc2VydmVyIHsNCiAgICAgICAg ICAgIGtleSBuYW1lOw0KICAgICAgICAgICAgbGVhZiBuYW1lIHsNCiAgICAgICAgICAgICAgICB0 eXBlIHN0cmluZzsNCiAgICAgICAgICAgIH0NCiAgICAgICAgICAgIGFjdGlvbiByZXNldCB7DQog ICAgICAgICAgICAgICAgaW5wdXQgew0KICAgICAgICAgICAgICAgICAgICBsZWFmIHJlc2V0LWF0 IHsNCiAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgeWFuZzpkYXRlLWFuZC10aW1lOw0KICAg ICAgICAgICAgICAgICAgICAgICAgbWFuZGF0b3J5IHRydWU7DQogICAgICAgICAgICAgICAgICAg IH0NCiAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgb3V0cHV0IHsNCiAgICAgICAg ICAgICAgICAgICAgbGVhZiByZXNldC1maW5pc2hlZC1hdCB7DQogICAgICAgICAgICAgICAgICAg ICB0eXBlIHN0cmluZzsNCiAgICAgICAgICAgICAgICAgICAgICBtYW5kYXRvcnkgdHJ1ZTsNCiAg ICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgIH0gICAg IA0KICAgICAgICB9DQogICAgfQ0KICAgIA0KICAgQSBjb3JyZXNwb25kaW5nIFhNTCBpbnN0YW5j ZSBleGFtcGxlIG9mIHRoZSBjb21wbGV0ZSBycGMgYW5kIHJwYy0NCiAgIHJlcGx5Og0KDQogICAg IDxycGMgbWVzc2FnZS1pZD0iMTAxIg0KICAgICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6 eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiDQogICAgICAgICAgeG1sbnM6eWFuZz0idXJuOmlldGY6 cGFyYW1zOnhtbDpuczp5YW5nOjEiPg0KICAgICAgICA8eWFuZzphY3Rpb24+DQogICAgICAgICAg ICA8ZGF0YT4NCiAgICAgICAgICAgICAgICA8c2VydmVyIHhtbG5zPSJodHRwOi8vZXhhbXBsZS5u ZXQvc2VydmVyLWZhcm0iPg0KICAgICAgICAgICAgICAgICAgICA8bmFtZT5hcGFjaGUtMTwvbmFt ZT4NCiAgICAgICAgICAgICAgICAgICAgPHJlc2V0Pg0KICAgICAgICAgICAgICAgICAgICAgICAg PHJlc2V0LWF0PjIwMTQtMDctMjlUMTM6NDJaPC9yZXNldC1hdD4NCiAgICAgICAgICAgICAgICAg ICAgPC9yZXNldD4NCiAgICAgICAgICAgICAgICA8L3NlcnZlcj4NCiAgICAgICAgICAgIDwvZGF0 YT4NCiAgICAgICAgPC9hY3Rpb24+DQogICAgIDwvcnBjPg0KDQogICAgIDxycGMtcmVwbHkgbWVz c2FnZS1pZD0iMTAxIg0KICAgICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5l dGNvbmY6YmFzZToxLjAiPg0KICAgICAgICA8ZGF0YT4NCiAgICAgICAgICAgIDxzZXJ2ZXIgeG1s bnM9Imh0dHA6Ly9leGFtcGxlLm5ldC9zZXJ2ZXItZmFybSI+DQogICAgICAgICAgICAgICAgPG5h bWU+YXBhY2hlLTE8L25hbWU+DQogICAgICAgICAgICAgICAgPHJlc2V0Pg0KICAgICAgICAgICAg ICAgICAgICA8cmVzZXQtZmluaXNoZWQtYXQ+MjAxNC0wNy0yOVQxMzo0NVo8L3Jlc2V0LWF0Pg0K ICAgICAgICAgICAgICAgIDwvcmVzZXQ+DQogICAgICAgICAgICA8L3NlcnZlcj4NCiAgICAgICAg PC9kYXRhPg0KICAgICA8L3JwYy1yZXBseT4gICANCiAgIA0KIA== --_004_971D4B790EC8B846BE223DD23AF72FF11EB7FF02ESESSMB103erics_-- From nobody Sun Aug 3 18:46: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 DFE481B27EC for ; Sun, 3 Aug 2014 18:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvppl7zL0J_V for ; Sun, 3 Aug 2014 18:46:10 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AFC31B27EF for ; Sun, 3 Aug 2014 18:46:10 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id f12so6259172qad.31 for ; Sun, 03 Aug 2014 18:46:09 -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=sajXoS8TesbaABSkSTCQ2FVWAbIzJzIxwXWMpUkxnbI=; b=M+FG1M7xiMw9MsPu6nuNiwxkPKNpNLZLM6ZcwDuxtu6pyy79SFhrex4aR29OEpYMjL SGaQ1hf4Jb4yK2WZ2PIwq9rWbwJlBnkWSN7yEpK4j5hkqETBDcUTvlAE+9juNWKQJAkZ hNvpWCKYcWOcYJrAFhSDlk2bHW5lSEDg0zNpseCYfoUIHkxFrYLUluD6+piYz/FMgk86 NMk+iSKyONYcAtTA0xsgmQd1tSVnUOjPVCXzsocf6Ye2/UXGvkMygdJ3BBF5n/d/mqq1 XgOcIPNM7ejYTA86Jd15jxdh+5J7vNySxArOBmJYIw9qFrpiGitnmpDdR8D/7xaX+QSK 8y2A== X-Gm-Message-State: ALoCoQkKKQTpb2v7gQUZfHa991W6meg4gyNLPB+S65PrrYQgxGkV1bX9FpUBynAN6iLnBb0cZ1F8 MIME-Version: 1.0 X-Received: by 10.140.107.131 with SMTP id h3mr30674259qgf.83.1407116769361; Sun, 03 Aug 2014 18:46:09 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Sun, 3 Aug 2014 18:46:09 -0700 (PDT) In-Reply-To: <971D4B790EC8B846BE223DD23AF72FF11EB7FF02@ESESSMB103.ericsson.se> References: <971D4B790EC8B846BE223DD23AF72FF11EB7FF02@ESESSMB103.ericsson.se> Date: Sun, 3 Aug 2014 18:46:09 -0700 Message-ID: From: Andy Bierman To: =?ISO-8859-1?Q?Bal=E1zs_Lengyel?= Content-Type: multipart/alternative; boundary=001a113a7f763217e504ffc3e70c Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nSVktsD5aZNBMBPabJHaXdwJr1o Cc: "netmod@ietf.org" Subject: Re: [netmod] Issue Y36: associate RPCs AND notification with a data node X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Aug 2014 01:46:13 -0000 --001a113a7f763217e504ffc3e70c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I have some questions and concerns about this proposal. 1) scope is inaccurate: * Y36 associate a notification with a data node This proposal has nothing to do with notifications. Where is the support to associate a notification with a data node? 2) In your example, how would the be encoded if there was a list above server: list group { key "a b "; leaf a { type string; } leaf b { type int32; } list server { ... action reset { ... } } } 3) What if there are 2 'reset' actions: module server-farm { namespace "http://example.net/server-farm"; prefix "sfarm"; list server { key name; leaf name { type string; } action reset { input { leaf reset-at { type yang:date-and-time; mandatory true; } } output { leaf reset-finished-at { type string; mandatory true; } } } } container top { list server { key name; leaf name { type string; } action reset { input { leaf reset-at { type string; } } } } } We have /server/reset and /top/server/reset. How do the server know which 1 is being invoked? 4) Ehat is the purpose of the extra container inserted in the action input and output? Andy On Sun, Aug 3, 2014 at 2:56 PM, Bal=E1zs Lengyel wrote: > Hello > > I attached my proposal for the action statement in YANG. Please comment. > > Regards Balazs > > > > > > On 2014-07-29 15:40, Balazs Lengyel wrote: > > Hello Juergen, > We should declare this issue alive because IETF is about rough consensus > and running code: > - Rough consensus: Major players (Martin, Andy :-) ) and myself for > Ericsson indicated strong interest and support (at least for connecting > RPCs, a.k.a. actions, to data nodes). That is at least a begining for a > consensus. > - Running code: Tail-f, Ericsson, and probably Huawei already has > implementations of actions. > > I have a reasonable proposal, which I will publish hopefully this week, > but want to check with Martin first. > Also, actions are similar in many ways to RPCs so IMHO they are not a > major new feature, no need to wait for a major YANG version: 2.0. > regards Balazs > > On 2014-07-23 21:16, Juergen Schoenwaelder wrote: > > On Wed, Jul 23, 2014 at 02:58:58PM -0400, Martin Bjorklund wrote: > > In NACM, you can have a rule that looks like this: > > > xx > /system/authentication/user[name=3D$USER] > exec > accept > > > (this would give a user access to any inline operations available for > a user, maybe 'generate-ssh-keys') > > So while the NACM procedure defined in RFC 6536 doesn't spell out how > to handle inline operations (not surpringsly...) the data model > supports them. > > I support Balazs in this; I think especially inline operations > (a.k.a. actions) have proven to be very useful. We support them in > our software, and a majority of our customers use them. > > Lets see what has happened. We discussed Y36 on 2014-06-04. Below is > the excerpt from the minutes. A call was made on the mailing list on > Fri, 27 Jun 2014 and nobody objected against the proposal to move this > to DEAD. > > Why do we reconsider this now? What makes this a YANG 1.1 issue now? > > /js > > * Y36 associate a notification with a data node > > MB says that he did not have customers asking for this but Tail-f > has something similar called actions (inlined rpcs). If we do this, > it makes sense to add inline RPCs as well. > > AZ sees a use case. > > PO sees value in notification source properties attached to leafs. > > PO says that this is essentially about associating a notification > with a resource object. > > MB says this is a nice to have feature because you can do > without. Sounds more like a YANG 2.0 issue. > > AB agrees that this is an optimization, perhaps this can also be > dealt with by certain design patterns. > > JS suggests that one could also think about guidelines on how to > structure notifications to make resource identification easier. > > Proposal: Reject this issue. May be considered for YANG 2.0. > > > > > > -- > > Balazs Lengyel Ericsson Hungary Ltd. > > Senior Specialist > > ECN: 831 7320 Tel: +36-1-437-7320 > > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --001a113a7f763217e504ffc3e70c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I have some questions and concerns = about this proposal.

1) scope is inaccurate:
=
=A0* Y36 associate a notification with a data node=A0
=A0 This proposal has nothing to do with notifications.
=A0 Where is the support to associate a notification with a da= ta node?

2) In your example, how would the <rpc> be= encoded if there was a
=A0 =A0 list above server:

=A0 = =A0 =A0 =A0 list group {
=A0 =A0 =A0 =A0 =A0 =A0 key "a b ";
=A0 =A0= =A0 =A0 =A0 =A0 leaf a { type string; }
=A0 =A0 =A0 =A0 =A0 =A0 leaf b { type int32; }
=A0 = =A0 =A0 =A0 =A0 =A0 list server { =A0... action reset { ... } }
=A0 =A0 =A0 }

=A03) What if the= re are 2 'reset' actions:

=A0 =A0
=A0module server-farm {
=A0 =A0 =A0 =A0= =A0namespace "http://examp= le.net/server-farm";
=A0 =A0 =A0 =A0 =A0prefix "sfarm";
=A0 =A0 =A0 =A0= =A0
=A0 =A0 =A0 =A0 =A0list server {
=A0 =A0 =A0 =A0 =A0 =A0 key name;
=A0 =A0 =A0 =A0= =A0 =A0 leaf name {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 type string;
=
=A0 =A0 =A0 =A0= =A0 =A0 }
=A0 =A0 =A0 =A0= =A0 =A0 action reset {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 input {
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 leaf reset-at {
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 type yang:date-and-time;
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 mandatory true;
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 output {
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 leaf reset-finished-at {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0type string;
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 mandatory true;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }<= /font>
=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0= =A0 =A0 } =A0 =A0=A0
=A0 =A0 =A0 =A0 }

= =A0 =A0 =A0 =A0 container top {
=A0 =A0 =A0 =A0 =A0 =A0 list server {
=A0 =A0 =A0 = =A0 =A0 =A0 =A0 key name;
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0leaf name {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 type string;
=
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0}
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0action reset {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0input {
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0leaf reset-at {
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 type string;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 }
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 = =A0 =A0} =A0 =A0=A0
=A0 =A0 =A0 =A0 }

=A0 =A0= }


We have /server/reset and /top/serv= er/reset.
How do the server know which 1 is being invoked?

4) Ehat is the purpose of the extra <data> containe= r inserted in the action input
and output?


Andy





On Sun, Aug 3, 2014 at 2:56 PM, Bal=E1zs= Lengyel <balazs.lengyel@ericsson.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">

Hello

I attached my proposal for the action statement in Y= ANG. Please comment.

Regards Balazs

=A0

=A0

On 2014-07-29 15:40, Balazs Lengyel wrote:=

Hello Juergen,
We should declare this issue alive because IETF is about rough consensus an= d running code:
- Rough consensus: Major players (Martin, Andy :-) ) and myself for Ericsso= n indicated strong interest and support (at least for connecting RPCs, a.k.= a. actions, to data nodes). That is at least a begining for a consensus.
- Running code: Tail-f, Ericsson, and probably Huawei already has implement= ations of actions.

I have a reasonable proposal, which I will publish hopefully this week, but= want to check with Martin first.
Also, actions are similar in many ways to RPCs so IMHO they are not a major= new feature, no need to wait for a major YANG version: 2.0.
regards Balazs

On 2014-07-23 21:16, Juergen Schoenwaelder wrote:

On Wed, Jul 23, 2014 at 02:58:58PM -0400, Martin Bjo= rklund wrote:

In NACM, you can have a= rule that looks like this:

=A0=A0 <rule>
=A0=A0=A0=A0 <name>xx</name>
=A0=A0=A0=A0 <path>/system/authentication/user[name=3D$USER]</path= >
=A0=A0=A0=A0 <access-operations>exec</access-operations>
=A0=A0=A0=A0 <action>accept</accept>
=A0=A0 </rule>

(this would give a user access to any inline operations available for
a user, maybe 'generate-ssh-keys')

So while the NACM procedure defined in RFC 6536 doesn't spell out how <= br> to handle inline operations (not surpringsly...) the data model
supports them.

I support Balazs in this; I think especially inline operations
(a.k.a. actions) have proven to be very useful.=A0 We support them in
our software, and a majority of our customers use them.

Lets see what has happe= ned. We discussed Y36 on 2014-06-04. Below is
the excerpt from the minutes. A call was made on the mailing list on
Fri, 27 Jun 2014 and nobody objected against the proposal to move this
to DEAD.

Why do we reconsider this now? What makes this a YANG 1.1 issue now?

/js

* Y36 associate a notification with a data node

=A0=A0 MB says that he did not have customers asking for this but Tail-f =A0=A0 has something similar called actions (inlined rpcs). If we do this, =
=A0=A0 it makes sense to add inline RPCs as well.

=A0=A0 AZ sees a use case.

=A0=A0 PO sees value in notification source properties attached to leafs. <= br>
=A0=A0 PO says that this is essentially about associating a notification =A0=A0 with a resource object.

=A0=A0 MB says this is a nice to have feature because you can do
=A0=A0 without. Sounds more like a YANG 2.0 issue.

=A0=A0 AB agrees that this is an optimization, perhaps this can also be =A0=A0 dealt with by certain design patterns.

=A0=A0 JS suggests that one could also think about guidelines on how to =A0=A0 structure notifications to make resource identification easier.

=A0=A0 Proposal: Reject this issue. May be considered for YANG 2.0. =

=A0



--

Balazs Lengyel=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 Ericsson Hungary Ltd.

Senior Specialist

ECN: 831 7320=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 Tel: +36-1-437-7320

Mobile: +36-70-330-7909=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= email: Ba= lazs.Lengyel@ericsson.com

=A0


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


--001a113a7f763217e504ffc3e70c-- From nobody Mon Aug 4 02:42: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 214B11B2974 for ; Mon, 4 Aug 2014 02:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 jRLl89j6KBfi for ; Mon, 4 Aug 2014 02:42:06 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 971421ACCF3 for ; Mon, 4 Aug 2014 02:42:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgFAJBU31PGmAcV/2dsb2JhbABbgkcjI1JXBK5bAQEBAQebWYE9HAEJhnlTAYEYFneEAwEBAQECAQEBAQ8bQQsFBwQCAQgNBAQBAQsdBycLFAkIAgQBDQUIGogYCAEMowihQBeFfIYhbIFhEQEfLQQGAQaDKYEcBY53jmOFeIQoiGuDTWwBAYELOQ X-IronPort-AV: E=Sophos; i="5.01,796,1400040000"; d="scan'208,217"; a="67386398" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 04 Aug 2014 05:42:02 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 04 Aug 2014 05:42:01 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Mon, 4 Aug 2014 11:42:01 +0200 From: "Romascanu, Dan (Dan)" To: Andy Bierman , "Thomas D. Nadeau" Thread-Topic: [netmod] NETMOD WG Interim Meeting, September 17-18, 2014 Thread-Index: AQHPrZno/9qdkkjb/UyPITQOsUgpSJu74C7Q///t3QCAAAE+gIAEZh0A Date: Mon, 4 Aug 2014 09:42:00 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C865BCD@AZ-FFEXMB04.global.avaya.com> References: <20140801150411.14577.32922.idtracker@ietfa.amsl.com> <9904FB1B0159DA42B0B887B7FA8119CA5C85AF56@AZ-FFEXMB04.global.avaya.com> <5A37AEEB-1F19-4B0D-A06C-DBA7E3BB9360@lucidvision.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C865BCDAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/geq4A0AMmkztOryI793OKedxBcI Cc: "netmod@ietf.org" Subject: Re: [netmod] NETMOD WG Interim Meeting, September 17-18, 2014 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Aug 2014 09:42:09 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C865BCDAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I entered a comment. Dan From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Friday, August 01, 2014 7:31 PM To: Thomas D. Nadeau Cc: Romascanu, Dan (Dan); netmod@ietf.org Subject: Re: [netmod] NETMOD WG Interim Meeting, September 17-18, 2014 On Fri, Aug 1, 2014 at 9:26 AM, Thomas D. Nadeau > wrote: Yes and Yes please register so we can size the Webex accordingly. There is no way to indicate remote attendance on the poll. --Tom Andy On Aug 1, 2014:11:32 AM, at 11:32 AM, Romascanu, Dan (Dan) > wrote: > Will remote participation be available? > > If yes - do remote participants need to register? > > Thanks and Regards, > > Dan > > >> -----Original Message----- >> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of >> IESG Secretary >> Sent: Friday, August 01, 2014 6:04 PM >> To: IETF Announcement List >> Cc: netmod@ietf.org >> Subject: NETMOD WG Interim Meeting, September 17-18, 2014 >> >> The IETF NETMOD WG will hold an Interim Meeting on September 17-18, >> 2014. The meeting will take place at One Penn Plaza, 9th Floor New York,= NY >> 10119 USA. >> >> The agenda of the meeting is to work on YANG 1.1 open issues and in >> particular on >> >> - issues related to YANG 1.1 conformance; >> - issues related to YANG 1.1 datastores and I2RS support; >> - any remaining open YANG 1.1 issues. >> >> If you'd like to attend, please register by sending an email to the NETM= OD >> WG chairs. The meeting details with further information about the >> participants and meeting logistics will be maintained in the SVN of the >> NETMOD working group >> >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ >> >> and also posted on the NETMOD mailing list. A preliminary list of partic= ipants >> is on the following Doodle poll: >> >> http://doodle.com/7eptxb7mggtdhwmc > > _______________________________________________ > 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 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C865BCDAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I entered a comment.

 <= /p>

Dan

 <= /p>

 <= /p>

From: Andy Bie= rman [mailto:andy@yumaworks.com]
Sent: Friday, August 01, 2014 7:31 PM
To: Thomas D. Nadeau
Cc: Romascanu, Dan (Dan); netmod@ietf.org
Subject: Re: [netmod] NETMOD WG Interim Meeting, September 17-18, 20= 14

 

 

 

On Fri, Aug 1, 2014 at 9:26 AM, Thomas D. Nadeau <= ;tnadeau@lucid= vision.com> wrote:


        Yes and Yes please register so we can size the = Webex accordingly.

 

There is no way to indicate remote attendance on the= poll.

 

 

        --Tom

 

Andy

 


On Aug 1, 2014:11:32 AM, at 11:32 AM, Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:

> Will remote participation be available?
>
> If yes - do remote participants need to register?
>
> Thanks and Regards,
>
> Dan
>
>
>> -----Original Message-----
>> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of
>> IESG Secretary
>> Sent: Friday, August 01, 2014 6:04 PM
>> To: IETF Announcement List
>> Cc: netmod@ietf.org
>> Subject: NETMOD WG Interim Meeting, September 17-18, 2014
>>
>> The IETF NETMOD WG will hold an Interim Meeting on September 17-18= ,
>> 2014. The meeting will take place at One Penn Plaza, 9th Floor New= York, NY
>> 10119 USA.
>>
>> The agenda of the meeting is to work on YANG 1.1 open issues and i= n
>> particular on
>>
>> - issues related to YANG 1.1 conformance;
>> - issues related to YANG 1.1 datastores and I2RS support;
>> - any remaining open YANG 1.1 issues.
>>
>> If you'd like to attend, please register by sending an email to th= e NETMOD
>> WG chairs. The meeting details with further information about the<= br> >> participants and meeting logistics will be maintained in the SVN o= f the
>> NETMOD working group
>>
>> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/
>>
>> and also posted on the NETMOD mailing list. A preliminary list of = participants
>> is on the following Doodle poll:
>>
>> h= ttp://doodle.com/7eptxb7mggtdhwmc
>
> _______________________________________________
> 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

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C865BCDAZFFEXMB04globa_-- From nobody Mon Aug 4 17:07: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 15B751A0AAC for ; Mon, 4 Aug 2014 17:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 POaAkOlmJGQ5 for ; Mon, 4 Aug 2014 17:07:32 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA2A1A0AA1 for ; Mon, 4 Aug 2014 17:07:31 -0700 (PDT) X-AuditID: c1b4fb25-f79da6d000004ad3-c0-53e0204094ca Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A6.3A.19155.04020E35; Tue, 5 Aug 2014 02:07:29 +0200 (CEST) Received: from ESESSMB103.ericsson.se ([169.254.3.143]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0174.001; Tue, 5 Aug 2014 02:07:28 +0200 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: Andy Bierman Thread-Topic: [netmod] Issue Y36: associate RPCs AND notification with a data node Thread-Index: Ac+vZUxZihDr2jF8Q6+dD2GXEYtHqQAD80aAADIgh+A= Date: Tue, 5 Aug 2014 00:07:27 +0000 Message-ID: <971D4B790EC8B846BE223DD23AF72FF11EB80310@ESESSMB103.ericsson.se> References: <971D4B790EC8B846BE223DD23AF72FF11EB7FF02@ESESSMB103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_971D4B790EC8B846BE223DD23AF72FF11EB80310ESESSMB103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGfG3RtdR4UGwwZLp7BYPjsxit5h/sZHV gcljyZKfTB4t/RdZApiiuGxSUnMyy1KL9O0SuDLa3z9gKlixgKliwtKlzA2MG78zdjFycEgI mEis38HbxcgJZIpJXLi3nq2LkYtDSOAoo0TngY9MEM5iRon76xcygVSxCbhKHPv0nQXEFhFQ lbgwdyIziM0soC5x59RjNhBbWCBYYvrDb+wQNSESG+c/ZAdZJiJgJTF3oh9ImEVARWJp83qw cl4BX4nlW38wQ+yawijx8dJDsPmcAoES6+4fArMZga77fmoNE8QucYlbT+YzQVwtILFkz3lm CFtU4uXjf6wQtpJE45InrBD1+RIbGpexQiwTlDg58wnLBEbRWUhGzUJSNgtJGURcT+LG1Cls ELa2xLKFr5khbF2JGf8OsSCLL2BkX8UoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokRGHMHt/xW 3cF4+Y3jIUYBDkYlHt4FkfeDhVgTy4orcw8xSnOwKInzLjw3L1hIID2xJDU7NbUgtSi+qDQn tfgQIxMHp1QDY9zm13zzVHiCHDd6eDA6pn1c8+7nx7kzHFQFdsl6dBbmcAQIfq4TDZglurbI /P73ievS1m89Zmkizt0bekbxcP6v0sPb49g3LNKynXVqmfzCBY1FntF5PZ4TYhMr9j65IGe+ 7h676PR6HZ/DDOXRd3ttSwz5I852NFk7ue9wUZv148znTwxBSizFGYmGWsxFxYkAlLdeCZoC AAA= Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6lkWD8CQyJMW6W8y-J-asH_Jjfo Cc: "netmod@ietf.org" Subject: Re: [netmod] Issue Y36: associate RPCs AND notification with a data node X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Aug 2014 00:07:39 -0000 --_000_971D4B790EC8B846BE223DD23AF72FF11EB80310ESESSMB103erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Monday, 04 August, 2014 03:46 To: Bal=E1zs Lengyel Cc: netmod@ietf.org Subject: Re: [netmod] Issue Y36: associate RPCs AND notification with a dat= a node Hi, I have some questions and concerns about this proposal. 1) scope is inaccurate: * Y36 associate a notification with a data node This proposal has nothing to do with notifications. Where is the support to associate a notification with a data node? BALAZS: Will be added if interest is indicated by the group. 2) In your example, how would the be encoded if there was a list above server: list group { key "a b "; leaf a { type string; } leaf b { type int32; } list server { ... action reset { ... } } } BALAZS: You just need to add the keys-of-the-group encapsulation. myKey1 23 apache-1 2014-07-29T13:42Z 3) What if there are 2 'reset' actions: module server-farm { namespace "http://example.net/server-farm"; prefix "sfarm"; list server { key name; leaf name { type string; } action reset { input { leaf reset-at { type yang:date-and-time; mandatory true; } } output { leaf reset-finished-at { type string; mandatory true; } } } } container top { list server { key name; leaf name { type string; } action reset { input { leaf reset-at { type string; } } } } } We have /server/reset and /top/server/reset. How do the server know which 1 is being invoked? BALAZS: The encoding for /server/reset does not change. The encoding for /top/serve= r/reset would additionally contain the ... encapsulating element= . SO the presence or absence of will tell the server which res= et to choose. It's the same logic uses. For each container or list you add= one more level of XML element encapsulation. /top/server/reset: apache-1 anyString 4) Ehat is the purpose of the extra container inserted in the action= input and output? BALAZS: It is there for data encapsulation similarly as for a reply for . Not crucial, but at the time we implemented it, it looked like, = the clean and consistent way to do things. Andy On Sun, Aug 3, 2014 at 2:56 PM, Bal=E1zs Lengyel > wrote: Hello I attached my proposal for the action statement in YANG. Please comment. Regards Balazs On 2014-07-29 15:40, Balazs Lengyel wrote: Hello Juergen, We should declare this issue alive because IETF is about rough consensus an= d running code: - Rough consensus: Major players (Martin, Andy :-) ) and myself for Ericsso= n indicated strong interest and support (at least for connecting RPCs, a.k.= a. actions, to data nodes). That is at least a begining for a consensus. - Running code: Tail-f, Ericsson, and probably Huawei already has implement= ations of actions. I have a reasonable proposal, which I will publish hopefully this week, but= want to check with Martin first. Also, actions are similar in many ways to RPCs so IMHO they are not a major= new feature, no need to wait for a major YANG version: 2.0. regards Balazs On 2014-07-23 21:16, Juergen Schoenwaelder wrote: On Wed, Jul 23, 2014 at 02:58:58PM -0400, Martin Bjorklund wrote: In NACM, you can have a rule that looks like this: xx /system/authentication/user[name=3D$USER] exec accept (this would give a user access to any inline operations available for a user, maybe 'generate-ssh-keys') So while the NACM procedure defined in RFC 6536 doesn't spell out how to handle inline operations (not surpringsly...) the data model supports them. I support Balazs in this; I think especially inline operations (a.k.a. actions) have proven to be very useful. We support them in our software, and a majority of our customers use them. Lets see what has happened. We discussed Y36 on 2014-06-04. Below is the excerpt from the minutes. A call was made on the mailing list on Fri, 27 Jun 2014 and nobody objected against the proposal to move this to DEAD. Why do we reconsider this now? What makes this a YANG 1.1 issue now? /js * Y36 associate a notification with a data node MB says that he did not have customers asking for this but Tail-f has something similar called actions (inlined rpcs). If we do this, it makes sense to add inline RPCs as well. AZ sees a use case. PO sees value in notification source properties attached to leafs. PO says that this is essentially about associating a notification with a resource object. MB says this is a nice to have feature because you can do without. Sounds more like a YANG 2.0 issue. AB agrees that this is an optimization, perhaps this can also be dealt with by certain design patterns. JS suggests that one could also think about guidelines on how to structure notifications to make resource identification easier. Proposal: Reject this issue. May be considered for YANG 2.0. -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_971D4B790EC8B846BE223DD23AF72FF11EB80310ESESSMB103erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 <= /p>

 <= /p>

From: Andy Bie= rman [mailto:andy@yumaworks.com]
Sent: Monday, 04 August, 2014 03:46
To: Bal=E1zs Lengyel
Cc: netmod@ietf.org
Subject: Re: [netmod] Issue Y36: associate RPCs AND notification wit= h a data node

 

Hi,

 

I have some questions and concerns about this propos= al.

 

1) scope is inaccurate:

 * Y36 associate a notification with a data nod= e 

  This proposal has nothing to do with notifica= tions.

  Where is the support to associate a notificat= ion with a data node?

BALAZS: Will be added if = interest is indicated by the group.

 

2) In your example, how would the <rpc> be enc= oded if there was a

    list above server:

 

        list group {<= /p>

            key "= a b ";

            leaf a { t= ype string; }

            leaf b { t= ype int32; }

            list serve= r {  ... action reset { ... } }

      }

 <= /p>

BALAZS:

You just need to add the = <group> keys-of-the-group</group> encapsulation.

     = <rpc message-id=3D"101"

    &= nbsp;     xmlns=3D"urn:ietf:params:xml:ns:netconf:= base:1.0"

    &= nbsp;     xmlns:yang=3D"urn:ietf:params:xml:ns:yan= g:1">

    &= nbsp;   <yang:action>

    &= nbsp;       <data>

    &= nbsp;          <group xmlns= =3D"http://example.net/server-farm">

    &= nbsp;            &nb= sp; <a>myKey1</a>

    &= nbsp;           &nbs= p;  <b>23</b>

    &= nbsp;            &nb= sp; <server>

    &= nbsp;           &nbs= p;      <name>apache-1</name>

    &= nbsp;           &nbs= p;      <reset>

    &= nbsp;           &nbs= p;          <reset-at>20= 14-07-29T13:42Z</reset-at>

    &= nbsp;           &nbs= p;      </reset>

    &= nbsp;            &nb= sp; </server>

    &= nbsp;          </group><= o:p>

    &= nbsp;       </data>

    &= nbsp;   </action>

     = </rpc>

 

 3) What if there are 2 'reset' actions:

 

   

 module server-farm {

         namespace "http://example.net/server-farm= ";

         prefix "sfarm= ";

         

         list server {=

            key name;<= o:p>

            leaf name = {

              &nb= sp; type string;

            }

            action res= et {

              &nb= sp; input {

              &nb= sp;     leaf reset-at {

              &nb= sp;         type yang:date-and-time;

              &nb= sp;         mandatory true;

              &nb= sp;     }

              &nb= sp; }

              &nb= sp; output {

              &nb= sp;     leaf reset-finished-at {

              &nb= sp;      type string;

              &nb= sp;       mandatory true;

              &nb= sp;     }

              &nb= sp; }

            }   &= nbsp; 

        }

 

        container top {

            list serve= r {

              key= name;

              &nb= sp;leaf name {

              &nb= sp;   type string;

              &nb= sp;}

              &nb= sp;action reset {

              &nb= sp;    input {

              &nb= sp;        leaf reset-at {

              &nb= sp;           type string;

              &nb= sp;       }

              &nb= sp;   }

             }     

        }

 

    }

 

 

We have /server/reset and /top/server/reset.

How do the server know which 1 is being invoked?

BALAZS:=

The encoding for /server/= reset does not change. The encoding for /top/server/reset would additionall= y contain the <top>…</top> encapsulating element. SO the presence or absence of  <top></top> will tell the server = which reset to choose.

It’s the same logic= <edit-config>  uses. For each container or list you add one mor= e level of XML element encapsulation.

/top/server/reset:

     = <rpc message-id=3D"101"

    &= nbsp;     xmlns=3D"urn:ietf:params:xml:ns:netconf:= base:1.0"

    &= nbsp;     xmlns:yang=3D"urn:ietf:params:xml:ns:yan= g:1">

    &= nbsp;   <yang:action>

    &= nbsp;       <data>

    &= nbsp;          <top xmlns= =3D"http://example.net/server-farm">

    &= nbsp;            &nb= sp; <server>

    &= nbsp;           &nbs= p;      <name>apache-1</name>

    &= nbsp;           &nbs= p;      <reset>

    &= nbsp;           &nbs= p;          <reset-at>an= yString</reset-at>

    &= nbsp;           &nbs= p;      </reset>

    &= nbsp;            &nb= sp; </server>

    &= nbsp;          </top>

    &= nbsp;       </data>

    &= nbsp;   </action>

     = </rpc>

 

4) Ehat is the purpose of the extra <data> con= tainer inserted in the action input

and output?

 <= /p>

BALAZS: It is there for d= ata encapsulation similarly as for a reply for <get-config>. Not cruc= ial, but at the time we implemented it, it looked like, the clean and  consistent way to do things.

 

 

Andy

 

 

 

 

On Sun, Aug 3, 2014 at 2:56 PM, Bal=E1zs Lengyel <= ;balazs.le= ngyel@ericsson.com> wrote:

Hello

I attached my proposal for the action statement in YANG. Please co= mment.

Regards Balazs

 

 

On 2014-07-29 15:40, Balazs Lengyel wrote:

Hello Juergen,
We should declare this issue alive because IETF is about rough consensus an= d running code:
- Rough consensus: Major players (Martin, Andy :-) ) and myself for Ericsso= n indicated strong interest and support (at least for connecting RPCs, a.k.= a. actions, to data nodes). That is at least a begining for a consensus.
- Running code: Tail-f, Ericsson, and probably Huawei already has implement= ations of actions.

I have a reasonable proposal, which I will publish hopefully this week, but= want to check with Martin first.
Also, actions are similar in many ways to RPCs so IMHO they are not a major= new feature, no need to wait for a major YANG version: 2.0.
regards Balazs

On 2014-07-23 21:16, Juergen Schoenwaelder wrote:

On Wed, Jul 23, 2014 at 02:58:58PM -0400, Martin Bjorklund wrote:

In NACM, you can have a rule that looks like this:

   <rule>
     <name>xx</name>
     <path>/system/authentication/user[name=3D$US= ER]</path>
     <access-operations>exec</access-operation= s>
     <action>accept</accept>
   </rule>

(this would give a user access to any inline operations available for
a user, maybe 'generate-ssh-keys')

So while the NACM procedure defined in RFC 6536 doesn't spell out how
to handle inline operations (not surpringsly...) the data model
supports them.

I support Balazs in this; I think especially inline operations
(a.k.a. actions) have proven to be very useful.  We support them in our software, and a majority of our customers use them.

Lets see what has happened. We discussed Y36 on 2014-06-04. Below is
the excerpt from the minutes. A call was made on the mailing list on
Fri, 27 Jun 2014 and nobody objected against the proposal to move this
to DEAD.

Why do we reconsider this now? What makes this a YANG 1.1 issue now?

/js

* Y36 associate a notification with a data node

   MB says that he did not have customers asking for this but Tai= l-f
   has something similar called actions (inlined rpcs). If we do = this,
   it makes sense to add inline RPCs as well.

   AZ sees a use case.

   PO sees value in notification source properties attached to le= afs.

   PO says that this is essentially about associating a notificat= ion
   with a resource object.

   MB says this is a nice to have feature because you can do
   without. Sounds more like a YANG 2.0 issue.

   AB agrees that this is an optimization, perhaps this can also = be
   dealt with by certain design patterns.

   JS suggests that one could also think about guidelines on how = to
   structure notifications to make resource identification easier= .

   Proposal: Reject this issue. May be considered for YANG 2.0. <= o:p>

 

 

--

Balazs Lengyel         &nbs= p;             = Ericsson Hungary Ltd.

Senior Specialist

ECN: 831 7320          = ;            &n= bsp; Tel: +36-1-437-7320

Mobile: +36-70-330-7909       &nb= sp;      email: Balazs.Len= gyel@ericsson.com

 


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

 

--_000_971D4B790EC8B846BE223DD23AF72FF11EB80310ESESSMB103erics_-- From nobody Tue Aug 5 05:30:21 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB37C1A00AF for ; Tue, 5 Aug 2014 05:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 DytBi8WulxR6 for ; Tue, 5 Aug 2014 05:30:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A201A007A for ; Tue, 5 Aug 2014 05:30:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHX92763; Tue, 05 Aug 2014 12:30:14 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Aug 2014 13:30:13 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.209]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Tue, 5 Aug 2014 20:30:06 +0800 From: Haoweiguo To: "netmod@ietf.org" Thread-Topic: Comments and doubts about the draft "draft-bogdanovic-netmod-acl-model-01" Thread-Index: Ac+wqMHKs5Wfdi5DQ1a3klrJpCfVnw== Date: Tue, 5 Aug 2014 12:30:05 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB5517334F7EEE30nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rzMHu4BmGyjCt30Bn_g_BhSQcxY Subject: [netmod] Comments and doubts about the draft "draft-bogdanovic-netmod-acl-model-01" X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Aug 2014 12:30:19 -0000 --_000_DD5FC8DE455C3348B94340C0AB5517334F7EEE30nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQ28tYXV0aG9ycywNCg0KDQoNCkFmdGVyIHJlYWRpbmcgb3ZlciB0aGUgZHJhZnQsIGkgaGF2 ZSBzb21lIGNvbW1lbnRzIGFuZCBkb3VidHMgYXMgZm9sbG93aW5nLg0KDQoNCg0KIlRoZXJlIGlz IGEgZGVmYXVsdCBBQ0Ugd2hpY2ggYXBwbGllcyBpZiBhIHBhY2tldCBkb2VzIG5vdCBtYXRjaCBh bnkgb2YgdGhlIG90aGVyIEFDRXMuIg0KW3dlaWd1b106IERpZmZlcmVudCB2ZW5kb3JzIG1heSBo YXZlIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMgZm9yIGRlZmF1bHQgQUNFIGFjdGlvbi4gRG9l cyBpdCBuZWVkIHRvIGRlZmluZSBhIGdlbmVyaWMgZGVmYXVsdCBhY3Rpb24/DQoNCg0KDQoNCg0K SW4gaWV0Zi1hY2wgbW9kdWxlOg0KDQpbd2VpZ3VvXTogV2h5IG1hdGNoIGNvdW50ZXIgY2FuIGJl IHdyaXR0ZW4/IENvdW50IGJhc2Ugb24gQUNFIGlzIGVub3VnaCwgTWF5YmUgdGhpcyBjb3VudGVy IGlzbid0IHJlcXVpcmVkLg0KDQorLS1ydyBtYXRjaC1jb3VudGVyPyBpZXRmOmNvdW50ZXI2NA0K fCArLS1ydyBwZXJtaXQtY291bnRlcj8gaWV0Zjpjb3VudGVyNjQNCnwgKy0tcncgZGVueS1jb3Vu dGVyPyBpZXRmOmNvdW50ZXI2NA0KDQoNCg0KW3dlaWd1b106ICBXaGF0IGRvZXMgInJ3IHRhcmdl dHMqIHN0cmluZyIgdXNlZCBmb3I/DQoNCg0KDQpbd2VpZ3VvXTogIFdoYXQgZG9lcyAiKy0tcncg bWF0Y2hlcyIgdXNlZCBmb3I/DQoNCg0KDQpbd2VpZ3VvXTogIEluIG1vc3Qgb2YgdGhlIGN1cnJl bnQgY29tbWVyY2lhbCBwcm9kdWN0cywgb25lIEFDTCBvbmx5IGhhcyBvbmUgQUNFLXR5cGUgZXZl biB0aG91Z2ggdGhlcmUgbWF5YmUgbWFueSBydWxlcyBpbnNpZGUgdGhlIEFDTCwgZWFjaCBydWxl IGhhcyBzYW1lICJhY2UtdHlwZSIuIEluIHRoZSBkcmFmdCwgZWFjaCBydWxlIGhhcyBpdHMgImFj ZS10eXBlIiwgaSB0aGluayBpdCBoYXMgdG9vIG11Y2ggZ3JhbnVsYXJpdHkuIENhbiBpdCBiZSBt b2RpZmllZCBhcyBmb2xsb3dpbmc/DQoNCistLXJ3IGFjY2Vzcy1saXN0DQorLS1ydyBhY2wtbmFt ZT8gc3RyaW5nDQorLS1ydyBhY2wtb3Blci1kYXRhDQp8ICstLXJ3IG1hdGNoLWNvdW50ZXI/IGll dGY6Y291bnRlcjY0DQp8ICstLXJ3IHBlcm1pdC1jb3VudGVyPyBpZXRmOmNvdW50ZXI2NA0KfCAr LS1ydyBkZW55LWNvdW50ZXI/IGlldGY6Y291bnRlcjY0DQp8ICstLXJ3IHRhcmdldHMqIHN0cmlu Zw0KKy0tcncgYWNsLXR5cGU/IHN0cmluZw0KICB8ICstLXJ3IGFjZS1pcC1lbnRyaWVzKiBbcnVs ZS1uYW1lXQ0KICAgfCArLS1ydyBydWxlLW5hbWUgc3RyaW5nDQoNClt3ZWlndW9dOiAgRG8gd2Ug bmVlZCBkZWZpbmUgbWF0Y2hlcyBhbmQgYWN0aW9ucyBhcyBjb250YWluZXI/IENhbiBpdCBiZSBt b2RpZmllZCBhcyBmb2xsb3dpbmc/DQoNCg0KDQorLS1ydyBhY2Nlc3MtbGlzdA0KKy0tcncgYWNs LW5hbWU/IHN0cmluZw0KKy0tcncgYWNsLW9wZXItZGF0YQ0KfCArLS1ydyBtYXRjaC1jb3VudGVy PyBpZXRmOmNvdW50ZXI2NA0KfCArLS1ydyBwZXJtaXQtY291bnRlcj8gaWV0Zjpjb3VudGVyNjQN CnwgKy0tcncgZGVueS1jb3VudGVyPyBpZXRmOmNvdW50ZXI2NA0KfCArLS1ydyB0YXJnZXRzKiBz dHJpbmcNCiAgKy0tcncgYWNsLXR5cGU/IHN0cmluZw0KICArLS06KGFjZS1pcCkNCiAgfCArLS1y dyBydWxlLW5hbWUgc3RyaW5nDQogIHwgKy0tcncgaXAtcHJvdG9jb2w/IHVpbnQ4DQogIHwgKy0t cncgZGVzdGluYXRpb24taXB2NC1hZGRyZXNzPyBpbmV0OmlwdjQtcHJlZml4DQogIHwgKy0tcncg c291cmNlLWlwdjQtYWRkcmVzcz8gaW5ldDppcHY0LXByZWZpeA0KICAgICstLXJ3IGFjdGlvbj8N CiAgKy0tOihhY2UtZXRoKQ0KICAuLi4uLg0KICArLS06KGFjZS1pcDYpDQogLi4uDQpUaGFua3MN Cg0Kd2VpZ3VvDQo= --_000_DD5FC8DE455C3348B94340C0AB5517334F7EEE30nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Co-authors,

 

After reading over the draft, i have s= ome comments and doubts as following.

 

"There is a default ACE which app= lies if a packet does not match any of the other ACEs."
[weiguo]: Different vendors may have different implementations for default = ACE action. Does it need to define a generic default action?

 

 

In ietf-acl module:

[weiguo]: Why match counter can be wri= tten? Count base on ACE is enough, Maybe this counter isn't required.

+--rw match-counter? ietf:counter6= 4
| +--rw permit-counter? ietf:counter64
| +--rw deny-counter? ietf:counter64

 

[weiguo]:  What does "rw tar= gets* string" used for?

 

[weiguo]:  What does "+-= -rw matches" used for?

 

[weiguo]:  In most of the current= commercial products, one ACL only has one ACE-type even though there maybe= many rules inside the ACL, each rule has same "ace-type". In the= draft, each rule has its "ace-type", i think it has too much granularity. Can it be modified as following?
  
+--rw access-list
+--rw acl-name? string
+--rw acl-oper-data
| +--rw match-counter? ietf:counter64
| +--rw permit-counter? ietf:counter64
| +--rw deny-counter? ietf:counter64
| +--rw targets* string
+--rw acl-type? string
  | +--rw ace-ip-entries* [rule-name]
   | +--rw rule-name string
  
[weiguo]:  Do we need define matches and actions as container? Can it = be modified as following?

 

+--rw access-list
+--rw acl-name? string
+--rw acl-oper-data
| +--rw match-counter? ietf:counter64
| +--rw permit-counter? ietf:counter64
| +--rw deny-counter? ietf:counter64
| +--rw targets* string
  +--rw acl-type? string
  +--:(ace-ip)
  | +--rw rule-name string
  | +--rw ip-protocol? uint8
  | +--rw destination-ipv4-address? inet:ipv4-prefix
  | +--rw source-ipv4-address? inet:ipv4-prefix
    +--rw action?
  +--:(ace-eth)
  .....
  +--:(ace-ip6)
 ...
Thanks

weiguo

--_000_DD5FC8DE455C3348B94340C0AB5517334F7EEE30nkgeml501mbschi_-- From nobody Tue Aug 5 16:58: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 0AFC61A0386 for ; Tue, 5 Aug 2014 16:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 dTs14du9-9tI for ; Tue, 5 Aug 2014 16:58:38 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C4AB1A03A7 for ; Tue, 5 Aug 2014 16:58:37 -0700 (PDT) X-AuditID: c1b4fb3a-f79a36d000000ffa-01-53e16fabbd95 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 08.C1.04090.BAF61E35; Wed, 6 Aug 2014 01:58:35 +0200 (CEST) Received: from ESESSMB103.ericsson.se ([169.254.3.143]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0174.001; Wed, 6 Aug 2014 01:58:34 +0200 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: "netmod@ietf.org" Thread-Topic: Y09: introduce optional keys Y09 Thread-Index: Ac+xCQvk//lEbE82Q9GCa4bOAQIlrQ== Date: Tue, 5 Aug 2014 23:58:33 +0000 Message-ID: <971D4B790EC8B846BE223DD23AF72FF11EB805EA@ESESSMB103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_971D4B790EC8B846BE223DD23AF72FF11EB805EAESESSMB103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje7q/IfBBvPf81vMv9jI6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMlvXrAUPKuoWHjyCXMD44+MLkZODgkBE4k7T9cwQdhiEhfu rWfrYuTiEBI4yigx798bVghnMaPE5FfzWUGq2ARcJY59+s4CYosIqEvM3AnSwckhLKAp8eD7 Qqi4nsSaH2eB4hxg9pJnYMtYBFQkmhY8BlvGK+ArMaPvHVg5I9Di76cgjmAWEJe49WQ+1EEC Ekv2nGeGsEUlXj7+xwphK0k0LnnCCjKeWSBf4tSVaoiRghInZz5hmcAoNAvJpFkIVbOQVEGU 6EncmDqFDcLWlli28DUzhK0rMePfIRZk8QWM7KsYRYtTi4tz042M9FKLMpOLi/Pz9PJSSzYx AuPh4JbfVjsYDz53PMQowMGoxMP7IPhhsBBrYllxZe4hRmkOFiVx3oXn5gULCaQnlqRmp6YW pBbFF5XmpBYfYmTi4JRqYMw5seDfZmMBQQa5FJk7HA53/etrVpi+4eHaNqd0hVofd5tb8W7n z4f1TyjNF+51TTySUaJ0fauCQubqY+/7VjInd7cE/GlaJekiaMtpdna9EiNj4Iuw+FCpJLFd jv8evjy5cyOD9j7Bb+mJ9zZc/PN32Y1OR2vbeT8vTt+rJtvuy+95KqMgU4mlOCPRUIu5qDgR ALvQUBRoAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-bwa3IhYLBBTD_Cs-fko_R44rsg Subject: [netmod] Y09: introduce optional keys Y09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Aug 2014 23:58:43 -0000 --_000_971D4B790EC8B846BE223DD23AF72FF11EB805EAESESSMB103erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, So before we go into the interim, I think we should consider this issue as = well. As Lada and Andy wrote in some cases there is no need for a key. We a= lready allow this for config false lists. I support what Andy wrote: "YANG 1.1 should allow user-ordered lists and leaf-lists to be keyed by the= sibling order, and not require any keys." Naturally this would mean that the rules for the operation an= d especially the insert before/after have to be defined for the keyless cas= e, but IMHO that's business as usual. regards Balazs On 2014-07-08 16:54, Ladislav Lhotka wrote: > Andy Bierman writes: > >> On Thu, Jul 3, 2014 at 6:50 AM, Balazs Lengyel >> wrote: >> >>> 1) Non-Unique leaf-list: YANG shall allow leaf-lists whose members are = not >>> unique. >>> They are needed in a number of cases especially for user-ordered lists, >>> where the position is stable and carries a meaning. >>> >> I actually like this one, but I think this is a more general problem >> which has been raised before, but should be reconsidered. >> >> Perhaps YANG 1.1 should allow user-ordered lists and leaf-lists to be ke= yed >> by >> the sibling order, and not require any keys. That would solve your prob= lem. >> It actually shows up in the example-jukebox "playlist" in RESTCONF. >> This is a list instead of a leaf-list just so a dummy key can be defined= , >> just so duplicates can be allowed in the playlist. >> >> >> YANG 1.0: >> >> list song { >> key index; >> ordered-by user; >> >> description >> "Example nested configuration data resource"; >> >> leaf index { // not really needed >> type uint32; >> description >> "An arbitrary integer index for this playlist song."; // >> <<<<< Yuch!!! >> } >> leaf id { >> type rc:data-resource-identifier; >> mandatory true; >> description >> "Song identifier. Must identify an instance of >> /jukebox/library/artist/album/song/name."; >> } >> } >> >> >> Maybe YANG 1.1: >> >> >> leaf-list song { >> ordered-by user; >> type rc:data-resource-identifier; >> description >> "Song identifier. Must identify an instance of >> /jukebox/library/artist/album/song/name."; >> } >> >> IMO this is a lot cleaner (You are right Balazs) > Yes, I'd support this. There are other use cases such as AS-Path that > may contain the same AS number repeatedly. > >> There would need to be a way in NETCONF to insert and delete by position >> instead of keys >> or leaf-list value. (e.g add position=3D"N" attribute in YANG 1.1 to go = with >> the "insert" >> and nc:operation=3D"delete" attributes). > Maybe it's time to move this from YANG to NETCONF spec where it really be= longs? > > Lada > >> >> >> >> >>> regards Balazs >> >> >> >> Andy >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com --_000_971D4B790EC8B846BE223DD23AF72FF11EB805EAESESSMB103erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

So before we go into the interim, I think we should = consider this issue as well. As Lada and Andy wrote in some cases there is = no need for a key. We already allow this for config false lists.

 

I support what Andy wrote:

"YANG 1.1 should allow user-ordered lists and l= eaf-lists to be keyed by the sibling order, and not require any keys."=

 

Naturally this would mean that the rules for the <= ;edit-config> operation and especially the insert before/after have to b= e defined for the keyless case, but IMHO that's business as usual.

regards Balazs

 

On 2014-07-08 16:54, Ladislav Lhotka wrote:

> Andy Bierman <andy@yumaworks.com> writes:=

> 

>> On Thu, Jul 3, 2014 at 6:50 AM, Balazs Leng= yel <balazs.lengyel@ericsson.com>

>> wrote:

>> 

>>> 1) Non-Unique leaf-list: YANG shall all= ow leaf-lists whose members are not

>>> unique.

>>> They are needed in a number of cases es= pecially for user-ordered lists,

>>> where the position is stable and  = carries a meaning.

>>> 

>> I actually like this one, but I think this = is a more general problem

>> which has been raised before, but should be= reconsidered.

>> 

>> Perhaps YANG 1.1 should allow user-ordered = lists and leaf-lists to be keyed

>> by

>> the sibling order, and not require any keys= .  That would solve your problem.

>> It actually shows up in the example-jukebox= "playlist" in RESTCONF.

>> This is a list instead of a leaf-list just = so a dummy key can be defined,

>> just so duplicates can be allowed in the pl= aylist.

>> 

>> 

>> YANG 1.0:

>> 

>>       &n= bsp; list song {

>>       &n= bsp;   key index;

>>       &n= bsp;   ordered-by user;

>> 

>>       &n= bsp;   description

>>       &n= bsp;     "Example nested configuration data resour= ce";

>> 

>>       &n= bsp;   leaf index {    // not really needed

>>       &n= bsp;     type uint32;

>>       &n= bsp;     description

>>       &n= bsp;       "An arbitrary integer index f= or this playlist song.";   //

>>   <<<<< Yuch!!!

>>       &n= bsp;   }

>>       &n= bsp;   leaf id {

>>       &n= bsp;     type rc:data-resource-identifier;

>>       &n= bsp;     mandatory true;

>>       &n= bsp;     description

>>       &n= bsp;       "Song identifier. Must identi= fy an instance of

>>       &n= bsp;        /jukebox/library/artist/albu= m/song/name.";

>>       &n= bsp;   }

>>       &n= bsp; }

>> 

>> 

>> Maybe YANG 1.1:

>> 

>> 

>>       &n= bsp; leaf-list song {

>>       &n= bsp;    ordered-by user;

>>       &n= bsp;    type rc:data-resource-identifier;

>>       &n= bsp;    description

>>       &n= bsp;       "Song identifier. Must identi= fy an instance of

>>       &n= bsp;        /jukebox/library/artist/albu= m/song/name.";

>>       &n= bsp; }

>> 

>> IMO this is a lot cleaner (You are right Ba= lazs)

> Yes, I'd support this. There are other use case= s such as AS-Path that

> may contain the same AS number repeatedly.=

> 

>> There would need to be a way in NETCONF to = insert and delete by position

>> instead of keys

>> or leaf-list value. (e.g add position=3D&qu= ot;N" attribute in YANG 1.1 to go with

>> the "insert"

>> and nc:operation=3D"delete" attri= butes).

> Maybe it's time to move this from YANG to NETCO= NF spec where it really belongs?

> 

> Lada

> 

>> 

>> 

>> 

>> 

>>> regards Balazs

>> 

>> 

>> 

>> Andy

>> ___________________________________________= ____

>> netmod mailing list

>> netmod@ietf.org

>> https://www.ietf.org/mailman/listinfo/netmo= d

 

--

Balazs Lengyel      &n= bsp;            = ;    Ericsson Hungary Ltd.

Senior Specialist

ECN: 831 7320      &nb= sp;            =      Tel: +36-1-437-7320

Mobile: +36-70-330-7909    &= nbsp;         email: Balazs.Lengyel= @ericsson.com

 

--_000_971D4B790EC8B846BE223DD23AF72FF11EB805EAESESSMB103erics_-- From nobody Wed Aug 6 19:24: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 BB1821A0643 for ; Wed, 6 Aug 2014 19:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 CUDVN46l8Oc4 for ; Wed, 6 Aug 2014 19:24:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA161A0659 for ; Wed, 6 Aug 2014 19:24:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKY93072; Thu, 07 Aug 2014 02:24:43 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Aug 2014 03:24:41 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.209]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Thu, 7 Aug 2014 10:24:35 +0800 From: Haoweiguo To: "netmod@ietf.org" Thread-Topic: Comments on the draft of draft-litkowski-netmod-isis-cfg-00 Thread-Index: Ac+x5EadHpMfisBeQumh8ccdDAowQg== Date: Thu, 7 Aug 2014 02:24:34 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB5517334F7F0052nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/uQFPjBcEpuMZwlICiOZ1ADpRhkc Subject: [netmod] Comments on the draft of draft-litkowski-netmod-isis-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Aug 2014 02:24:47 -0000 --_000_DD5FC8DE455C3348B94340C0AB5517334F7F0052nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQ28tYXV0aG9ycywNCg0KQWZ0ZXIgcmVhZGluZyB0aGlzIGRyYWZ0LCBpIGhhdmUgdGhlIGZv bGxvd2luZyBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMuDQoNCg0KDQptb2R1bGU6IGlzaXMNCist LXJ3IGlzaXMtY2ZnDQp8ICstLXJ3IGluc3RhbmNlcw0KfCArLS1ydyBpbnN0YW5jZSBbbmFtZV0N CnwgKy0tcncgbmFtZQ0KfCArLS1ydyBlbmFibGVkDQp8ICstLXJ3IGlzaXMtbGV2ZWwNCnwgKy0t cncgYXJlYQ0KfCArLS1ydyBzeXN0ZW0taWQNCnwgKy0tcncgaXB2NC1yb3V0ZXItaWQgLi4uLi4N CnwgKy0tcncgaXB2Ni1yb3V0ZXItaWQgIC4uLi4uLi4uDQoNCg0KDQpbd2VpZ3VvXTogSSB0aGlu ayBJUy1JUyBwcm90b2NvbCBkb2Vzbid0IHVzZSBpcHY0LXJvdXRlci1pZCAgYW5kICBpcHY2LXJv dXRlci1pZCAsIHNvIGl0IGhhZCBiZXR0ZXIgYmUgcmVtb3ZlZC4NCg0KDQoNCistLXJ3IGlzaXMt YXV0aGVudGljYXRpb24tY2ZnDQorLS1ydyBwc25wLWF1dGhlbnRpY2F0aW9uDQorLS1ydyBjc25w LWF1dGhlbnRpY2F0aW9uDQorLS1ydyBoZWxsby1hdXRoZW50aWNhdGlvbg0KDQoNCg0KKy0tcncg aXNpcy1sZXZlbC0xLWNmZw0KKy0tcncgZW5hYmxlZA0KKy0tcncgcHNucC1hdXRoZW50aWNhdGlv bg0KKy0tcncgY3NucC1hdXRoZW50aWNhdGlvbg0KKy0tcncgaGVsbG8tYXV0aGVudGljYXRpb24N Cg0KDQoNClt3ZWlndW9dOiBGb3IgdGhlIGFib3ZlIGF1dGhlbnRpY2F0aW9uIHJlbGF0ZWQgY29u ZmlnLCBQU05QLWF1dGhlbnRpY2F0aW9uIGFuZCBDU05QLWF1dGhlbnRpY2F0aW9uIGhhZCBiZXR0 ZXIgbWVyZ2UgaW50byBzaW5nbGUgZG9tYWluLWF1dGhlbmNpYXRpb24sIGJlY2F1c2UgUFNOUCBh bmQgQ1NOUCBhdXRoZW50aWNhdGlvbiBjb25maWd1cmF0aW9uIHNob3VsZCBiZSBzYW1lLiBJZiB0 d28gaW5kZXBlbmRhbnQgUFNOUC1hdXRoZW50aWNhdGlvbiBhbmQgQ1NOUC1hdXRoZW50aWNhdGlv biBleGlzdCwgdGhlIG9wZXJhdG9ycyBjYW4gY29uZmlndXJlIGRpZmZlcmVudCBwYXJhIGZvciBQ U05QIGFuZCBDU05QLCBjb25mbGljdGlvbiB3aWxsIG9jY3VyLg0KDQoNCg0KVGhhbmtzDQoNCndl aWd1bw0K --_000_DD5FC8DE455C3348B94340C0AB5517334F7F0052nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Co-authors,

After reading this draft, i have the f= ollowing comments and suggestions.

 

module: isis
+--rw isis-cfg
| +--rw instances
| +--rw instance [name]
| +--rw name
| +--rw enabled
| +--rw isis-level
| +--rw area
| +--rw system-id
| +--rw ipv4-router-id .....
| +--rw ipv6-router-id  ........

 

[weiguo]: I think IS-IS protocol doesn= 't use ipv4-router-id  and  ipv6-router-id , so it had bette= r be removed.

 

+--rw isis-authentication-cfg
+--rw psnp-authentication
+--rw csnp-authentication
+--rw hello-authentication

 

+--rw isis-level-1-cfg
+--rw enabled
+--rw psnp-authentication
+--rw csnp-authentication
+--rw hello-authentication

 

[weiguo]: For the above authentication= related config, PSNP-authentication and CSNP-authentication had better mer= ge into single domain-authenciation, because PSNP and CSNP authentication c= onfiguration should be same. If two independant PSNP-authentication a= nd CSNP-authentication exist, the operators can configure different para fo= r PSNP and CSNP, confliction will occur.

 

Thanks

weiguo

--_000_DD5FC8DE455C3348B94340C0AB5517334F7F0052nkgeml501mbschi_-- From nobody Wed Aug 6 19:31: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 1A1661A0645 for ; Wed, 6 Aug 2014 19:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 u5HS7BereMAK for ; Wed, 6 Aug 2014 19:31:11 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3AEA1A0654 for ; Wed, 6 Aug 2014 19:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1513; q=dns/txt; s=iport; t=1407378671; x=1408588271; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=v0MkFvTaIW6nIFkY4MWktVvtDJYwYmVX5axHzkH7/EE=; b=jT5NlcAfqfufm1MoNcPPZAAOduS/VCiES6zVpUrWD1hCZGL6P6665jgO AMBdPSREFY3qPwLccw1pz1eB57U3LYdUGJVcfWq3/mYyimoszg0/T8Hkr gw6ZyAbAHCGoqxeKOzGWj8QB1HqID36B5qU6UApDJ8bif1ncynWLX6U8v g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAEHk4lOtJA2E/2dsb2JhbABagmojgS3VOxZ3hAo6UQE+QicEiFUBngilbxeUHgWcE5Rmg1eCMg X-IronPort-AV: E=Sophos;i="5.01,815,1400025600"; d="scan'208";a="345629428" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-7.cisco.com with ESMTP; 07 Aug 2014 02:31:11 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s772VBfk020364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 7 Aug 2014 02:31:11 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Wed, 6 Aug 2014 21:31:10 -0500 From: "Clyde Wildes (cwildes)" To: "netmod@ietf.org" Thread-Topic: The Question For The netmod List - Please Comment Thread-Index: AQHPseemj5uOng+olUW5RBrnMNJkrg== Date: Thu, 7 Aug 2014 02:31:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.27.7.178] Content-Type: text/plain; charset="us-ascii" Content-ID: <45F4A94F0C2A5045A2535698F212C66D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/TQ2EIxsTFp69hHOsIEifJZA6fOc Subject: [netmod] The Question For The netmod List - Please Comment X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Aug 2014 02:31:16 -0000 Hi, We are modeling state data for a single component that maintains state on both the active and standby RP in a fully redundant configuration as well on line cards or other distributed nodes. We are thinking of standardizing the models so we appreciate feedback. Is it best to handle this by: a) using a list where each element in the list contains the state for each location container xyz-component-state { config false; description "This container describes component state for all locations for this network device."; list location { key "location-name"; description "This list describes a collection of component state for multiple locations in a distributed system. There would would be at least one entry called main and possibly others."; leaf location-name { type string; description "This leaf describes the name of the location containing operational state. Example: main, standby, line_card_1, etc."; } list neighbors { key "name"; leaf name { type string; description "This leaf describes the name of the neighbor."; } leaf address { type inet:ip-address; } leaf up-time { type inet:timestamp; } } } } b) the use of a location specific datastore source for a get operation c) some other means. Thanks, Clyde From nobody Thu Aug 7 01:00: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 10CC01B2977 for ; Thu, 7 Aug 2014 01:00:37 -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 idJso_Ej69uz for ; Thu, 7 Aug 2014 01:00:34 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14461B290E for ; Thu, 7 Aug 2014 01:00:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id D40DE54080C for ; Thu, 7 Aug 2014 10:00:30 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duhd+6yyt35M for ; Thu, 7 Aug 2014 10:00:26 +0200 (CEST) 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 8DEA5540192 for ; Thu, 7 Aug 2014 10:00:26 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Thu, 07 Aug 2014 10:00:27 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/E7MHXYYvTIkzHWGNGJkJjBAG-C0 Subject: [netmod] more evidence for Y26 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Aug 2014 08:00:37 -0000 Hi, Stephane also ran into the Y26 problem: -------------------- Start of forwarded message -------------------- From: To: ... Subject: RE: ISIS YANG ... I have one Yang error that I'm not able to fix yet (and even understand :) ) for area-address configuration : "cannot augment mandatory node area-address". ... -------------------- End of forwarded message -------------------- It is an already well-known pattern that needs to be supported: augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" +"rt:routing-protocol" { when "rt:type = 'isis:isis'"; container isis { ... leaf-list area-address { type area-address; min-elements 1; ... } } } Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Aug 7 01:25: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 027CB1B29B7 for ; Thu, 7 Aug 2014 01:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 JkjY70qG-LCu for ; Thu, 7 Aug 2014 01:25:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A39791B29B3 for ; Thu, 7 Aug 2014 01:25:06 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id A494622C9FA; Thu, 7 Aug 2014 10:25:04 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 7F03327C079; Thu, 7 Aug 2014 10:25:04 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.132]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0181.006; Thu, 7 Aug 2014 10:25:04 +0200 From: To: Haoweiguo , "netmod@ietf.org" Thread-Topic: Comments on the draft of draft-litkowski-netmod-isis-cfg-00 Thread-Index: Ac+x5EadHpMfisBeQumh8ccdDAowQgANG+aw Date: Thu, 7 Aug 2014 08:25:04 +0000 Message-ID: <17441_1407399904_53E337E0_17441_15495_1_9E32478DFA9976438E7A22F69B08FF920615BB@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF920615BBOPEXCLILM34corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.6.200921 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/IL2DgfI_004RgzTr8pgum2K-ZeI Subject: Re: [netmod] Comments on the draft of draft-litkowski-netmod-isis-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Aug 2014 08:25:10 -0000 --_000_9E32478DFA9976438E7A22F69B08FF920615BBOPEXCLILM34corpor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Thanks for the comment, please use the last version of the doc for your nex= t comments (draft-litkowski-isis-yang-cfg). Please find inline answers. Stephane From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Haoweiguo Sent: Thursday, August 07, 2014 04:25 To: netmod@ietf.org Subject: [netmod] Comments on the draft of draft-litkowski-netmod-isis-cfg-= 00 Hi Co-authors, After reading this draft, i have the following comments and suggestions. module: isis +--rw isis-cfg | +--rw instances | +--rw instance [name] | +--rw name | +--rw enabled | +--rw isis-level | +--rw area | +--rw system-id | +--rw ipv4-router-id ..... | +--rw ipv6-router-id ........ [weiguo]: I think IS-IS protocol doesn't use ipv4-router-id and ipv6-rout= er-id , so it had better be removed. [SLI] Wrong, IS-IS uses IPv4 and/or IPv6 router-ids. IPv4 router-id is TLV1= 34 and it must be configurable. +--rw isis-authentication-cfg +--rw psnp-authentication +--rw csnp-authentication +--rw hello-authentication +--rw isis-level-1-cfg +--rw enabled +--rw psnp-authentication +--rw csnp-authentication +--rw hello-authentication [weiguo]: For the above authentication related config, PSNP-authentication = and CSNP-authentication had better merge into single domain-authenciation, = because PSNP and CSNP authentication configuration should be same. If two i= ndependant PSNP-authentication and CSNP-authentication exist, the operators= can configure different para for PSNP and CSNP, confliction will occur. [SLI] Most of implementations already propose to tune authentication in thi= s way ... Thanks weiguo ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_9E32478DFA9976438E7A22F69B08FF920615BBOPEXCLILM34corpor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

Thanks for the comment, p= lease use the last version of the doc for your next comments (draft-litkows= ki-isis-yang-cfg).

Please find inline answer= s.

 <= /p>

Stephane

 <= /p>

From: netmod [= mailto:netmod-bounces@ietf.org] On Behalf Of Haoweiguo
Sent: Thursday, August 07, 2014 04:25
To: netmod@ietf.org
Subject: [netmod] Comments on the draft of draft-litkowski-netmod-is= is-cfg-00

 

Hi Co-authors,<= /p>

After reading this draft, i have the following comments and sugg= estions.

 

module: isis
+--rw isis-cfg
| +--rw instances
| +--rw instance [name]
| +--rw name
| +--rw enabled
| +--rw isis-level
| +--rw area
| +--rw system-id
| +--rw ipv4-router-id .....
| +--rw ipv6-router-id  ........

 

[weiguo]: I think IS-IS protocol doesn't use ipv4-router-id = ; and  ipv6-router-id , so it had better be removed.

[SLI] Wrong, IS-IS uses IPv4 and/or IPv6 route= r-ids. IPv4 router-id is TLV134 and it must be configurable. 

 

+--rw isis-authentication-cfg
+--rw psnp-authentication
+--rw csnp-authentication
+--rw hello-authentication

 

+--rw isis-level-1-cfg
+--rw enabled
+--rw psnp-authentication
+--rw csnp-authentication
+--rw hello-authentication

 

[weiguo]: For the above authentication related config, PSNP-auth= entication and CSNP-authentication had better merge into single domain-auth= enciation, because PSNP and CSNP authentication configuration should be same. If two independant PSNP-authentication and CSNP-authentica= tion exist, the operators can configure different para for PSNP and CSNP, c= onfliction will occur.

 

[SLI] Most of implementations already propose= to tune authentication in this way …

 

 

Thanks

weiguo

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_9E32478DFA9976438E7A22F69B08FF920615BBOPEXCLILM34corpor_-- From nobody Thu Aug 7 01:34: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 5D5961B28A1 for ; Thu, 7 Aug 2014 01:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-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 VhKV_PaRFBHC for ; Thu, 7 Aug 2014 01:34:24 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ADA61A0377 for ; Thu, 7 Aug 2014 01:34:24 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 63D841274; Thu, 7 Aug 2014 10:34:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 9lVVVUciq43u; Thu, 7 Aug 2014 10:34:07 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 7 Aug 2014 10:34:22 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7D5D42002C; Thu, 7 Aug 2014 10:34:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Kx18eYp-le44; Thu, 7 Aug 2014 10:34:21 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B62A420017; Thu, 7 Aug 2014 10:34:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1886A2E04376; Thu, 7 Aug 2014 10:34:19 +0200 (CEST) Date: Thu, 7 Aug 2014 10:34:19 +0200 From: Juergen Schoenwaelder To: =?iso-8859-1?Q?Bal=E1zs?= Lengyel Message-ID: <20140807083419.GA80765@elstar.local> Mail-Followup-To: =?iso-8859-1?Q?Bal=E1zs?= Lengyel , "netmod@ietf.org" References: <971D4B790EC8B846BE223DD23AF72FF11EB805EA@ESESSMB103.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <971D4B790EC8B846BE223DD23AF72FF11EB805EA@ESESSMB103.ericsson.se> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/aVGDf1DL04x9oYSROfo2NnXWxAo Cc: "netmod@ietf.org" Subject: Re: [netmod] Y09: introduce optional keys Y09 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, 07 Aug 2014 08:34:26 -0000 Hi, this was discussed during the 2014-07-02 virtual interim meeting and Martin took an action item to write up a solution proposal (see the virtual interim meeting minutes). If you want to help Martin with this, please go ahead and coordinate with him. /js On Tue, Aug 05, 2014 at 11:58:33PM +0000, Balázs Lengyel wrote: > Hello, > So before we go into the interim, I think we should consider this issue as well. As Lada and Andy wrote in some cases there is no need for a key. We already allow this for config false lists. > > I support what Andy wrote: > "YANG 1.1 should allow user-ordered lists and leaf-lists to be keyed by the sibling order, and not require any keys." > > Naturally this would mean that the rules for the operation and especially the insert before/after have to be defined for the keyless case, but IMHO that's business as usual. > regards Balazs > > On 2014-07-08 16:54, Ladislav Lhotka wrote: > > Andy Bierman writes: > > > >> On Thu, Jul 3, 2014 at 6:50 AM, Balazs Lengyel > >> wrote: > >> > >>> 1) Non-Unique leaf-list: YANG shall allow leaf-lists whose members are not > >>> unique. > >>> They are needed in a number of cases especially for user-ordered lists, > >>> where the position is stable and carries a meaning. > >>> > >> I actually like this one, but I think this is a more general problem > >> which has been raised before, but should be reconsidered. > >> > >> Perhaps YANG 1.1 should allow user-ordered lists and leaf-lists to be keyed > >> by > >> the sibling order, and not require any keys. That would solve your problem. > >> It actually shows up in the example-jukebox "playlist" in RESTCONF. > >> This is a list instead of a leaf-list just so a dummy key can be defined, > >> just so duplicates can be allowed in the playlist. > >> > >> > >> YANG 1.0: > >> > >> list song { > >> key index; > >> ordered-by user; > >> > >> description > >> "Example nested configuration data resource"; > >> > >> leaf index { // not really needed > >> type uint32; > >> description > >> "An arbitrary integer index for this playlist song."; // > >> <<<<< Yuch!!! > >> } > >> leaf id { > >> type rc:data-resource-identifier; > >> mandatory true; > >> description > >> "Song identifier. Must identify an instance of > >> /jukebox/library/artist/album/song/name."; > >> } > >> } > >> > >> > >> Maybe YANG 1.1: > >> > >> > >> leaf-list song { > >> ordered-by user; > >> type rc:data-resource-identifier; > >> description > >> "Song identifier. Must identify an instance of > >> /jukebox/library/artist/album/song/name."; > >> } > >> > >> IMO this is a lot cleaner (You are right Balazs) > > Yes, I'd support this. There are other use cases such as AS-Path that > > may contain the same AS number repeatedly. > > > >> There would need to be a way in NETCONF to insert and delete by position > >> instead of keys > >> or leaf-list value. (e.g add position="N" attribute in YANG 1.1 to go with > >> the "insert" > >> and nc:operation="delete" attributes). > > Maybe it's time to move this from YANG to NETCONF spec where it really belongs? > > > > Lada > > > >> > >> > >> > >> > >>> regards Balazs > >> > >> > >> > >> Andy > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Aug 7 02:30: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 802221B2A3B for ; Thu, 7 Aug 2014 02:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.749 X-Spam-Level: * X-Spam-Status: No, score=1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 lkQ7HZk7Xyt2 for ; Thu, 7 Aug 2014 02:30:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A39D61B2A3A for ; Thu, 7 Aug 2014 02:30:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHZ78608; Thu, 07 Aug 2014 09:30:00 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Aug 2014 10:29:58 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.209]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Thu, 7 Aug 2014 17:29:51 +0800 From: Haoweiguo To: "stephane.litkowski@orange.com" , "netmod@ietf.org" Thread-Topic: Comments on the draft of draft-litkowski-netmod-isis-cfg-00 Thread-Index: Ac+x5EadHpMfisBeQumh8ccdDAowQgANG+awAAIN74U= Date: Thu, 7 Aug 2014 09:29:50 +0000 Message-ID: References: , <17441_1407399904_53E337E0_17441_15495_1_9E32478DFA9976438E7A22F69B08FF920615BB@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <17441_1407399904_53E337E0_17441_15495_1_9E32478DFA9976438E7A22F69B08FF920615BB@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB5517334F7F10BBnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/RoYkIrhqSm1Dr79DST0Q8AdDOXI Subject: [netmod] =?gb2312?b?tPC4tDogQ29tbWVudHMgb24gdGhlIGRyYWZ0IG9mIGRy?= =?gb2312?b?YWZ0LWxpdGtvd3NraS1uZXRtb2QtaXNpcy1jZmctMDA=?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Aug 2014 09:30:05 -0000 --_000_DD5FC8DE455C3348B94340C0AB5517334F7F10BBnkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQoNClBscyBzZWUgbXkgcmVwbHkgaW5saW5lIHdpdGggW3dlaWd1bzJdIGJlbG93Lg0KDQpU aGFua3MNCg0Kd2VpZ3VvDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+ yMs6IHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIFtzdGVwaGFuZS5saXRrb3dza2lAb3Jh bmdlLmNvbV0NCreiy83KsbzkOiAyMDE0xOo41MI3yNUgMTY6MjUNCsrVvP7IyzogSGFvd2VpZ3Vv OyBuZXRtb2RAaWV0Zi5vcmcNCtb3zOI6IFJFOiBDb21tZW50cyBvbiB0aGUgZHJhZnQgb2YgZHJh ZnQtbGl0a293c2tpLW5ldG1vZC1pc2lzLWNmZy0wMA0KDQpIaSwNCg0KVGhhbmtzIGZvciB0aGUg Y29tbWVudCwgcGxlYXNlIHVzZSB0aGUgbGFzdCB2ZXJzaW9uIG9mIHRoZSBkb2MgZm9yIHlvdXIg bmV4dCBjb21tZW50cyAoZHJhZnQtbGl0a293c2tpLWlzaXMteWFuZy1jZmcpLg0KUGxlYXNlIGZp bmQgaW5saW5lIGFuc3dlcnMuDQoNClN0ZXBoYW5lDQoNCkZyb206IG5ldG1vZCBbbWFpbHRvOm5l dG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSGFvd2VpZ3VvDQpTZW50OiBUaHVy c2RheSwgQXVndXN0IDA3LCAyMDE0IDA0OjI1DQpUbzogbmV0bW9kQGlldGYub3JnDQpTdWJqZWN0 OiBbbmV0bW9kXSBDb21tZW50cyBvbiB0aGUgZHJhZnQgb2YgZHJhZnQtbGl0a293c2tpLW5ldG1v ZC1pc2lzLWNmZy0wMA0KDQoNCkhpIENvLWF1dGhvcnMsDQoNCkFmdGVyIHJlYWRpbmcgdGhpcyBk cmFmdCwgaSBoYXZlIHRoZSBmb2xsb3dpbmcgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zLg0KDQoN Cg0KbW9kdWxlOiBpc2lzDQorLS1ydyBpc2lzLWNmZw0KfCArLS1ydyBpbnN0YW5jZXMNCnwgKy0t cncgaW5zdGFuY2UgW25hbWVdDQp8ICstLXJ3IG5hbWUNCnwgKy0tcncgZW5hYmxlZA0KfCArLS1y dyBpc2lzLWxldmVsDQp8ICstLXJ3IGFyZWENCnwgKy0tcncgc3lzdGVtLWlkDQp8ICstLXJ3IGlw djQtcm91dGVyLWlkDQoNCnwgKy0tcncgaXB2Ni1yb3V0ZXItaWQNCg0KDQoNClt3ZWlndW9dOiBJ IHRoaW5rIElTLUlTIHByb3RvY29sIGRvZXNuJ3QgdXNlIGlwdjQtcm91dGVyLWlkICBhbmQgIGlw djYtcm91dGVyLWlkICwgc28gaXQgaGFkIGJldHRlciBiZSByZW1vdmVkLg0KDQpbU0xJXSBXcm9u ZywgSVMtSVMgdXNlcyBJUHY0IGFuZC9vciBJUHY2IHJvdXRlci1pZHMuIElQdjQgcm91dGVyLWlk IGlzIFRMVjEzNCBhbmQgaXQgbXVzdCBiZSBjb25maWd1cmFibGUuDQoNClt3ZWlndW8yXTogaXB2 NC1yb3V0ZXItaWQgYW5kIGlwdjYtcm91dGVyLWlkICBhcmUgZm9yIFRFIHB1cnBvc2UsIGkgdGhp bmsgdGhlIHR3byBwYXJhcyBoYWQgYmV0dGVyIGJlIGNvbmZpZ3VyZWQgaW4gTVBMUyBURSBmZWF0 dXJlLCB0aGVuIFRFIG5vdGlmaWVzIElTLUlTIHByb3RvY29sIHRvIGFubm91bmNlIHRoZSBwYXJh IHRocm91Z2ggdGhlIFRMVjEzNC4NCg0KDQoNCistLXJ3IGlzaXMtYXV0aGVudGljYXRpb24tY2Zn DQorLS1ydyBwc25wLWF1dGhlbnRpY2F0aW9uDQorLS1ydyBjc25wLWF1dGhlbnRpY2F0aW9uDQor LS1ydyBoZWxsby1hdXRoZW50aWNhdGlvbg0KDQoNCg0KKy0tcncgaXNpcy1sZXZlbC0xLWNmZw0K Ky0tcncgZW5hYmxlZA0KKy0tcncgcHNucC1hdXRoZW50aWNhdGlvbg0KKy0tcncgY3NucC1hdXRo ZW50aWNhdGlvbg0KKy0tcncgaGVsbG8tYXV0aGVudGljYXRpb24NCg0KDQoNClt3ZWlndW9dOiBG b3IgdGhlIGFib3ZlIGF1dGhlbnRpY2F0aW9uIHJlbGF0ZWQgY29uZmlnLCBQU05QLWF1dGhlbnRp Y2F0aW9uIGFuZCBDU05QLWF1dGhlbnRpY2F0aW9uIGhhZCBiZXR0ZXIgbWVyZ2UgaW50byBzaW5n bGUgZG9tYWluLWF1dGhlbmNpYXRpb24sIGJlY2F1c2UgUFNOUCBhbmQgQ1NOUCBhdXRoZW50aWNh dGlvbiBjb25maWd1cmF0aW9uIHNob3VsZCBiZSBzYW1lLiBJZiB0d28gaW5kZXBlbmRhbnQgUFNO UC1hdXRoZW50aWNhdGlvbiBhbmQgQ1NOUC1hdXRoZW50aWNhdGlvbiBleGlzdCwgdGhlIG9wZXJh dG9ycyBjYW4gY29uZmlndXJlIGRpZmZlcmVudCBwYXJhIGZvciBQU05QIGFuZCBDU05QLCBjb25m bGljdGlvbiB3aWxsIG9jY3VyLg0KDQoNCg0KW1NMSV0gTW9zdCBvZiBpbXBsZW1lbnRhdGlvbnMg YWxyZWFkeSBwcm9wb3NlIHRvIHR1bmUgYXV0aGVudGljYXRpb24gaW4gdGhpcyB3YXkgoa0NCg0K W3dlaWd1bzJdOiBTb3JyeSwgaSBzaG91bGQgY29ycmVjdCBteSBmaXJzdCBjb21tZW50IGFzIGZv bGxvd2luZzoNCg0KIFRoZSBhdXRoZW50aWNhdGlvbiByZWxhdGVkIGNvbmZpZyBpbmNsdWRlcyBh cmVhLWF1dGhlbnRpY2F0aW9uLCBkb21haW4tYXV0aGVudGljYXRpb24gYW5kIGhlbGxvLWF1dGhl bnRpY2F0aW9uLCBwc25wLWF1dGhlbnRpY2F0aW9uIGFuZCBjc25wLWF1dGhlbnRpY2F0aW9uIG5h bWUgaGFkIGJldHRlciBiZSBtb2RpZmllZC4NCg0KDQoNClRoYW5rcw0KDQp3ZWlndW8NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmly IGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBk b2l2ZW50IGRvbmMNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMg YXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZl dWlsbGV6IGxlIHNpZ25hbGVyDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBx dWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBz dXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2Fi aWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1l cmNpLg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25m aWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQg YnkgbGF3Ow0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3 aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCg0K --_000_DD5FC8DE455C3348B94340C0AB5517334F7F10BBnkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi,

Pls see my reply inline with [weiguo2]= below.

Thanks

weiguo

=B7=A2=BC=FE=C8=CB: stephane.litkowski@ora= nge.com [stephane.litkowski@orange.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA8=D4=C27=C8=D5 16:25
=CA=D5=BC=FE=C8=CB: Haoweiguo; netmod@ietf.org
=D6=F7=CC=E2: RE: Comments on the draft of draft-litkowski-netmod-is= is-cfg-00

Hi,

 

Thanks for the comment, please use the las= t version of the doc for your next comments (draft-litkowski-isis-yang-cfg)= .

Please find inline answers.

 

Stephane

 

From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Haoweiguo
Sent: Thursday, August 07, 2014 04:25
To: netmod@ietf.org
Subject: [netmod] Comments on the draft of draft-litkowski-netmod-is= is-cfg-00

 

Hi Co-= authors,

After = reading this draft, i have the following comments and suggestions.

 

module= : isis
+--rw isis-cfg
| +--rw instances
| +--rw instance [name]
| +--rw name
| +--rw enabled
| +--rw isis-level
| +--rw area
| +--rw system-id
| +--rw ipv4-router-id

| += ;--rw ipv6-router-id 

 

[weiguo]= : I think IS-IS protocol doesn't use ipv4-router-id  and  ipv6-ro= uter-id , so it had better be removed.

[SLI] Wrong, IS-IS uses IPv4 and/or IPv6 router-ids. IPv4 route= r-id is TLV134 and it must be configurable. 

[weiguo2]: ipv4-router-id and ipv6-router-id  = are for TE purpose, i think the two paras had better be configured in = MPLS TE feature, then TE notifies IS-IS protocol to announce the para throu= gh the TLV134.

 

+-= -rw isis-authentication-cfg
+--rw psnp-authentication
+--rw csnp-authentication
+--rw hello-authentication

 

+-= -rw isis-level-1-cfg
+--rw enabled
+--rw psnp-authentication
+--rw csnp-authentication
+--rw hello-authentication

 

[weigu= o]: For the above authentication related config, PSNP-authentication and CS= NP-authentication had better merge into single domain-authenciation, becaus= e PSNP and CSNP authentication configuration should be same. If two independant PSNP-authentication and CSNP-authentica= tion exist, the operators can configure different para for PSNP and CSNP, c= onfliction will occur.

 

[SLI] Most of implementations already propose to tune authenti= cation in this way =A1=AD

[weiguo2]: Sorry, i should correct my first comment as followi= ng:

 The authentication related config includes area-authenti= cation, domain-authentication and hello-authentication, psnp-authentication= and csnp-authentication name had better be modified.

 

Thanks=

weiguo= 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_DD5FC8DE455C3348B94340C0AB5517334F7F10BBnkgeml501mbschi_-- From nobody Thu Aug 7 05: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 7D3471B2A74 for ; Thu, 7 Aug 2014 05:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 IJbDihmI9nkf for ; Thu, 7 Aug 2014 05:12:49 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB42E1B2A4D for ; Thu, 7 Aug 2014 05:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1513; q=dns/txt; s=iport; t=1407413568; x=1408623168; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=v0MkFvTaIW6nIFkY4MWktVvtDJYwYmVX5axHzkH7/EE=; b=MQO3LxgZQVgot0pXsl6eyJ8OkzSChTM2/QxQF4R35U1SDF4+hlcjl8sO gchJBrOC55/CznVrmQRd/opKqPFev3IjKWSYryUuspOC8T67cp40uHxvc wtLpRCwt01EhFIOXdPbk4GXfW2YFyxWdsrcqRYVN21LpN6ASoqpDcz9p4 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFACls41OtJA2J/2dsb2JhbABagmojgS3VKRZ3hAo6UQE+QicEiFUBnhmlaReUHgWcGJRtg1eCMg X-IronPort-AV: E=Sophos;i="5.01,817,1400025600"; d="scan'208";a="67275687" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP; 07 Aug 2014 12:12:48 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s77CCm6r023196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 7 Aug 2014 12:12:48 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Thu, 7 Aug 2014 07:12:48 -0500 From: "Clyde Wildes (cwildes)" To: "netmod@ietf.org" Thread-Topic: A Question On Modeling Redundant State Thread-Index: AQHPsjjm+90hHaH56E2upGCXAGQFuA== Date: Thu, 7 Aug 2014 12:12:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.27.7.178] Content-Type: text/plain; charset="us-ascii" Content-ID: <0C807B4299669E4F88E7D9C57CB9959B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/tf7dBNqUg6DrZRLuSxnEbqGwJwQ Subject: [netmod] A Question On Modeling Redundant State X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Aug 2014 12:12:54 -0000 Hi, We are modeling state data for a single component that maintains state on both the active and standby RP in a fully redundant configuration as well on line cards or other distributed nodes. We are thinking of standardizing the models so we appreciate feedback. Is it best to handle this by: a) using a list where each element in the list contains the state for each location container xyz-component-state { config false; description "This container describes component state for all locations for this network device."; list location { key "location-name"; description "This list describes a collection of component state for multiple locations in a distributed system. There would would be at least one entry called main and possibly others."; leaf location-name { type string; description "This leaf describes the name of the location containing operational state. Example: main, standby, line_card_1, etc."; } list neighbors { key "name"; leaf name { type string; description "This leaf describes the name of the neighbor."; } leaf address { type inet:ip-address; } leaf up-time { type inet:timestamp; } } } } b) the use of a location specific datastore source for a get operation c) some other means. Thanks, Clyde From nobody Thu Aug 7 07:29:52 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DAF1B2B7F for ; Thu, 7 Aug 2014 07:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 eDP8pvdF2Ft6 for ; Thu, 7 Aug 2014 07:29:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950361B2B7A for ; Thu, 7 Aug 2014 07:29:44 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 945222642CE; Thu, 7 Aug 2014 16:29:42 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 6FEB22380A2; Thu, 7 Aug 2014 16:29:42 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.132]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0181.006; Thu, 7 Aug 2014 16:29:42 +0200 From: To: Haoweiguo , "netmod@ietf.org" Thread-Topic: Comments on the draft of draft-litkowski-netmod-isis-cfg-00 Thread-Index: AQHPsiI4K1BLygSk8UqX1vKRMY7htZvFMENg Date: Thu, 7 Aug 2014 14:29:42 +0000 Message-ID: <7097_1407421782_53E38D56_7097_7700_1_9E32478DFA9976438E7A22F69B08FF92061763@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: , <17441_1407399904_53E337E0_17441_15495_1_9E32478DFA9976438E7A22F69B08FF920615BB@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92061763OPEXCLILM34corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.7.83920 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/lOBZ_XCvMFKJOuznKp431TD78CI Subject: Re: [netmod] Comments on the draft of draft-litkowski-netmod-isis-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Aug 2014 14:29:49 -0000 --_000_9E32478DFA9976438E7A22F69B08FF92061763OPEXCLILM34corpor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable module: isis +--rw isis-cfg | +--rw instances | +--rw instance [name] | +--rw name | +--rw enabled | +--rw isis-level | +--rw area | +--rw system-id | +--rw ipv4-router-id | +--rw ipv6-router-id [weiguo]: I think IS-IS protocol doesn't use ipv4-router-id and ipv6-rout= er-id , so it had better be removed. [SLI] Wrong, IS-IS uses IPv4 and/or IPv6 router-ids. IPv4 router-id is TLV1= 34 and it must be configurable. [weiguo2]: ipv4-router-id and ipv6-router-id are for TE purpose, i think t= he two paras had better be configured in MPLS TE feature, then TE notifies = IS-IS protocol to announce the para through the TLV134. [SLI2] Even if router-ids where defined for TE purpose, they have now usage= outside TE application and so configuration of router IDs is necessary eve= n in non TE deployment. +--rw isis-authentication-cfg +--rw psnp-authentication +--rw csnp-authentication +--rw hello-authentication +--rw isis-level-1-cfg +--rw enabled +--rw psnp-authentication +--rw csnp-authentication +--rw hello-authentication [weiguo]: For the above authentication related config, PSNP-authentication = and CSNP-authentication had better merge into single domain-authenciation, = because PSNP and CSNP authentication configuration should be same. If two i= ndependant PSNP-authentication and CSNP-authentication exist, the operators= can configure different para for PSNP and CSNP, confliction will occur. [SLI] Most of implementations already propose to tune authentication in thi= s way ... [weiguo2]: Sorry, i should correct my first comment as following: The authentication related config includes area-authentication, domain-aut= hentication and hello-authentication, psnp-authentication and csnp-authenti= cation name had better be modified. [SLI2] Hmmm ... that's a different way (Cisco way :) ) to view things ... F= rom a protocol point of view, control of authentication is at PDU level. Ea= ch PDU may or not use authentication. Thanks weiguo ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_9E32478DFA9976438E7A22F69B08FF92061763OPEXCLILM34corpor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

module: isis
+--rw isis-cfg
| +--rw instances
| +--rw instance [name]
| +--rw name
| +--rw enabled
| +--rw isis-level
| +--rw area
| +--rw system-id
| +--rw ipv4-router-id

| +--rw ipv6-router-id 

 

[weiguo]: I think IS-IS protocol doesn't use ipv4-router-id = ; and  ipv6-router-id , so it had better be removed.

[SLI] Wrong, IS-IS uses IPv4 and/or IPv6 route= r-ids. IPv4 router-id is TLV134 and it must be configurable. 

[weiguo2]: ipv4-router-id and ipv6-router-id  are for TE purpose, = i think the two paras had better be configured in MPLS TE feature, the= n TE notifies IS-IS protocol to announce the para through the TLV134.<= /o:p>

[SLI2] Even if router-ids where defined for T= E purpose, they have now usage outside TE application and so configuration = of router IDs is necessary even in non TE deployment.

 

 

+--rw isis-authentication-cfg
+--rw psnp-authentication
+--rw csnp-authentication
+--rw hello-authentication

 

+--rw isis-level-1-cfg
+--rw enabled
+--rw psnp-authentication
+--rw csnp-authentication
+--rw hello-authentication

 

[weiguo]: For the above authentication related config, PSNP-auth= entication and CSNP-authentication had better merge into single domain-auth= enciation, because PSNP and CSNP authentication configuration should be same. If two independant PSNP-authentication and CSNP-authentica= tion exist, the operators can configure different para for PSNP and CSNP, c= onfliction will occur.

 

[SLI] Most of implementations already propose= to tune authentication in this way …

[weiguo2]: Sorry, i should correct my first c= omment as following:

 The authentication related config inclu= des area-authentication, domain-authentication and hello-authentication, ps= np-authentication and csnp-authentication name had better be modified.

[SLI2] Hmmm … that’s a different = way (Cisco way J ) to view things … From a protoc= ol point of view, control of authentication is at PDU level. Each PDU may or not use authentication.

 

 

 

Thanks

weiguo

__________________________________________=
___________________________________________________________________________=
____
 
Ce message et ses pieces jointes peuvent c=
ontenir des informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies san=
s autorisation. Si vous avez recu ce message par erreur, veuillez le signal=
er
a l'expediteur et le detruire ainsi que le=
s pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n,
Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may conta=
in confidential or privileged information that may be protected by law;
they should not be distributed, used or co=
pied without authorisation.
If you have received this email in error, =
please notify the sender and delete this message and its attachments.<=
/o:p>
As emails may be altered, Orange is not li=
able for messages that have been modified, changed or falsified.=

Thank you.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_9E32478DFA9976438E7A22F69B08FF92061763OPEXCLILM34corpor_-- From nobody Thu Aug 7 09:35: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 C144A1B2CAD for ; Thu, 7 Aug 2014 09:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 6AjyzncF2ahu for ; Thu, 7 Aug 2014 09:35:05 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 296F21B2851 for ; Thu, 7 Aug 2014 09:35:05 -0700 (PDT) Received: from localhost (2.68.155.131.mobile.tre.se [2.68.155.131]) by mail.tail-f.com (Postfix) with ESMTPSA id 2D2AC1280987; Thu, 7 Aug 2014 18:33:56 +0200 (CEST) Date: Thu, 07 Aug 2014 18:34:50 +0200 (CEST) Message-Id: <20140807.183450.202596243.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140807083419.GA80765@elstar.local> References: <971D4B790EC8B846BE223DD23AF72FF11EB805EA@ESESSMB103.ericsson.se> <20140807083419.GA80765@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=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-Qx7xOvPUitBqgTJg1aMamjbsFM Cc: netmod@ietf.org Subject: Re: [netmod] Y09: introduce optional keys Y09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Aug 2014 16:35:08 -0000 Juergen Schoenwaelder wrote: > Hi, > = > this was discussed during the 2014-07-02 virtual interim meeting and > Martin took an action item to write up a solution proposal (see the > virtual interim meeting minutes). If you want to help Martin with > this, please go ahead and coordinate with him. I took an action to do a proposal for optional keys. I do not agree with the new issue of having key-less ordered-by user lists, so I won't cover that part in my proposal. /martin > = > /js > = > On Tue, Aug 05, 2014 at 11:58:33PM +0000, Bal=E1zs Lengyel wrote: > > Hello, > > So before we go into the interim, I think we should consider this > > issue as well. As Lada and Andy wrote in some cases there is no nee= d > > for a key. We already allow this for config false lists. > > = > > I support what Andy wrote: > > "YANG 1.1 should allow user-ordered lists and leaf-lists to be keye= d > > by the sibling order, and not require any keys." > > = > > Naturally this would mean that the rules for the > > operation and especially the insert before/after have to be defined= > > for the keyless case, but IMHO that's business as usual. > > regards Balazs > > = > > On 2014-07-08 16:54, Ladislav Lhotka wrote: > > > Andy Bierman writes: > > > > > >> On Thu, Jul 3, 2014 at 6:50 AM, Balazs Lengyel > > >> > > >> wrote: > > >> > > >>> 1) Non-Unique leaf-list: YANG shall allow leaf-lists whose memb= ers are > > >>> not > > >>> unique. > > >>> They are needed in a number of cases especially for user-ordere= d > > >>> lists, > > >>> where the position is stable and carries a meaning. > > >>> > > >> I actually like this one, but I think this is a more general pro= blem > > >> which has been raised before, but should be reconsidered. > > >> > > >> Perhaps YANG 1.1 should allow user-ordered lists and leaf-lists = to be > > >> keyed > > >> by > > >> the sibling order, and not require any keys. That would solve y= our > > >> problem. > > >> It actually shows up in the example-jukebox "playlist" in RESTCO= NF. > > >> This is a list instead of a leaf-list just so a dummy key can be= > > >> defined, > > >> just so duplicates can be allowed in the playlist. > > >> > > >> > > >> YANG 1.0: > > >> > > >> list song { > > >> key index; > > >> ordered-by user; > > >> > > >> description > > >> "Example nested configuration data resource"; > > >> > > >> leaf index { // not really needed > > >> type uint32; > > >> description > > >> "An arbitrary integer index for this playlist song= ."; // > > >> <<<<< Yuch!!! > > >> } > > >> leaf id { > > >> type rc:data-resource-identifier; > > >> mandatory true; > > >> description > > >> "Song identifier. Must identify an instance of > > >> /jukebox/library/artist/album/song/name."; > > >> } > > >> } > > >> > > >> > > >> Maybe YANG 1.1: > > >> > > >> > > >> leaf-list song { > > >> ordered-by user; > > >> type rc:data-resource-identifier; > > >> description > > >> "Song identifier. Must identify an instance of > > >> /jukebox/library/artist/album/song/name."; > > >> } > > >> > > >> IMO this is a lot cleaner (You are right Balazs) > > > Yes, I'd support this. There are other use cases such as AS-Path = that > > > may contain the same AS number repeatedly. > > > > > >> There would need to be a way in NETCONF to insert and delete by > > >> position > > >> instead of keys > > >> or leaf-list value. (e.g add position=3D"N" attribute in YANG 1.= 1 to go > > >> with > > >> the "insert" > > >> and nc:operation=3D"delete" attributes). > > > Maybe it's time to move this from YANG to NETCONF spec where it r= eally > > > belongs? > > > > > > Lada > > > > > >> > > >> > > >> > > >> > > >>> regards Balazs > > >> > > >> > > >> > > >> Andy > > >> _______________________________________________ > > >> netmod mailing list > > >> netmod@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netmod > > = > > -- > > Balazs Lengyel Ericsson Hungary Ltd. > > Senior Specialist > > ECN: 831 7320 Tel: +36-1-437-7320 > > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > = > = > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > = > = > -- = > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > = > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > = From nobody Thu Aug 7 11:08: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 58E091A0347 for ; Thu, 7 Aug 2014 11:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 fBHOgGTYO9sW for ; Thu, 7 Aug 2014 11:08:06 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id B3A631A034B for ; Thu, 7 Aug 2014 11:08:05 -0700 (PDT) Received: from localhost (host-90-236-248-99.mobileonline.telia.com [90.236.248.99]) by mail.tail-f.com (Postfix) with ESMTPSA id 9B9E61280987 for ; Thu, 7 Aug 2014 20:06:56 +0200 (CEST) Date: Thu, 07 Aug 2014 20:07:57 +0200 (CEST) Message-Id: <20140807.200757.441533667.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/X2Z9_G62Pd1l6wGc7phNKbyfSPo Subject: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Aug 2014 18:08:11 -0000 Hi, Here is a proposal for how to introduce optional keys. In summary, we allow a key leaf to be marked as "mandatory false", and also allow such a leaf to have a default value. All key leafs can be optional, but a list instance MUST have at least one of the key leafs instantiated, in order to be able to uniquely identify each instance. The combination of all given keys MUST be unique. For example, with the list: list foo { key "a b"; leaf a { type string; mandatory false; } leaf b { type string; mandatory false; } } We might have: hi hi hi mom One way of viewing this is that if a list instance does not have a certain key instantiated, its value is NULL (or its defualt). So in the example above we have the tree instances: ("hi", NULL) (NULL, "hi") ("hi", "mom") ------ In order to allow this, the following changes need to be done. In section 7.6.5, The leaf's mandatory Statement: OLD: The "mandatory" statement, which is optional, takes as an argument the string "true" or "false", and puts a constraint on valid data. If not specified, the default is "false". If "mandatory" is "true", the behavior of the constraint depends on the type of the leaf's closest ancestor node in the schema tree that is not a non-presence container (see Section 7.5.1): NEW: The "mandatory" statement, which is optional, takes as an argument the string "true" or "false", and puts a constraint on valid data. If not specified, the default is "false" for leafs that are not list keys, and "true" for leafs that are list keys. For leafs that are not list keys, if "mandatory" is "true", the behavior of the constraint depends on the type of the leaf's closest ancestor node in the schema tree that is not a non-presence container (see Section 7.5.1): And add NEW: For a leaf that is a list key, if "mandatory" is "true", the leaf MUST exist in a list instance. In section 7.8.2. The list's key Statement: OLD: The combined values of all the leafs specified in the key are used to uniquely identify a list entry. All key leafs MUST be given values when a list entry is created. Thus, any default values in the key leafs or their types are ignored. It also implies that any mandatory statement in the key leafs are ignored. A leaf that is part of the key can be of any built-in or derived type, except it MUST NOT be the built-in type "empty". NEW: The combined values of all the leaf instances specified in the key, including leafs with default values, are used to uniquely identify a list entry. All key leafs that are marked as mandatory MUST be given values when a list entry is created. A list instance MUST have at least one key leaf instantiated. A leaf that is part of the key can be of any built-in or derived type. In section 7.8.3.1. Usage Example: Add this: With the following list: list target { key "ip vrf"; leaf ip { type inet:ip-address; } leaf vrf { type string; } ... } the following configuration is valid: 192.0.2.1 192.0.2.1 vrf-2 In section 7.8.6. NETCONF Operations: OLD: List entries can be created, deleted, replaced, and modified through , by using the "operation" attribute in the list's XML element. In each case, the values of all keys are used to uniquely identify a list entry. If all keys are not specified for a list entry, a "missing-element" error is returned. NEW: List entries can be created, deleted, replaced, and modified through , by using the "operation" attribute in the list's XML element. In each case, the values of all instantiated keys are used to uniquely identify a list entry. If a mandatory key is not specified for a list entry, a "missing-element" error is returned. In secrion 9.13. The instance-identifier Built-In Type: OLD: For identifying list entries with keys, each predicate consists of one equality test per key, and each key MUST have a corresponding predicate. NEW: For identifying list entries with keys, each predicate consists of one equality test per existing key leaf. /martin From nobody Thu Aug 7 11:35: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 783E31A0240 for ; Thu, 7 Aug 2014 11:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-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 9AJcfXj08k4E for ; Thu, 7 Aug 2014 11:35:26 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965291A03CD for ; Thu, 7 Aug 2014 11:35:22 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2BBB3132C; Thu, 7 Aug 2014 20:35:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id z-pURob6fwJz; Thu, 7 Aug 2014 20:35:02 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 7 Aug 2014 20:35:19 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D5B652002C; Thu, 7 Aug 2014 20:35:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GeVW5YbGzyU5; Thu, 7 Aug 2014 20:35:17 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE60820017; Thu, 7 Aug 2014 20:35:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EBC432E046E3; Thu, 7 Aug 2014 20:35:14 +0200 (CEST) Date: Thu, 7 Aug 2014 20:35:14 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140807183514.GA81733@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20140807.200757.441533667.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140807.200757.441533667.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/J2IYjRwNGI2Zg6vaHnhqde37fpU Cc: netmod@ietf.org Subject: Re: [netmod] Y09 introduce optional keys 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, 07 Aug 2014 18:35:28 -0000 Martin, can you update Y09-01 in the issues list with this more detailed proposal? (Or add Y09-02 if you think this is different from what Y09-01 says today.) Thanks, /js On Thu, Aug 07, 2014 at 08:07:57PM +0200, Martin Bjorklund wrote: > Hi, > > Here is a proposal for how to introduce optional keys. > > In summary, we allow a key leaf to be marked as "mandatory false", and > also allow such a leaf to have a default value. All key leafs can be > optional, but a list instance MUST have at least one of the key leafs > instantiated, in order to be able to uniquely identify each instance. > The combination of all given keys MUST be unique. > > For example, with the list: > > list foo { > key "a b"; > leaf a { > type string; > mandatory false; > } > leaf b { > type string; > mandatory false; > } > } > > We might have: > > > hi > > > hi > > > hi > mom > > > One way of viewing this is that if a list instance does not have a > certain key instantiated, its value is NULL (or its defualt). So in > the example above we have the tree instances: > > ("hi", NULL) > (NULL, "hi") > ("hi", "mom") > > ------ > > In order to allow this, the following changes need to be done. > > > In section 7.6.5, The leaf's mandatory Statement: > > OLD: > > The "mandatory" statement, which is optional, takes as an argument > the string "true" or "false", and puts a constraint on valid data. > If not specified, the default is "false". > > If "mandatory" is "true", the behavior of the constraint depends on > the type of the leaf's closest ancestor node in the schema tree that > is not a non-presence container (see Section 7.5.1): > > NEW: > > The "mandatory" statement, which is optional, takes as an argument > the string "true" or "false", and puts a constraint on valid data. > If not specified, the default is "false" for leafs that are not > list keys, and "true" for leafs that are list keys. > > For leafs that are not list keys, if "mandatory" is "true", the > behavior of the constraint depends on the type of the leaf's > closest ancestor node in the schema tree that is not a non-presence > container (see Section 7.5.1): > > > And add NEW: > > For a leaf that is a list key, if "mandatory" is "true", the leaf > MUST exist in a list instance. > > > > In section 7.8.2. The list's key Statement: > > OLD: > > The combined values of all the leafs specified in the key are used to > uniquely identify a list entry. All key leafs MUST be given values > when a list entry is created. Thus, any default values in the key > leafs or their types are ignored. It also implies that any mandatory > statement in the key leafs are ignored. > > A leaf that is part of the key can be of any built-in or derived > type, except it MUST NOT be the built-in type "empty". > > NEW: > > The combined values of all the leaf instances specified in the key, > including leafs with default values, are used to uniquely identify > a list entry. All key leafs that are marked as mandatory MUST be > given values when a list entry is created. A list instance MUST > have at least one key leaf instantiated. > > A leaf that is part of the key can be of any built-in or derived > type. > > > > In section 7.8.3.1. Usage Example: > > Add this: > > With the following list: > > list target { > key "ip vrf"; > leaf ip { > type inet:ip-address; > } > leaf vrf { > type string; > } > ... > } > > the following configuration is valid: > > > 192.0.2.1 > > > 192.0.2.1 > vrf-2 > > > > > In section 7.8.6. NETCONF Operations: > > OLD: > > List entries can be created, deleted, replaced, and modified through > , by using the "operation" attribute in the list's XML > element. In each case, the values of all keys are used to uniquely > identify a list entry. If all keys are not specified for a list > entry, a "missing-element" error is returned. > > NEW: > > List entries can be created, deleted, replaced, and modified through > , by using the "operation" attribute in the list's XML > element. In each case, the values of all instantiated keys are > used to uniquely identify a list entry. If a mandatory key is not > specified for a list entry, a "missing-element" error is returned. > > > In secrion 9.13. The instance-identifier Built-In Type: > > OLD: > > For > identifying list entries with keys, each predicate consists of one > equality test per key, and each key MUST have a corresponding > predicate. > > NEW: > > For > identifying list entries with keys, each predicate consists of one > equality test per existing key leaf. > > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Aug 7 11:43: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 CF86E1A039C for ; Thu, 7 Aug 2014 11:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 SqHbazhUpcNs for ; Thu, 7 Aug 2014 11:43:28 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5671A03BC for ; Thu, 7 Aug 2014 11:43:28 -0700 (PDT) Received: from localhost (host-90-236-248-99.mobileonline.telia.com [90.236.248.99]) by mail.tail-f.com (Postfix) with ESMTPSA id 841D41280ABD; Thu, 7 Aug 2014 20:42:23 +0200 (CEST) Date: Thu, 07 Aug 2014 20:43:24 +0200 (CEST) Message-Id: <20140807.204324.386343166.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140807183514.GA81733@elstar.local> References: <20140807.200757.441533667.mbj@tail-f.com> <20140807183514.GA81733@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/pGgegecTUIYy_6FOS0F8hb1272o Cc: netmod@ietf.org Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Aug 2014 18:43:30 -0000 Juergen Schoenwaelder wrote: > Martin, > > can you update Y09-01 in the issues list with this more detailed > proposal? (Or add Y09-02 if you think this is different from what > Y09-01 says today.) Done. /martin From nobody Thu Aug 7 22:56: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 1F4871A02DE for ; Thu, 7 Aug 2014 22:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-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 d0DFgCMnKXcI for ; Thu, 7 Aug 2014 22:56:31 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 911601A02DD for ; Thu, 7 Aug 2014 22:56:31 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3492110E0; Fri, 8 Aug 2014 07:56:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id NR4TM8-hCRmL; Fri, 8 Aug 2014 07:56:28 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 8 Aug 2014 07:56:28 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 982C42002C; Fri, 8 Aug 2014 07:56:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BUx-uD3vj8xO; Fri, 8 Aug 2014 07:56:27 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B16C20017; Fri, 8 Aug 2014 07:56:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9296A2E048F5; Fri, 8 Aug 2014 07:56:25 +0200 (CEST) Date: Fri, 8 Aug 2014 07:56:25 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140808055625.GA82640@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20140807.200757.441533667.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140807.200757.441533667.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2Jmc1owiyibmx95ziDdGvjRJwCA Cc: netmod@ietf.org Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 05:56:34 -0000 Martin, two quick questions/comments: a) Is it allowed to add an optional key while revising a YANG module? b) It seems to be not possible to augmentation an optional key (e.g. a VRF) since this would require to replace the 'key' statement. (In hindsight, perhaps it would have been better to mark the leafs that form the key instead of listing them in a key statement.) /js On Thu, Aug 07, 2014 at 08:07:57PM +0200, Martin Bjorklund wrote: > Hi, > > Here is a proposal for how to introduce optional keys. > > In summary, we allow a key leaf to be marked as "mandatory false", and > also allow such a leaf to have a default value. All key leafs can be > optional, but a list instance MUST have at least one of the key leafs > instantiated, in order to be able to uniquely identify each instance. > The combination of all given keys MUST be unique. > > For example, with the list: > > list foo { > key "a b"; > leaf a { > type string; > mandatory false; > } > leaf b { > type string; > mandatory false; > } > } > > We might have: > > > hi > > > hi > > > hi > mom > > > One way of viewing this is that if a list instance does not have a > certain key instantiated, its value is NULL (or its defualt). So in > the example above we have the tree instances: > > ("hi", NULL) > (NULL, "hi") > ("hi", "mom") > > ------ > > In order to allow this, the following changes need to be done. > > > In section 7.6.5, The leaf's mandatory Statement: > > OLD: > > The "mandatory" statement, which is optional, takes as an argument > the string "true" or "false", and puts a constraint on valid data. > If not specified, the default is "false". > > If "mandatory" is "true", the behavior of the constraint depends on > the type of the leaf's closest ancestor node in the schema tree that > is not a non-presence container (see Section 7.5.1): > > NEW: > > The "mandatory" statement, which is optional, takes as an argument > the string "true" or "false", and puts a constraint on valid data. > If not specified, the default is "false" for leafs that are not > list keys, and "true" for leafs that are list keys. > > For leafs that are not list keys, if "mandatory" is "true", the > behavior of the constraint depends on the type of the leaf's > closest ancestor node in the schema tree that is not a non-presence > container (see Section 7.5.1): > > > And add NEW: > > For a leaf that is a list key, if "mandatory" is "true", the leaf > MUST exist in a list instance. > > > > In section 7.8.2. The list's key Statement: > > OLD: > > The combined values of all the leafs specified in the key are used to > uniquely identify a list entry. All key leafs MUST be given values > when a list entry is created. Thus, any default values in the key > leafs or their types are ignored. It also implies that any mandatory > statement in the key leafs are ignored. > > A leaf that is part of the key can be of any built-in or derived > type, except it MUST NOT be the built-in type "empty". > > NEW: > > The combined values of all the leaf instances specified in the key, > including leafs with default values, are used to uniquely identify > a list entry. All key leafs that are marked as mandatory MUST be > given values when a list entry is created. A list instance MUST > have at least one key leaf instantiated. > > A leaf that is part of the key can be of any built-in or derived > type. > > > > In section 7.8.3.1. Usage Example: > > Add this: > > With the following list: > > list target { > key "ip vrf"; > leaf ip { > type inet:ip-address; > } > leaf vrf { > type string; > } > ... > } > > the following configuration is valid: > > > 192.0.2.1 > > > 192.0.2.1 > vrf-2 > > > > > In section 7.8.6. NETCONF Operations: > > OLD: > > List entries can be created, deleted, replaced, and modified through > , by using the "operation" attribute in the list's XML > element. In each case, the values of all keys are used to uniquely > identify a list entry. If all keys are not specified for a list > entry, a "missing-element" error is returned. > > NEW: > > List entries can be created, deleted, replaced, and modified through > , by using the "operation" attribute in the list's XML > element. In each case, the values of all instantiated keys are > used to uniquely identify a list entry. If a mandatory key is not > specified for a list entry, a "missing-element" error is returned. > > > In secrion 9.13. The instance-identifier Built-In Type: > > OLD: > > For > identifying list entries with keys, each predicate consists of one > equality test per key, and each key MUST have a corresponding > predicate. > > NEW: > > For > identifying list entries with keys, each predicate consists of one > equality test per existing key leaf. > > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Aug 7 22:57: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 8D0BA1A02E4 for ; Thu, 7 Aug 2014 22:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.749 X-Spam-Level: * X-Spam-Status: No, score=1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 tkLQC3iAG5fb for ; Thu, 7 Aug 2014 22:57:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C89D1A02DD for ; Thu, 7 Aug 2014 22:57:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLA09632; Fri, 08 Aug 2014 05:57:44 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Aug 2014 06:57:43 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.209]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 8 Aug 2014 13:57:37 +0800 From: Haoweiguo To: "stephane.litkowski@orange.com" , "netmod@ietf.org" Thread-Topic: Comments on the draft of draft-litkowski-netmod-isis-cfg-00 Thread-Index: Ac+x5EadHpMfisBeQumh8ccdDAowQgANG+awAAIN74X//9AVAIABiBqr Date: Fri, 8 Aug 2014 05:57:37 +0000 Message-ID: References: , <17441_1407399904_53E337E0_17441_15495_1_9E32478DFA9976438E7A22F69B08FF920615BB@OPEXCLILM34.corporate.adroot.infra.ftgroup> , <7097_1407421782_53E38D56_7097_7700_1_9E32478DFA9976438E7A22F69B08FF92061763@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <7097_1407421782_53E38D56_7097_7700_1_9E32478DFA9976438E7A22F69B08FF92061763@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB5517334F7F1248nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rsLHL7OKS3__n6cAsX30PFGkZr4 Subject: [netmod] =?gb2312?b?tPC4tDogQ29tbWVudHMgb24gdGhlIGRyYWZ0IG9mIGRy?= =?gb2312?b?YWZ0LWxpdGtvd3NraS1uZXRtb2QtaXNpcy1jZmctMDA=?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Aug 2014 05:57:53 -0000 --_000_DD5FC8DE455C3348B94340C0AB5517334F7F1248nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IHN0ZXBoYW5lLmxp dGtvd3NraUBvcmFuZ2UuY29tIFtzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbV0NCreiy83K sbzkOiAyMDE0xOo41MI3yNUgMjI6MjkNCsrVvP7IyzogSGFvd2VpZ3VvOyBuZXRtb2RAaWV0Zi5v cmcNCtb3zOI6IFJFOiBDb21tZW50cyBvbiB0aGUgZHJhZnQgb2YgZHJhZnQtbGl0a293c2tpLW5l dG1vZC1pc2lzLWNmZy0wMA0KDQoNCm1vZHVsZTogaXNpcw0KKy0tcncgaXNpcy1jZmcNCnwgKy0t cncgaW5zdGFuY2VzDQp8ICstLXJ3IGluc3RhbmNlIFtuYW1lXQ0KfCArLS1ydyBuYW1lDQp8ICst LXJ3IGVuYWJsZWQNCnwgKy0tcncgaXNpcy1sZXZlbA0KfCArLS1ydyBhcmVhDQp8ICstLXJ3IHN5 c3RlbS1pZA0KfCArLS1ydyBpcHY0LXJvdXRlci1pZA0KDQp8ICstLXJ3IGlwdjYtcm91dGVyLWlk DQoNCg0KDQpbd2VpZ3VvXTogSSB0aGluayBJUy1JUyBwcm90b2NvbCBkb2Vzbid0IHVzZSBpcHY0 LXJvdXRlci1pZCAgYW5kICBpcHY2LXJvdXRlci1pZCAsIHNvIGl0IGhhZCBiZXR0ZXIgYmUgcmVt b3ZlZC4NCg0KW1NMSV0gV3JvbmcsIElTLUlTIHVzZXMgSVB2NCBhbmQvb3IgSVB2NiByb3V0ZXIt aWRzLiBJUHY0IHJvdXRlci1pZCBpcyBUTFYxMzQgYW5kIGl0IG11c3QgYmUgY29uZmlndXJhYmxl Lg0KDQpbd2VpZ3VvMl06IGlwdjQtcm91dGVyLWlkIGFuZCBpcHY2LXJvdXRlci1pZCAgYXJlIGZv ciBURSBwdXJwb3NlLCBpIHRoaW5rIHRoZSB0d28gcGFyYXMgaGFkIGJldHRlciBiZSBjb25maWd1 cmVkIGluIE1QTFMgVEUgZmVhdHVyZSwgdGhlbiBURSBub3RpZmllcyBJUy1JUyBwcm90b2NvbCB0 byBhbm5vdW5jZSB0aGUgcGFyYSB0aHJvdWdoIHRoZSBUTFYxMzQuDQoNCltTTEkyXSBFdmVuIGlm IHJvdXRlci1pZHMgd2hlcmUgZGVmaW5lZCBmb3IgVEUgcHVycG9zZSwgdGhleSBoYXZlIG5vdyB1 c2FnZSBvdXRzaWRlIFRFIGFwcGxpY2F0aW9uIGFuZCBzbyBjb25maWd1cmF0aW9uIG9mIHJvdXRl ciBJRHMgaXMgbmVjZXNzYXJ5IGV2ZW4gaW4gbm9uIFRFIGRlcGxveW1lbnQuDQoNClt3ZWlndW8z XTogSU1PLCBJZiB0aGUgcm91dGVyLWlkcyBhcmUgdXNlZCBmb3Igb3RoZXIgYXBwbGljYXRpb25z LCAgdGhlIGNvbmZpZ3VhdGlvbiBvZiByb3V0ZXIgSURzIGhhZCBiZXR0ZXIgYmUgY29uZmlndXJl ZCBpbiB0aGVzZSBhcHBsaWNhdGlvbnMgcmF0aGVyIHRoYW4gaW4gSVMtSVMuDQoNCg0KDQorLS1y dyBpc2lzLWF1dGhlbnRpY2F0aW9uLWNmZw0KKy0tcncgcHNucC1hdXRoZW50aWNhdGlvbg0KKy0t cncgY3NucC1hdXRoZW50aWNhdGlvbg0KKy0tcncgaGVsbG8tYXV0aGVudGljYXRpb24NCg0KDQoN CistLXJ3IGlzaXMtbGV2ZWwtMS1jZmcNCistLXJ3IGVuYWJsZWQNCistLXJ3IHBzbnAtYXV0aGVu dGljYXRpb24NCistLXJ3IGNzbnAtYXV0aGVudGljYXRpb24NCistLXJ3IGhlbGxvLWF1dGhlbnRp Y2F0aW9uDQoNCg0KDQpbd2VpZ3VvXTogRm9yIHRoZSBhYm92ZSBhdXRoZW50aWNhdGlvbiByZWxh dGVkIGNvbmZpZywgUFNOUC1hdXRoZW50aWNhdGlvbiBhbmQgQ1NOUC1hdXRoZW50aWNhdGlvbiBo YWQgYmV0dGVyIG1lcmdlIGludG8gc2luZ2xlIGRvbWFpbi1hdXRoZW5jaWF0aW9uLCBiZWNhdXNl IFBTTlAgYW5kIENTTlAgYXV0aGVudGljYXRpb24gY29uZmlndXJhdGlvbiBzaG91bGQgYmUgc2Ft ZS4gSWYgdHdvIGluZGVwZW5kYW50IFBTTlAtYXV0aGVudGljYXRpb24gYW5kIENTTlAtYXV0aGVu dGljYXRpb24gZXhpc3QsIHRoZSBvcGVyYXRvcnMgY2FuIGNvbmZpZ3VyZSBkaWZmZXJlbnQgcGFy YSBmb3IgUFNOUCBhbmQgQ1NOUCwgY29uZmxpY3Rpb24gd2lsbCBvY2N1ci4NCg0KDQoNCltTTEld IE1vc3Qgb2YgaW1wbGVtZW50YXRpb25zIGFscmVhZHkgcHJvcG9zZSB0byB0dW5lIGF1dGhlbnRp Y2F0aW9uIGluIHRoaXMgd2F5IKGtDQoNClt3ZWlndW8yXTogU29ycnksIGkgc2hvdWxkIGNvcnJl Y3QgbXkgZmlyc3QgY29tbWVudCBhcyBmb2xsb3dpbmc6DQoNCiBUaGUgYXV0aGVudGljYXRpb24g cmVsYXRlZCBjb25maWcgaW5jbHVkZXMgYXJlYS1hdXRoZW50aWNhdGlvbiwgZG9tYWluLWF1dGhl bnRpY2F0aW9uIGFuZCBoZWxsby1hdXRoZW50aWNhdGlvbiwgcHNucC1hdXRoZW50aWNhdGlvbiBh bmQgY3NucC1hdXRoZW50aWNhdGlvbiBuYW1lIGhhZCBiZXR0ZXIgYmUgbW9kaWZpZWQuDQoNCltT TEkyXSBIbW1tIKGtIHRoYXShr3MgYSBkaWZmZXJlbnQgd2F5IChDaXNjbyB3YXkgOikgKSB0byB2 aWV3IHRoaW5ncyChrSBGcm9tIGEgcHJvdG9jb2wgcG9pbnQgb2YgdmlldywgY29udHJvbCBvZiBh dXRoZW50aWNhdGlvbiBpcyBhdCBQRFUgbGV2ZWwuIEVhY2ggUERVIG1heSBvciBub3QgdXNlIGF1 dGhlbnRpY2F0aW9uLg0KDQoNCg0KDQoNCg0KDQpUaGFua3MNCg0Kd2VpZ3VvDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIg ZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRv aXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2 ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5z aSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFu dCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNw b25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZp ZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQg b3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN CkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGlu Zm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQg ZG9uYw0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlz YXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXog bGUgc2lnbmFsZXINCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMg cGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRp YmxlcyBkJ2FsdGVyYXRpb24sDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBz aSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoN ClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7 DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg YXV0aG9yaXNhdGlvbi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzLg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxp YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs c2lmaWVkLg0KVGhhbmsgeW91Lg0KDQo= --_000_DD5FC8DE455C3348B94340C0AB5517334F7F1248nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

 

=B7=A2=BC=FE=C8=CB: stephane.litkowski@ora= nge.com [stephane.litkowski@orange.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA8=D4=C27=C8=D5 22:29
=CA=D5=BC=FE=C8=CB: Haoweiguo; netmod@ietf.org
=D6=F7=CC=E2: RE: Comments on the draft of draft-litkowski-netmod-is= is-cfg-00

module= : isis
+--rw isis-cfg
| +--rw instances
| +--rw instance [name]
| +--rw name
| +--rw enabled
| +--rw isis-level
| +--rw area
| +--rw system-id
| +--rw ipv4-router-id

| += ;--rw ipv6-router-id 

 

[weigu= o]: I think IS-IS protocol doesn't use ipv4-router-id  and  ipv6-= router-id , so it had better be removed.

[SLI] Wrong, IS-IS uses IPv4 and/or IPv6 router-ids. IPv4 route= r-id is TLV134 and it must be configurable. 

[weiguo2]: ip= v4-router-id and ipv6-router-id  are for TE purpose, i think the = two paras had better be configured in MPLS TE feature, then TE notifies IS-= IS protocol to announce the para through the TLV134.

[SLI2] Even if router-ids where defined for TE purpose, they h= ave now usage outside TE application and so configuration of router IDs is = necessary even in non TE deployment.

[weiguo3]: IMO, If the router-ids are used for other appl= ications,  the configuation of router IDs had better be configured in = these applications rather than in IS-IS.

 

+-= -rw isis-authentication-cfg
+--rw psnp-authentication
+--rw csnp-authentication
+--rw hello-authentication

 

+-= -rw isis-level-1-cfg
+--rw enabled
+--rw psnp-authentication
+--rw csnp-authentication
+--rw hello-authentication

 

[weigu= o]: For the above authentication related config, PSNP-authentication and CS= NP-authentication had better merge into single domain-authenciation, becaus= e PSNP and CSNP authentication configuration should be same. If two independant PSNP-authentication and CSNP-authentica= tion exist, the operators can configure different para for PSNP and CSNP, c= onfliction will occur.

 

[SLI] Most of implementations already propose to tune authenti= cation in this way =A1=AD

[weiguo2]: Sorry, i should correct my first comment as followi= ng:

 The authentication related config includes area-authenti= cation, domain-authentication and hello-authentication, psnp-authentication= and csnp-authentication name had better be modified.

[SLI2] Hmmm =A1=AD that=A1=AFs a different way (Cisco way J ) to view things =A1=AD From a protocol point of vie= w, control of authentication is at PDU level. Each PDU may or not use authentication.

 

 

 

Thanks=

weiguo= 

_________________________________________=
___________________________________________________________________________=
_____
 
Ce message et ses pieces jointes peuvent =
contenir des informations confidentielles ou privilegiees et ne doivent don=
c
pas etre diffuses, exploites ou copies sa=
ns autorisation. Si vous avez recu ce message par erreur, veuillez le signa=
ler
a l'expediteur et le detruire ainsi que l=
es pieces jointes. Les messages electroniques etant susceptibles d'alterati=
on,
Orange decline toute responsabilite si ce=
 message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may cont=
ain confidential or privileged information that may be protected by law;
they should not be distributed, used or c=
opied without authorisation.
If you have received this email in error,=
 please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not l=
iable for messages that have been modified, changed or falsified.

Thank you.


______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_DD5FC8DE455C3348B94340C0AB5517334F7F1248nkgeml501mbschi_-- From nobody Fri Aug 8 00:44: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 537BB1A04A1 for ; Fri, 8 Aug 2014 00:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 UfoXCu1qBDku for ; Fri, 8 Aug 2014 00:44:42 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 154191A0428 for ; Fri, 8 Aug 2014 00:44:41 -0700 (PDT) Received: from localhost (213-65-181-180-no181.tbcn.telia.com [213.65.181.180]) by mail.tail-f.com (Postfix) with ESMTPSA id C10F712809A3; Fri, 8 Aug 2014 09:43:30 +0200 (CEST) Date: Fri, 08 Aug 2014 09:44:34 +0200 (CEST) Message-Id: <20140808.094434.377676763.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140808055625.GA82640@elstar.local> References: <20140807.200757.441533667.mbj@tail-f.com> <20140808055625.GA82640@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/7mLmiKDhh9Fs2J5x3kEiLmSjYgw Cc: netmod@ietf.org Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Aug 2014 07:44:47 -0000 Juergen Schoenwaelder wrote: > Martin, > > two quick questions/comments: > > a) Is it allowed to add an optional key while revising a YANG module? Yes I think so. In section 10. Updating a Module: NEW: #+BEGIN_EXAMPLE o A new leaf may be added to the "key" statement, provided the leaf is optional. #+END_EXAMPLE > b) It seems to be not possible to augmentation an optional key (e.g. a > VRF) since this would require to replace the 'key' statement. (In > hindsight, perhaps it would have been better to mark the leafs that > form the key instead of listing them in a key statement.) Maybe. OTOH augmenting an optional key is not safe for old clients. /martin From nobody Fri Aug 8 00:54: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 838111A0A87 for ; Fri, 8 Aug 2014 00:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-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 5rxEA1hqJ4v5 for ; Fri, 8 Aug 2014 00:54:03 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 306EF1A0A40 for ; Fri, 8 Aug 2014 00:54: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 EEC2613AC; Fri, 8 Aug 2014 09:54:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id zr0CryGEy-5E; Fri, 8 Aug 2014 09:54:01 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 8 Aug 2014 09:54:01 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 667E12002C; Fri, 8 Aug 2014 09:54:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5t2fbV-97uMo; Fri, 8 Aug 2014 09:54:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7009C20017; Fri, 8 Aug 2014 09:54:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C7D9B2E049DB; Fri, 8 Aug 2014 09:53:58 +0200 (CEST) Date: Fri, 8 Aug 2014 09:53:58 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140808075358.GA82910@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20140807.200757.441533667.mbj@tail-f.com> <20140808055625.GA82640@elstar.local> <20140808.094434.377676763.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140808.094434.377676763.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Yn-NPdzc0mTkGq5aHXcwT-50TGs Cc: netmod@ietf.org Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 07:54:04 -0000 On Fri, Aug 08, 2014 at 09:44:34AM +0200, Martin Bjorklund wrote: > > > b) It seems to be not possible to augmentation an optional key (e.g. a > > VRF) since this would require to replace the 'key' statement. (In > > hindsight, perhaps it would have been better to mark the leafs that > > form the key instead of listing them in a key statement.) > > Maybe. OTOH augmenting an optional key is not safe for old clients. > Why is it unsafe for an old client? How is this different from adding an optional key during a revision of a module? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Aug 8 00:59: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 C43251A0AB2 for ; Fri, 8 Aug 2014 00:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 q93Rd6Ac-AS6 for ; Fri, 8 Aug 2014 00:59:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28CBC1A0A89 for ; Fri, 8 Aug 2014 00:59:39 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 4A9A732415B; Fri, 8 Aug 2014 09:59:37 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 2546035C045; Fri, 8 Aug 2014 09:59:37 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.43]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0195.001; Fri, 8 Aug 2014 09:59:37 +0200 From: To: Haoweiguo , "netmod@ietf.org" Thread-Topic: Comments on the draft of draft-litkowski-netmod-isis-cfg-00 Thread-Index: AQHPss2wNjwyPPn7Q0SBMEnjCyL75ZvGV3vw Date: Fri, 8 Aug 2014 07:59:36 +0000 Message-ID: <13285_1407484777_53E48369_13285_16943_1_9E32478DFA9976438E7A22F69B08FF92070EC0@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: , <17441_1407399904_53E337E0_17441_15495_1_9E32478DFA9976438E7A22F69B08FF920615BB@OPEXCLILM34.corporate.adroot.infra.ftgroup> , <7097_1407421782_53E38D56_7097_7700_1_9E32478DFA9976438E7A22F69B08FF92061763@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92070EC0OPEXCLILM34corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.7.235717 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/vk48jmDMWvMLkadvUvmQ6OtWGZE Subject: Re: [netmod] Comments on the draft of draft-litkowski-netmod-isis-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Aug 2014 07:59:42 -0000 --_000_9E32478DFA9976438E7A22F69B08FF92070EC0OPEXCLILM34corpor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable module: isis +--rw isis-cfg | +--rw instances | +--rw instance [name] | +--rw name | +--rw enabled | +--rw isis-level | +--rw area | +--rw system-id | +--rw ipv4-router-id | +--rw ipv6-router-id [weiguo]: I think IS-IS protocol doesn't use ipv4-router-id and ipv6-rout= er-id , so it had better be removed. [SLI] Wrong, IS-IS uses IPv4 and/or IPv6 router-ids. IPv4 router-id is TLV1= 34 and it must be configurable. [weiguo2]: ipv4-router-id and ipv6-router-id are for TE purpose, i think t= he two paras had better be configured in MPLS TE feature, then TE notifies = IS-IS protocol to announce the para through the TLV134. [SLI2] Even if router-ids where defined for TE purpose, they have now usage= outside TE application and so configuration of router IDs is necessary eve= n in non TE deployment. [weiguo3]: IMO, If the router-ids are used for other applications, the con= figuation of router IDs had better be configured in these applications rath= er than in IS-IS. [SLI3] IMO, advertisement of ISIS information should be kept in ISIS config= uration. That's the way it's done today. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_9E32478DFA9976438E7A22F69B08FF92070EC0OPEXCLILM34corpor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

module: isis
+--rw isis-cfg
| +--rw instances
| +--rw instance [name]
| +--rw name
| +--rw enabled
| +--rw isis-level
| +--rw area
| +--rw system-id
| +--rw ipv4-router-id

| +--rw ipv6-router-id 

 

[weiguo]: I think IS-IS protocol doesn't use ipv4-router-id = ; and  ipv6-router-id , so it had better be removed.

[SLI] Wrong, IS-IS uses IPv4 and/or IPv6 route= r-ids. IPv4 router-id is TLV134 and it must be configurable. 

[weiguo2]: ipv4-router-id and ipv6-router-id  are for TE purpose, = i think the two paras had better be configured in MPLS TE feature, the= n TE notifies IS-IS protocol to announce the para through the TLV134.

[SLI2] Even if router-ids where defined for T= E purpose, they have now usage outside TE application and so configuration = of router IDs is necessary even in non TE deployment.

[weiguo3]: IMO, If the router-ids are us= ed for other applications,  the configuation of router IDs had better = be configured in these applications rather than in IS-IS.

[SLI3] IMO, advertisement= of ISIS information should be kept in ISIS configuration. That’s the= way it’s done today.

 <= /p> 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_9E32478DFA9976438E7A22F69B08FF92070EC0OPEXCLILM34corpor_-- From nobody Fri Aug 8 01:03: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 ACB631A0A8C for ; Fri, 8 Aug 2014 01:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 CgUaOL5mR2dw for ; Fri, 8 Aug 2014 01:03:07 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 498401A0A40 for ; Fri, 8 Aug 2014 01:03:07 -0700 (PDT) Received: from localhost (213-65-181-180-no181.tbcn.telia.com [213.65.181.180]) by mail.tail-f.com (Postfix) with ESMTPSA id AF0CA1280A89; Fri, 8 Aug 2014 10:02:01 +0200 (CEST) Date: Fri, 08 Aug 2014 10:02:37 +0200 (CEST) Message-Id: <20140808.100237.250665120.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140808075358.GA82910@elstar.local> References: <20140808055625.GA82640@elstar.local> <20140808.094434.377676763.mbj@tail-f.com> <20140808075358.GA82910@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/uF1RNQlT5Ej-jQQzSqpJt7Sxz8U Cc: netmod@ietf.org Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Aug 2014 08:03:08 -0000 Juergen Schoenwaelder wrote: > On Fri, Aug 08, 2014 at 09:44:34AM +0200, Martin Bjorklund wrote: > > > > > b) It seems to be not possible to augmentation an optional key (e.g. a > > > VRF) since this would require to replace the 'key' statement. (In > > > hindsight, perhaps it would have been better to mark the leafs that > > > form the key instead of listing them in a key statement.) > > > > Maybe. OTOH augmenting an optional key is not safe for old clients. > > > > Why is it unsafe for an old client? Suppose we had: list target { key "ip"; ... } And a client understands that. The someone (somwhow) augments "vrf" as an additional optional key. We might now have entries: (10.0.0.1, "vrf-1") (10.0.0.1, "vrf-2") But the client that doesn't know about the augmentation sees (10.0.0.1) (10.0.0.1) which doesn't work. > How is this different from adding > an optional key during a revision of a module? B/c in this case there is a new revision of the module, so the client knows that what it has might not completely work (module the upgrade rules). The important difference is that the client can detect this situation, but not the augment situation. /martin From nobody Sat Aug 9 09:58: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 C20A61A0033 for ; Sat, 9 Aug 2014 09:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.87 X-Spam-Level: X-Spam-Status: No, score=-104.87 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdQQGGOC4Bgq for ; Sat, 9 Aug 2014 09:58:26 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 82CFF1A0023 for ; Sat, 9 Aug 2014 09:58:26 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7A53418047A; Sat, 9 Aug 2014 09:56:48 -0700 (PDT) To: j.schoenwaelder@jacobs-university.de, bclaise@cisco.com, joelja@bogus.com, j.schoenwaelder@jacobs-university.de, tnadeau@lucidvision.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140809165648.7A53418047A@rfc-editor.org> Date: Sat, 9 Aug 2014 09:56:48 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yr_XGqHlTfaPp-OMLFfLnhxL3Yc Cc: netmod@ietf.org, rfc-editor@rfc-editor.org Subject: [netmod] [Editorial Errata Reported] RFC6991 (4076) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Aug 2014 16:58:28 -0000 The following errata report has been submitted for RFC6991, "Common YANG Data Types". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6991&eid=4076 -------------------------------------- Type: Editorial Reported by: Andy Bierman Section: 3 Original Text ------------- In date-and-time typedef description-stmt (c) The canonical format (see below) of data-and-time values Corrected Text -------------- (c) The canonical format (see below) of date-and-time values Notes ----- date-and-time spelled data-and-time Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6991 (draft-ietf-netmod-rfc6021-bis-03) -------------------------------------- Title : Common YANG Data Types Publication Date : July 2013 Author(s) : J. Schoenwaelder, Ed. Category : PROPOSED STANDARD Source : NETCONF Data Modeling Language Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Mon Aug 11 02:38: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 0BB9D1A03AA for ; Mon, 11 Aug 2014 02:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFeqdY5Tt5PT for ; Mon, 11 Aug 2014 02:38:09 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7194B1A03A9 for ; Mon, 11 Aug 2014 02:38:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 523EA5406A6; Mon, 11 Aug 2014 11:38:06 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgxLY76zOq2X; Mon, 11 Aug 2014 11:38:02 +0200 (CEST) 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 535F254043A; Mon, 11 Aug 2014 11:38:02 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , netmod@ietf.org In-Reply-To: <20140807.200757.441533667.mbj@tail-f.com> References: <20140807.200757.441533667.mbj@tail-f.com> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Mon, 11 Aug 2014 11:37:59 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7UiVEm7UQXhuoJjT2yFSCa28c6c Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Aug 2014 09:38:11 -0000 Martin Bjorklund writes: > In section 7.8.3.1. Usage Example: > > Add this: > > With the following list: > > list target { > key "ip vrf"; > leaf ip { > type inet:ip-address; > } > leaf vrf { > type string; "mandatory false;" should be here, right? > } > ... > } We should also get rid of the CLR that keys cannot be of type "empty", see Y09-01. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Aug 11 02:48: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 EE9771A03AC for ; Mon, 11 Aug 2014 02:48:40 -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 mmvJBcSKEL9s for ; Mon, 11 Aug 2014 02:48:39 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 312491A03A4 for ; Mon, 11 Aug 2014 02:48:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id A1EDF5406A6; Mon, 11 Aug 2014 11:48:37 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xolMgnp0R0NN; Mon, 11 Aug 2014 11:48:32 +0200 (CEST) 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 A13E754043A; Mon, 11 Aug 2014 11:48:32 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , Martin Bjorklund In-Reply-To: <20140808055625.GA82640@elstar.local> References: <20140807.200757.441533667.mbj@tail-f.com> <20140808055625.GA82640@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Mon, 11 Aug 2014 11:48:30 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KV22-SEm0L_02W47-0H8ftjrMF0 Cc: netmod@ietf.org Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Aug 2014 09:48:41 -0000 Juergen Schoenwaelder writes: > Martin, > > two quick questions/comments: > > a) Is it allowed to add an optional key while revising a YANG module? > > b) It seems to be not possible to augmentation an optional key (e.g. a > VRF) since this would require to replace the 'key' statement. (In > hindsight, perhaps it would have been better to mark the leafs that > form the key instead of listing them in a key statement.) This possibility is IMO quite needed. One use case is the list of static routes: an easy and elegant solution would be to define "destination-prefix" as the only key in the core routing model, and allow new keys to be added via augments. The inability of doing so leads to bogus "id" keys that are confusing and annoying. Lada > > /js > > On Thu, Aug 07, 2014 at 08:07:57PM +0200, Martin Bjorklund wrote: >> Hi, >> >> Here is a proposal for how to introduce optional keys. >> >> In summary, we allow a key leaf to be marked as "mandatory false", and >> also allow such a leaf to have a default value. All key leafs can be >> optional, but a list instance MUST have at least one of the key leafs >> instantiated, in order to be able to uniquely identify each instance. >> The combination of all given keys MUST be unique. >> >> For example, with the list: >> >> list foo { >> key "a b"; >> leaf a { >> type string; >> mandatory false; >> } >> leaf b { >> type string; >> mandatory false; >> } >> } >> >> We might have: >> >> >> hi >> >> >> hi >> >> >> hi >> mom >> >> >> One way of viewing this is that if a list instance does not have a >> certain key instantiated, its value is NULL (or its defualt). So in >> the example above we have the tree instances: >> >> ("hi", NULL) >> (NULL, "hi") >> ("hi", "mom") >> >> ------ >> >> In order to allow this, the following changes need to be done. >> >> >> In section 7.6.5, The leaf's mandatory Statement: >> >> OLD: >> >> The "mandatory" statement, which is optional, takes as an argument >> the string "true" or "false", and puts a constraint on valid data. >> If not specified, the default is "false". >> >> If "mandatory" is "true", the behavior of the constraint depends on >> the type of the leaf's closest ancestor node in the schema tree that >> is not a non-presence container (see Section 7.5.1): >> >> NEW: >> >> The "mandatory" statement, which is optional, takes as an argument >> the string "true" or "false", and puts a constraint on valid data. >> If not specified, the default is "false" for leafs that are not >> list keys, and "true" for leafs that are list keys. >> >> For leafs that are not list keys, if "mandatory" is "true", the >> behavior of the constraint depends on the type of the leaf's >> closest ancestor node in the schema tree that is not a non-presence >> container (see Section 7.5.1): >> >> >> And add NEW: >> >> For a leaf that is a list key, if "mandatory" is "true", the leaf >> MUST exist in a list instance. >> >> >> >> In section 7.8.2. The list's key Statement: >> >> OLD: >> >> The combined values of all the leafs specified in the key are used to >> uniquely identify a list entry. All key leafs MUST be given values >> when a list entry is created. Thus, any default values in the key >> leafs or their types are ignored. It also implies that any mandatory >> statement in the key leafs are ignored. >> >> A leaf that is part of the key can be of any built-in or derived >> type, except it MUST NOT be the built-in type "empty". >> >> NEW: >> >> The combined values of all the leaf instances specified in the key, >> including leafs with default values, are used to uniquely identify >> a list entry. All key leafs that are marked as mandatory MUST be >> given values when a list entry is created. A list instance MUST >> have at least one key leaf instantiated. >> >> A leaf that is part of the key can be of any built-in or derived >> type. >> >> >> >> In section 7.8.3.1. Usage Example: >> >> Add this: >> >> With the following list: >> >> list target { >> key "ip vrf"; >> leaf ip { >> type inet:ip-address; >> } >> leaf vrf { >> type string; >> } >> ... >> } >> >> the following configuration is valid: >> >> >> 192.0.2.1 >> >> >> 192.0.2.1 >> vrf-2 >> >> >> >> >> In section 7.8.6. NETCONF Operations: >> >> OLD: >> >> List entries can be created, deleted, replaced, and modified through >> , by using the "operation" attribute in the list's XML >> element. In each case, the values of all keys are used to uniquely >> identify a list entry. If all keys are not specified for a list >> entry, a "missing-element" error is returned. >> >> NEW: >> >> List entries can be created, deleted, replaced, and modified through >> , by using the "operation" attribute in the list's XML >> element. In each case, the values of all instantiated keys are >> used to uniquely identify a list entry. If a mandatory key is not >> specified for a list entry, a "missing-element" error is returned. >> >> >> In secrion 9.13. The instance-identifier Built-In Type: >> >> OLD: >> >> For >> identifying list entries with keys, each predicate consists of one >> equality test per key, and each key MUST have a corresponding >> predicate. >> >> NEW: >> >> For >> identifying list entries with keys, each predicate consists of one >> equality test per existing key leaf. >> >> >> >> /martin >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > 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 Aug 11 02: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 70AA91A03AA for ; Mon, 11 Aug 2014 02:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErPj_LDsBhXh for ; Mon, 11 Aug 2014 02:54:00 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E3C21A03A6 for ; Mon, 11 Aug 2014 02:54:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 8F76A540990; Mon, 11 Aug 2014 11:53:58 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHmMadMa0Yvw; Mon, 11 Aug 2014 11:53:55 +0200 (CEST) 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 33DDC54043A; Mon, 11 Aug 2014 11:53:55 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de In-Reply-To: <20140808.100237.250665120.mbj@tail-f.com> References: <20140808055625.GA82640@elstar.local> <20140808.094434.377676763.mbj@tail-f.com> <20140808075358.GA82910@elstar.local> <20140808.100237.250665120.mbj@tail-f.com> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Mon, 11 Aug 2014 11:53:52 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rBvMP0crEbhpH5mlLPHT4dUYN1M Cc: netmod@ietf.org Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Aug 2014 09:54:03 -0000 Martin Bjorklund writes: > Juergen Schoenwaelder wrote: >> On Fri, Aug 08, 2014 at 09:44:34AM +0200, Martin Bjorklund wrote: >> > >> > > b) It seems to be not possible to augmentation an optional key (e.g. a >> > > VRF) since this would require to replace the 'key' statement. (In >> > > hindsight, perhaps it would have been better to mark the leafs that >> > > form the key instead of listing them in a key statement.) >> > >> > Maybe. OTOH augmenting an optional key is not safe for old clients. >> > >> >> Why is it unsafe for an old client? > > Suppose we had: > > list target { > key "ip"; > ... > } > > And a client understands that. The someone (somwhow) augments "vrf" > as an additional optional key. We might now have entries: > > (10.0.0.1, "vrf-1") > (10.0.0.1, "vrf-2") > > But the client that doesn't know about the augmentation sees > > (10.0.0.1) > (10.0.0.1) > > which doesn't work. > >> How is this different from adding >> an optional key during a revision of a module? > > B/c in this case there is a new revision of the module, so the client > knows that what it has might not completely work (module the upgrade > rules). > > The important difference is that the client can detect this situation, > but not the augment situation. I don't agree. The client does see the augmenting module, and this information cannot be freely ignored. Lada > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Aug 13 07:31: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 800141A065D; Wed, 13 Aug 2014 07:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43t4B6QulF6r; Wed, 13 Aug 2014 07:31:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A321A040D; Wed, 13 Aug 2014 07:31:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140813143144.8647.60864.idtracker@ietfa.amsl.com> Date: Wed, 13 Aug 2014 07:31:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5nI5Xmy_TASZt-vT3N2kf6ra-BA Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-snmp-cfg-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 14:31:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : A YANG Data Model for SNMP Configuration Authors : Martin Bjorklund Juergen Schoenwaelder Filename : draft-ietf-netmod-snmp-cfg-07.txt Pages : 81 Date : 2014-08-13 Abstract: This document defines a collection of YANG definitions for configuring SNMP engines. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-snmp-cfg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-snmp-cfg-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-snmp-cfg-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 13 07:34: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 ABF721A06A1 for ; Wed, 13 Aug 2014 07:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 EKfM419-EEc2 for ; Wed, 13 Aug 2014 07:34:34 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0D41A0667 for ; Wed, 13 Aug 2014 07:34:34 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 39EFA128097C; Wed, 13 Aug 2014 16:33:05 +0200 (CEST) Date: Wed, 13 Aug 2014 16:34:33 +0200 (CEST) Message-Id: <20140813.163433.460639977788828997.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20140813143144.8647.60864.idtracker@ietfa.amsl.com> References: <20140813143144.8647.60864.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/dkMiaYjkLcKZKjuYTAlChPaoqB4 Cc: joelja@bogus.com Subject: Re: [netmod] I-D Action: draft-ietf-netmod-snmp-cfg-07.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, 13 Aug 2014 14:34:36 -0000 Hi, The snmp-cfg is updated with a minor nit from the gen-art review, and a missing IANA request to register the urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name in the XML namespace registry. /martin 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 SNMP Configuration > Authors : Martin Bjorklund > Juergen Schoenwaelder > Filename : draft-ietf-netmod-snmp-cfg-07.txt > Pages : 81 > Date : 2014-08-13 > > Abstract: > This document defines a collection of YANG definitions for > configuring SNMP engines. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-snmp-cfg/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netmod-snmp-cfg-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-snmp-cfg-07 > > > 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 Wed Aug 13 10:34: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 148261A01D0 for ; Wed, 13 Aug 2014 10:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 QaCLt_usYIWZ for ; Wed, 13 Aug 2014 10:34:01 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980EF1A0176 for ; Wed, 13 Aug 2014 10:34:01 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id q108so64451qgd.9 for ; Wed, 13 Aug 2014 10:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=f2WIeTifUGf4wJKUrS5K6DeBuugEH/SNTLNQHWCwtcw=; b=RXhnAQbrEypbYRtFb7IAouYi+NFhGUUVfuPOo/ccjXn6bx+ewSGokhpDUHnz+75LAO ZYDVGnGFvpZWepL9VulS9hGtK+IPVOibf1ChLkhMLvc42ovNo+JnMuvGVLtRhxc7lO9f Ezgfy6ZqTfoBXMhlEzk8gLJpHetB1necsp4zFsTCjlgQ0QPLoubTpGHzzW7GqtYqK0OL +2soVj5PNbEVWBiJSM78VIHDDFvZjSEuiYFFAYTOMO6lKI8bTZiA4l6ZDY+qgyKpv4ON CBg9EMMyY/Nu3LG3kQt73zUZGrFaojI3/mWbWtvJez/I9xyzIlPr1Xc+WZQh3fGZySjO xRFg== MIME-Version: 1.0 X-Received: by 10.140.46.55 with SMTP id j52mr8596076qga.27.1407951240746; Wed, 13 Aug 2014 10:34:00 -0700 (PDT) Received: by 10.140.24.73 with HTTP; Wed, 13 Aug 2014 10:34:00 -0700 (PDT) Date: Wed, 13 Aug 2014 10:34:00 -0700 Message-ID: From: Mahesh Jethanandani To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a1139616090de62050086312a Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/uIanT-mGsnT6NiUt1h42LLozQKo Subject: [netmod] YANG plugin for Eclipse X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Aug 2014 17:34:03 -0000 --001a1139616090de62050086312a Content-Type: text/plain; charset=UTF-8 Can anyone recommend a plugin for YANG for the latest version of Eclipse (Kepler)? The ones I have tried (http://bcsw.net/YangEclipsePlugIn and http://atnog.av.it.pt/~ptavares/yangplugin/installation/) are for older versions or just do not work. Thanks. -- Mahesh Jethanandani mjethanandani@gmail.com --001a1139616090de62050086312a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a1139616090de62050086312a-- From nobody Thu Aug 14 06:55: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 C08E11A0A0A for ; Thu, 14 Aug 2014 06:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, 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 hv85kidrNgOA for ; Thu, 14 Aug 2014 06:55:14 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id B43D61A073C for ; Thu, 14 Aug 2014 06:55:13 -0700 (PDT) Received: from jans-mbp.tail-f.com (Jans-MBP.tail-f.com [192.168.1.132]) by mail.tail-f.com (Postfix) with ESMTPSA id D553C1280955; Thu, 14 Aug 2014 15:53:36 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_59EB2A15-47CD-4568-8992-D68B0E4CB60F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jan Lindblad In-Reply-To: Date: Thu, 14 Aug 2014 15:55:09 +0200 Message-Id: <3A66B426-3599-45D9-9711-F53750BE159E@tail-f.com> References: To: Mahesh Jethanandani X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yJF4u01HKkN8g-eH6rhcRq8r6bc Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG plugin for Eclipse X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Aug 2014 13:55:16 -0000 --Apple-Mail=_59EB2A15-47CD-4568-8992-D68B0E4CB60F Content-Type: multipart/alternative; boundary="Apple-Mail=_BF8ADE58-9542-4B23-83BF-E4927ED2FDAA" --Apple-Mail=_BF8ADE58-9542-4B23-83BF-E4927ED2FDAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mahesh, > Can anyone recommend a plugin for YANG for the latest version of = Eclipse (Kepler)?=20 >=20 > The ones I have tried (http://bcsw.net/YangEclipsePlugIn Tried the one above now, and it works fine for me in Kepler. Doesn't do = very much yet, though. Syntax coloring (but not completely correct), = indentation/outdentation, and keyword completion is what I've found.=20 Outline view is what I'm really looking forward to! It's listed on the = roadmap. > and http://atnog.av.it.pt/~ptavares/yangplugin/installation/) are for = older versions or just do not work. Have tried this one in the past, but as you say it appears to no longer = be developed and doesn't function with any remotely recent Eclipse = version. Best Regards, /jan -- Jan Lindblad, janl@tail-f.com, +46 702855728 Solutions Architect/Business Development, CTO Office Cisco Cloud and Virtualization Group --Apple-Mail=_BF8ADE58-9542-4B23-83BF-E4927ED2FDAA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Mahesh,

Can anyone recommend a plugin for YANG = for the latest version of Eclipse (Kepler)? 

The = ones I have tried (http://bcsw.net/YangEclipsePlug= In

Tried the one above = now, and it works fine for me in Kepler. Doesn't do very much yet, = though. Syntax coloring (but not completely correct), = indentation/outdentation, and keyword completion is what I've = found. 

Outline view is what I'm really = looking forward to! It's listed on the = roadmap.

and http://a= tnog.av.it.pt/~ptavares/yangplugin/installation/) are for older = versions or just do not = work.

Have tried this one in = the past, but as you say it appears to no longer be developed and = doesn't function with any remotely recent Eclipse = version.

Best Regards,
/jan
--
Jan Lindblad, janl@tail-f.com, +46 = 702855728
Solutions Architect/Business Development, CTO = Office
Cisco Cloud and Virtualization = Group

= --Apple-Mail=_BF8ADE58-9542-4B23-83BF-E4927ED2FDAA-- --Apple-Mail=_59EB2A15-47CD-4568-8992-D68B0E4CB60F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT7L+9AAoJEBSCnbqufIis+t0IAI127bqNPkHOp/FtrOOCnXGv xFGq3JjKl9Jr7m2KEyH6dLHcPQIVBxTM6Cc8oIdhSouCWG+aS5/K8cftptVeXw1X Oga4tywpuqtJ8j+KIz2uFMbV7VkvNbeygPKgA4a+eipGKsIFAlH+ujDEH2u1LqB/ pVdgBFdCUQcD1c3igGxJSxdqvmE9We7RUKZKCmSWA0cQfbAB7jA7mx7RDvqIyrTM uAwfbTrKqY7UrLejUGJl/FSoJaXdzduadbKx2b+KfYh3p/I0Z0QYKuHtcmq67uX8 Xjd5wdV+8wk8deNltxGMpM0SU9ZIss6T1jTqaleE/BtGuxGar7jjeLY9EasIdGw= =XFDQ -----END PGP SIGNATURE----- --Apple-Mail=_59EB2A15-47CD-4568-8992-D68B0E4CB60F-- From nobody Sun Aug 17 04:45: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 319201A083E for ; Sun, 17 Aug 2014 04:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.381 X-Spam-Level: * X-Spam-Status: No, score=1.381 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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.668] 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 jTW2UbVfKgBE for ; Sun, 17 Aug 2014 04:45:15 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19C061A0839 for ; Sun, 17 Aug 2014 04:45:14 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id C72DD140CDB for ; Sun, 17 Aug 2014 13:45:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1408275912; bh=p5QfqSor+kbvB3RIOb9l5bsJgChg5hPu5ncOVRpjnHQ=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id: Date:To:Mime-Version; b=IwAYyDi6AkyFC7Ckj5XEqoo1nkpYcFo7kCuPKZJb9n90Z+4zVa1Qy/yZzC7xyHE6q sPF/W93VV3gfPdWT1U0YpWD62YeoGmhws8+fq7d3Xx6uJeAwFyLCP50o9PKMBo+LsT BRDoS0GhjCXkv2r2uZy1u3ABpyhhArswwfigM1CU= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sun, 17 Aug 2014 13:45:10 +0200 To: NETMOD Working Group Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/W0C3tiacV5drRhSymrXP8Dt6T2Q Subject: [netmod] GitHub project for YANG & I-D development X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 17 Aug 2014 11:45:17 -0000 Hi, I created a GitHub project, https://github.com/llhotka/YANG-I-D, intended as a skeleton for joint YANG and I-D development. The idea is = that people can fork this project and populate the copy with their = modules and I-D text. The Makefile tries to automate some of the routine = and error-prone steps such as inclusion of modules and other external = stuff into the I-D text. Here is already one project that has been = forked from it: https://github.com/igp-yang/isis-yang The Makefile assumes xml2rfc as the I-D source format. I know that not = everybody is happy with writing XML in their text editor, so support for = other source formats (Markdown, Emacs outline) may be added later, = perhaps in separate branches of the skeleton project. Feedback and suggestions are welcome. Lada=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Aug 20 23:06: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 41D531A0702; Wed, 20 Aug 2014 13:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] 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 nKpRlDxEIgwD; Wed, 20 Aug 2014 13:08:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E731A0676; Wed, 20 Aug 2014 13:08:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: =?utf-8?b?SsO8cmdlbiBTY2jDtm53w6RsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2Jz?=@ietfa.amsl.com, =?utf-8?q?-university=2Ede=3E=2C__Tom_Nadeau_=3Ctnadeau=40lucidvision=2Ecom?=@ietfa.amsl.com, =?utf-8?q?=3E?=@ietfa.amsl.com X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140820200806.30600.80876.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 13:08:06 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/bTT6PP8pznfUo39-P9z2JBSfQuQ X-Mailman-Approved-At: Wed, 20 Aug 2014 23:06:49 -0700 Cc: Bill Bjorkman , netmod@ietf.org, kevin@metroethernetforum.org, nan@metroethernetforum.org, Joel Jaeggli , glenn.parsons@ericsson.com, rraghu@ciena.com, tsbsg15@itu.int Subject: [netmod] New Liaison Statement, "Liaison to IETF on YANG Service OAM models" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 20:08:08 -0000 Title: Liaison to IETF on YANG Service OAM models Submission Date: 2014-07-31 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1346/ From: MEF (Mike Bencheck ) To: NETCONF Data Modeling Language (Jürgen Schönwälder , Tom Nadeau ) Cc: Benoit Claise ,Joel Jaeggli ,Nan Chen ,Bill Bjorkman ,Raghu Ranganathan ,kevin@metroethernetforum.org,netmod@ietf.org,tsbsg15@itu.int,glenn.parsons@ericsson.com,tnadeau@lucidvision.com Response Contact: nan@metroethernetforum.org, rraghu@ciena.com Technical Contact: Purpose: For information Body: Dear Jürgen Schönwälder, Tom Nadeau, and Benoit Claise: The MEF wants to communicate to the IETF NETCONF Data Modeling Language (netmod) Working Group that MEF has existing YANG Service OAM Fault Monitoring (MEF 38) and Service OAM Performance Monitoring (MEF 39) specifications. MEF 38 and MEF 39 are published specifications and can be found on the MEF public website at: http://www.metroethernetforum.org/Assets/Technical_Specifications/PDF/MEF_38.pdf http://www.metroethernetforum.org/Assets/Technical_Specifications/PDF/MEF_39.pdf There appears to be some direct overlap with these specifications and the goals of the Working Group, specifically in the area of MD, MA (MEG) and MEP definitions as found in http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/. We request that IETF review and consider using these models, if applicable. We look forward to feedback from you on this subject. The MEF Technical Committee meets next in Atlanta in October 27-29, 2014. Attachments: Liaison to IETF on YANG Service OAM models https://datatracker.ietf.org/documents/LIAISON/liaison-2014-07-31-mef-netmod-liaison-to-ietf-on-yang-service-oam-models-attachment-1.pdf From nobody Sun Aug 24 22:15: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 DD6FC1A8A16; Sun, 24 Aug 2014 22:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.893 X-Spam-Level: X-Spam-Status: No, score=-100.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 FcHkN6Hy9UV1; Sun, 24 Aug 2014 22:14:51 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 341401A8A15; Sun, 24 Aug 2014 22:14:51 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-05-53fa71a3aa42 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 52.D5.05330.3A17AF35; Mon, 25 Aug 2014 01:13:40 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Mon, 25 Aug 2014 01:14:48 -0400 From: Gregory Mirsky To: "'draft-tissa-netmod-oam@tools.ietf.org'" Thread-Topic: draft-tissa-netmod-oam Thread-Index: Ac+tKouGZjiF/7GjRZGwGunQsgwS9A== Date: Mon, 25 Aug 2014 05:14:47 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B82567E@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B82567Eeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyuXSPn+6Swl/BBt8a+Sz2bnvJavH42yF2 i1tLV7JazL/YyGrxdL6kxec/2xgtjl/4zWgxb9cHJgcOjyVLfjJ5fLn8mS2AKYrLJiU1J7Ms tUjfLoEr4/yZ1ewFN6oqdrT/YGlg3JTVxcjJISFgIvHgxG0mCFtM4sK99WwgtpDAUUaJX4/0 IezljBJbvumA2GwCRhIvNvawg9giAuESK+7/ALK5OJgFGpkk5j5+BdYsLKAgsfndbxaIIlWJ /Y3/mSFsPYn38w+CxVmA4lc6JoIN4hXwlZjWfAaslxHoiO+n1oAdxCwgLnHryXyo4wQkluw5 zwxhi0q8fPyPFcJWkvj4ez47RH2+xJUdp1kgZgpKnJz5hGUCo/AsJKNmISmbhaQMIq4jsWD3 JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2LkKC1OLctNNzLYxAiMr2MSbLo7GPe8tDzEKMDBqMTD u2D7z2Ah1sSy4srcQ4zSHCxK4ryzaucFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBk2JL7 oOnR171K7X9yJ/8N3Gi1VcxsvsNGufZ+i3lznpjezzKb6+DSW3XFP3ey28Rp7U0+1e/WlL2N 4t280WCqyoLXKxKfak7dan3F5eXBuX1f37vMrzaasdZdfjHjTTV2Kft/r8yuH+linHP6FN83 HfN7B7o3KpqlB1jWZUQdb45PPTBlUd4aJZbijERDLeai4kQAvcFrVJACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/odArghV6NzeuLIHRy56kVgLZksU Cc: "l2vpn@ietf.org" , "mpls@ietf.org" , "spring@ietf.org" , "time@ietf.org" , "'netmod@ietf.org'" , "nvo3@ietf.org" , "rtg-bfd@ietf.org" Subject: [netmod] draft-tissa-netmod-oam X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Aug 2014 05:14:54 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B82567Eeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et.al, please kindly consider my comments and questions to this document: * Introduction o "... it is a reasonable choice to develop the unified OAM framework ba= sed on those (CFM) concepts." I agree that for packet switching connection-= oriented networks that are based on G.800 architecture CFM, but more so Y.1= 731, provides shared concepts. I think that the same cannot be said for con= nectionless packet switching networks. Thus extending CFM model onto arbitr= ary networks without consideration whether these are connection-oriented or= connectionless is very questionable approach, IMO; o "...CFM, it is a reasonable choice to develop the unified OAM framework= based on those concepts" IP OAM is not based on Ethernet Service OAM model= or principles but, IMO, OAM of overlay networks more closer resemble IP OA= M as these networks are connectionless in their architecture; o "The YANG model presented in this document is the base model and suppor= ts IP Ping and Traceroute." If only these and similar OAM tools, e.g. LSP p= ing, Loopback/Linktrace, are in scope of the document, then, I believe, the= title may say something like "YANG model of on-demand OAM tool to detect a= nd localize Loss of Continuity defect". Referring to ping/traceroute as "ge= neric OAM" comes as stretch too far; o "...initiate a performance monitoring session can do so in the same ma= nner regardless of the underlying protocol or technology" I'd point to work= of LMAP WG on informational model of performance measurements in large-sca= le access networks, work of ITU-T's SG15, MEF. Perhaps sentence can be stop= ped after "... or a Traceroute". o "In this document we define the YANG model for Generic OAM" Can you pro= vide definition or reference to the definition of the "Generic OAM"? It is = challenging to validate informational model of something that not been suff= iciently defined. * Section 3 o "This allows users to traverse between OAM of different technologies at= ease through a uniform API set." Usually relationships between OAM layers = referred and viewed as OAM interworking. There are several examples of IETF= addressing aspects of OAM interworking. I think that interworking includes= not only scenarios of nested OAM layers but peering layers and thus is bro= ader than introduced in the document "nested OAM". o Figure 1 depicts OAM of both connection-oriented and connectionless net= works. What you see common, generic in respective OAM of these networks? * Section 4 o "In IP, the MA can be per IP Subnet ..." As there's no definition of MA= in IP, is this the definition or one of examples. Can MA in IP network be = other than per IP Subnet? o "Under each MA, there can be two or more MEPs (Maintenance End Points)"= Firstly, since you adopt MA-centric terminology, MEP stands for Maintenanc= e Association End Point. Secondly, in some OAM models Down and Up MEP being= distinguished. Would your model consider that? As there's no definition of= MEP for several networks you've listed, e.g. IP, how the YANG model will a= bstract something that is not defined? And thirdly, how and where MIPs are = located in IP OAM? Thank you for your consideration of my notes and looking forward to the int= eresting discussion. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B82567Eeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Authors, et.al,

please kindly consider my comments and questions to = this document:

·         Introduction

o    “… it is a reasonable choi= ce to develop the unified OAM framework based on those (CFM) concepts.̶= 1; I agree that for packet switching connection-oriented networks that are = based on G.800 architecture CFM, but more so Y.1731, provides shared concepts. I think that the same cannot be said for connectionless p= acket switching networks. Thus extending CFM model onto arbitrary networks = without consideration whether these are connection-oriented or connectionle= ss is very questionable approach, IMO;

o   “…CFM, it is a reasonable choice= to develop the unified OAM framework based on those concepts” IP OAM= is not based on Ethernet Service OAM model or principles but, IMO, OAM of = overlay networks more closer resemble IP OAM as these networks are connectionless in their architecture;

o   “The YANG model presented in this docu= ment is the base model and supports IP Ping and Traceroute.” If only = these and similar OAM tools, e.g. LSP ping, Loopback/Linktrace, are in scop= e of the document, then, I believe, the title may say something like “YANG model of on-demand OAM tool to detect a= nd localize Loss of Continuity defect”. Referring to ping/traceroute = as “generic OAM” comes as stretch too far;

o    “…initiate a performance m= onitoring session can do so in the same manner regardless of the underlying= protocol or technology” I’d point to work of LMAP WG on inform= ational model of performance measurements in large-scale access networks, work of ITU-T’s SG15, MEF. Perhaps sentence can be stopped= after “… or a Traceroute”.

o   “In this document we define the YANG m= odel for Generic OAM” Can you provide definition or reference to the = definition of the “Generic OAM”? It is challenging to validate = informational model of something that not been sufficiently defined.

·         Section 3

o   “This allows users to traverse between= OAM of different technologies at ease through a uniform API set.” Us= ually relationships between OAM layers referred and viewed as OAM interwork= ing. There are several examples of IETF addressing aspects of OAM interworking. I think that interworking includes not only s= cenarios of nested OAM layers but peering layers and thus is broader than i= ntroduced in the document “nested OAM”.

o   Figure 1 depicts OAM of both connection-orie= nted and connectionless networks. What you see common, generic in respectiv= e OAM of these networks?

·         Section 4

o   “In IP, the MA can be per IP Subnet &#= 8230;” As there’s no definition of MA in IP, is this the defini= tion or one of examples. Can MA in IP network be other than per IP Subnet?<= o:p>

o   “Under each MA, there can be two or mo= re MEPs (Maintenance End Points)” Firstly, since you adopt MA-centric= terminology, MEP stands for Maintenance Association End Point. Secondly, i= n some OAM models Down and Up MEP being distinguished. Would your model consider that? As there’s no definition of MEP for = several networks you’ve listed, e.g. IP, how the YANG model will abst= ract something that is not defined? And thirdly, how and where MIPs are loc= ated in IP OAM?

 

Thank you for your consideration of my notes and loo= king forward to the interesting discussion.

 

Regards,

    =     Greg

--_000_7347100B5761DC41A166AC17F22DF1121B82567Eeusaamb103erics_-- From nobody Mon Aug 25 10:28: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 15C271A00F6 for ; Mon, 25 Aug 2014 10:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668, T_FILL_THIS_FORM_SHORT=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 s46XttPSC7VX for ; Mon, 25 Aug 2014 10:28:27 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 586511A00E1 for ; Mon, 25 Aug 2014 10:28:27 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2BE2A155F for ; Mon, 25 Aug 2014 19:28:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Cer3OLMW35Zs for ; Mon, 25 Aug 2014 19:28:22 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 25 Aug 2014 19:28:25 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 394B420034 for ; Mon, 25 Aug 2014 19:28:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KEI4udn48vLm; Mon, 25 Aug 2014 19:28:23 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2098B20033; Mon, 25 Aug 2014 19:28:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3512D2E4EBE0; Mon, 25 Aug 2014 19:28:22 +0200 (CEST) Date: Mon, 25 Aug 2014 19:28:21 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140825172821.GA53635@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20140731193311.24685.49820.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline In-Reply-To: <20140731193311.24685.49820.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/FPHNzAhkl9TkofNYNjZMadVT1VI Subject: Re: [netmod] NETMOD WG Virtual Interim Meetings beginning 2014-08-27 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, 25 Aug 2014 17:28:29 -0000 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jul 31, 2014 at 12:33:12PM -0700, IESG Secretary wrote: > The NETMOD WG will hold a series of weekly virtual interim meetings. > The meetings will take place on Wednesdays between 16:00 and 18:00 > CEST. The first meeting will be on Wednesday 2014-08-27. The agenda is > to iterate over the YANG 1.1 issues list with the goal to close open > issues until there are none left open. The virtual interim meetings > will continue weekly until either all issues have been closed or > 2014-10-22 has passed (the last Wednesday before the I-D cutoff for > IETF 91). > Hi, attached please find the Webex information for the upcoming series of YANG 1.1 virtual interim meetings. The first meeting in this series is this Wednesday. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="netmod-webex.txt" Topic: NETMOD WG Date: Every Wednesday, from Wednesday, August 27, 2014 to Wednesday, October 22, 2014 Time: 4:00 pm, Europe Summer Time (Berlin, GMT+02:00) Meeting Number: 649 102 111 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?MTID=mbbe9c321c8e9f472df4ce74c1987a0f0 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". 5. Follow the instructions that appear on your screen. To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?MTID=me720293ef5473cc3bf963302b2f6a8f1 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:649 102 111 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: cmorgan@amsl.com 1-510-492-4085 To update this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ietf.webex.com/ietf/j.php?MTID=m4f877f2e629b841380e2d593e4e39b87 WebEx will automatically setup Meeting Manager for Windows the first time you join a meeting. To save time, you can setup prior to the meeting by clicking this link: https://ietf.webex.com/ietf/meetingcenter/mcsetup.php The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. http://www.webex.com CCP:+16504793208x649102111# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. --xHFwDpU9dbj6ez1V-- From nobody Tue Aug 26 06:05: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 AB42B1A6FD1 for ; Tue, 26 Aug 2014 06:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 Veof8Hlxz0JE for ; Tue, 26 Aug 2014 06:05:43 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731101A6FE3 for ; Tue, 26 Aug 2014 06:05:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id DC099540854; Tue, 26 Aug 2014 15:05:39 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzqrF6OH8DUv; Tue, 26 Aug 2014 15:05:30 +0200 (CEST) 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 2EFD45401C2; Tue, 26 Aug 2014 15:05:30 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20140731122200.GC64359@elstar.local> References: <20140730110826.GE61382@elstar.local> <20140730130412.GB61698@elstar.local> <20140731055201.GC63208@elstar.local> <5BA7630E-B06F-47B5-9ACD-92D9A3512864@nic.cz> <20140731122200.GC64359@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 26 Aug 2014 15:05:25 +0200 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/sBNIOkErsN-uAyZyFnmJrqyd5sQ Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in 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: Tue, 26 Aug 2014 13:05:54 -0000 Hi, I would like to resolve the issue of metadata encoding in JSON, so let me summarize the options we have. There are actually two valid questions: 1. Does the specification of the mapping of XML attributes in JSON belong to the yang-json document, and if so, in what form? Possible answers: 1.1. No, as YANG doesn't model XML attributes. 1.2. Yes, as normative text. 1.3. Yes, as non-normative text. For 1.2 and 1.3, we have to answer the second question because I assume most XML attributes in use with YANG-modelled data will have non-null names= pace: 2. How do we represent the namespace of an attribute in JSON? Possible answers, using bar as an example: 2.1. Use Clark's notation [1]: "elem": "bar", "@elem": { "{http://example.com/ns/URI}attr": "foo" } 2.2. Associate somehow every attribute with a YANG module, and then use the same notation as for encoding the namespace of YANG data nodes: "elem": "bar", "@elem": { "somemodule:attr": "foo" } 2.3. Associate somehow the XML namespace URI with a prefix in JSON and then use the same notation as for XML: "elem": "bar", "@elem": { "x:attr": "foo" } In both 2.2 and 2.3, we need to say what "somehow" actually means. If we accept 1.3, it could I guess involve a certain amount of hand-waving but leaving it completely unanswered IMO makes the whole thing useless. I personally think that 2.3 would be a step in a wrong direction because the URI-prefix duality was recognized as a serious problem of XML namespaces=C2=A0[2]. Please indicate your preferences or propose something else. Thanks, Lada [1] http://tools.ietf.org/html/draft-saintandre-json-namespaces-00 [2] http://blog.jclark.com/2010/01/xml-namespaces.html Juergen Schoenwaelder writes: > On Thu, Jul 31, 2014 at 10:49:07AM +0200, Ladislav Lhotka wrote: >>=20 >> On 31 Jul 2014, at 07:52, Juergen Schoenwaelder wrote: >>=20 >> > On Wed, Jul 30, 2014 at 05:53:30PM +0200, Ladislav Lhotka wrote: >> >>=20 >> >>>>> understand that this makes the solution somewhat incomplete but it >> >>>>> allows us to finish this document now and to move forward. >> >>>>=20 >> >>>> That is my priority, too. >> >>>=20 >> >>> Good. So what speaks against saying that if attribute names clash and >> >>> if attributes are scoped by a module name, then the encoding is XYZ? >> >>=20 >> >> I thought YANG 1.1 was a good opportunity to decide about how to do t= his scoping, provided that standard attributes are really needed. >> >>=20 >> >=20 >> > Lets keep the discussion focused on the JSON document. Are you OK with >> > the proposal to add text that attribute names may be scoped? >>=20 >> Yes, if there is no other choice. It is unclear what =E2=80=9Cscoped=E2= =80=9D means. >>=20 > > Scoped by a namespace, such as 'namespace:identifier'. > > /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 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Aug 26 06:20: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 1F6EE1A6FD6 for ; Tue, 26 Aug 2014 06:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 ynqCHqXOm-na for ; Tue, 26 Aug 2014 06:19:57 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id B298E1A6FDA for ; Tue, 26 Aug 2014 06:19:56 -0700 (PDT) Received: from localhost (173-38-208-169.cisco.com [173.38.208.169]) by mail.tail-f.com (Postfix) with ESMTPSA id E3B59128097A; Tue, 26 Aug 2014 15:17:27 +0200 (CEST) Date: Tue, 26 Aug 2014 15:19:55 +0200 (CEST) Message-Id: <20140826.151955.1338003814359491302.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <5BA7630E-B06F-47B5-9ACD-92D9A3512864@nic.cz> <20140731122200.GC64359@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=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/DGxG4TczEWnhYspWQfsq0YyK34Q Cc: netmod@ietf.org Subject: Re: [netmod] metadata in 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: Tue, 26 Aug 2014 13:19:59 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gSGksDQo+IA0KPiBJIHdv dWxkIGxpa2UgdG8gcmVzb2x2ZSB0aGUgaXNzdWUgb2YgbWV0YWRhdGEgZW5jb2RpbmcgaW4gSlNP Tiwgc28gbGV0DQo+IG1lIHN1bW1hcml6ZSB0aGUgb3B0aW9ucyB3ZSBoYXZlLiBUaGVyZSBhcmUg YWN0dWFsbHkgdHdvIHZhbGlkIHF1ZXN0aW9uczoNCj4gDQo+IDEuIERvZXMgdGhlIHNwZWNpZmlj YXRpb24gb2YgdGhlIG1hcHBpbmcgb2YgWE1MIGF0dHJpYnV0ZXMgaW4gSlNPTg0KPiAgICBiZWxv bmcgdG8gdGhlIHlhbmctanNvbiBkb2N1bWVudCwgYW5kIGlmIHNvLCBpbiB3aGF0IGZvcm0/DQo+ IA0KPiBQb3NzaWJsZSBhbnN3ZXJzOg0KPiANCj4gMS4xLiBObywgYXMgWUFORyBkb2Vzbid0IG1v ZGVsIFhNTCBhdHRyaWJ1dGVzLg0KPiAxLjIuIFllcywgYXMgbm9ybWF0aXZlIHRleHQuDQo+IDEu My4gWWVzLCBhcyBub24tbm9ybWF0aXZlIHRleHQuDQoNCjEuMg0KDQo+IEZvciAxLjIgYW5kIDEu Mywgd2UgaGF2ZSB0byBhbnN3ZXIgdGhlIHNlY29uZCBxdWVzdGlvbiBiZWNhdXNlIEkgYXNzdW1l DQo+IG1vc3QgWE1MIGF0dHJpYnV0ZXMgaW4gdXNlIHdpdGggWUFORy1tb2RlbGxlZCBkYXRhIHdp bGwgaGF2ZQ0KPiBub24tbnVsbCBuYW1lc3BhY2U6DQo+IA0KPiAyLiBIb3cgZG8gd2UgcmVwcmVz ZW50IHRoZSBuYW1lc3BhY2Ugb2YgYW4gYXR0cmlidXRlIGluIEpTT04/DQo+IA0KPiBQb3NzaWJs ZSBhbnN3ZXJzLCB1c2luZw0KPiANCj4gICA8ZWxlbSB4bWxuczp4PSJodHRwOi8vZXhhbXBsZS5j b20vbnMvVVJJIiB4OmF0dHI9ImZvbyI+YmFyPC9lbGVtPg0KPiANCj4gYXMgYW4gZXhhbXBsZToN Cj4gDQo+IDIuMS4gVXNlIENsYXJrJ3Mgbm90YXRpb24gWzFdOg0KPiANCj4gICAiZWxlbSI6ICJi YXIiLA0KPiAgICJAZWxlbSI6IHsNCj4gICAgICJ7aHR0cDovL2V4YW1wbGUuY29tL25zL1VSSX1h dHRyIjogImZvbyINCj4gICB9DQo+IA0KPiAyLjIuIEFzc29jaWF0ZSBzb21laG93IGV2ZXJ5IGF0 dHJpYnV0ZSB3aXRoIGEgWUFORyBtb2R1bGUsIGFuZCB0aGVuIHVzZQ0KPiAgICAgIHRoZSBzYW1l IG5vdGF0aW9uIGFzIGZvciBlbmNvZGluZyB0aGUgbmFtZXNwYWNlIG9mIFlBTkcgZGF0YSBub2Rl czoNCj4gDQo+ICAgImVsZW0iOiAiYmFyIiwNCj4gICAiQGVsZW0iOiB7DQo+ICAgICAic29tZW1v ZHVsZTphdHRyIjogImZvbyINCj4gICB9DQo+IA0KPiAyLjMuIEFzc29jaWF0ZSBzb21laG93IHRo ZSBYTUwgbmFtZXNwYWNlIFVSSSB3aXRoIGEgcHJlZml4IGluIEpTT04gYW5kDQo+ICAgICAgdGhl biB1c2UgdGhlIHNhbWUgbm90YXRpb24gYXMgZm9yIFhNTDoNCj4gDQo+ICAgImVsZW0iOiAiYmFy IiwNCj4gICAiQGVsZW0iOiB7DQo+ICAgICAieDphdHRyIjogImZvbyINCj4gICB9DQoNCjIuMQ0K DQpBbmQgSSB0aGluayB0aGUgdGV4dCBzaG91bGQgc3BlY2lmeSB0aGF0IHRoZSB1c2FnZSBvZiB0 aGlzIG1ldGEgZGF0YQ0KbXVzdCBiZSBkZWZpbmVkIGJ5IGEgc3BlY2lmaWNhdGlvbiB0aGF0IHVz ZXMgdGhpcyBtYXBwaW5nLiAgVGhpcyBtZWFucw0KdGhhdCBSRVNUQ09ORiBtdXN0IHNwZWNpZnkg d2hpY2ggYXR0cmlidXRlcyBhcmUgc3VwcG9ydGVkIGluIFJFU1RDT05GLA0KYW5kIGhvdyB0aGV5 IGFyZSBlbmNvZGVkIChpLmUuIGlmIHRoZXkgaGF2ZSBhIG5hbWVzcGFjZSBvciBub3QpLg0KDQoN Ci9tYXJ0aW4NCg0KDQoNCj4gDQo+IEluIGJvdGggMi4yIGFuZCAyLjMsIHdlIG5lZWQgdG8gc2F5 IHdoYXQgInNvbWVob3ciIGFjdHVhbGx5IG1lYW5zLiBJZiB3ZQ0KPiBhY2NlcHQgMS4zLCBpdCBj b3VsZCBJIGd1ZXNzIGludm9sdmUgYSBjZXJ0YWluIGFtb3VudCBvZiBoYW5kLXdhdmluZyBidXQN Cj4gbGVhdmluZyBpdCBjb21wbGV0ZWx5IHVuYW5zd2VyZWQgSU1PIG1ha2VzIHRoZSB3aG9sZSB0 aGluZyB1c2VsZXNzLg0KPiANCj4gSSBwZXJzb25hbGx5IHRoaW5rIHRoYXQgMi4zIHdvdWxkIGJl IGEgc3RlcCBpbiBhIHdyb25nIGRpcmVjdGlvbiBiZWNhdXNlDQo+IHRoZSBVUkktcHJlZml4IGR1 YWxpdHkgd2FzIHJlY29nbml6ZWQgYXMgYSBzZXJpb3VzIHByb2JsZW0gb2YgWE1MDQo+IG5hbWVz cGFjZXPCoFsyXS4NCj4gDQo+IFBsZWFzZSBpbmRpY2F0ZSB5b3VyIHByZWZlcmVuY2VzIG9yIHBy b3Bvc2Ugc29tZXRoaW5nIGVsc2UuDQo+IA0KPiBUaGFua3MsIExhZGENCj4gDQo+IFsxXSBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWludGFuZHJlLWpzb24tbmFtZXNwYWNlcy0w MA0KPiBbMl0gaHR0cDovL2Jsb2cuamNsYXJrLmNvbS8yMDEwLzAxL3htbC1uYW1lc3BhY2VzLmh0 bWwNCj4gDQo+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11 bml2ZXJzaXR5LmRlPiB3cml0ZXM6DQo+IA0KPiA+IE9uIFRodSwgSnVsIDMxLCAyMDE0IGF0IDEw OjQ5OjA3QU0gKzAyMDAsIExhZGlzbGF2IExob3RrYSB3cm90ZToNCj4gPj4gDQo+ID4+IE9uIDMx IEp1bCAyMDE0LCBhdCAwNzo1MiwgSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxk ZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KPiA+PiANCj4gPj4gPiBPbiBXZWQsIEp1 bCAzMCwgMjAxNCBhdCAwNTo1MzozMFBNICswMjAwLCBMYWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+ ID4+ID4+IA0KPiA+PiA+Pj4+PiB1bmRlcnN0YW5kIHRoYXQgdGhpcyBtYWtlcyB0aGUgc29sdXRp b24gc29tZXdoYXQgaW5jb21wbGV0ZSBidXQgaXQNCj4gPj4gPj4+Pj4gYWxsb3dzIHVzIHRvIGZp bmlzaCB0aGlzIGRvY3VtZW50IG5vdyBhbmQgdG8gbW92ZSBmb3J3YXJkLg0KPiA+PiA+Pj4+IA0K PiA+PiA+Pj4+IFRoYXQgaXMgbXkgcHJpb3JpdHksIHRvby4NCj4gPj4gPj4+IA0KPiA+PiA+Pj4g R29vZC4gU28gd2hhdCBzcGVha3MgYWdhaW5zdCBzYXlpbmcgdGhhdCBpZiBhdHRyaWJ1dGUgbmFt ZXMgY2xhc2ggYW5kDQo+ID4+ID4+PiBpZiBhdHRyaWJ1dGVzIGFyZSBzY29wZWQgYnkgYSBtb2R1 bGUgbmFtZSwgdGhlbiB0aGUgZW5jb2RpbmcgaXMgWFlaPw0KPiA+PiA+PiANCj4gPj4gPj4gSSB0 aG91Z2h0IFlBTkcgMS4xIHdhcyBhIGdvb2Qgb3Bwb3J0dW5pdHkgdG8gZGVjaWRlIGFib3V0IGhv dyB0byBkbyB0aGlzIHNjb3BpbmcsIHByb3ZpZGVkIHRoYXQgc3RhbmRhcmQgYXR0cmlidXRlcyBh cmUgcmVhbGx5IG5lZWRlZC4NCj4gPj4gPj4gDQo+ID4+ID4gDQo+ID4+ID4gTGV0cyBrZWVwIHRo ZSBkaXNjdXNzaW9uIGZvY3VzZWQgb24gdGhlIEpTT04gZG9jdW1lbnQuIEFyZSB5b3UgT0sgd2l0 aA0KPiA+PiA+IHRoZSBwcm9wb3NhbCB0byBhZGQgdGV4dCB0aGF0IGF0dHJpYnV0ZSBuYW1lcyBt YXkgYmUgc2NvcGVkPw0KPiA+PiANCj4gPj4gWWVzLCBpZiB0aGVyZSBpcyBubyBvdGhlciBjaG9p Y2UuIEl0IGlzIHVuY2xlYXIgd2hhdCDigJxzY29wZWTigJ0gbWVhbnMuDQo+ID4+IA0KPiA+DQo+ ID4gU2NvcGVkIGJ5IGEgbmFtZXNwYWNlLCBzdWNoIGFzICduYW1lc3BhY2U6aWRlbnRpZmllcicu DQo+ID4NCj4gPiAvanMNCj4gPg0KPiA+IC0tIA0KPiA+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAg ICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+ID4gUGhvbmU6ICs0OSA0 MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxLCAyODc1OSBCcmVtZW4sIEdlcm1hbnkN Cj4gPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11 bml2ZXJzaXR5LmRlLz4NCj4gDQo+IC0tIA0KPiBMYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJz DQo+IFBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K From nobody Tue Aug 26 06:32: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 622B01A6FF4 for ; Tue, 26 Aug 2014 06:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 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.668] 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 uR7ZgCftRpAK for ; Tue, 26 Aug 2014 06:32:23 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B00461A6FF2 for ; Tue, 26 Aug 2014 06:32:22 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 217F413F697; Tue, 26 Aug 2014 15:32:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409059941; bh=pKpHz2CeJBJvhAv4rdfSDo/G2p6Rzb3E63SxuVNR2uo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TdpUeEvAusWKoU+OQLhBE9sEY8+OoSQcnq6V1mL3U4HhsJfoQXCZP8rkVbQYlKYgt 1Z3wYROPorMgqNaWVQm65pzyrm0dPxivX3zRmu+af4ZIdhseJ4KM8fuompv7tg0l6t n0JboDJEfcyRPy6/m5t+1mKZ0o5WufTOOXU1zMpo= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140826.151955.1338003814359491302.mbj@tail-f.com> Date: Tue, 26 Aug 2014 15:32:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3A525146-145D-42D8-8660-80FF6B159F0F@nic.cz> References: <5BA7630E-B06F-47B5-9ACD-92D9A3512864@nic.cz> <20140731122200.GC64359@elstar.local> <20140826.151955.1338003814359491302.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_h2eMKrbLQbKC7zFIkeaJZREFFE Cc: netmod@ietf.org Subject: Re: [netmod] metadata in 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: Tue, 26 Aug 2014 13:32:24 -0000 On 26 Aug 2014, at 15:19, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Hi, >>=20 >> I would like to resolve the issue of metadata encoding in JSON, so = let >> me summarize the options we have. There are actually two valid = questions: >>=20 >> 1. Does the specification of the mapping of XML attributes in JSON >> belong to the yang-json document, and if so, in what form? >>=20 >> Possible answers: >>=20 >> 1.1. No, as YANG doesn't model XML attributes. >> 1.2. Yes, as normative text. >> 1.3. Yes, as non-normative text. >=20 > 1.2 >=20 >> For 1.2 and 1.3, we have to answer the second question because I = assume >> most XML attributes in use with YANG-modelled data will have >> non-null namespace: >>=20 >> 2. How do we represent the namespace of an attribute in JSON? >>=20 >> Possible answers, using >>=20 >> bar >>=20 >> as an example: >>=20 >> 2.1. Use Clark's notation [1]: >>=20 >> "elem": "bar", >> "@elem": { >> "{http://example.com/ns/URI}attr": "foo" >> } >>=20 >> 2.2. Associate somehow every attribute with a YANG module, and then = use >> the same notation as for encoding the namespace of YANG data = nodes: >>=20 >> "elem": "bar", >> "@elem": { >> "somemodule:attr": "foo" >> } >>=20 >> 2.3. Associate somehow the XML namespace URI with a prefix in JSON = and >> then use the same notation as for XML: >>=20 >> "elem": "bar", >> "@elem": { >> "x:attr": "foo" >> } >=20 > 2.1 >=20 > And I think the text should specify that the usage of this meta data > must be defined by a specification that uses this mapping. This means > that RESTCONF must specify which attributes are supported in RESTCONF, > and how they are encoded (i.e. if they have a namespace or not). Hmm, do you mean that the set of attributes allowed in (a given version = of) RESTCONF will be fixed and no other attributes can be used? In this = case we probably needn=92t bother with attribute namespaces at all. Lada >=20 >=20 > /martin >=20 >=20 >=20 >>=20 >> In both 2.2 and 2.3, we need to say what "somehow" actually means. If = we >> accept 1.3, it could I guess involve a certain amount of hand-waving = but >> leaving it completely unanswered IMO makes the whole thing useless. >>=20 >> I personally think that 2.3 would be a step in a wrong direction = because >> the URI-prefix duality was recognized as a serious problem of XML >> namespaces [2]. >>=20 >> Please indicate your preferences or propose something else. >>=20 >> Thanks, Lada >>=20 >> [1] http://tools.ietf.org/html/draft-saintandre-json-namespaces-00 >> [2] http://blog.jclark.com/2010/01/xml-namespaces.html >>=20 >> Juergen Schoenwaelder writes: >>=20 >>> On Thu, Jul 31, 2014 at 10:49:07AM +0200, Ladislav Lhotka wrote: >>>>=20 >>>> On 31 Jul 2014, at 07:52, Juergen Schoenwaelder = wrote: >>>>=20 >>>>> On Wed, Jul 30, 2014 at 05:53:30PM +0200, Ladislav Lhotka wrote: >>>>>>=20 >>>>>>>>> understand that this makes the solution somewhat incomplete = but it >>>>>>>>> allows us to finish this document now and to move forward. >>>>>>>>=20 >>>>>>>> That is my priority, too. >>>>>>>=20 >>>>>>> Good. So what speaks against saying that if attribute names = clash and >>>>>>> if attributes are scoped by a module name, then the encoding is = XYZ? >>>>>>=20 >>>>>> I thought YANG 1.1 was a good opportunity to decide about how to = do this scoping, provided that standard attributes are really needed. >>>>>>=20 >>>>>=20 >>>>> Lets keep the discussion focused on the JSON document. Are you OK = with >>>>> the proposal to add text that attribute names may be scoped? >>>>=20 >>>> Yes, if there is no other choice. It is unclear what =93scoped=94 = means. >>>>=20 >>>=20 >>> Scoped by a namespace, such as 'namespace:identifier'. >>>=20 >>> /js >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 >>=20 >> --=20 >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=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 Aug 26 06:36: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 1EBF21A6FF0 for ; Tue, 26 Aug 2014 06:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 F9u-MxZjgaOI for ; Tue, 26 Aug 2014 06:36:10 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6CA1A6FED for ; Tue, 26 Aug 2014 06:36:10 -0700 (PDT) Received: from localhost (173-38-208-169.cisco.com [173.38.208.169]) by mail.tail-f.com (Postfix) with ESMTPSA id 2C07A128097A; Tue, 26 Aug 2014 15:33:41 +0200 (CEST) Date: Tue, 26 Aug 2014 15:36:08 +0200 (CEST) Message-Id: <20140826.153608.405577889262820806.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <3A525146-145D-42D8-8660-80FF6B159F0F@nic.cz> References: <20140826.151955.1338003814359491302.mbj@tail-f.com> <3A525146-145D-42D8-8660-80FF6B159F0F@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/RtCXhaiZqiaGkheyboU0DOI7a1A Cc: netmod@ietf.org Subject: Re: [netmod] metadata in 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: Tue, 26 Aug 2014 13:36:12 -0000 Ladislav Lhotka wrote: > > On 26 Aug 2014, at 15:19, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > >> Hi, > >> > >> I would like to resolve the issue of metadata encoding in JSON, so let > >> me summarize the options we have. There are actually two valid questions: > >> > >> 1. Does the specification of the mapping of XML attributes in JSON > >> belong to the yang-json document, and if so, in what form? > >> > >> Possible answers: > >> > >> 1.1. No, as YANG doesn't model XML attributes. > >> 1.2. Yes, as normative text. > >> 1.3. Yes, as non-normative text. > > > > 1.2 > > > >> For 1.2 and 1.3, we have to answer the second question because I assume > >> most XML attributes in use with YANG-modelled data will have > >> non-null namespace: > >> > >> 2. How do we represent the namespace of an attribute in JSON? > >> > >> Possible answers, using > >> > >> bar > >> > >> as an example: > >> > >> 2.1. Use Clark's notation [1]: > >> > >> "elem": "bar", > >> "@elem": { > >> "{http://example.com/ns/URI}attr": "foo" > >> } > >> > >> 2.2. Associate somehow every attribute with a YANG module, and then use > >> the same notation as for encoding the namespace of YANG data nodes: > >> > >> "elem": "bar", > >> "@elem": { > >> "somemodule:attr": "foo" > >> } > >> > >> 2.3. Associate somehow the XML namespace URI with a prefix in JSON and > >> then use the same notation as for XML: > >> > >> "elem": "bar", > >> "@elem": { > >> "x:attr": "foo" > >> } > > > > 2.1 > > > > And I think the text should specify that the usage of this meta data > > must be defined by a specification that uses this mapping. This means > > that RESTCONF must specify which attributes are supported in RESTCONF, > > and how they are encoded (i.e. if they have a namespace or not). > > Hmm, do you mean that the set of attributes allowed in (a given > version of) RESTCONF will be fixed and no other attributes can be > used? This will be up to the RESTCONF specification - but yes, RESTCONF probably won't need namespaces for the attributes. But IMO it is better if the json mapping document is complete and handle the namespace case as well. We don't know what other specifications might want to use. /martin From nobody Tue Aug 26 06:50: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 6438D1A6FFF for ; Tue, 26 Aug 2014 06:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRjg8NJ8H0Rb for ; Tue, 26 Aug 2014 06:50:48 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C31751A6FFB for ; Tue, 26 Aug 2014 06:50:47 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9659913FD; Tue, 26 Aug 2014 15:50:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id hSrwHSHoMcf6; Tue, 26 Aug 2014 15:50:44 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 26 Aug 2014 15:50:45 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C172920035; Tue, 26 Aug 2014 15:50:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id S6DQafhYpevq; Tue, 26 Aug 2014 15:50:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1111220033; Tue, 26 Aug 2014 15:50:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 619AC2E4FE70; Tue, 26 Aug 2014 15:50:43 +0200 (CEST) Date: Tue, 26 Aug 2014 15:50:42 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140826135042.GA56223@elstar.local> Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org References: <5BA7630E-B06F-47B5-9ACD-92D9A3512864@nic.cz> <20140731122200.GC64359@elstar.local> <20140826.151955.1338003814359491302.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140826.151955.1338003814359491302.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kbIdHD_kPbc4GAUJUDylqasE-uE Cc: netmod@ietf.org Subject: Re: [netmod] metadata in JSON 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, 26 Aug 2014 13:50:50 -0000 On Tue, Aug 26, 2014 at 03:19:55PM +0200, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > Hi, > > > > I would like to resolve the issue of metadata encoding in JSON, so let > > me summarize the options we have. There are actually two valid questions: > > > > 1. Does the specification of the mapping of XML attributes in JSON > > belong to the yang-json document, and if so, in what form? > > > > Possible answers: > > > > 1.1. No, as YANG doesn't model XML attributes. > > 1.2. Yes, as normative text. > > 1.3. Yes, as non-normative text. > > 1.2 > > > For 1.2 and 1.3, we have to answer the second question because I assume > > most XML attributes in use with YANG-modelled data will have > > non-null namespace: > > > > 2. How do we represent the namespace of an attribute in JSON? > > > > Possible answers, using > > > > bar > > > > as an example: > > > > 2.1. Use Clark's notation [1]: > > > > "elem": "bar", > > "@elem": { > > "{http://example.com/ns/URI}attr": "foo" > > } > > > > 2.2. Associate somehow every attribute with a YANG module, and then use > > the same notation as for encoding the namespace of YANG data nodes: > > > > "elem": "bar", > > "@elem": { > > "somemodule:attr": "foo" > > } > > > > 2.3. Associate somehow the XML namespace URI with a prefix in JSON and > > then use the same notation as for XML: > > > > "elem": "bar", > > "@elem": { > > "x:attr": "foo" > > } > > 2.1 > > And I think the text should specify that the usage of this meta data > must be defined by a specification that uses this mapping. This means > that RESTCONF must specify which attributes are supported in RESTCONF, > and how they are encoded (i.e. if they have a namespace or not). > Martin, does it make sense to have two different namespace notations? For attributes, you seem to like to use {} while for regular leafs, the I-D currently says we use : Would it note make sense to consider being consistent, i.e., to use {} as well? The counter argument I have heard so far is that module names are likely shorter than URLs. While true, they are still way longer than prefixes we use in XML land. /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 Aug 26 07:19: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 7B3831A7032 for ; Tue, 26 Aug 2014 07:19: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 tmHyta69Jq3k for ; Tue, 26 Aug 2014 07:19:51 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D39EA1A7033 for ; Tue, 26 Aug 2014 07:19:50 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id cm18so13525390qab.4 for ; Tue, 26 Aug 2014 07:19:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=no8yFo/NCXqO3PILHHcy0W1T7hqMh/osP5gVByP5eP4=; b=kzVOupRydbm73uNOt0GkT6WFiiOQAycJaUckekwHpnqxTiHyH1SY+vKgQVOmKqGqsf A2yki9Li2JVHQGU9zGh9rUp35/POvhz1xbGw7lFDzco0v2sSF1Uq9npOucfcBujqrm40 Pffm0cJjJUK5UBwhn+0ql1C0+0+8D9/fgVYs71t/6X436gLxyqjQv+GAV49eANTwUpMb 960iMYuI0PkpQ76cvc57D9uTfQVgmuQwVnNIfaOrMlTFCKKCe728DvgjWNp1+lfPbGHf fAXYojI/ko8HqCdWYrE7ZzEBKapYrHKbkf35wg+BAkiFhbOlUhjXD2tUUGxBz2BLPosU Sf5Q== X-Gm-Message-State: ALoCoQkBFfSzSx9UXb05fpxkepstD8NNFmdvZGWCRL/DwbSaijZufYFb+HKH+cp04fxrfW1CnzBE MIME-Version: 1.0 X-Received: by 10.140.95.101 with SMTP id h92mr43723018qge.35.1409062789867; Tue, 26 Aug 2014 07:19:49 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Tue, 26 Aug 2014 07:19:49 -0700 (PDT) In-Reply-To: References: <20140730110826.GE61382@elstar.local> <20140730130412.GB61698@elstar.local> <20140731055201.GC63208@elstar.local> <5BA7630E-B06F-47B5-9ACD-92D9A3512864@nic.cz> <20140731122200.GC64359@elstar.local> Date: Tue, 26 Aug 2014 07:19:49 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c15c500e88d5050188ffd7 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jeT1XiYUJDfBbL_H5lj-FIFxWZA Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in 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: Tue, 26 Aug 2014 14:19:55 -0000 --001a11c15c500e88d5050188ffd7 Content-Type: text/plain; charset=ISO-8859-1 Hi, This issue and been opened and closed again at least 3 times. Are we spinning on this issue until you get the answer you like? Which choice is the solution from Martin we already agreed to use? That is the one I prefer. The namespace URI is much longer than the module-name, and not easy to remember like the module name. But if YANG will not have attributes, then there may be no other choice. I do not agree with the CLR that only the RESTCONF protocol doc can define meta-data. What is the purpose of that rule? NETCONF has "with-defaults" in a separate document. The protocol needs to be modular so new optional features can be added over time. Vendors should be able to add meta-data as well. Andy On Tue, Aug 26, 2014 at 6:05 AM, Ladislav Lhotka wrote: > Hi, > > I would like to resolve the issue of metadata encoding in JSON, so let > me summarize the options we have. There are actually two valid questions: > > 1. Does the specification of the mapping of XML attributes in JSON > belong to the yang-json document, and if so, in what form? > > Possible answers: > > 1.1. No, as YANG doesn't model XML attributes. > 1.2. Yes, as normative text. > 1.3. Yes, as non-normative text. > > For 1.2 and 1.3, we have to answer the second question because I assume > most XML attributes in use with YANG-modelled data will have non-null > namespace: > > 2. How do we represent the namespace of an attribute in JSON? > > Possible answers, using > > bar > > as an example: > > 2.1. Use Clark's notation [1]: > > "elem": "bar", > "@elem": { > "{http://example.com/ns/URI}attr": "foo" > } > > 2.2. Associate somehow every attribute with a YANG module, and then use > the same notation as for encoding the namespace of YANG data nodes: > > "elem": "bar", > "@elem": { > "somemodule:attr": "foo" > } > > 2.3. Associate somehow the XML namespace URI with a prefix in JSON and > then use the same notation as for XML: > > "elem": "bar", > "@elem": { > "x:attr": "foo" > } > > In both 2.2 and 2.3, we need to say what "somehow" actually means. If we > accept 1.3, it could I guess involve a certain amount of hand-waving but > leaving it completely unanswered IMO makes the whole thing useless. > > I personally think that 2.3 would be a step in a wrong direction because > the URI-prefix duality was recognized as a serious problem of XML > namespaces [2]. > > Please indicate your preferences or propose something else. > > Thanks, Lada > > [1] http://tools.ietf.org/html/draft-saintandre-json-namespaces-00 > [2] http://blog.jclark.com/2010/01/xml-namespaces.html > > Juergen Schoenwaelder writes: > > > On Thu, Jul 31, 2014 at 10:49:07AM +0200, Ladislav Lhotka wrote: > >> > >> On 31 Jul 2014, at 07:52, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> > >> > On Wed, Jul 30, 2014 at 05:53:30PM +0200, Ladislav Lhotka wrote: > >> >> > >> >>>>> understand that this makes the solution somewhat incomplete but it > >> >>>>> allows us to finish this document now and to move forward. > >> >>>> > >> >>>> That is my priority, too. > >> >>> > >> >>> Good. So what speaks against saying that if attribute names clash > and > >> >>> if attributes are scoped by a module name, then the encoding is XYZ? > >> >> > >> >> I thought YANG 1.1 was a good opportunity to decide about how to do > this scoping, provided that standard attributes are really needed. > >> >> > >> > > >> > Lets keep the discussion focused on the JSON document. Are you OK with > >> > the proposal to add text that attribute names may be scoped? > >> > >> Yes, if there is no other choice. It is unclear what "scoped" means. > >> > > > > Scoped by a namespace, such as 'namespace:identifier'. > > > > /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 > --001a11c15c500e88d5050188ffd7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

This issue and been opened and clos= ed again at least 3 times.
Are we spinning on this issue until yo= u get the answer you like?
Which choice is the solution from Mart= in we already agreed to use?
That is the one I prefer.   The namespace URI is much longer than=
the module-name, and not easy to remember like the module name.<= /div>
But if YANG will not have attributes, then there may be no other = choice.

I do not agree with the CLR that only the RESTCONF prot= ocol doc
can define meta-data.  What is the purpose of that = rule?  NETCONF
has "with-defaults" in a separate d= ocument.  The protocol
needs to be modular so new optional features can be added over time.
Vendors should be able to add meta-data as well.


Andy


On Tue, Aug 26, 2014 at 6:05 AM, Ladislav Lh= otka <lhotka@nic.cz> wrote:
Hi,

I would like to resolve the issue of metadata encoding in JSON, so let
me summarize the options we have. There are actually two valid questions:
1. Does the specification of the mapping of XML attributes in JSON
   belong to the yang-json document, and if so, in what form?

Possible answers:

1.1. No, as YANG doesn't model XML attributes.
1.2. Yes, as normative text.
1.3. Yes, as non-normative text.

For 1.2 and 1.3, we have to answer the second question because I assume
most XML attributes in use with YANG-modelled data will have non-null names= pace:

2. How do we represent the namespace of an attribute in JSON?

Possible answers, using

  <elem xmlns:x=3D"http://example.com/ns/URI" x:attr=3D"foo"&g= t;bar</elem>

as an example:

2.1. Use Clark's notation [1]:

  "elem": "bar",
  "@elem": {
    "{http://example.com/ns/URI}attr": "foo"
  }

2.2. Associate somehow every attribute with a YANG module, and then use
     the same notation as for encoding the namespace of YANG= data nodes:

  "elem": "bar",
  "@elem": {
    "somemodule:attr": "foo"
  }

2.3. Associate somehow the XML namespace URI with a prefix in JSON and
     then use the same notation as for XML:

  "elem": "bar",
  "@elem": {
    "x:attr": "foo"
  }

In both 2.2 and 2.3, we need to say what "somehow" actually means= . If we
accept 1.3, it could I guess involve a certain amount of hand-waving but leaving it completely unanswered IMO makes the whole thing useless.

I personally think that 2.3 would be a step in a wrong direction because the URI-prefix duality was recognized as a serious problem of XML
namespaces [2].

Please indicate your preferences or propose something else.

Thanks, Lada

[1] http://tools.ietf.org/html/draft-saintandre-json-name= spaces-00
[2] http://blog.jclark.com/2010/01/xml-namespaces.html

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:

> On Thu, Jul 31, 2014 at 10:49:07AM +0200, Ladislav Lhotka wrote:
>>
>> On 31 Jul 2014, at 07:52, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university= .de> wrote:
>>
>> > On Wed, Jul 30, 2014 at 05:53:30PM +0200, Ladislav Lhotka wro= te:
>> >>
>> >>>>> understand that this makes the solution somew= hat incomplete but it
>> >>>>> allows us to finish this document now and to = move forward.
>> >>>>
>> >>>> That is my priority, too.
>> >>>
>> >>> Good. So what speaks against saying that if attribute= names clash and
>> >>> if attributes are scoped by a module name, then the e= ncoding is XYZ?
>> >>
>> >> I thought YANG 1.1 was a good opportunity to decide about= how to do this scoping, provided that standard attributes are really neede= d.
>> >>
>> >
>> > Lets keep the discussion focused on the JSON document. Are yo= u OK with
>> > the proposal to add text that attribute names may be scoped?<= br> >>
>> Yes, if there is no other choice. It is unclear what “scoped= ” means.
>>
>
> Scoped by a namespace, such as 'namespace:identifier'.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1= , 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <= ;http://www.= jacobs-university.de/>

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

--001a11c15c500e88d5050188ffd7-- From nobody Tue Aug 26 07:28: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 7858B1A8028 for ; Tue, 26 Aug 2014 07:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 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.668] 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 dyxs6FB6WtAn for ; Tue, 26 Aug 2014 07:28:48 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E911A70FE for ; Tue, 26 Aug 2014 07:28:48 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 699D8141B8C; Tue, 26 Aug 2014 16:28:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409063326; bh=XtGKhr5lISkK/ATpKx4JZ07lPrfh3I0lLoLvd7nvhps=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=m7+uxWT2RczHLqsSUQXvB/suaMxLIBbO7KkxWBGv6lRLtXQ0ajDmG2qQixXRRSXtC xkxQP4zkU5m7Q63h1CWthtbDdYfiEkEQ5ZmMOtnoMC7LfEWYUS/IYi1E2f2f5vRdwt m5+Gb2aSHs/hkPcB5/CNaJ0Mpd21mrkeQt1YVGwU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 26 Aug 2014 16:28:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6D9FD52D-0401-4115-AB99-BDC893949434@nic.cz> References: <20140730110826.GE61382@elstar.local> <20140730130412.GB61698@elstar.local> <20140731055201.GC63208@elstar.local> <5BA7630E-B06F-47B5-9ACD-92D9A3512864@nic.cz> <20140731122200.GC64359@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LbxlGa05QsyvnE1pgJ2X5Asp_fA Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in 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: Tue, 26 Aug 2014 14:28:49 -0000 On 26 Aug 2014, at 16:19, Andy Bierman wrote: > Hi, >=20 > This issue and been opened and closed again at least 3 times. > Are we spinning on this issue until you get the answer you like? > Which choice is the solution from Martin we already agreed to use? I am now seriously confused. Can you point me to that Martin=92s = solution? Did it take into account attribute namespaces? Lada > That is the one I prefer. The namespace URI is much longer than > the module-name, and not easy to remember like the module name. > But if YANG will not have attributes, then there may be no other = choice. >=20 > I do not agree with the CLR that only the RESTCONF protocol doc > can define meta-data. What is the purpose of that rule? NETCONF > has "with-defaults" in a separate document. The protocol > needs to be modular so new optional features can be added over time. > Vendors should be able to add meta-data as well. >=20 >=20 > Andy >=20 >=20 > On Tue, Aug 26, 2014 at 6:05 AM, Ladislav Lhotka = wrote: > Hi, >=20 > I would like to resolve the issue of metadata encoding in JSON, so let > me summarize the options we have. There are actually two valid = questions: >=20 > 1. Does the specification of the mapping of XML attributes in JSON > belong to the yang-json document, and if so, in what form? >=20 > Possible answers: >=20 > 1.1. No, as YANG doesn't model XML attributes. > 1.2. Yes, as normative text. > 1.3. Yes, as non-normative text. >=20 > For 1.2 and 1.3, we have to answer the second question because I = assume > most XML attributes in use with YANG-modelled data will have non-null = namespace: >=20 > 2. How do we represent the namespace of an attribute in JSON? >=20 > Possible answers, using >=20 > bar >=20 > as an example: >=20 > 2.1. Use Clark's notation [1]: >=20 > "elem": "bar", > "@elem": { > "{http://example.com/ns/URI}attr": "foo" > } >=20 > 2.2. Associate somehow every attribute with a YANG module, and then = use > the same notation as for encoding the namespace of YANG data = nodes: >=20 > "elem": "bar", > "@elem": { > "somemodule:attr": "foo" > } >=20 > 2.3. Associate somehow the XML namespace URI with a prefix in JSON and > then use the same notation as for XML: >=20 > "elem": "bar", > "@elem": { > "x:attr": "foo" > } >=20 > In both 2.2 and 2.3, we need to say what "somehow" actually means. If = we > accept 1.3, it could I guess involve a certain amount of hand-waving = but > leaving it completely unanswered IMO makes the whole thing useless. >=20 > I personally think that 2.3 would be a step in a wrong direction = because > the URI-prefix duality was recognized as a serious problem of XML > namespaces [2]. >=20 > Please indicate your preferences or propose something else. >=20 > Thanks, Lada >=20 > [1] http://tools.ietf.org/html/draft-saintandre-json-namespaces-00 > [2] http://blog.jclark.com/2010/01/xml-namespaces.html >=20 > Juergen Schoenwaelder writes: >=20 > > On Thu, Jul 31, 2014 at 10:49:07AM +0200, Ladislav Lhotka wrote: > >> > >> On 31 Jul 2014, at 07:52, Juergen Schoenwaelder = wrote: > >> > >> > On Wed, Jul 30, 2014 at 05:53:30PM +0200, Ladislav Lhotka wrote: > >> >> > >> >>>>> understand that this makes the solution somewhat incomplete = but it > >> >>>>> allows us to finish this document now and to move forward. > >> >>>> > >> >>>> That is my priority, too. > >> >>> > >> >>> Good. So what speaks against saying that if attribute names = clash and > >> >>> if attributes are scoped by a module name, then the encoding is = XYZ? > >> >> > >> >> I thought YANG 1.1 was a good opportunity to decide about how to = do this scoping, provided that standard attributes are really needed. > >> >> > >> > > >> > Lets keep the discussion focused on the JSON document. Are you OK = with > >> > the proposal to add text that attribute names may be scoped? > >> > >> Yes, if there is no other choice. It is unclear what =93scoped=94 = means. > >> > > > > Scoped by a namespace, such as 'namespace:identifier'. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Aug 26 07:38: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 09B9F1A86E5 for ; Tue, 26 Aug 2014 07:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 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.668] 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 TRPzWHwIXTIL for ; Tue, 26 Aug 2014 07:38:21 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 905B31A86E9 for ; Tue, 26 Aug 2014 07:38:20 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 80316141B8C; Tue, 26 Aug 2014 16:38:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409063896; bh=c8TDsptf6rDK2QqJ8iy2JFnskYRVxBnYmgR2pVggjH4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=wivmR6gzRLzFnLTSPe4pgH4De69vqZG+KNV29KJ3PT9figIqLoR/Bg9plC+xMj7FG cfkjL8xGdsurhHjvNzXU02bnpwfHHwaNvXBnnxfLnR/ypk2vFgd9LhyUh6qjJe6i+6 8VkgGMqvsY7UitE7eHUqMPUrgfjnHbIX7AzdG4dg= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140826135042.GA56223@elstar.local> Date: Tue, 26 Aug 2014 16:38:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <33797277-8E0D-45A8-81FC-6EE2A8C03E50@nic.cz> References: <5BA7630E-B06F-47B5-9ACD-92D9A3512864@nic.cz> <20140731122200.GC64359@elstar.local> <20140826.151955.1338003814359491302.mbj@tail-f.com> <20140826135042.GA56223@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/tKGK1Bw6TfCZS2rjxDohVl6N5pI Cc: netmod@ietf.org Subject: Re: [netmod] metadata in 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: Tue, 26 Aug 2014 14:38:22 -0000 On 26 Aug 2014, at 15:50, Juergen Schoenwaelder = wrote: > On Tue, Aug 26, 2014 at 03:19:55PM +0200, Martin Bjorklund wrote: >> Ladislav Lhotka wrote: >>> Hi, >>>=20 >>> I would like to resolve the issue of metadata encoding in JSON, so = let >>> me summarize the options we have. There are actually two valid = questions: >>>=20 >>> 1. Does the specification of the mapping of XML attributes in JSON >>> belong to the yang-json document, and if so, in what form? >>>=20 >>> Possible answers: >>>=20 >>> 1.1. No, as YANG doesn't model XML attributes. >>> 1.2. Yes, as normative text. >>> 1.3. Yes, as non-normative text. >>=20 >> 1.2 >>=20 >>> For 1.2 and 1.3, we have to answer the second question because I = assume >>> most XML attributes in use with YANG-modelled data will have >>> non-null namespace: >>>=20 >>> 2. How do we represent the namespace of an attribute in JSON? >>>=20 >>> Possible answers, using >>>=20 >>> bar= >>>=20 >>> as an example: >>>=20 >>> 2.1. Use Clark's notation [1]: >>>=20 >>> "elem": "bar", >>> "@elem": { >>> "{http://example.com/ns/URI}attr": "foo" >>> } >>>=20 >>> 2.2. Associate somehow every attribute with a YANG module, and then = use >>> the same notation as for encoding the namespace of YANG data = nodes: >>>=20 >>> "elem": "bar", >>> "@elem": { >>> "somemodule:attr": "foo" >>> } >>>=20 >>> 2.3. Associate somehow the XML namespace URI with a prefix in JSON = and >>> then use the same notation as for XML: >>>=20 >>> "elem": "bar", >>> "@elem": { >>> "x:attr": "foo" >>> } >>=20 >> 2.1 >>=20 >> And I think the text should specify that the usage of this meta data >> must be defined by a specification that uses this mapping. This = means >> that RESTCONF must specify which attributes are supported in = RESTCONF, >> and how they are encoded (i.e. if they have a namespace or not). >>=20 >=20 > Martin, >=20 > does it make sense to have two different namespace notations? For > attributes, you seem to like to use >=20 > {} >=20 > while for regular leafs, the I-D currently says we use >=20 > : >=20 > Would it note make sense to consider being consistent, i.e., to > use >=20 > {} >=20 > as well? The counter argument I have heard so far is that module names > are likely shorter than URLs. While true, they are still way longer > than prefixes we use in XML land. Module names are also more regular in that they are YANG identifiers = whereas URIs may contain pretty much any mess. I don=92t think your = previous objection that (non-IETF) module names aren=92t guaranteed to = be unique is really relevant: a server implementing two different = modules with the same name must be considered seriously broken. 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 Tue Aug 26 07:47: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 D39BF1A802B for ; Tue, 26 Aug 2014 07:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, J_BACKHAIR_44=1, 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 v54-Tihb-cvL for ; Tue, 26 Aug 2014 07:47:52 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19C911A7D80 for ; Tue, 26 Aug 2014 07:47:52 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id v10so22687575pde.24 for ; Tue, 26 Aug 2014 07:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=jIJ17pMzjhydsV+zf9MFyGZ+G5aBypC19ngavcNy8qs=; b=qN7DMO+vkAaIaJVvR/C+9EPDgibfGH7VHHFTP7WiyxNDjbrG4jdKy5qr6uttWzZ/T4 Xw6Jr2yOymZDQ0ZV7vK2Mq+dI/5ICRFXvsVnZh9heWu6pkxmeiqwpnbyU+j8AL0xM5yy P2theKZMdxJ74FBstLfhkw83+9+sU8hIB5r/v4FeEWJkY9vdO7h9G1nPeFlZ1JLCsBfm CYcZpv/TE0mjSKQAi+y4CWZTJPc9pWUJs/u6rRiOsMbSAQEaHcs2cKgZdGNiW+a31SJq dm9hd5x7qOKEUNYXzeorVMRxpjtryEakjpryb2WCRJ/rBdR+ncCjrM9+fKeHadr9Fw+6 hipg== X-Received: by 10.70.61.162 with SMTP id q2mr37712688pdr.50.1409064471631; Tue, 26 Aug 2014 07:47:51 -0700 (PDT) Received: from [10.21.94.61] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPSA id pd7sm11158451pac.33.2014.08.26.07.47.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Aug 2014 07:47:50 -0700 (PDT) Message-ID: <53FC9E15.6060301@gmail.com> Date: Tue, 26 Aug 2014 07:47:49 -0700 From: Reinaldo Penno User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: netmod@ietf.org References: <20140730110826.GE61382@elstar.local> <20140730130412.GB61698@elstar.local> <20140731055201.GC63208@elstar.local> <5BA7630E-B06F-47B5-9ACD-92D9A3512864@nic.cz> <20140731122200.GC64359@elstar.local> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000102020005030708020307" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mz-IqKfOcrXtRgmZLSyLoyKzLIs Subject: Re: [netmod] metadata in 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: Tue, 26 Aug 2014 14:47:54 -0000 This is a multi-part message in MIME format. --------------000102020005030708020307 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I agree that vendors could define metadata as long as there is a procedure for that such as a IETF document and a IANA registry. My reasoning is that I see this metadata is much like decorators in Java. In the case of JAVA<->JSON there are multiple libraries that can do serialization and they use different decorators, therefore not very interoperable. So, we I would suggest metadata/decorators are registered somewhere and there is possibility for standard, experimental and private notations. On 8/26/14 7:19 AM, Andy Bierman wrote: > Hi, > > This issue and been opened and closed again at least 3 times. > Are we spinning on this issue until you get the answer you like? > Which choice is the solution from Martin we already agreed to use? > That is the one I prefer. The namespace URI is much longer than > the module-name, and not easy to remember like the module name. > But if YANG will not have attributes, then there may be no other choice. > > I do not agree with the CLR that only the RESTCONF protocol doc > can define meta-data. What is the purpose of that rule? NETCONF > has "with-defaults" in a separate document. The protocol > needs to be modular so new optional features can be added over time. > Vendors should be able to add meta-data as well. > > > Andy > > > On Tue, Aug 26, 2014 at 6:05 AM, Ladislav Lhotka > wrote: > > Hi, > > I would like to resolve the issue of metadata encoding in JSON, so let > me summarize the options we have. There are actually two valid > questions: > > 1. Does the specification of the mapping of XML attributes in JSON > belong to the yang-json document, and if so, in what form? > > Possible answers: > > 1.1. No, as YANG doesn't model XML attributes. > 1.2. Yes, as normative text. > 1.3. Yes, as non-normative text. > > For 1.2 and 1.3, we have to answer the second question because I > assume > most XML attributes in use with YANG-modelled data will have > non-null namespace: > > 2. How do we represent the namespace of an attribute in JSON? > > Possible answers, using > > bar > > as an example: > > 2.1. Use Clark's notation [1]: > > "elem": "bar", > "@elem": { > "{http://example.com/ns/URI}attr > ": "foo" > } > > 2.2. Associate somehow every attribute with a YANG module, and > then use > the same notation as for encoding the namespace of YANG data > nodes: > > "elem": "bar", > "@elem": { > "somemodule:attr": "foo" > } > > 2.3. Associate somehow the XML namespace URI with a prefix in JSON and > then use the same notation as for XML: > > "elem": "bar", > "@elem": { > "x:attr": "foo" > } > > In both 2.2 and 2.3, we need to say what "somehow" actually means. > If we > accept 1.3, it could I guess involve a certain amount of > hand-waving but > leaving it completely unanswered IMO makes the whole thing useless. > > I personally think that 2.3 would be a step in a wrong direction > because > the URI-prefix duality was recognized as a serious problem of XML > namespaces [2]. > > Please indicate your preferences or propose something else. > > Thanks, Lada > > [1] http://tools.ietf.org/html/draft-saintandre-json-namespaces-00 > [2] http://blog.jclark.com/2010/01/xml-namespaces.html > > Juergen Schoenwaelder > writes: > > > On Thu, Jul 31, 2014 at 10:49:07AM +0200, Ladislav Lhotka wrote: > >> > >> On 31 Jul 2014, at 07:52, Juergen Schoenwaelder > > wrote: > >> > >> > On Wed, Jul 30, 2014 at 05:53:30PM +0200, Ladislav Lhotka wrote: > >> >> > >> >>>>> understand that this makes the solution somewhat > incomplete but it > >> >>>>> allows us to finish this document now and to move forward. > >> >>>> > >> >>>> That is my priority, too. > >> >>> > >> >>> Good. So what speaks against saying that if attribute names > clash and > >> >>> if attributes are scoped by a module name, then the > encoding is XYZ? > >> >> > >> >> I thought YANG 1.1 was a good opportunity to decide about > how to do this scoping, provided that standard attributes are > really needed. > >> >> > >> > > >> > Lets keep the discussion focused on the JSON document. Are > you OK with > >> > the proposal to add text that attribute names may be scoped? > >> > >> Yes, if there is no other choice. It is unclear what “scoped” > means. > >> > > > > Scoped by a namespace, such as 'namespace:identifier'. > > > > /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 > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------000102020005030708020307 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I agree that vendors could define metadata as long as there is a procedure for that such as a IETF document and a IANA registry.

My reasoning is that I see this metadata is much like decorators in Java. In the case of JAVA<->JSON there are multiple libraries that can do serialization and they use different decorators, therefore not very interoperable. So, we I would suggest metadata/decorators are registered somewhere and there is possibility for standard, experimental and private notations.

On 8/26/14 7:19 AM, Andy Bierman wrote:
Hi,

This issue and been opened and closed again at least 3 times.
Are we spinning on this issue until you get the answer you like?
Which choice is the solution from Martin we already agreed to use?
That is the one I prefer.   The namespace URI is much longer than
the module-name, and not easy to remember like the module name.
But if YANG will not have attributes, then there may be no other choice.

I do not agree with the CLR that only the RESTCONF protocol doc
can define meta-data.  What is the purpose of that rule?  NETCONF
has "with-defaults" in a separate document.  The protocol
needs to be modular so new optional features can be added over time.
Vendors should be able to add meta-data as well.


Andy


On Tue, Aug 26, 2014 at 6:05 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
Hi,

I would like to resolve the issue of metadata encoding in JSON, so let
me summarize the options we have. There are actually two valid questions:

1. Does the specification of the mapping of XML attributes in JSON
   belong to the yang-json document, and if so, in what form?

Possible answers:

1.1. No, as YANG doesn't model XML attributes.
1.2. Yes, as normative text.
1.3. Yes, as non-normative text.

For 1.2 and 1.3, we have to answer the second question because I assume
most XML attributes in use with YANG-modelled data will have non-null namespace:

2. How do we represent the namespace of an attribute in JSON?

Possible answers, using

  <elem xmlns:x="http://example.com/ns/URI" x:attr="foo">bar</elem>

as an example:

2.1. Use Clark's notation [1]:

  "elem": "bar",
  "@elem": {
    "{http://example.com/ns/URI}attr": "foo"
  }

2.2. Associate somehow every attribute with a YANG module, and then use
     the same notation as for encoding the namespace of YANG data nodes:

  "elem": "bar",
  "@elem": {
    "somemodule:attr": "foo"
  }

2.3. Associate somehow the XML namespace URI with a prefix in JSON and
     then use the same notation as for XML:

  "elem": "bar",
  "@elem": {
    "x:attr": "foo"
  }

In both 2.2 and 2.3, we need to say what "somehow" actually means. If we
accept 1.3, it could I guess involve a certain amount of hand-waving but
leaving it completely unanswered IMO makes the whole thing useless.

I personally think that 2.3 would be a step in a wrong direction because
the URI-prefix duality was recognized as a serious problem of XML
namespaces [2].

Please indicate your preferences or propose something else.

Thanks, Lada

[1] http://tools.ietf.org/html/draft-saintandre-json-namespaces-00
[2] http://blog.jclark.com/2010/01/xml-namespaces.html

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:

> On Thu, Jul 31, 2014 at 10:49:07AM +0200, Ladislav Lhotka wrote:
>>
>> On 31 Jul 2014, at 07:52, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>>
>> > On Wed, Jul 30, 2014 at 05:53:30PM +0200, Ladislav Lhotka wrote:
>> >>
>> >>>>> understand that this makes the solution somewhat incomplete but it
>> >>>>> allows us to finish this document now and to move forward.
>> >>>>
>> >>>> That is my priority, too.
>> >>>
>> >>> Good. So what speaks against saying that if attribute names clash and
>> >>> if attributes are scoped by a module name, then the encoding is XYZ?
>> >>
>> >> I thought YANG 1.1 was a good opportunity to decide about how to do this scoping, provided that standard attributes are really needed.
>> >>
>> >
>> > Lets keep the discussion focused on the JSON document. Are you OK with
>> > the proposal to add text that attribute names may be scoped?
>>
>> Yes, if there is no other choice. It is unclear what “scoped” means.
>>
>
> Scoped by a namespace, such as 'namespace:identifier'.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

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



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

--------------000102020005030708020307-- From nobody Tue Aug 26 07:56: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 952151A86FF for ; Tue, 26 Aug 2014 07:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 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.668] 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 WHRuQ7_znxMM for ; Tue, 26 Aug 2014 07:56:11 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5261A802B for ; Tue, 26 Aug 2014 07:56:11 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 861B3141B8F; Tue, 26 Aug 2014 16:56:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409064969; bh=zuHqKeGVH92+BRWtziXJE0NLcLpGWxI8uTk0FisU5yg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=R0IjyZ/MBGLr9MaPx4qTQv1Jf4wayDX6gvE+YSEO7rYD98JpeWnp2TI9gp7PSzPsT 3R9eDKv4G8tT1X9z/eJ7hkgTIQNG+B5dJLTkAF6r8Q+ZFFAz7P5SQfNP/o4E8xq1yP xGc0QqYOK8x4VdKhnmCKuiNTuNVL+pjm4DnDcVV4= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140826.153608.405577889262820806.mbj@tail-f.com> Date: Tue, 26 Aug 2014 16:56:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140826.151955.1338003814359491302.mbj@tail-f.com> <3A525146-145D-42D8-8660-80FF6B159F0F@nic.cz> <20140826.153608.405577889262820806.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/0LGzqOfGewMaNk1HEYroaFoBsz8 Cc: netmod@ietf.org Subject: Re: [netmod] metadata in 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: Tue, 26 Aug 2014 14:56:13 -0000 On 26 Aug 2014, at 15:36, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On 26 Aug 2014, at 15:19, Martin Bjorklund wrote: >>=20 >>> Ladislav Lhotka wrote: >>>> Hi, >>>>=20 >>>> I would like to resolve the issue of metadata encoding in JSON, so = let >>>> me summarize the options we have. There are actually two valid = questions: >>>>=20 >>>> 1. Does the specification of the mapping of XML attributes in JSON >>>> belong to the yang-json document, and if so, in what form? >>>>=20 >>>> Possible answers: >>>>=20 >>>> 1.1. No, as YANG doesn't model XML attributes. >>>> 1.2. Yes, as normative text. >>>> 1.3. Yes, as non-normative text. >>>=20 >>> 1.2 >>>=20 >>>> For 1.2 and 1.3, we have to answer the second question because I = assume >>>> most XML attributes in use with YANG-modelled data will have >>>> non-null namespace: >>>>=20 >>>> 2. How do we represent the namespace of an attribute in JSON? >>>>=20 >>>> Possible answers, using >>>>=20 >>>> bar= >>>>=20 >>>> as an example: >>>>=20 >>>> 2.1. Use Clark's notation [1]: >>>>=20 >>>> "elem": "bar", >>>> "@elem": { >>>> "{http://example.com/ns/URI}attr": "foo" >>>> } >>>>=20 >>>> 2.2. Associate somehow every attribute with a YANG module, and then = use >>>> the same notation as for encoding the namespace of YANG data = nodes: >>>>=20 >>>> "elem": "bar", >>>> "@elem": { >>>> "somemodule:attr": "foo" >>>> } >>>>=20 >>>> 2.3. Associate somehow the XML namespace URI with a prefix in JSON = and >>>> then use the same notation as for XML: >>>>=20 >>>> "elem": "bar", >>>> "@elem": { >>>> "x:attr": "foo" >>>> } >>>=20 >>> 2.1 >>>=20 >>> And I think the text should specify that the usage of this meta data >>> must be defined by a specification that uses this mapping. This = means >>> that RESTCONF must specify which attributes are supported in = RESTCONF, >>> and how they are encoded (i.e. if they have a namespace or not). >>=20 >> Hmm, do you mean that the set of attributes allowed in (a given >> version of) RESTCONF will be fixed and no other attributes can be >> used? >=20 > This will be up to the RESTCONF specification - but yes, RESTCONF > probably won't need namespaces for the attributes. >=20 > But IMO it is better if the json mapping document is complete and > handle the namespace case as well. We don't know what other > specifications might want to use. I don=92t know, perhaps the document can say that those who really can=92t= do without namespaces are on their own. This is also worth reading: https://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json Let me cite one paragraph from it: "Starting with the obvious, I=92d say that if you can use JSON without = namespaces, you really, really should. In other words, if you really = need distributed extensibility, you need something like namespaces, but = for all other purposes, they should be avoided like the plague; they = make it too complex, and simplicity is the name of the game in JSON.=94 I tend to agree with you that metadata we are talking about are mostly = protocol-specific and then distributed extensibility is not needed. Lada =20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Aug 26 08:06: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 B656D1A871C for ; Tue, 26 Aug 2014 08:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_44=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2GKbJK6e_Kh for ; Tue, 26 Aug 2014 08:06:25 -0700 (PDT) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 462941A873F for ; Tue, 26 Aug 2014 08:06:08 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id i13so14011314qae.34 for ; Tue, 26 Aug 2014 08:06:07 -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=tUSZVhJPL4LaaCtR3PzotLHIT4dqY221tJ0iTI/fhRk=; b=QBT/iSAkmPWhmS2nzub/jv4WC8S4We3sKSSsQlUKPWTIzokKtetVFh25U30q6+FtCf 4Bq3UkxFAb+1lvp8Zu1P4hd4f46S/3e5jVhkTqliAWemVzhxY8XKZDimq7F8y+9F88Jz itBbsQc6a+MIQdSUVgKwsoB7dtrdHPAin2SoXKuy0ak5aX61oG9n8yTYR1OOR64+KPUp +V0OifBmWhGmbShggP9i3eVhAZj9+E+NCAELLN88VWYCp2Zfy/9oo2lMhFSx2cS4I81A 8l5K9SS85qybvVi4GBFGvsSVL5Db+LqhUMKLdapiYQWYOoe2/38J2XATMVBszeiWGS+X Vbxg== X-Gm-Message-State: ALoCoQmXE25VtSRlGD2t9eN0O0c7slyja5ZcLAiyDDvt5ofSKYrVVvo0bPV6PcIhoOa+VMuDpOjm MIME-Version: 1.0 X-Received: by 10.229.191.2 with SMTP id dk2mr45940827qcb.8.1409065567206; Tue, 26 Aug 2014 08:06:07 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Tue, 26 Aug 2014 08:06:07 -0700 (PDT) In-Reply-To: <53FC9E15.6060301@gmail.com> References: <20140730110826.GE61382@elstar.local> <20140730130412.GB61698@elstar.local> <20140731055201.GC63208@elstar.local> <5BA7630E-B06F-47B5-9ACD-92D9A3512864@nic.cz> <20140731122200.GC64359@elstar.local> <53FC9E15.6060301@gmail.com> Date: Tue, 26 Aug 2014 08:06:07 -0700 Message-ID: From: Andy Bierman To: Reinaldo Penno Content-Type: multipart/alternative; boundary=001a1133979e995b7c050189a42e Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/eLbGl8S2SkDwqNXs8eY0pOI2cq4 Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in 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: Tue, 26 Aug 2014 15:06:29 -0000 --001a1133979e995b7c050189a42e Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 26, 2014 at 7:47 AM, Reinaldo Penno wrote: > I agree that vendors could define metadata as long as there is a > procedure for that such as a IETF document and a IANA registry. > > We don't need this for XML. Why do we need it for JSON? > My reasoning is that I see this metadata is much like decorators in Java. > In the case of JAVA<->JSON there are multiple libraries that can do > serialization and they use different decorators, therefore not very > interoperable. So, we I would suggest metadata/decorators are registered > somewhere and there is possibility for standard, experimental and private > notations. > > The client parser does not need to understand the semantics of an attribute in order to be able to parse it in a reply. The client won't be sending any requests with attributes unless it is programmed to understand specific attributes. I see JSON attributes being used the same way XML attributes are being used now to represent meta-data associated with datastores. (with-defaults, enabled, etc.) If the feature is designed correctly, then it won't break clients that don't know about the attribute (client has to ask in the request for certain attributes to be present in the reply). I don't see how Java programming practices impact the operational requirements for datastores. Vendors are going to use datastore meta-data whether the standard supports it or not. Andy On 8/26/14 7:19 AM, Andy Bierman wrote: > > Hi, > > This issue and been opened and closed again at least 3 times. > Are we spinning on this issue until you get the answer you like? > Which choice is the solution from Martin we already agreed to use? > That is the one I prefer. The namespace URI is much longer than > the module-name, and not easy to remember like the module name. > But if YANG will not have attributes, then there may be no other choice. > > I do not agree with the CLR that only the RESTCONF protocol doc > can define meta-data. What is the purpose of that rule? NETCONF > has "with-defaults" in a separate document. The protocol > needs to be modular so new optional features can be added over time. > Vendors should be able to add meta-data as well. > > > Andy > > > On Tue, Aug 26, 2014 at 6:05 AM, Ladislav Lhotka wrote: > >> Hi, >> >> I would like to resolve the issue of metadata encoding in JSON, so let >> me summarize the options we have. There are actually two valid questions: >> >> 1. Does the specification of the mapping of XML attributes in JSON >> belong to the yang-json document, and if so, in what form? >> >> Possible answers: >> >> 1.1. No, as YANG doesn't model XML attributes. >> 1.2. Yes, as normative text. >> 1.3. Yes, as non-normative text. >> >> For 1.2 and 1.3, we have to answer the second question because I assume >> most XML attributes in use with YANG-modelled data will have non-null >> namespace: >> >> 2. How do we represent the namespace of an attribute in JSON? >> >> Possible answers, using >> >> bar >> >> as an example: >> >> 2.1. Use Clark's notation [1]: >> >> "elem": "bar", >> "@elem": { >> "{http://example.com/ns/URI}attr": "foo" >> } >> >> 2.2. Associate somehow every attribute with a YANG module, and then use >> the same notation as for encoding the namespace of YANG data nodes: >> >> "elem": "bar", >> "@elem": { >> "somemodule:attr": "foo" >> } >> >> 2.3. Associate somehow the XML namespace URI with a prefix in JSON and >> then use the same notation as for XML: >> >> "elem": "bar", >> "@elem": { >> "x:attr": "foo" >> } >> >> In both 2.2 and 2.3, we need to say what "somehow" actually means. If we >> accept 1.3, it could I guess involve a certain amount of hand-waving but >> leaving it completely unanswered IMO makes the whole thing useless. >> >> I personally think that 2.3 would be a step in a wrong direction because >> the URI-prefix duality was recognized as a serious problem of XML >> namespaces [2]. >> >> Please indicate your preferences or propose something else. >> >> Thanks, Lada >> >> [1] http://tools.ietf.org/html/draft-saintandre-json-namespaces-00 >> [2] http://blog.jclark.com/2010/01/xml-namespaces.html >> >> Juergen Schoenwaelder writes: >> >> > On Thu, Jul 31, 2014 at 10:49:07AM +0200, Ladislav Lhotka wrote: >> >> >> >> On 31 Jul 2014, at 07:52, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: >> >> >> >> > On Wed, Jul 30, 2014 at 05:53:30PM +0200, Ladislav Lhotka wrote: >> >> >> >> >> >>>>> understand that this makes the solution somewhat incomplete but >> it >> >> >>>>> allows us to finish this document now and to move forward. >> >> >>>> >> >> >>>> That is my priority, too. >> >> >>> >> >> >>> Good. So what speaks against saying that if attribute names clash >> and >> >> >>> if attributes are scoped by a module name, then the encoding is >> XYZ? >> >> >> >> >> >> I thought YANG 1.1 was a good opportunity to decide about how to do >> this scoping, provided that standard attributes are really needed. >> >> >> >> >> > >> >> > Lets keep the discussion focused on the JSON document. Are you OK >> with >> >> > the proposal to add text that attribute names may be scoped? >> >> >> >> Yes, if there is no other choice. It is unclear what "scoped" means. >> >> >> > >> > Scoped by a namespace, such as 'namespace:identifier'. >> > >> > /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 >> > > > > _______________________________________________ > netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --001a1133979e995b7c050189a42e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Aug 26, 2014 at 7:47 AM, Reinaldo Penno &= lt;rapenno@gmail.com= > wrote:
=20 =20 =20
I agree that vendors could define metadata as long as there is a procedure for that such as a IETF document and a IANA registry.


We don't need this for X= ML. Why do we need it for JSON?

 
My reasoning is that I see this metadata is much like decorators in Java. In the case of JAVA<->JSON there are multiple libraries that can do serialization and they use different decorators, therefore not very interoperable. So, we I would suggest metadata/decorators are registered somewhere and there is possibility for standard, experimental and private notations.


The client parser does not n= eed to understand the semantics of an attribute in order to be able
to parse it in a reply.   The client won't be sending any reque= sts with attributes unless
it is programmed to understand specific attributes.

I see JSON attributes being used the same way XML attributes are bei= ng used now
to represent meta-data associated with datastores. &n= bsp;(with-defaults, enabled, etc.)
If the feature is designed correctly, then it won't break clients = that don't
know about the attribute (client has to ask in the= request for certain attributes
to be present in the reply).

I don't see how Java programming practices impact t= he operational requirements for datastores.
Vendors are going to = use datastore meta-data whether the standard supports it or not.


Andy


On 8/26/14 7:19 AM, Andy Bierman wrote:
Hi,

This issue and been opened and closed again at least 3 times.
Are we spinning on this issue until you get the answer you like?
Which choice is the solution from Martin we already agreed to use?
That is the one I prefer.   The namespace URI is much longer than
the module-name, and not easy to remember like the module name.
But if YANG will not have attributes, then there may be no other choice.

I do not agree with the CLR that only the RESTCONF protocol doc
can define meta-data.  What is the purpose of that rule?  NETCONF
has "with-defaults" in a separate document.  Th= e protocol
needs to be modular so new optional features can be added over time.
Vendors should be able to add meta-data as well.


Andy


On Tue, Aug 26, 2014 at 6:05 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
Hi,

I would like to resolve the issue of metadata encoding in JSON, so let
me summarize the options we have. There are actually two valid questions:

1. Does the specification of the mapping of XML attributes in JSON
   belong to the yang-json document, and if so, i= n what form?

Possible answers:

1.1. No, as YANG doesn't model XML attributes.
1.2. Yes, as normative text.
1.3. Yes, as non-normative text.

For 1.2 and 1.3, we have to answer the second question because I assume
most XML attributes in use with YANG-modelled data will have non-null namespace:

2. How do we represent the namespace of an attribute in JSON?

Possible answers, using

  <elem xmlns:x=3D"http://example.com/ns/URI" x:attr=3D"foo">bar</elem>

as an example:

2.1. Use Clark's notation [1]:

  "elem": "bar",
  "@elem": {
    "{http://example.com/ns/URI}attr": "foo"
  }

2.2. Associate somehow every attribute with a YANG module, and then use
     the same notation as for encoding the n= amespace of YANG data nodes:

  "elem": "bar",
  "@elem": {
    "somemodule:attr": "foo"<= br>   }

2.3. Associate somehow the XML namespace URI with a prefix in JSON and
     then use the same notation as for XML:<= br>
  "elem": "bar",
  "@elem": {
    "x:attr": "foo"
  }

In both 2.2 and 2.3, we need to say what "somehow"= ; actually means. If we
accept 1.3, it could I guess involve a certain amount of hand-waving but
leaving it completely unanswered IMO makes the whole thing useless.

I personally think that 2.3 would be a step in a wrong direction because
the URI-prefix duality was recognized as a serious problem of XML
namespaces [2].

Please indicate your preferences or propose something else.

Thanks, Lada

[1] http://tools.ietf.org/html/draft-sain= tandre-json-namespaces-00
[2] http://blog.jclark.com/2010/01/xml-namespaces.htm= l

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.= de> writes:

> On Thu, Jul 31, 2014 at 10:49:07AM +0200, Ladislav Lhotka wrote:
>>
>> On 31 Jul 2014, at 07:52, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>>
>> > On Wed, Jul 30, 2014 at 05:53:30PM +0200, Ladislav Lhotka wrote:
>> >>
>> >>>>> understand that this makes the solution somewhat incomplete but it
>> >>>>> allows us to finish this document now and to move forward.
>> >>>>
>> >>>> That is my priority, too.
>> >>>
>> >>> Good. So what speaks against saying that if attribute names clash and
>> >>> if attributes are scoped by a module name, then the encoding is XYZ?
>> >>
>> >> I thought YANG 1.1 was a good opportunity to decide about how to do this scoping, provided that standard attributes are really needed.
>> >>
>> >
>> > Lets keep the discussion focused on the JSON document. Are you OK with
>> > the proposal to add text that attribute names may be scoped?
>>
>> Yes, if there is no other choice. It is unclear what “scoped” means.
>>
>
> Scoped by a namespace, such as 'namespace:identifier'.
>
> /js
>
> --
> Juergen Schoenwaelder        &= nbsp;  Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587       =  Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103    &nb= sp;    <http://www.jacobs-university.de/>

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



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


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


--001a1133979e995b7c050189a42e-- From nobody Tue Aug 26 08:14: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 B67A71A871F for ; Tue, 26 Aug 2014 08:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, J_BACKHAIR_44=1, 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 Xu_5FXtGxnLe for ; Tue, 26 Aug 2014 08:14:36 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B73BF1A8728 for ; Tue, 26 Aug 2014 08:14:25 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id rd3so23452282pab.0 for ; Tue, 26 Aug 2014 08:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=QmjEPrSjXOmsvfrYUqV7ovnbeDITny9eNuxlSI3lHTQ=; b=VBIpCTGsQsKR07a8cecsL2XyVrAIkbu0Lht6rINCeAAWf3CzUllNOn5XRaKwBcPsW2 FhZ2pVL5EPcKVwLfLqXrsJJLfgGP7gi0a30OIxGaz/0QsQl4Z++xm9gyes8I2mxRF6U/ MccQbAXv0sZzOoXJ3WTA7Lg8HpqmY+wRiZIv5WJQ8p/ZmI3iysHBFSbzR1aPFi5w8l2V KPlnDhChdjZM5etsQN2+WvfnXAo9iQSKloI77Yo2XpXqoT1Op4gDRyJXKqEaTJJyNLLt 9tAcBoxyPyDahJ+5FF5IRtxDINQSMCwNh/CxbqbWJzMoErj6BClAiyRH0K7nuNX0ZcVb IIhw== X-Received: by 10.66.176.97 with SMTP id ch1mr37127795pac.101.1409066065309; Tue, 26 Aug 2014 08:14:25 -0700 (PDT) Received: from ?IPv6:2001:420:c0c8:1007::67f? ([2001:420:c0c8:1007::67f]) by mx.google.com with ESMTPSA id s8sm5192386pdj.54.2014.08.26.08.14.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Aug 2014 08:14:24 -0700 (PDT) Message-ID: <53FCA44E.3020105@gmail.com> Date: Tue, 26 Aug 2014 08:14:22 -0700 From: Reinaldo Penno User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Andy Bierman References: <20140730110826.GE61382@elstar.local> <20140730130412.GB61698@elstar.local> <20140731055201.GC63208@elstar.local> <5BA7630E-B06F-47B5-9ACD-92D9A3512864@nic.cz> <20140731122200.GC64359@elstar.local> <53FC9E15.6060301@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050605090908080100020406" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/eBUjjDJhxr19Ngn0sf50ikj_aP4 Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in 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: Tue, 26 Aug 2014 15:14:39 -0000 This is a multi-part message in MIME format. --------------050605090908080100020406 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 8/26/14 8:06 AM, Andy Bierman wrote: > > > > On Tue, Aug 26, 2014 at 7:47 AM, Reinaldo Penno > wrote: > > I agree that vendors could define metadata as long as there is a > procedure for that such as a IETF document and a IANA registry. > > > We don't need this for XML. Why do we need it for JSON? [RP] Because the metadata work for JSON is being done in the IETF > > > My reasoning is that I see this metadata is much like decorators > in Java. In the case of JAVA<->JSON there are multiple libraries > that can do serialization and they use different decorators, > therefore not very interoperable. So, we I would suggest > metadata/decorators are registered somewhere and there is > possibility for standard, experimental and private notations. > > > The client parser does not need to understand the semantics of an > attribute in order to be able > to parse it in a reply. [RP] That should be true. > The client won't be sending any requests with attributes unless > it is programmed to understand specific attributes. [RP] Yes... > > I see JSON attributes being used the same way XML attributes are being > used now > to represent meta-data associated with datastores. (with-defaults, > enabled, etc.) > If the feature is designed correctly, then it won't break clients that > don't > know about the attribute (client has to ask in the request for certain > attributes > to be present in the reply). [RP] Standards based attributes could be present in request or response without necessary a previous request, much like certain HTTP headers, or X-based HTTP headers. This goes back to my previous point about IANA registry. > > I don't see how Java programming practices impact the operational > requirements for datastores. > Vendors are going to use datastore meta-data whether the standard > supports it or not. > > > Andy > > > On 8/26/14 7:19 AM, Andy Bierman wrote: >> Hi, >> >> This issue and been opened and closed again at least 3 times. >> Are we spinning on this issue until you get the answer you like? >> Which choice is the solution from Martin we already agreed to use? >> That is the one I prefer. The namespace URI is much longer than >> the module-name, and not easy to remember like the module name. >> But if YANG will not have attributes, then there may be no other >> choice. >> >> I do not agree with the CLR that only the RESTCONF protocol doc >> can define meta-data. What is the purpose of that rule? NETCONF >> has "with-defaults" in a separate document. The protocol >> needs to be modular so new optional features can be added over time. >> Vendors should be able to add meta-data as well. >> >> >> Andy >> >> >> On Tue, Aug 26, 2014 at 6:05 AM, Ladislav Lhotka > > wrote: >> >> Hi, >> >> I would like to resolve the issue of metadata encoding in >> JSON, so let >> me summarize the options we have. There are actually two >> valid questions: >> >> 1. Does the specification of the mapping of XML attributes in >> JSON >> belong to the yang-json document, and if so, in what form? >> >> Possible answers: >> >> 1.1. No, as YANG doesn't model XML attributes. >> 1.2. Yes, as normative text. >> 1.3. Yes, as non-normative text. >> >> For 1.2 and 1.3, we have to answer the second question >> because I assume >> most XML attributes in use with YANG-modelled data will have >> non-null namespace: >> >> 2. How do we represent the namespace of an attribute in JSON? >> >> Possible answers, using >> >> > x:attr="foo">bar >> >> as an example: >> >> 2.1. Use Clark's notation [1]: >> >> "elem": "bar", >> "@elem": { >> "{http://example.com/ns/URI}attr >> ": "foo" >> } >> >> 2.2. Associate somehow every attribute with a YANG module, >> and then use >> the same notation as for encoding the namespace of YANG >> data nodes: >> >> "elem": "bar", >> "@elem": { >> "somemodule:attr": "foo" >> } >> >> 2.3. Associate somehow the XML namespace URI with a prefix in >> JSON and >> then use the same notation as for XML: >> >> "elem": "bar", >> "@elem": { >> "x:attr": "foo" >> } >> >> In both 2.2 and 2.3, we need to say what "somehow" actually >> means. If we >> accept 1.3, it could I guess involve a certain amount of >> hand-waving but >> leaving it completely unanswered IMO makes the whole thing >> useless. >> >> I personally think that 2.3 would be a step in a wrong >> direction because >> the URI-prefix duality was recognized as a serious problem of XML >> namespaces [2]. >> >> Please indicate your preferences or propose something else. >> >> Thanks, Lada >> >> [1] >> http://tools.ietf.org/html/draft-saintandre-json-namespaces-00 >> [2] http://blog.jclark.com/2010/01/xml-namespaces.html >> >> Juergen Schoenwaelder > > writes: >> >> > On Thu, Jul 31, 2014 at 10:49:07AM +0200, Ladislav Lhotka >> wrote: >> >> >> >> On 31 Jul 2014, at 07:52, Juergen Schoenwaelder >> > > wrote: >> >> >> >> > On Wed, Jul 30, 2014 at 05:53:30PM +0200, Ladislav >> Lhotka wrote: >> >> >> >> >> >>>>> understand that this makes the solution somewhat >> incomplete but it >> >> >>>>> allows us to finish this document now and to move >> forward. >> >> >>>> >> >> >>>> That is my priority, too. >> >> >>> >> >> >>> Good. So what speaks against saying that if attribute >> names clash and >> >> >>> if attributes are scoped by a module name, then the >> encoding is XYZ? >> >> >> >> >> >> I thought YANG 1.1 was a good opportunity to decide >> about how to do this scoping, provided that standard >> attributes are really needed. >> >> >> >> >> > >> >> > Lets keep the discussion focused on the JSON document. >> Are you OK with >> >> > the proposal to add text that attribute names may be scoped? >> >> >> >> Yes, if there is no other choice. It is unclear what >> “scoped” means. >> >> >> > >> > Scoped by a namespace, such as 'namespace:identifier'. >> > >> > /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 >> >> >> >> >> _______________________________________________ >> 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 > > --------------050605090908080100020406 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 8/26/14 8:06 AM, Andy Bierman wrote:



On Tue, Aug 26, 2014 at 7:47 AM, Reinaldo Penno <rapenno@gmail.com> wrote:
I agree that vendors could define metadata as long as there is a procedure for that such as a IETF document and a IANA registry.


We don't need this for XML. Why do we need it for JSON?

[RP] Because the metadata work for JSON is being done in the IETF


 
My reasoning is that I see this metadata is much like decorators in Java. In the case of JAVA<->JSON there are multiple libraries that can do serialization and they use different decorators, therefore not very interoperable. So, we I would suggest metadata/decorators are registered somewhere and there is possibility for standard, experimental and private notations.


The client parser does not need to understand the semantics of an attribute in order to be able
to parse it in a reply.  

[RP] That should be true.

The client won't be sending any requests with attributes unless
it is programmed to understand specific attributes.

[RP] Yes...


I see JSON attributes being used the same way XML attributes are being used now
to represent meta-data associated with datastores.  (with-defaults, enabled, etc.)
If the feature is designed correctly, then it won't break clients that don't
know about the attribute (client has to ask in the request for certain attributes
to be present in the reply).

[RP] Standards based attributes could be present in request or response without necessary a previous request, much like certain HTTP headers, or X-based HTTP headers. This goes back to my previous point about IANA registry.


I don't see how Java programming practices impact the operational requirements for datastores.
Vendors are going to use datastore meta-data whether the standard supports it or not.


Andy


On 8/26/14 7:19 AM, Andy Bierman wrote:
Hi,

This issue and been opened and closed again at least 3 times.
Are we spinning on this issue until you get the answer you like?
Which choice is the solution from Martin we already agreed to use?
That is the one I prefer.   The namespace URI is much longer than
the module-name, and not easy to remember like the module name.
But if YANG will not have attributes, then there may be no other choice.

I do not agree with the CLR that only the RESTCONF protocol doc
can define meta-data.  What is the purpose of that rule?  NETCONF
has "with-defaults" in a separate document.  The protocol
needs to be modular so new optional features can be added over time.
Vendors should be able to add meta-data as well.


Andy


On Tue, Aug 26, 2014 at 6:05 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
Hi,

I would like to resolve the issue of metadata encoding in JSON, so let
me summarize the options we have. There are actually two valid questions:

1. Does the specification of the mapping of XML attributes in JSON
   belong to the yang-json document, and if so, in what form?

Possible answers:

1.1. No, as YANG doesn't model XML attributes.
1.2. Yes, as normative text.
1.3. Yes, as non-normative text.

For 1.2 and 1.3, we have to answer the second question because I assume
most XML attributes in use with YANG-modelled data will have non-null namespace:

2. How do we represent the namespace of an attribute in JSON?

Possible answers, using

  <elem xmlns:x="http://example.com/ns/URI" x:attr="foo">bar</elem>

as an example:

2.1. Use Clark's notation [1]:

  "elem": "bar",
  "@elem": {
    "{http://example.com/ns/URI}attr": "foo"
  }

2.2. Associate somehow every attribute with a YANG module, and then use
     the same notation as for encoding the namespace of YANG data nodes:

  "elem": "bar",
  "@elem": {
    "somemodule:attr": "foo"
  }

2.3. Associate somehow the XML namespace URI with a prefix in JSON and
     then use the same notation as for XML:

  "elem": "bar",
  "@elem": {
    "x:attr": "foo"
  }

In both 2.2 and 2.3, we need to say what "somehow" actually means. If we
accept 1.3, it could I guess involve a certain amount of hand-waving but
leaving it completely unanswered IMO makes the whole thing useless.

I personally think that 2.3 would be a step in a wrong direction because
the URI-prefix duality was recognized as a serious problem of XML
namespaces [2].

Please indicate your preferences or propose something else.

Thanks, Lada

[1] http://tools.ietf.org/html/draft-saintandre-json-namespaces-00
[2] http://blog.jclark.com/2010/01/xml-namespaces.html

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:

> On Thu, Jul 31, 2014 at 10:49:07AM +0200, Ladislav Lhotka wrote:
>>
>> On 31 Jul 2014, at 07:52, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>>
>> > On Wed, Jul 30, 2014 at 05:53:30PM +0200, Ladislav Lhotka wrote:
>> >>
>> >>>>> understand that this makes the solution somewhat incomplete but it
>> >>>>> allows us to finish this document now and to move forward.
>> >>>>
>> >>>> That is my priority, too.
>> >>>
>> >>> Good. So what speaks against saying that if attribute names clash and
>> >>> if attributes are scoped by a module name, then the encoding is XYZ?
>> >>
>> >> I thought YANG 1.1 was a good opportunity to decide about how to do this scoping, provided that standard attributes are really needed.
>> >>
>> >
>> > Lets keep the discussion focused on the JSON document. Are you OK with
>> > the proposal to add text that attribute names may be scoped?
>>
>> Yes, if there is no other choice. It is unclear what “scoped” means.
>>
>
> Scoped by a namespace, such as 'namespace:identifier'.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

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



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


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



--------------050605090908080100020406-- From nobody Tue Aug 26 08:51: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 B1A591A8730 for ; Tue, 26 Aug 2014 08:51:34 -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 5Q02TsYRo1uO for ; Tue, 26 Aug 2014 08:51:31 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 716BC1A8716 for ; Tue, 26 Aug 2014 08:51:31 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id m20so15874526qcx.10 for ; Tue, 26 Aug 2014 08:51: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=L9mT3uloQCXtUPM+CcU2O1Jmh0UtHJOsUdDcQ6FxVNg=; b=MzxTdh9fFGlrg0Z11c5dob/dM93v1c+zErH0zB3wz3jMQXqV3Pdv4K/i7PFK2NUMgG 7gv4EIQvGz8lfJLpIKlDXnB02BSXlrySVhaWSBOJUo8jqPbmlYPeTDgVbbhraVPS3hJv F5TUlio9cme+KohUzkAvxnnKrX+33RKlBDqm3PdDzKjsOQbdmomJeCG2VqTKZAxACtjX 0YKxvGfKxkNvUDHteEgrPJUnCO1oG3L5IQvofc41yAJZQ431HBZbdVZr6o5X3pAty0vV rdNKb8oEp83VdxRZovvNd8rBg0jOzdJoazRfP0x739DUkjboWfS+wqU2DuW/JNGkwam2 8sVw== X-Gm-Message-State: ALoCoQmrW/pJvMMNB42mq3Hec3OZZiBcLtuWRJQ/fU2Rt5L0GDuz9nSg7NKjfgpjoRYUkzs4x4Mi MIME-Version: 1.0 X-Received: by 10.140.98.147 with SMTP id o19mr4227029qge.21.1409068290550; Tue, 26 Aug 2014 08:51:30 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Tue, 26 Aug 2014 08:51:30 -0700 (PDT) In-Reply-To: References: <20140826.151955.1338003814359491302.mbj@tail-f.com> <3A525146-145D-42D8-8660-80FF6B159F0F@nic.cz> <20140826.153608.405577889262820806.mbj@tail-f.com> Date: Tue, 26 Aug 2014 08:51:30 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113a923cec4beb05018a46a2 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xhw_bYB1npUpYVwAZ__zx7uwBfg Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in 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: Tue, 26 Aug 2014 15:51:34 -0000 --001a113a923cec4beb05018a46a2 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 26, 2014 at 7:56 AM, Ladislav Lhotka wrote: > > On 26 Aug 2014, at 15:36, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > >> > >> On 26 Aug 2014, at 15:19, Martin Bjorklund wrote: > >> > >>> Ladislav Lhotka wrote: > >>>> Hi, > >>>> > >>>> I would like to resolve the issue of metadata encoding in JSON, so let > >>>> me summarize the options we have. There are actually two valid > questions: > >>>> > >>>> 1. Does the specification of the mapping of XML attributes in JSON > >>>> belong to the yang-json document, and if so, in what form? > >>>> > >>>> Possible answers: > >>>> > >>>> 1.1. No, as YANG doesn't model XML attributes. > >>>> 1.2. Yes, as normative text. > >>>> 1.3. Yes, as non-normative text. > >>> > >>> 1.2 > >>> > >>>> For 1.2 and 1.3, we have to answer the second question because I > assume > >>>> most XML attributes in use with YANG-modelled data will have > >>>> non-null namespace: > >>>> > >>>> 2. How do we represent the namespace of an attribute in JSON? > >>>> > >>>> Possible answers, using > >>>> > >>>> bar > >>>> > >>>> as an example: > >>>> > >>>> 2.1. Use Clark's notation [1]: > >>>> > >>>> "elem": "bar", > >>>> "@elem": { > >>>> "{http://example.com/ns/URI}attr": "foo" > >>>> } > >>>> > >>>> 2.2. Associate somehow every attribute with a YANG module, and then > use > >>>> the same notation as for encoding the namespace of YANG data nodes: > >>>> > >>>> "elem": "bar", > >>>> "@elem": { > >>>> "somemodule:attr": "foo" > >>>> } > >>>> > >>>> 2.3. Associate somehow the XML namespace URI with a prefix in JSON and > >>>> then use the same notation as for XML: > >>>> > >>>> "elem": "bar", > >>>> "@elem": { > >>>> "x:attr": "foo" > >>>> } > >>> > >>> 2.1 > >>> > >>> And I think the text should specify that the usage of this meta data > >>> must be defined by a specification that uses this mapping. This means > >>> that RESTCONF must specify which attributes are supported in RESTCONF, > >>> and how they are encoded (i.e. if they have a namespace or not). > >> > >> Hmm, do you mean that the set of attributes allowed in (a given > >> version of) RESTCONF will be fixed and no other attributes can be > >> used? > > > > This will be up to the RESTCONF specification - but yes, RESTCONF > > probably won't need namespaces for the attributes. > > > > But IMO it is better if the json mapping document is complete and > > handle the namespace case as well. We don't know what other > > specifications might want to use. > > I don't know, perhaps the document can say that those who really can't do > without namespaces are on their own. This is also worth reading: > > https://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json > > Let me cite one paragraph from it: > > "Starting with the obvious, I'd say that if you can use JSON without > namespaces, you really, really should. In other words, if you really need > distributed extensibility, you need something like namespaces, but for all > other purposes, they should be avoided like the plague; they make it too > complex, and simplicity is the name of the game in JSON." > > Too bad we can't just force the use-cases to change to match our solutions. We want "distributed naming authority" instead of "centralized naming authority". This allows multiple vendors and SDOs to create modules independently with near-zero possibility of naming collisions. I agree we pay a lot for this feature, but it is important. I tend to agree with you that metadata we are talking about are mostly > protocol-specific and then distributed extensibility is not needed. > > ??? How do I tell the difference between the standard "with-defaults" attribute and some vendor attribute with the same name? I am more concerned about URI query parameter extensions than attributes. You should expect to see lots more of those than custom attributes. Lada > > > > Andy > > > > /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a113a923cec4beb05018a46a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Aug 26, 2014 at 7:56 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

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

> Ladislav Lhotka <lhotka@nic.cz= > wrote:
>>
>> On 26 Aug 2014, at 15:19, Martin Bjorklund <mbj@tail-f.com> wrote:
>>
>>> Ladislav Lhotka <lhotka@ni= c.cz> wrote:
>>>> Hi,
>>>>
>>>> I would like to resolve the issue of metadata encoding in = JSON, so let
>>>> me summarize the options we have. There are actually two v= alid questions:
>>>>
>>>> 1. Does the specification of the mapping of XML attributes= in JSON
>>>>  belong to the yang-json document, and if so, in what= form?
>>>>
>>>> Possible answers:
>>>>
>>>> 1.1. No, as YANG doesn't model XML attributes.
>>>> 1.2. Yes, as normative text.
>>>> 1.3. Yes, as non-normative text.
>>>
>>> 1.2
>>>
>>>> For 1.2 and 1.3, we have to answer the second question bec= ause I assume
>>>> most XML attributes in use with YANG-modelled data will ha= ve
>>>> non-null namespace:
>>>>
>>>> 2. How do we represent the namespace of an attribute in JS= ON?
>>>>
>>>> Possible answers, using
>>>>
>>>> <elem xmlns:x=3D"http://example.com/ns/URI" x:attr=3D"f= oo">bar</elem>
>>>>
>>>> as an example:
>>>>
>>>> 2.1. Use Clark's notation [1]:
>>>>
>>>> "elem": "bar",
>>>> "@elem": {
>>>>   "{http://example.com/ns/URI}attr": "foo&q= uot;
>>>> }
>>>>
>>>> 2.2. Associate somehow every attribute with a YANG module,= and then use
>>>>    the same notation as for encoding the namespa= ce of YANG data nodes:
>>>>
>>>> "elem": "bar",
>>>> "@elem": {
>>>>   "somemodule:attr": "foo" >>>> }
>>>>
>>>> 2.3. Associate somehow the XML namespace URI with a prefix= in JSON and
>>>>    then use the same notation as for XML:
>>>>
>>>> "elem": "bar",
>>>> "@elem": {
>>>>   "x:attr": "foo"
>>>> }
>>>
>>> 2.1
>>>
>>> And I think the text should specify that the usage of this met= a data
>>> must be defined by a specification that uses this mapping.&nbs= p; This means
>>> that RESTCONF must specify which attributes are supported in R= ESTCONF,
>>> and how they are encoded (i.e. if they have a namespace or not= ).
>>
>> Hmm, do you mean that the set of attributes allowed in (a given >> version of) RESTCONF will be fixed and no other attributes can be<= br> >> used?
>
> This will be up to the RESTCONF specification - but yes, RESTCONF
> probably won't need namespaces for the attributes.
>
> But IMO it is better if the json mapping document is complete and
> handle the namespace case as well.  We don't know what other<= br> > specifications might want to use.

I don’t know, perhaps the document can say that those who really can&= rsquo;t do without namespaces are on their own. This is also worth reading:=

https://www.mnot.net/blog/2011/10/12/thinking_abo= ut_namespaces_in_json

Let me cite one paragraph from it:

"Starting with the obvious, I’d say that if you can use JSON wit= hout namespaces, you really, really should. In other words, if you really n= eed distributed extensibility, you need something like namespaces, but for = all other purposes, they should be avoided like the plague; they make it to= o complex, and simplicity is the name of the game in JSON.”


Too bad we can't just force the us= e-cases to change to match our solutions.
We want "distribut= ed naming authority" instead of "centralized naming authority&quo= t;.
This allows multiple vendors and SDOs to create modules independently = with near-zero
possibility of naming collisions.

I agree we pay a lot for this feature, but it is important.


I tend to agree with you that metadata we are talking about are mostly prot= ocol-specific and then distributed extensibility is not needed.


???
How do I tell the differ= ence between the standard "with-defaults" attribute
and= some vendor attribute with the same name?

I am mo= re concerned about URI query parameter extensions than attributes.
You should expect to see lots more of those than custom attributes.


Lada

>


Andy
&nbs= p;
>
> /martin

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




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

--001a113a923cec4beb05018a46a2-- From nobody Tue Aug 26 09:34: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 64E841A00BE for ; Tue, 26 Aug 2014 09:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id St2m_AhwfftZ for ; Tue, 26 Aug 2014 09:34:32 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D83C1A008F for ; Tue, 26 Aug 2014 09:34: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 E82418A3; Tue, 26 Aug 2014 18:34:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id faGGT2kfPz32; Tue, 26 Aug 2014 18:34:28 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 26 Aug 2014 18:34:29 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B029A20035; Tue, 26 Aug 2014 18:34:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 07GaKn23ECET; Tue, 26 Aug 2014 18:34:29 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC13920033; Tue, 26 Aug 2014 18:34:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B69F02E5046A; Tue, 26 Aug 2014 18:34:27 +0200 (CEST) Date: Tue, 26 Aug 2014 18:34:27 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140826163426.GA56502@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin =?iso-8859-1?Q?Bj=F6rklund?= , netmod@ietf.org References: <20140826.151955.1338003814359491302.mbj@tail-f.com> <3A525146-145D-42D8-8660-80FF6B159F0F@nic.cz> <20140826.153608.405577889262820806.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/EjyqOX93aJTNUXEvXX6_HUDapjE Cc: netmod@ietf.org Subject: Re: [netmod] metadata in JSON 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, 26 Aug 2014 16:34:34 -0000 On Tue, Aug 26, 2014 at 04:56:03PM +0200, Ladislav Lhotka wrote: > > I don’t know, perhaps the document can say that those who really can’t do without namespaces are on their own. This is also worth reading: > > https://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json > > Let me cite one paragraph from it: > > "Starting with the obvious, I’d say that if you can use JSON without namespaces, you really, really should. In other words, if you really need distributed extensibility, you need something like namespaces, but for all other purposes, they should be avoided like the plague; they make it too complex, and simplicity is the name of the game in JSON.†> > I tend to agree with you that metadata we are talking about are mostly protocol-specific and then distributed extensibility is not needed. > Unfortunately, name collisions will happen. So we need to deal with namespaces and (speaking as technical contributor) I prefer a solution that is solving this problem in a consistent manner. Even if your assumption is correct that metadata is mostly protocol-specific, this does not guarantee that meta-data attribute names will be collision free. If we go with YANG module names as namespaces in JSON, another option is to say that the general format is [:]. For YANG defined names, the namespace is the module name while for names not defined in YANG modules (like attribute names), it is unspecified how namespaces with low collision probability will be derived. We could provide guidelines about possible ways to choose namespaces with low collision probability. My understanding is that the JSON I-D only requires to use explicit namespaces if there is actually a name collision. So ideally, namespace qualification would be rather an exception than the default. Perhaps advice should be given that vendor extensions for meta data should pick names that likely won't collide with a future standard usage. /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 Aug 26 09:39: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 EA8DB1A002B for ; Tue, 26 Aug 2014 09:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 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.668] 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 6dif8oqk9vtF for ; Tue, 26 Aug 2014 09:39:28 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286BF1A000A for ; Tue, 26 Aug 2014 09:39:27 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id B6689141B8B; Tue, 26 Aug 2014 18:39:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409071166; bh=+9ON7KVzUMxlHjWE5zXbt6gaHItho55+Sjv56y+LuZY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=uS/Nx1KQaRbTo6AN/L78pK4FoomSY9PeYqHzIkkrq/RLjrePqlrnqZhnEyS+UsvYA K1agTGUrvEv4iSQIeZ4DLVz+rprmt2/ggImzKMZfBhEC5d8/r+IxTejPAEFLLP8AQ+ 82uBAkEBw1ucU3zZXquRDvKj3Fi1QciakxNbllU8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 26 Aug 2014 18:39:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3A9DE0EC-0783-464B-817B-C111C6EB4C76@nic.cz> References: <20140826.151955.1338003814359491302.mbj@tail-f.com> <3A525146-145D-42D8-8660-80FF6B159F0F@nic.cz> <20140826.153608.405577889262820806.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/tmF-J4XpheO92wTPj9gQuUbOOmE Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in 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: Tue, 26 Aug 2014 16:39:30 -0000 On 26 Aug 2014, at 17:51, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Aug 26, 2014 at 7:56 AM, Ladislav Lhotka = wrote: >=20 > On 26 Aug 2014, at 15:36, Martin Bjorklund wrote: >=20 > > Ladislav Lhotka wrote: > >> > >> On 26 Aug 2014, at 15:19, Martin Bjorklund wrote: > >> > >>> Ladislav Lhotka wrote: > >>>> Hi, > >>>> > >>>> I would like to resolve the issue of metadata encoding in JSON, = so let > >>>> me summarize the options we have. There are actually two valid = questions: > >>>> > >>>> 1. Does the specification of the mapping of XML attributes in = JSON > >>>> belong to the yang-json document, and if so, in what form? > >>>> > >>>> Possible answers: > >>>> > >>>> 1.1. No, as YANG doesn't model XML attributes. > >>>> 1.2. Yes, as normative text. > >>>> 1.3. Yes, as non-normative text. > >>> > >>> 1.2 > >>> > >>>> For 1.2 and 1.3, we have to answer the second question because I = assume > >>>> most XML attributes in use with YANG-modelled data will have > >>>> non-null namespace: > >>>> > >>>> 2. How do we represent the namespace of an attribute in JSON? > >>>> > >>>> Possible answers, using > >>>> > >>>> bar > >>>> > >>>> as an example: > >>>> > >>>> 2.1. Use Clark's notation [1]: > >>>> > >>>> "elem": "bar", > >>>> "@elem": { > >>>> "{http://example.com/ns/URI}attr": "foo" > >>>> } > >>>> > >>>> 2.2. Associate somehow every attribute with a YANG module, and = then use > >>>> the same notation as for encoding the namespace of YANG data = nodes: > >>>> > >>>> "elem": "bar", > >>>> "@elem": { > >>>> "somemodule:attr": "foo" > >>>> } > >>>> > >>>> 2.3. Associate somehow the XML namespace URI with a prefix in = JSON and > >>>> then use the same notation as for XML: > >>>> > >>>> "elem": "bar", > >>>> "@elem": { > >>>> "x:attr": "foo" > >>>> } > >>> > >>> 2.1 > >>> > >>> And I think the text should specify that the usage of this meta = data > >>> must be defined by a specification that uses this mapping. This = means > >>> that RESTCONF must specify which attributes are supported in = RESTCONF, > >>> and how they are encoded (i.e. if they have a namespace or not). > >> > >> Hmm, do you mean that the set of attributes allowed in (a given > >> version of) RESTCONF will be fixed and no other attributes can be > >> used? > > > > This will be up to the RESTCONF specification - but yes, RESTCONF > > probably won't need namespaces for the attributes. > > > > But IMO it is better if the json mapping document is complete and > > handle the namespace case as well. We don't know what other > > specifications might want to use. >=20 > I don=92t know, perhaps the document can say that those who really = can=92t do without namespaces are on their own. This is also worth = reading: >=20 > https://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json >=20 > Let me cite one paragraph from it: >=20 > "Starting with the obvious, I=92d say that if you can use JSON without = namespaces, you really, really should. In other words, if you really = need distributed extensibility, you need something like namespaces, but = for all other purposes, they should be avoided like the plague; they = make it too complex, and simplicity is the name of the game in JSON.=94 >=20 >=20 > Too bad we can't just force the use-cases to change to match our = solutions. > We want "distributed naming authority" instead of "centralized naming = authority". > This allows multiple vendors and SDOs to create modules independently = with near-zero > possibility of naming collisions. This is certainly true for YANG data nodes, I am not so sure about = attributes. >=20 > I agree we pay a lot for this feature, but it is important. >=20 >=20 > I tend to agree with you that metadata we are talking about are mostly = protocol-specific and then distributed extensibility is not needed. >=20 >=20 > ??? > How do I tell the difference between the standard "with-defaults" = attribute > and some vendor attribute with the same name? How do you tell the difference between the standard HTTP =93GET=94 = method and some vendor method with the same name? If it is part of the = protocol, the vendor simply cannot use the name. >=20 > I am more concerned about URI query parameter extensions than = attributes. > You should expect to see lots more of those than custom attributes. Yes, but this has nothing to do with yang-json, right? Lada >=20 >=20 > Lada >=20 > > >=20 >=20 > Andy > =20 > > > > /martin >=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 Aug 26 09:49: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 D3F0D1A0091 for ; Tue, 26 Aug 2014 09:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfEoIfmOggoR for ; Tue, 26 Aug 2014 09:49:01 -0700 (PDT) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7361A87EF for ; Tue, 26 Aug 2014 09:43:55 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id l6so16060905qcy.11 for ; Tue, 26 Aug 2014 09:43:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=LYq2I3ib87eaLX8CYfvS01rokQYhcB9vLlZwN4P5Sso=; b=jjkuPBHi8WU9kEh3qDg5cVtqSlPDiq7uhUQ8iW/u8pSYTgOrnJ2REA3xJdHOSkc5Yx xGrjHN8wuM8e1GLVcGePv4U/2UD3nIk6d5nWUGYRl8SpFvhtVSWKCAnp+HKD516EW/6m InvwSea72jCTyqvqHcH/mKb5uZvBhQumm+YvVfgax4Fzm03i7tiJ272zoANDPX4ItC7d qomRXHtT45LJCUcwV+fsMrHORrQSV6WH8yEIHUyskoVQ3WfXSmY4zmg5U+0PlEfKaSZS Uxp0U4v7bc7Qx2/ePiW1PC+sGnnwW5LUOm4lzb3Ka7Li9kZSpBcmzIlDPr0wPF61XpKG 5+6w== X-Gm-Message-State: ALoCoQlVSb589fm1CAO1hyPz+G6IVte2uONYnGaXVHRAgbnnbW9vOkPMNinEmG3VRpZ13PjIeVX0 MIME-Version: 1.0 X-Received: by 10.140.109.116 with SMTP id k107mr44499512qgf.36.1409071434210; Tue, 26 Aug 2014 09:43:54 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Tue, 26 Aug 2014 09:43:54 -0700 (PDT) In-Reply-To: <20140826163426.GA56502@elstar.local> References: <20140826.151955.1338003814359491302.mbj@tail-f.com> <3A525146-145D-42D8-8660-80FF6B159F0F@nic.cz> <20140826.153608.405577889262820806.mbj@tail-f.com> <20140826163426.GA56502@elstar.local> Date: Tue, 26 Aug 2014 09:43:54 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Ladislav Lhotka , =?ISO-8859-1?Q?Martin_Bj=F6rklund?= , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a113ac6664d1bc205018b02e7 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2ThVSq8wan5BJn4b4WGqYEPMYDo Subject: Re: [netmod] metadata in 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: Tue, 26 Aug 2014 16:49:03 -0000 --001a113ac6664d1bc205018b02e7 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 26, 2014 at 9:34 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Aug 26, 2014 at 04:56:03PM +0200, Ladislav Lhotka wrote: > > > > I don't know, perhaps the document can say that those who really can't > do without namespaces are on their own. This is also worth reading: > > > > https://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json > > > > Let me cite one paragraph from it: > > > > "Starting with the obvious, I'd say that if you can use JSON without > namespaces, you really, really should. In other words, if you really need > distributed extensibility, you need something like namespaces, but for all > other purposes, they should be avoided like the plague; they make it too > complex, and simplicity is the name of the game in JSON." > > > > I tend to agree with you that metadata we are talking about are mostly > protocol-specific and then distributed extensibility is not needed. > > > > Unfortunately, name collisions will happen. So we need to deal with > namespaces and (speaking as technical contributor) I prefer a solution > that is solving this problem in a consistent manner. > > Even if your assumption is correct that metadata is mostly > protocol-specific, this does not guarantee that meta-data attribute > names will be collision free. > > If we go with YANG module names as namespaces in JSON, another option > is to say that the general format is [:]. For YANG > defined names, the namespace is the module name while for names not > defined in YANG modules (like attribute names), it is unspecified how > namespaces with low collision probability will be derived. We could > provide guidelines about possible ways to choose namespaces with low > collision probability. > > I like this proposal. We give the same guidance for capability URIs without specifying an exact format. > My understanding is that the JSON I-D only requires to use explicit > namespaces if there is actually a name collision. So ideally, > namespace qualification would be rather an exception than the > default. Perhaps advice should be given that vendor extensions > for meta data should pick names that likely won't collide with > a future standard usage. > > I think Lada's draft says SHOULD use where namespace changes (including top) even if there are no collisions right now. As Phil pointed out, a new module can be loaded later, which causes a new naming collision. (Then old client send /foo and it is suddenly an "ambiguous node error".) /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a113ac6664d1bc205018b02e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Aug 26, 2014 at 9:34 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Aug 26, 2014 at 04:56:03PM +0200, La= dislav Lhotka wrote:
>
> I don’t know, perhaps the document can say that those who really= can’t do without namespaces are on their own. This is also worth rea= ding:
>
> https://www.mnot.net/blog/2011/10/12/thinkin= g_about_namespaces_in_json
>
> Let me cite one paragraph from it:
>
> "Starting with the obvious, I’d say that if you can use JSO= N without namespaces, you really, really should. In other words, if you rea= lly need distributed extensibility, you need something like namespaces, but= for all other purposes, they should be avoided like the plague; they make = it too complex, and simplicity is the name of the game in JSON.”
>
> I tend to agree with you that metadata we are talking about are mostly= protocol-specific and then distributed extensibility is not needed.
>

Unfortunately, name collisions will happen. So we need to deal with
namespaces and (speaking as technical contributor) I prefer a solution
that is solving this problem in a consistent manner.

Even if your assumption is correct that metadata is mostly
protocol-specific, this does not guarantee that meta-data attribute
names will be collision free.

If we go with YANG module names as namespaces in JSON, another option
is to say that the general format is [<namespace>:]<name>. For = YANG
defined names, the namespace is the module name while for names not
defined in YANG modules (like attribute names), it is unspecified how
namespaces with low collision probability will be derived. We could
provide guidelines about possible ways to choose namespaces with low
collision probability.


I like this proposal.  We give th= e same guidance for capability URIs
without specifying an exact f= ormat.
 
My understanding is that the JSON I-D only requires to use explicit
namespaces if there is actually a name collision. So ideally,
namespace qualification would be rather an exception than the
default. Perhaps advice should be given that vendor extensions
for meta data should pick names that likely won't collide with
a future standard usage.


I think Lada's draft says SHOULD use where names= pace changes (including top)
even if there are no collisions righ= t now.  As Phil pointed out, a new module can
be loaded later, which causes a new naming collision. (Then old client= send /foo
and it is suddenly an "ambiguous node error"= .)



/js


Andy
 
--
Juergen Schoenwaelder           Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 287= 59 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacob= s-university.de/>

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

--001a113ac6664d1bc205018b02e7-- From nobody Tue Aug 26 11:26: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 B9B8A1A014D for ; Tue, 26 Aug 2014 11:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwxSF4j3v8Sj for ; Tue, 26 Aug 2014 11:25:55 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id E27371A0144 for ; Tue, 26 Aug 2014 11:25:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=FiQgxldJjJq5f3YTC0wYpicreCrTzNtSmpQGAaaST/JUfMmJvZ6rlGi4ej2bNIx7; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.39] (helo=elwamui-little.atl.sa.earthlink.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1XMLRK-0002iz-9t for netmod@ietf.org; Tue, 26 Aug 2014 14:25:54 -0400 Received: from 76.254.52.166 by webmail.earthlink.net with HTTP; Tue, 26 Aug 2014 14:25:54 -0400 Message-ID: <1315215.1409077554288.JavaMail.root@elwamui-little.atl.sa.earthlink.net> Date: Tue, 26 Aug 2014 11:25:54 -0700 (GMT-07:00) From: Randy Presuhn To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88864c4c3a38ce6fd815821a4c910b0d4b6716e3a18f0ddc94f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.39 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/CygZ5l-SjBw8Hsq_GOwcdqyZJIQ Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 18:25:56 -0000 Hi - >From: Ladislav Lhotka >Sent: Aug 26, 2014 7:38 AM >To: J=C3=BCrgen Sch=C3=B6nw=C3=A4lder >Cc: netmod@ietf.org >Subject: Re: [netmod] metadata in JSON ... >I don=E2=80=99t think your previous objection that (non-IETF) >module names aren=E2=80=99t guaranteed to be unique is really >relevant: a server implementing two different modules >with the same name must be considered seriously broken. Consider, however, (1) the *client* working with multiple servers using the same module name to refer to different things, and (2) the situation in "open" systems with components from multiple vendors installed. Randy From nobody Tue Aug 26 11:39: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 7234D1A010C for ; Tue, 26 Aug 2014 11:39:56 -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 mYpDqOr3iubE for ; Tue, 26 Aug 2014 11:39:54 -0700 (PDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E17191A01BD for ; Tue, 26 Aug 2014 11:39:53 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id j107so15020086qga.36 for ; Tue, 26 Aug 2014 11:39:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NjAoiDdkhDjE0lsIeIsEVwTGMccJaLnCZh/+LbENCNM=; b=PXY0brMBKIqKPTTgAlCQaNQDdoXo+RMaUMwix/v92+tlYpUX+cCuasZZwzVKMtaGHa e13U065uWTsnoF8P4tCqne8wDWW9VeURkGgIDP1m4R35K6spw/4elnstj3Jg6DFhe97z qKuKF02aEYQKQJj7H5GysuvTCG0tlrXiyDdntN1onrq/642YYada+B/MxMJbn40F8e1K a5WrAjqDGasqksXuJ/Xsy+Ai7pNJg52nwYk6siMp0CLLP/dcNhb8b6sNoMZmjXCTIKiX ZnIKXqUVXydiSNXTIx3vi5M8nQXZ9kWlQuFrMfQMo5ZEYh162WUfXDbSq1kT9bAzNCQR /jNA== X-Gm-Message-State: ALoCoQnaaj4ZrVIWMvyfv5jbXkYai++NhCkIz3WW1jW7mWE/79DuiSRLpFvRbieu7hUvKx+K1hyi MIME-Version: 1.0 X-Received: by 10.140.98.7 with SMTP id n7mr46411588qge.83.1409078392959; Tue, 26 Aug 2014 11:39:52 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Tue, 26 Aug 2014 11:39:52 -0700 (PDT) In-Reply-To: <1315215.1409077554288.JavaMail.root@elwamui-little.atl.sa.earthlink.net> References: <1315215.1409077554288.JavaMail.root@elwamui-little.atl.sa.earthlink.net> Date: Tue, 26 Aug 2014 11:39:52 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: multipart/alternative; boundary=001a113ac3c612cff705018ca11f Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yxbUpB6bu9ozXYS5lDQvt1tyf_A Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in 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: Tue, 26 Aug 2014 18:39:56 -0000 --001a113ac3c612cff705018ca11f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Aug 26, 2014 at 11:25 AM, Randy Presuhn < randy_presuhn@mindspring.com> wrote: > Hi - > > >From: Ladislav Lhotka > >Sent: Aug 26, 2014 7:38 AM > >To: J=FCrgen Sch=F6nw=E4lder > >Cc: netmod@ietf.org > >Subject: Re: [netmod] metadata in JSON > ... > >I don't think your previous objection that (non-IETF) > >module names aren't guaranteed to be unique is really > >relevant: a server implementing two different modules > >with the same name must be considered seriously broken. > > Consider, however, (1) the *client* working with multiple > servers using the same module name to refer to different > things, and (2) the situation in "open" systems with > components from multiple vendors installed. > > The module names are supposed to start with some string to distinguish the organization, e.g., ietf-interfaces and acme-interfaces should never clash. Randy > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a113ac3c612cff705018ca11f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Aug 26, 2014 at 11:25 AM, Randy Presuhn &= lt;randy_= presuhn@mindspring.com> wrote:
Hi -

>From: Ladislav Lhotka <lhotka@nic.c= z>
>Sent: Aug 26, 2014 7:38 AM
>To: J=FCrgen Sch=F6nw=E4lder <j.schoenwaelder@jacobs-university.de>
>Cc: netmod@ietf.org
>Subject: Re: [netmod] metadata in JSON
...
>I don’t think your previous objection that (non-IETF)
>module names aren’t guaranteed to be unique is really
>relevant: a server implementing two different modules
>with the same name must be considered seriously broken.

Consider, however, (1) the *client* working with multiple
servers using the same module name to refer to different
things, and (2) the situation in "open" systems with
components from multiple vendors installed.


The module names are supposed to start= with some string to distinguish
the organization, e.g., ietf-int= erfaces and acme-interfaces should never clash.


Randy

Andy
 

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

--001a113ac3c612cff705018ca11f-- From nobody Tue Aug 26 13: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 DE90E1A0302 for ; Tue, 26 Aug 2014 13:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 x_gGF2zDW-oL for ; Tue, 26 Aug 2014 13:28:26 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2451A02F6 for ; Tue, 26 Aug 2014 13:28:26 -0700 (PDT) Received: from localhost (s193-12-221-208.cust.tele2.se [193.12.221.208]) by mail.tail-f.com (Postfix) with ESMTPSA id 5E663128097A; Tue, 26 Aug 2014 22:25:53 +0200 (CEST) Date: Tue, 26 Aug 2014 22:28:21 +0200 (CEST) Message-Id: <20140826.222821.102112065.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140826163426.GA56502@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/8lKN5gL3huLxK9IUaKDCQxR9rOo Cc: netmod@ietf.org Subject: Re: [netmod] metadata in 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: Tue, 26 Aug 2014 20:28:28 -0000 Andy Bierman wrote: > On Tue, Aug 26, 2014 at 9:34 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Tue, Aug 26, 2014 at 04:56:03PM +0200, Ladislav Lhotka wrote: > > > > > > I don't know, perhaps the document can say that those who really can't > > do without namespaces are on their own. This is also worth reading: > > > > > > https://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json > > > > > > Let me cite one paragraph from it: > > > > > > "Starting with the obvious, I'd say that if you can use JSON without > > namespaces, you really, really should. In other words, if you really need > > distributed extensibility, you need something like namespaces, but for all > > other purposes, they should be avoided like the plague; they make it too > > complex, and simplicity is the name of the game in JSON." > > > > > > I tend to agree with you that metadata we are talking about are mostly > > protocol-specific and then distributed extensibility is not needed. > > > > > > > Unfortunately, name collisions will happen. So we need to deal with > > namespaces and (speaking as technical contributor) I prefer a solution > > that is solving this problem in a consistent manner. > > > > Even if your assumption is correct that metadata is mostly > > protocol-specific, this does not guarantee that meta-data attribute > > names will be collision free. > > > > If we go with YANG module names as namespaces in JSON, another option > > is to say that the general format is [:]. For YANG > > defined names, the namespace is the module name while for names not > > defined in YANG modules (like attribute names), it is unspecified how > > namespaces with low collision probability will be derived. We could > > provide guidelines about possible ways to choose namespaces with low > > collision probability. > > > > > I like this proposal. +1 RESTCONF still needs to specify how all standard attributes are encoded (probably w/o namespace). > We give the same guidance for capability URIs > without specifying an exact format. > > > > My understanding is that the JSON I-D only requires to use explicit > > namespaces if there is actually a name collision. So ideally, > > namespace qualification would be rather an exception than the > > default. Perhaps advice should be given that vendor extensions > > for meta data should pick names that likely won't collide with > > a future standard usage. > > > > > I think Lada's draft says SHOULD use where namespace changes (including top) > even if there are no collisions right now. As Phil pointed out, a new > module can > be loaded later, which causes a new naming collision. (Then old client send > /foo > and it is suddenly an "ambiguous node error".) I have suggested before that it should be MUST use the explicit namespace whenever the namespace changes. This gives determistic and stable names, even if modules are revised or added. /martin From nobody Wed Aug 27 00:01: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 553AF1A042D for ; Wed, 27 Aug 2014 00:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENppCXLrNqcR for ; Wed, 27 Aug 2014 00:01:09 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0AD1A0427 for ; Wed, 27 Aug 2014 00:01:08 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0A12F132B; Wed, 27 Aug 2014 09:01:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id KOafGk9SuqIl; Wed, 27 Aug 2014 09:01:04 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 27 Aug 2014 09:01:06 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4E23F20033; Wed, 27 Aug 2014 09:01:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 97nnDGdzu-0u; Wed, 27 Aug 2014 09:01:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B883020036; Wed, 27 Aug 2014 09:01:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D3F7C2E509C0; Wed, 27 Aug 2014 09:01:03 +0200 (CEST) Date: Wed, 27 Aug 2014 09:01:03 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140827070103.GA57782@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, lhotka@nic.cz, netmod@ietf.org References: <20140826163426.GA56502@elstar.local> <20140826.222821.102112065.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140826.222821.102112065.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/V21Vi_ZVijwe-CmRrki-H22FJw4 Cc: netmod@ietf.org Subject: Re: [netmod] metadata in JSON 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, 27 Aug 2014 07:01:11 -0000 On Tue, Aug 26, 2014 at 10:28:21PM +0200, Martin Bjorklund wrote: > > I have suggested before that it should be MUST use the explicit > namespace whenever the namespace changes. This gives determistic and > stable names, even if modules are revised or added. > What do you mean with "whenever the namespace changes"? The I-D currently says: The namespace identifier MUST be used for local names that are ambiguous, i.e., whenever the data model permits a sibling data node with the same local name. Otherwise, the namespace identifier is OPTIONAL. I think the phrase 'the data model permits a sibling data node with the same local name' was supposed to mean 'a server supports a sibling data node with the same local name' (and if I am correct I think this phrase should be changed since in general every YANG defined data node 'permits' a sibling data node with the same local name). So what do you mean by 'whenever the namespace changes'? I do not think the YANG to JSON I-D has a notion of a current namespace and namespace changes. /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 Aug 27 00:15: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 E3F611A046B for ; Wed, 27 Aug 2014 00:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOYor7-ZZONX for ; Wed, 27 Aug 2014 00:15:26 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C5EF1A044F for ; Wed, 27 Aug 2014 00:15:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 92E4D54075D; Wed, 27 Aug 2014 09:15:24 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdiJFBxuyt6E; Wed, 27 Aug 2014 09:15:19 +0200 (CEST) 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 98D1D540145; Wed, 27 Aug 2014 09:15:18 +0200 (CEST) From: Ladislav Lhotka To: Randy Presuhn , netmod@ietf.org In-Reply-To: <1315215.1409077554288.JavaMail.root@elwamui-little.atl.sa.earthlink.net> References: <1315215.1409077554288.JavaMail.root@elwamui-little.atl.sa.earthlink.net> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Wed, 27 Aug 2014 09:15:15 +0200 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/Wto6fnjiZqXPeyu1A9FUrLqoHgQ Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 07:15:28 -0000 Randy Presuhn writes: > Hi - > >>From: Ladislav Lhotka >>Sent: Aug 26, 2014 7:38 AM >>To: J=C3=BCrgen Sch=C3=B6nw=C3=A4lder >>Cc: netmod@ietf.org >>Subject: Re: [netmod] metadata in JSON > ... >>I don=E2=80=99t think your previous objection that (non-IETF) >>module names aren=E2=80=99t guaranteed to be unique is really >>relevant: a server implementing two different modules >>with the same name must be considered seriously broken. > > Consider, however, (1) the *client* working with multiple > servers using the same module name to refer to different > things, and (2) the situation in "open" systems with > components from multiple vendors installed. Either situation represents no real problem because explicit namespace identifiers will almost never be used - the client will just use local names. A conflict could arise only in the case when two different modules having the same name augment the same target node with sibling nodes having identical local names, and a server uses such a bizarre data model. The price we pay for it is that the client has to keep the context (i.e. the data model) for every server, but we want to do it anyway I guess. Lada > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Aug 27 00:45: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 3A3261A045C for ; Wed, 27 Aug 2014 00:45: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 y8_uvNpNR56M for ; Wed, 27 Aug 2014 00:45:07 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73B0D1A046D for ; Wed, 27 Aug 2014 00:45:07 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id w7so16798559qcr.32 for ; Wed, 27 Aug 2014 00:45:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=iqC4X7xfgIhwJd8JxvZv9NlCY/DydayvkQRWjr2j+Tc=; b=c2Ms7gPOED/UnqO3VwNVnkilqRggynPYCO7epXvl2M0CE5+xiD0Kxquapb3HqgnHv5 UH0JlO/JULaMvZTuzLvnc2E3Nb6trTaFEs+1WR3qbEiCLfzMCYeGNqfa8+c0dQ354trn A6NIqnFImLCkNFMrbqYPmX5LQ5CP+kOw53OJ8jWsZUle1874paiMWlL4TGKH5/3EwUKO W/l1W1xbM5Lr4d5c1jpt4CsdiM4CQPZ4kwk2aQ+8GysIo5HR2yI4iYMK1m1v7YygrTBy /jgZlz4HxZZZUhmNMLITi3duSbaPVbp6D+IWdv34puLne6F+Vn+dpzJ8DgunnQ0wmtwl BSpg== X-Gm-Message-State: ALoCoQk9lnUKW9su7f7f/gzQCNXoMYJnrGWQSDAtNSI/M/i0MGgkYzoJc5wXR8OhW5Dy6C1Uae7a MIME-Version: 1.0 X-Received: by 10.140.95.101 with SMTP id h92mr51241443qge.35.1409125506619; Wed, 27 Aug 2014 00:45:06 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Wed, 27 Aug 2014 00:45:06 -0700 (PDT) In-Reply-To: <20140827070103.GA57782@elstar.local> References: <20140826163426.GA56502@elstar.local> <20140826.222821.102112065.mbj@tail-f.com> <20140827070103.GA57782@elstar.local> Date: Wed, 27 Aug 2014 00:45:06 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Martin Bjorklund , Andy Bierman , Ladislav Lhotka , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c15c5044b7fa0501979987 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/8TLVDNp05KeY02ILLUv5ymhok20 Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 07:45:09 -0000 --001a11c15c5044b7fa0501979987 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 27, 2014 at 12:01 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Aug 26, 2014 at 10:28:21PM +0200, Martin Bjorklund wrote: > > > > I have suggested before that it should be MUST use the explicit > > namespace whenever the namespace changes. This gives determistic and > > stable names, even if modules are revised or added. > > > > What do you mean with "whenever the namespace changes"? The I-D > currently says: > > The namespace identifier MUST be used for local names that are > ambiguous, i.e., whenever the data model permits a sibling data node > with the same local name. Otherwise, the namespace identifier is > OPTIONAL. > > I think the phrase 'the data model permits a sibling data node with > the same local name' was supposed to mean 'a server supports a sibling > data node with the same local name' (and if I am correct I think this > phrase should be changed since in general every YANG defined data node > 'permits' a sibling data node with the same local name). > > So what do you mean by 'whenever the namespace changes'? I do not think > the YANG to JSON I-D has a notion of a current namespace and namespace > changes. > Nested nodes which result from augment-stmt from an external module. Otherwise the node is the same namespace as its parent. If there is no module-name, then the parent module-name applies. Perhaps the draft text is wrong -- there is no ambiguity determining the module name for a nested node without a prefix. It is simply the module name of its parent. Only the sibling from the external module needs a module-name to clarify its namespace. > /js > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a11c15c5044b7fa0501979987 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Aug 27, 2014 at 12:01 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Aug 26, 2014 at 10:28:21PM +0200, Ma= rtin Bjorklund wrote:
>
> I have suggested before that it should be MUST use the explicit
> namespace whenever the namespace changes.=A0 This gives determistic an= d
> stable names, even if modules are revised or added.
>

What do you mean with "whenever the namespace changes"? The I-D currently says:

=A0 =A0The namespace identifier MUST be used for local names that are
=A0 =A0ambiguous, i.e., whenever the data model permits a sibling data node=
=A0 =A0with the same local name.=A0 Otherwise, the namespace identifier is<= br> =A0 =A0OPTIONAL.

I think the phrase 'the data model permits a sibling data node with
the same local name' was supposed to mean 'a server supports a sibl= ing
data node with the same local name' (and if I am correct I think this phrase should be changed since in general every YANG defined data node
'permits' a sibling data node with the same local name).

So what do you mean by 'whenever the namespace changes'? I do not t= hink
the YANG to JSON I-D has a notion of a current namespace and namespace
changes.


Nested nodes wh= ich result from augment-stmt from an external module.
Otherwise t= he node is the same namespace as its parent. =A0If there
is no mo= dule-name, then the parent module-name applies.

Perhaps the draft text is wrong -- there is no ambiguit= y
determining the module name for a nested node without a prefix.=
It is simply the module name of its parent. =A0Only the sibling = from
the external module needs a module-name to clarify its namespace.



/js

=A0Andy

--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

--001a11c15c5044b7fa0501979987-- From nobody Wed Aug 27 00:51: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 929551A0479 for ; Wed, 27 Aug 2014 00:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 sXK901VBFD1D for ; Wed, 27 Aug 2014 00:51:42 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id A086A1A047C for ; Wed, 27 Aug 2014 00:51:39 -0700 (PDT) Received: from localhost (s193-12-221-208.cust.tele2.se [193.12.221.208]) by mail.tail-f.com (Postfix) with ESMTPSA id 4EE221280B26; Wed, 27 Aug 2014 09:49:07 +0200 (CEST) Date: Wed, 27 Aug 2014 09:51:38 +0200 (CEST) Message-Id: <20140827.095138.218223070.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140827070103.GA57782@elstar.local> References: <20140826.222821.102112065.mbj@tail-f.com> <20140827070103.GA57782@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZOyj-CnBa3ZjbzlZvtEqrH8CLxM Cc: netmod@ietf.org Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 07:51:43 -0000 Juergen Schoenwaelder wrote: > On Tue, Aug 26, 2014 at 10:28:21PM +0200, Martin Bjorklund wrote: > > > > I have suggested before that it should be MUST use the explicit > > namespace whenever the namespace changes. This gives determistic and > > stable names, even if modules are revised or added. > > > > What do you mean with "whenever the namespace changes"? The I-D > currently says: > > The namespace identifier MUST be used for local names that are > ambiguous, i.e., whenever the data model permits a sibling data node > with the same local name. Otherwise, the namespace identifier is > OPTIONAL. > > I think the phrase 'the data model permits a sibling data node with > the same local name' was supposed to mean 'a server supports a sibling > data node with the same local name' (and if I am correct I think this > phrase should be changed since in general every YANG defined data node > 'permits' a sibling data node with the same local name). > > So what do you mean by 'whenever the namespace changes'? I do not think > the YANG to JSON I-D has a notion of a current namespace and namespace > changes. Consider this situation: module a { ... container x { container y { ... } } } module b { ... augment "/a:x/a:y" { container z { ...} } } If this is all there is, the current draft allows: "x": { "y": { "z": { ... } } I.e., "z" can be encoded w/o the prefix since there is no conflict. I propose that since the module of "z" is different from the module of "y" (a namespace change), the prefix is MANDATORY: "a:x": { "y": { "b:z": { ... } } } This also means that if module a has: module a { ... container x { container y { container z { ... } } } } then we could have: "a:x": { "y": { "z": { ... } "b:z": { ... } } } I.e., the "z" from module "a" is encoded w/o prefix even though "b" is there. This means that the data looks the same regardless of whether module "b" is implemented or not. /martin From nobody Wed Aug 27 01:16:21 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4A01A048E for ; Wed, 27 Aug 2014 01:15:56 -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 zxGpwuEuzOif for ; Wed, 27 Aug 2014 01:15:47 -0700 (PDT) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 152791A0489 for ; Wed, 27 Aug 2014 01:15:46 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id l6so16786787qcy.33 for ; Wed, 27 Aug 2014 01:15: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=mGu82QQor87JNmMZkS9l0faEuQIYk8c0cmIQ1wXEFCU=; b=Mo6lfGk9u6hRifdfh6X9LEiv12AMBswIlXmSVRhome7FAiAYfq9jlaMebARbJEVxYR eA2GHXIxzWgN7xdHnvQ9WYyLIQLWvqJUVzEulN18zeNc4h+C61jw2SknL9RjVAUjYJ8m lcn8a6YMU8MmPx8ZuOAiqkB/TNqPU8twxBpJL2n3CjwjDphAlrxTm+zOiYugjYJllp6w g62lXogNrxC3i3ZHcMXq4rvluOCwX2GcEes6/InO12IHZNurIqMtg1qovBsmk/eccqvP DvuOMFpWwRlIUcYXCaOgGuuoLCgoE2rtMts1xe4SF+ULjK1U04ab97IoIzF61AE+2Ci8 jovQ== X-Gm-Message-State: ALoCoQmdUF+WW6oJMaZU4cSYFdZNDu++NBYg6R3uKGygXjwJBjsdLzwdKD+BiXmPG2gvDz4yhJlI MIME-Version: 1.0 X-Received: by 10.224.122.83 with SMTP id k19mr42348271qar.78.1409127346233; Wed, 27 Aug 2014 01:15:46 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Wed, 27 Aug 2014 01:15:46 -0700 (PDT) In-Reply-To: <20140827.095138.218223070.mbj@tail-f.com> References: <20140826.222821.102112065.mbj@tail-f.com> <20140827070103.GA57782@elstar.local> <20140827.095138.218223070.mbj@tail-f.com> Date: Wed, 27 Aug 2014 01:15:46 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7bf0c346ea7e050501980629 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/XmgvzOfXU-K2SjAYUpWKEIEH6gU Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 08:15:57 -0000 --047d7bf0c346ea7e050501980629 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 27, 2014 at 12:51 AM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Tue, Aug 26, 2014 at 10:28:21PM +0200, Martin Bjorklund wrote: > > > > > > I have suggested before that it should be MUST use the explicit > > > namespace whenever the namespace changes. This gives determistic and > > > stable names, even if modules are revised or added. > > > > > > > What do you mean with "whenever the namespace changes"? The I-D > > currently says: > > > > The namespace identifier MUST be used for local names that are > > ambiguous, i.e., whenever the data model permits a sibling data node > > with the same local name. Otherwise, the namespace identifier is > > OPTIONAL. > > > > I think the phrase 'the data model permits a sibling data node with > > the same local name' was supposed to mean 'a server supports a sibling > > data node with the same local name' (and if I am correct I think this > > phrase should be changed since in general every YANG defined data node > > 'permits' a sibling data node with the same local name). > > > > So what do you mean by 'whenever the namespace changes'? I do not think > > the YANG to JSON I-D has a notion of a current namespace and namespace > > changes. > > Consider this situation: > > module a { > ... > container x { > container y { ... } > } > } > > module b { > ... > augment "/a:x/a:y" { > container z { ...} > } > } > > If this is all there is, the current draft allows: > > "x": { > "y": { > "z": { > ... > } > } > > I.e., "z" can be encoded w/o the prefix since there is no conflict. > > The text about needing a module-name because there is a sibling with the same local-name is wrong. The node "z" is not qualified above. There is no child "z" in parent "y". The module name "b" is ALWAYS needed because it is not from the module "a". There does not need to be any child nodes defined for "y" in module "a", let alone a duplicate. The module name is needed to correctly identify namespace "b". > I propose that since the module of "z" is different from the module of > "y" (a namespace change), the prefix is MANDATORY: > > "a:x": { > "y": { > "b:z": { ... } > } > } > > This also means that if module a has: > > module a { > ... > container x { > container y { > container z { ... } > } > } > } > > then we could have: > > "a:x": { > "y": { > "z": { ... } > "b:z": { ... } > } > } > > I.e., the "z" from module "a" is encoded w/o prefix even though "b" is > there. This means that the data looks the same regardless of whether > module "b" is implemented or not. > > It is really simple -- if a node has no prefix, then it is in the same namespace as its parent. Siblings have nothing to do with it. > > /martin > Andy --047d7bf0c346ea7e050501980629 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Aug 27, 2014 at 12:51 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<= /a>> wrote:
> On Tue, Aug 26, 2014 at 10:28:21PM +0200, Martin Bjorklund wrote:
> >
> > I have suggested before that it should be MUST use the explicit > > namespace whenever the namespace changes.=A0 This gives determist= ic and
> > stable names, even if modules are revised or added.
> >
>
> What do you mean with "whenever the namespace changes"? The = I-D
> currently says:
>
>=A0 =A0 The namespace identifier MUST be used for local names that are<= br> >=A0 =A0 ambiguous, i.e., whenever the data model permits a sibling data= node
>=A0 =A0 with the same local name.=A0 Otherwise, the namespace identifie= r is
>=A0 =A0 OPTIONAL.
>
> I think the phrase 'the data model permits a sibling data node wit= h
> the same local name' was supposed to mean 'a server supports a= sibling
> data node with the same local name' (and if I am correct I think t= his
> phrase should be changed since in general every YANG defined data node=
> 'permits' a sibling data node with the same local name).
>
> So what do you mean by 'whenever the namespace changes'? I do = not think
> the YANG to JSON I-D has a notion of a current namespace and namespace=
> changes.

Consider this situation:

=A0 module a {
=A0 =A0 ...
=A0 =A0 container x {
=A0 =A0 =A0 container y=A0 { ... }
=A0 =A0 }
=A0 }

=A0 module b {
=A0 =A0 ...
=A0 =A0 augment "/a:x/a:y" {
=A0 =A0 =A0 container z { ...}
=A0 =A0 }
=A0 }

If this is all there is, the current draft allows:

=A0 =A0"x": {
=A0 =A0 =A0 "y": {
=A0 =A0 =A0 =A0 =A0"z": {
=A0 =A0 =A0 =A0 =A0 =A0 ...
=A0 =A0 =A0 =A0}
=A0 =A0}

I.e., "z" can be encoded w/o the prefix since there is no conflic= t.




in parent "y". =A0The module name "b" is ALWAYS ne= eded
because it is not from the module "a".
<= br>
There does not need to be any child nodes defined for "y= "
in module "a", let alone a duplicate. =A0The module name
is needed to correctly identify namespace "b".
<= br>
=A0
I propose that since the module of "z" is different from the modu= le of
"y" (a namespace change), the prefix is MANDATORY:

=A0 =A0"a:x": {
=A0 =A0 =A0 "y": {
=A0 =A0 =A0 =A0 =A0"b:z": { ... }
=A0 =A0 =A0 =A0}
=A0 =A0}

This also means that if module a has:

=A0 module a {
=A0 =A0 ...
=A0 =A0 container x {
=A0 =A0 =A0 container y=A0 {
=A0 =A0 =A0 =A0 container z { ... }
=A0 =A0 =A0 }
=A0 =A0 }
=A0 }

then we could have:

=A0 =A0"a:x": {
=A0 =A0 =A0 "y": {
=A0 =A0 =A0 =A0 =A0"z": { ... }
=A0 =A0 =A0 =A0 =A0"b:z": { ... }
=A0 =A0 =A0 =A0}
=A0 =A0}

I.e., the "z" from module "a" is encoded w/o prefix eve= n though "b" is
there.=A0 This means that the data looks the same regardless of whether
module "b" is implemented or not.


It is really simple -- if a node has no prefix, then= it is in the same
namespace as its parent. Siblings have nothing= to do with it.

=A0

/martin

Andy<= /div>

--047d7bf0c346ea7e050501980629-- From nobody Wed Aug 27 01:24: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 DB8351A0489 for ; Wed, 27 Aug 2014 01:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 ien86OY3LJWH for ; Wed, 27 Aug 2014 01:24:50 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id E9E2F1A046D for ; Wed, 27 Aug 2014 01:24:49 -0700 (PDT) Received: from localhost (s193-12-221-208.cust.tele2.se [193.12.221.208]) by mail.tail-f.com (Postfix) with ESMTPSA id BE5B91280B34; Wed, 27 Aug 2014 10:22:17 +0200 (CEST) Date: Wed, 27 Aug 2014 10:24:48 +0200 (CEST) Message-Id: <20140827.102448.353732895.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140827070103.GA57782@elstar.local> <20140827.095138.218223070.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9h9EOq_9gFiVBpKyCfwXnTdqIq0 Cc: netmod@ietf.org Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 08:24:52 -0000 Andy, It seems we agree, but this it not how the current draft is specified! /martin Andy Bierman wrote: > On Wed, Aug 27, 2014 at 12:51 AM, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > On Tue, Aug 26, 2014 at 10:28:21PM +0200, Martin Bjorklund wrote: > > > > > > > > I have suggested before that it should be MUST use the explicit > > > > namespace whenever the namespace changes. This gives determistic and > > > > stable names, even if modules are revised or added. > > > > > > > > > > What do you mean with "whenever the namespace changes"? The I-D > > > currently says: > > > > > > The namespace identifier MUST be used for local names that are > > > ambiguous, i.e., whenever the data model permits a sibling data node > > > with the same local name. Otherwise, the namespace identifier is > > > OPTIONAL. > > > > > > I think the phrase 'the data model permits a sibling data node with > > > the same local name' was supposed to mean 'a server supports a sibling > > > data node with the same local name' (and if I am correct I think this > > > phrase should be changed since in general every YANG defined data node > > > 'permits' a sibling data node with the same local name). > > > > > > So what do you mean by 'whenever the namespace changes'? I do not think > > > the YANG to JSON I-D has a notion of a current namespace and namespace > > > changes. > > > > Consider this situation: > > > > module a { > > ... > > container x { > > container y { ... } > > } > > } > > > > module b { > > ... > > augment "/a:x/a:y" { > > container z { ...} > > } > > } > > > > If this is all there is, the current draft allows: > > > > "x": { > > "y": { > > "z": { > > ... > > } > > } > > > > I.e., "z" can be encoded w/o the prefix since there is no conflict. > > > > > > The text about needing a module-name because there is a > sibling with the same local-name is wrong. > > The node "z" is not qualified above. There is no child "z" > in parent "y". The module name "b" is ALWAYS needed > because it is not from the module "a". > > There does not need to be any child nodes defined for "y" > in module "a", let alone a duplicate. The module name > is needed to correctly identify namespace "b". > > > > > I propose that since the module of "z" is different from the module of > > "y" (a namespace change), the prefix is MANDATORY: > > > > "a:x": { > > "y": { > > "b:z": { ... } > > } > > } > > > > This also means that if module a has: > > > > module a { > > ... > > container x { > > container y { > > container z { ... } > > } > > } > > } > > > > then we could have: > > > > "a:x": { > > "y": { > > "z": { ... } > > "b:z": { ... } > > } > > } > > > > I.e., the "z" from module "a" is encoded w/o prefix even though "b" is > > there. This means that the data looks the same regardless of whether > > module "b" is implemented or not. > > > > > It is really simple -- if a node has no prefix, then it is in the same > namespace as its parent. Siblings have nothing to do with it. > > > > > > > /martin > > > > Andy From nobody Wed Aug 27 01:29: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 4180F1A0489 for ; Wed, 27 Aug 2014 01:29:21 -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 9OWJtJelflTG for ; Wed, 27 Aug 2014 01:29:17 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AADCD1A046D for ; Wed, 27 Aug 2014 01:29:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id DAD8454075D; Wed, 27 Aug 2014 10:29:14 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xGCnJXG5Oh7; Wed, 27 Aug 2014 10:29:09 +0200 (CEST) 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 4B2CD54043A; Wed, 27 Aug 2014 10:29:09 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20140826163426.GA56502@elstar.local> References: <20140826.151955.1338003814359491302.mbj@tail-f.com> <3A525146-145D-42D8-8660-80FF6B159F0F@nic.cz> <20140826.153608.405577889262820806.mbj@tail-f.com> <20140826163426.GA56502@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Wed, 27 Aug 2014 10:29:05 +0200 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/dDjPpGWrOzGd2cvKAsdgR1jR1dM Cc: netmod@ietf.org Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 08:29:21 -0000 Juergen Schoenwaelder writes: > On Tue, Aug 26, 2014 at 04:56:03PM +0200, Ladislav Lhotka wrote: >>=20 >> I don=E2=80=99t know, perhaps the document can say that those who really= can=E2=80=99t do without namespaces are on their own. This is also worth r= eading: >>=20 >> https://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json >>=20 >> Let me cite one paragraph from it: >>=20 >> "Starting with the obvious, I=E2=80=99d say that if you can use JSON wit= hout namespaces, you really, really should. In other words, if you really n= eed distributed extensibility, you need something like namespaces, but for = all other purposes, they should be avoided like the plague; they make it to= o complex, and simplicity is the name of the game in JSON.=E2=80=9D >>=20 >> I tend to agree with you that metadata we are talking about are mostly p= rotocol-specific and then distributed extensibility is not needed. >>=20 > > Unfortunately, name collisions will happen. So we need to deal with > namespaces and (speaking as technical contributor) I prefer a solution > that is solving this problem in a consistent manner. > > Even if your assumption is correct that metadata is mostly > protocol-specific, this does not guarantee that meta-data attribute > names will be collision free. > > If we go with YANG module names as namespaces in JSON, another option > is to say that the general format is [:]. For YANG > defined names, the namespace is the module name while for names not > defined in YANG modules (like attribute names), it is unspecified how > namespaces with low collision probability will be derived. We could > provide guidelines about possible ways to choose namespaces with low > collision probability. > > My understanding is that the JSON I-D only requires to use explicit > namespaces if there is actually a name collision. So ideally, For YANG data nodes, we can find out whether there is a collision or not from the data model. To be able do it for metadata, we need to know whether/how the server will advertise support for particular metadata. Lada > namespace qualification would be rather an exception than the > default. Perhaps advice should be given that vendor extensions > for meta data should pick names that likely won't collide with > a future standard usage. > > /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 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Aug 27 01:40: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 8FE981A0177 for ; Wed, 27 Aug 2014 01:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] 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 OUb4bHM0d2Cu for ; Wed, 27 Aug 2014 01:40:20 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF7C61A00C3 for ; Wed, 27 Aug 2014 01:40:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 72C9154075D; Wed, 27 Aug 2014 10:40:18 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lgav-YRnSVEd; Wed, 27 Aug 2014 10:40:14 +0200 (CEST) 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 C8C56540145; Wed, 27 Aug 2014 10:40:13 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Juergen Schoenwaelder , Martin =?utf-8?Q?Bj=C3=B6rklund?= , "netmod\@ietf.org" In-Reply-To: References: <20140826.151955.1338003814359491302.mbj@tail-f.com> <3A525146-145D-42D8-8660-80FF6B159F0F@nic.cz> <20140826.153608.405577889262820806.mbj@tail-f.com> <20140826163426.GA56502@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Wed, 27 Aug 2014 10:40:09 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mMsstGdNMkiTtzPFkO_cHzCCOZw Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 08:40:23 -0000 Andy Bierman writes: > On Tue, Aug 26, 2014 at 9:34 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> On Tue, Aug 26, 2014 at 04:56:03PM +0200, Ladislav Lhotka wrote: >> > >> > I don't know, perhaps the document can say that those who really can't >> do without namespaces are on their own. This is also worth reading: >> > >> > https://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json >> > >> > Let me cite one paragraph from it: >> > >> > "Starting with the obvious, I'd say that if you can use JSON without >> namespaces, you really, really should. In other words, if you really need >> distributed extensibility, you need something like namespaces, but for all >> other purposes, they should be avoided like the plague; they make it too >> complex, and simplicity is the name of the game in JSON." >> > >> > I tend to agree with you that metadata we are talking about are mostly >> protocol-specific and then distributed extensibility is not needed. >> > >> >> Unfortunately, name collisions will happen. So we need to deal with >> namespaces and (speaking as technical contributor) I prefer a solution >> that is solving this problem in a consistent manner. >> >> Even if your assumption is correct that metadata is mostly >> protocol-specific, this does not guarantee that meta-data attribute >> names will be collision free. >> >> If we go with YANG module names as namespaces in JSON, another option >> is to say that the general format is [:]. For YANG >> defined names, the namespace is the module name while for names not >> defined in YANG modules (like attribute names), it is unspecified how >> namespaces with low collision probability will be derived. We could >> provide guidelines about possible ways to choose namespaces with low >> collision probability. >> >> > I like this proposal. We give the same guidance for capability URIs > without specifying an exact format. > > >> My understanding is that the JSON I-D only requires to use explicit >> namespaces if there is actually a name collision. So ideally, >> namespace qualification would be rather an exception than the >> default. Perhaps advice should be given that vendor extensions >> for meta data should pick names that likely won't collide with >> a future standard usage. >> >> > I think Lada's draft says SHOULD use where namespace changes > (including top) even if there are no collisions right now. As Phil This is possible. > pointed out, a new module can be loaded later, which causes a new > naming collision. (Then old client send /foo and it is suddenly an > "ambiguous node error".) Well, loading a new module means a different contract, so the client should be notified. Lada > > > > /js >> >> > Andy > > >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Aug 27 01:46: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 6E6601A02FB for ; Wed, 27 Aug 2014 01:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74Me4i2Lmh7K for ; Wed, 27 Aug 2014 01:46:19 -0700 (PDT) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABE1F1A000B for ; Wed, 27 Aug 2014 01:46:19 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id f51so15433107qge.25 for ; Wed, 27 Aug 2014 01:46:19 -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=3RX8acslEA/xYtPmZRjQLuWnjnIzNIn1xm6mli3Qyns=; b=mC83SEzMQNa+bHw69F/zezvn7vAv4EOcCfWyuyVdSSyZGz0ZyeyXnQPrFWCxGsgtj+ 7zstRxUX5psWWiCDj9LeyG71a51MXTkhtZetdjV4BVll1KO5Hl2Ah/E+UVQK4RVvNSE2 T4UTkFr95kotzSN8EpN2Clza5LSgvZgvm2B5PMNYYJUGAqHVxmz4UXc5RhWI5kMC9cXx RkfyngC8EoQsOsb16sMa+vEQNgLHYmRNCLC6BHyvR8jxcYD5gg+dMO+Ne7ixDFGAl9eV KYzL6GP+TNxPqRyzunuFB5HsP8WlSOtOiuY8tuqpLDwWMLQf3q6DHr7pP7x+QcJ/ZlY2 /w2Q== X-Gm-Message-State: ALoCoQkAXD1Q3U2rtHIZ/C1JoHzQhIgvpppBcN2A2aJJQJk0DalsmyyAMSsgrh5iEdtYu0xG2/Zl MIME-Version: 1.0 X-Received: by 10.140.98.147 with SMTP id o19mr11126705qge.21.1409129178900; Wed, 27 Aug 2014 01:46:18 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Wed, 27 Aug 2014 01:46:18 -0700 (PDT) In-Reply-To: <20140827.102448.353732895.mbj@tail-f.com> References: <20140827070103.GA57782@elstar.local> <20140827.095138.218223070.mbj@tail-f.com> <20140827.102448.353732895.mbj@tail-f.com> Date: Wed, 27 Aug 2014 01:46:18 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a113a923c26c82405019874d4 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hgxH6lhzzJfsrNJ0hHIbE4udMUc Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 08:46:21 -0000 --001a113a923c26c82405019874d4 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 27, 2014 at 1:24 AM, Martin Bjorklund wrote: > Andy, > > It seems we agree, but this it not how the current draft is specified! > > Consider: module c { ... augment "/a:x/a:y" { leaf z { ...} } } It doesn't matter that module "a" does not define any child nodes for "y". The node "z" always needs a prefix so we know if it is from module "b" or "c". > > /martin > > Andy > > > Andy Bierman wrote: > > On Wed, Aug 27, 2014 at 12:51 AM, Martin Bjorklund > wrote: > > > > > Juergen Schoenwaelder wrote: > > > > On Tue, Aug 26, 2014 at 10:28:21PM +0200, Martin Bjorklund wrote: > > > > > > > > > > I have suggested before that it should be MUST use the explicit > > > > > namespace whenever the namespace changes. This gives determistic > and > > > > > stable names, even if modules are revised or added. > > > > > > > > > > > > > What do you mean with "whenever the namespace changes"? The I-D > > > > currently says: > > > > > > > > The namespace identifier MUST be used for local names that are > > > > ambiguous, i.e., whenever the data model permits a sibling data > node > > > > with the same local name. Otherwise, the namespace identifier is > > > > OPTIONAL. > > > > > > > > I think the phrase 'the data model permits a sibling data node with > > > > the same local name' was supposed to mean 'a server supports a > sibling > > > > data node with the same local name' (and if I am correct I think this > > > > phrase should be changed since in general every YANG defined data > node > > > > 'permits' a sibling data node with the same local name). > > > > > > > > So what do you mean by 'whenever the namespace changes'? I do not > think > > > > the YANG to JSON I-D has a notion of a current namespace and > namespace > > > > changes. > > > > > > Consider this situation: > > > > > > module a { > > > ... > > > container x { > > > container y { ... } > > > } > > > } > > > > > > module b { > > > ... > > > augment "/a:x/a:y" { > > > container z { ...} > > > } > > > } > > > > > > If this is all there is, the current draft allows: > > > > > > "x": { > > > "y": { > > > "z": { > > > ... > > > } > > > } > > > > > > I.e., "z" can be encoded w/o the prefix since there is no conflict. > > > > > > > > > > The text about needing a module-name because there is a > > sibling with the same local-name is wrong. > > > > The node "z" is not qualified above. There is no child "z" > > in parent "y". The module name "b" is ALWAYS needed > > because it is not from the module "a". > > > > There does not need to be any child nodes defined for "y" > > in module "a", let alone a duplicate. The module name > > is needed to correctly identify namespace "b". > > > > > > > > > I propose that since the module of "z" is different from the module of > > > "y" (a namespace change), the prefix is MANDATORY: > > > > > > "a:x": { > > > "y": { > > > "b:z": { ... } > > > } > > > } > > > > > > This also means that if module a has: > > > > > > module a { > > > ... > > > container x { > > > container y { > > > container z { ... } > > > } > > > } > > > } > > > > > > then we could have: > > > > > > "a:x": { > > > "y": { > > > "z": { ... } > > > "b:z": { ... } > > > } > > > } > > > > > > I.e., the "z" from module "a" is encoded w/o prefix even though "b" is > > > there. This means that the data looks the same regardless of whether > > > module "b" is implemented or not. > > > > > > > > It is really simple -- if a node has no prefix, then it is in the same > > namespace as its parent. Siblings have nothing to do with it. > > > > > > > > > > > > /martin > > > > > > > Andy > --001a113a923c26c82405019874d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Aug 27, 2014 at 1:24 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Andy,

It seems we agree, but this it not how the current draft is specified!


Consider:


=A0 = module c {
=A0 =A0 ...
=A0 =A0 augment "/a:x/a:y" {
=A0 = =A0 =A0 leaf z { ...}
=A0 =A0 }
=A0 }

It doesn't matter that module "a" does not define any child n= odes for "y".
The node "z" always needs a pre= fix so we know if it is from module "b" or "c".

=A0

/martin


Andy
=A0


Andy Bierman <andy@yumaworks.com> wrote:
> On Wed, Aug 27, 2014 at 12:51 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > > On Tue, Aug 26, 2014 at 10:28:21PM +0200, Martin Bjorklund w= rote:
> > > >
> > > > I have suggested before that it should be MUST use the = explicit
> > > > namespace whenever the namespace changes.=A0 This gives= determistic and
> > > > stable names, even if modules are revised or added.
> > > >
> > >
> > > What do you mean with "whenever the namespace changes&q= uot;? The I-D
> > > currently says:
> > >
> > >=A0 =A0 The namespace identifier MUST be used for local names= that are
> > >=A0 =A0 ambiguous, i.e., whenever the data model permits a si= bling data node
> > >=A0 =A0 with the same local name.=A0 Otherwise, the namespace= identifier is
> > >=A0 =A0 OPTIONAL.
> > >
> > > I think the phrase 'the data model permits a sibling dat= a node with
> > > the same local name' was supposed to mean 'a server = supports a sibling
> > > data node with the same local name' (and if I am correct= I think this
> > > phrase should be changed since in general every YANG defined= data node
> > > 'permits' a sibling data node with the same local na= me).
> > >
> > > So what do you mean by 'whenever the namespace changes&#= 39;? I do not think
> > > the YANG to JSON I-D has a notion of a current namespace and= namespace
> > > changes.
> >
> > Consider this situation:
> >
> >=A0 =A0module a {
> >=A0 =A0 =A0...
> >=A0 =A0 =A0container x {
> >=A0 =A0 =A0 =A0container y=A0 { ... }
> >=A0 =A0 =A0}
> >=A0 =A0}
> >
> >=A0 =A0module b {
> >=A0 =A0 =A0...
> >=A0 =A0 =A0augment "/a:x/a:y" {
> >=A0 =A0 =A0 =A0container z { ...}
> >=A0 =A0 =A0}
> >=A0 =A0}
> >
> > If this is all there is, the current draft allows:
> >
> >=A0 =A0 "x": {
> >=A0 =A0 =A0 =A0"y": {
> >=A0 =A0 =A0 =A0 =A0 "z": {
> >=A0 =A0 =A0 =A0 =A0 =A0 =A0...
> >=A0 =A0 =A0 =A0 }
> >=A0 =A0 }
> >
> > I.e., "z" can be encoded w/o the prefix since there is = no conflict.
> >
> >
>
> The text about needing a module-name because there is a
> sibling with the same local-name is wrong.
>
> The node "z" is not qualified above.=A0 There is no child &q= uot;z"
> in parent "y".=A0 The module name "b" is ALWAYS ne= eded
> because it is not from the module "a".
>
> There does not need to be any child nodes defined for "y" > in module "a", let alone a duplicate.=A0 The module name
> is needed to correctly identify namespace "b".
>
>
>
> > I propose that since the module of "z" is different fro= m the module of
> > "y" (a namespace change), the prefix is MANDATORY:
> >
> >=A0 =A0 "a:x": {
> >=A0 =A0 =A0 =A0"y": {
> >=A0 =A0 =A0 =A0 =A0 "b:z": { ... }
> >=A0 =A0 =A0 =A0 }
> >=A0 =A0 }
> >
> > This also means that if module a has:
> >
> >=A0 =A0module a {
> >=A0 =A0 =A0...
> >=A0 =A0 =A0container x {
> >=A0 =A0 =A0 =A0container y=A0 {
> >=A0 =A0 =A0 =A0 =A0container z { ... }
> >=A0 =A0 =A0 =A0}
> >=A0 =A0 =A0}
> >=A0 =A0}
> >
> > then we could have:
> >
> >=A0 =A0 "a:x": {
> >=A0 =A0 =A0 =A0"y": {
> >=A0 =A0 =A0 =A0 =A0 "z": { ... }
> >=A0 =A0 =A0 =A0 =A0 "b:z": { ... }
> >=A0 =A0 =A0 =A0 }
> >=A0 =A0 }
> >
> > I.e., the "z" from module "a" is encoded w/o = prefix even though "b" is
> > there.=A0 This means that the data looks the same regardless of w= hether
> > module "b" is implemented or not.
> >
> >
> It is really simple -- if a node has no prefix, then it is in the same=
> namespace as its parent. Siblings have nothing to do with it.
>
>
>
> >
> > /martin
> >
>
> Andy

--001a113a923c26c82405019874d4-- From nobody Wed Aug 27 01:52: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 DD37D1A038A for ; Wed, 27 Aug 2014 01:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 pynJB3gtA_sN for ; Wed, 27 Aug 2014 01:52:20 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7191A00B0 for ; Wed, 27 Aug 2014 01:52:19 -0700 (PDT) Received: from localhost (s193-12-221-208.cust.tele2.se [193.12.221.208]) by mail.tail-f.com (Postfix) with ESMTPSA id AB7D81280B26; Wed, 27 Aug 2014 10:49:46 +0200 (CEST) Date: Wed, 27 Aug 2014 10:52:17 +0200 (CEST) Message-Id: <20140827.105217.408629738.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140827.102448.353732895.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/tttWO2O7q92bAUK9R3STSDoo2oQ Cc: netmod@ietf.org Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 08:52:21 -0000 Andy Bierman wrote: > On Wed, Aug 27, 2014 at 1:24 AM, Martin Bjorklund wrote: > > > Andy, > > > > It seems we agree, but this it not how the current draft is specified! > > > > > Consider: > > > module c { > ... > augment "/a:x/a:y" { > leaf z { ...} > } > } > > It doesn't matter that module "a" does not define any child nodes for "y". > The node "z" always needs a prefix so we know if it is from module "b" or > "c". I agree. If the node is not in the same module as its parent (i.e., an it is an augmented node), then it MUST be encoded with the module name as prefix. I would even say: If the node is in the same module as its parent, then it MUST NOT be encoded with the module name as prefix. The reason for these rules is simplicitly. Each node is *always* encoded the same way, regardless of which modules are loaded in a particular server. Simple, unambigous, and easy to implement. /martin From nobody Wed Aug 27 02: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 408E91A03DF for ; Wed, 27 Aug 2014 02:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 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.668] 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 YpHUZ8szFt3p for ; Wed, 27 Aug 2014 02:24:52 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 664E21A03BB for ; Wed, 27 Aug 2014 02:24:52 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 9D9FD141B7F; Wed, 27 Aug 2014 11:24:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409131487; bh=NMbzOmCBrYLRzOUmxg78mVCtoPsb2WvGpS1R33X89Bs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TSm8TXjRz9epw9dasWm7HAowkBOmGgJKNFRFchGEUzZL/qty53HphxB4fyCxXvP1C BT5vTTs1r3a4pSZmso5nh1PmY2JkTNChESqbyiv5B8WmbeEYmYwksxLppaMqJwYpIC V6o+rN53GWqaB/KKAC5Z4pghVNeQulxCPqg4s+po= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 27 Aug 2014 11:24:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140826.151955.1338003814359491302.mbj@tail-f.com> <3A525146-145D-42D8-8660-80FF6B159F0F@nic.cz> <20140826.153608.405577889262820806.mbj@tail-f.com> <20140826163426.GA56502@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KZnTvDxytgBBi9tB0-ZIHxIiry4 Cc: netmod@ietf.org Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 09:24:54 -0000 Hi, Andy once proposed to define metadata as YANG identities. I don=92t = think it is a good idea to overload identities for this purpose but, = well, maybe defining metadata with a top-level statement in YANG modules = is the best way for solving the metadata issues after all. There are = actually two options: 1. Reconsider YANG 1.1 issue Y33 - the new statement could be called = e.g. =93annotation=94 to avoid any XML connotations. 2. Define this statement as an extension. Either way, benefits of doing so are: - we immediately get the module name, namespace URI and prefix, so the = encoding can be the same as for YANG data (both in XML and JSON); - YANG module revision mechanism could be also handy; - the semantics can be explained in a description; - a data type can be specified. For example: annotation inactive { type boolean; description "If this annotation is attached to a configuration data node, and its value is 'true', then the server MUST behave as if the node was not present.";=20 } Lada On 27 Aug 2014, at 10:29, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: >=20 >> On Tue, Aug 26, 2014 at 04:56:03PM +0200, Ladislav Lhotka wrote: >>>=20 >>> I don=92t know, perhaps the document can say that those who really = can=92t do without namespaces are on their own. This is also worth = reading: >>>=20 >>> = https://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json >>>=20 >>> Let me cite one paragraph from it: >>>=20 >>> "Starting with the obvious, I=92d say that if you can use JSON = without namespaces, you really, really should. In other words, if you = really need distributed extensibility, you need something like = namespaces, but for all other purposes, they should be avoided like the = plague; they make it too complex, and simplicity is the name of the game = in JSON.=94 >>>=20 >>> I tend to agree with you that metadata we are talking about are = mostly protocol-specific and then distributed extensibility is not = needed. >>>=20 >>=20 >> Unfortunately, name collisions will happen. So we need to deal with >> namespaces and (speaking as technical contributor) I prefer a = solution >> that is solving this problem in a consistent manner. >>=20 >> Even if your assumption is correct that metadata is mostly >> protocol-specific, this does not guarantee that meta-data attribute >> names will be collision free. >>=20 >> If we go with YANG module names as namespaces in JSON, another option >> is to say that the general format is [:]. For YANG >> defined names, the namespace is the module name while for names not >> defined in YANG modules (like attribute names), it is unspecified how >> namespaces with low collision probability will be derived. We could >> provide guidelines about possible ways to choose namespaces with low >> collision probability. >>=20 >> My understanding is that the JSON I-D only requires to use explicit >> namespaces if there is actually a name collision. So ideally, >=20 > For YANG data nodes, we can find out whether there is a collision or = not > from the data model. To be able do it for metadata, we need to know > whether/how the server will advertise support for particular metadata. >=20 > Lada >=20 >> namespace qualification would be rather an exception than the >> default. Perhaps advice should be given that vendor extensions >> for meta data should pick names that likely won't collide with >> a future standard usage. >>=20 >> /js >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >=20 > --=20 > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Aug 27 02:39: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 0F2CD1A0417 for ; Wed, 27 Aug 2014 02:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlD61g4GeZ_P for ; Wed, 27 Aug 2014 02:39:11 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33711A0413 for ; Wed, 27 Aug 2014 02:39:10 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C6A2AFB7; Wed, 27 Aug 2014 11:39:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 6Ha7o7chhsMf; Wed, 27 Aug 2014 11:39:06 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 27 Aug 2014 11:39:08 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8DD2520037; Wed, 27 Aug 2014 11:39:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wjL3zz2H35l5; Wed, 27 Aug 2014 11:39:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1351820033; Wed, 27 Aug 2014 11:39:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F38582E514FA; Wed, 27 Aug 2014 11:39:05 +0200 (CEST) Date: Wed, 27 Aug 2014 11:39:04 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140827093904.GB58388@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20140826.151955.1338003814359491302.mbj@tail-f.com> <3A525146-145D-42D8-8660-80FF6B159F0F@nic.cz> <20140826.153608.405577889262820806.mbj@tail-f.com> <20140826163426.GA56502@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5BqsoMNUkLrGrcxDoJ7UjS5GjtE Cc: netmod@ietf.org Subject: Re: [netmod] metadata in JSON 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, 27 Aug 2014 09:39:13 -0000 Hi, when Y33 was discussed, there was generally an agreement that we will only have a small set of metadata 'attributes' and there was a concern that making 'attributes' a first class citizen of YANG 1.1 may actually encourage misuse. That said, if a formal way to define metadata 'attributes' can be provided using a YANG extension, someone should write a concrete proposal up as an I-D and then this may be considered independent of the YANG 1.1 effort. It is not clear to me why this presumably rarely used mechanism needs to be part of YANG 1.1. /js On Wed, Aug 27, 2014 at 11:24:42AM +0200, Ladislav Lhotka wrote: > Hi, > > Andy once proposed to define metadata as YANG identities. I don’t think it is a good idea to overload identities for this purpose but, well, maybe defining metadata with a top-level statement in YANG modules is the best way for solving the metadata issues after all. There are actually two options: > > 1. Reconsider YANG 1.1 issue Y33 - the new statement could be called e.g. “annotation†to avoid any XML connotations. > > 2. Define this statement as an extension. > > Either way, benefits of doing so are: > > - we immediately get the module name, namespace URI and prefix, so the encoding can be the same as for YANG data (both in XML and JSON); > - YANG module revision mechanism could be also handy; > - the semantics can be explained in a description; > - a data type can be specified. > > For example: > > annotation inactive { > type boolean; > description > "If this annotation is attached to a configuration > data node, and its value is 'true', then the server > MUST behave as if the node was not present."; > } > > Lada > > On 27 Aug 2014, at 10:29, Ladislav Lhotka wrote: > > > Juergen Schoenwaelder writes: > > > >> On Tue, Aug 26, 2014 at 04:56:03PM +0200, Ladislav Lhotka wrote: > >>> > >>> I don’t know, perhaps the document can say that those who really can’t do without namespaces are on their own. This is also worth reading: > >>> > >>> https://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json > >>> > >>> Let me cite one paragraph from it: > >>> > >>> "Starting with the obvious, I’d say that if you can use JSON without namespaces, you really, really should. In other words, if you really need distributed extensibility, you need something like namespaces, but for all other purposes, they should be avoided like the plague; they make it too complex, and simplicity is the name of the game in JSON.†> >>> > >>> I tend to agree with you that metadata we are talking about are mostly protocol-specific and then distributed extensibility is not needed. > >>> > >> > >> Unfortunately, name collisions will happen. So we need to deal with > >> namespaces and (speaking as technical contributor) I prefer a solution > >> that is solving this problem in a consistent manner. > >> > >> Even if your assumption is correct that metadata is mostly > >> protocol-specific, this does not guarantee that meta-data attribute > >> names will be collision free. > >> > >> If we go with YANG module names as namespaces in JSON, another option > >> is to say that the general format is [:]. For YANG > >> defined names, the namespace is the module name while for names not > >> defined in YANG modules (like attribute names), it is unspecified how > >> namespaces with low collision probability will be derived. We could > >> provide guidelines about possible ways to choose namespaces with low > >> collision probability. > >> > >> My understanding is that the JSON I-D only requires to use explicit > >> namespaces if there is actually a name collision. So ideally, > > > > For YANG data nodes, we can find out whether there is a collision or not > > from the data model. To be able do it for metadata, we need to know > > whether/how the server will advertise support for particular metadata. > > > > Lada > > > >> namespace qualification would be rather an exception than the > >> default. Perhaps advice should be given that vendor extensions > >> for meta data should pick names that likely won't collide with > >> a future standard usage. > >> > >> /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 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > -- 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 Aug 27 02:42: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 B0F631A0439 for ; Wed, 27 Aug 2014 02:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 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.668] 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 zf6q-bWf9-Th for ; Wed, 27 Aug 2014 02:42:03 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 688B11A0417 for ; Wed, 27 Aug 2014 02:42:03 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id CBE80141B7F; Wed, 27 Aug 2014 11:42:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409132522; bh=3kB9WF4CL1aWfkuB/k1IXKjSi5g4KPYnmlzw0X3ZS14=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pBqyCwmJ1T+ntE51/1gRGakVcg/CzTe10IoL1tlx2WaEQJ4ihlfBdm5F24dPeXGzf 7wQ/H+avC6fZ3Vr6wW0meHBAyrOju8wJammY5wMTPtisRT8B4GDf1OT7ZP0ZrM5eB3 igrCllvpRBh8FkoTraUQcSQ47ZT6pKGGtem8MqC4= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140827.105217.408629738.mbj@tail-f.com> Date: Wed, 27 Aug 2014 11:41:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140827.102448.353732895.mbj@tail-f.com> <20140827.105217.408629738.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/f7jgAVQ2bl8nKAk_XqSYwsWsj-g Cc: netmod@ietf.org Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 09:42:04 -0000 On 27 Aug 2014, at 10:52, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Wed, Aug 27, 2014 at 1:24 AM, Martin Bjorklund = wrote: >>=20 >>> Andy, >>>=20 >>> It seems we agree, but this it not how the current draft is = specified! >>>=20 >>>=20 >> Consider: >>=20 >>=20 >> module c { >> ... >> augment "/a:x/a:y" { >> leaf z { ...} >> } >> } >>=20 >> It doesn't matter that module "a" does not define any child nodes for = "y". >> The node "z" always needs a prefix so we know if it is from module = "b" or >> "c". >=20 > I agree. >=20 > If the node is not in the same module as its parent (i.e., an it is > an augmented node), then it MUST be encoded with the module name as > prefix. >=20 > I would even say: >=20 > If the node is in the same module as its parent, then it MUST NOT be > encoded with the module name as prefix. OK, if it is the consensus, I am fine with it. In our previous = discussion, Andy wanted to retain the possibility for using the = qualified name anywhere, even if it=92s not necessary. Lada >=20 > The reason for these rules is simplicitly. Each node is *always* > encoded the same way, regardless of which modules are loaded in a > particular server. Simple, unambigous, and easy to implement. >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Aug 27 02:44: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 3B3841A0465 for ; Wed, 27 Aug 2014 02:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 NduI3VHEFKcf for ; Wed, 27 Aug 2014 02:44:26 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 383B71A0417 for ; Wed, 27 Aug 2014 02:44:26 -0700 (PDT) Received: from localhost (s193-12-221-208.cust.tele2.se [193.12.221.208]) by mail.tail-f.com (Postfix) with ESMTPSA id C5E821280B26; Wed, 27 Aug 2014 11:41:53 +0200 (CEST) Date: Wed, 27 Aug 2014 11:44:24 +0200 (CEST) Message-Id: <20140827.114424.397838396.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140827093904.GB58388@elstar.local> References: <20140827093904.GB58388@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/VoMpJVX0KsqAXpiHzskRhL6Mink Cc: netmod@ietf.org Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 09:44:27 -0000 Juergen Schoenwaelder wrote: > Hi, > > when Y33 was discussed, there was generally an agreement that we will > only have a small set of metadata 'attributes' and there was a concern > that making 'attributes' a first class citizen of YANG 1.1 may > actually encourage misuse. Agreed. > That said, if a formal way to define metadata 'attributes' can be > provided using a YANG extension, someone should write a concrete > proposal up as an I-D and then this may be considered independent of > the YANG 1.1 effort. It is not clear to me why this presumably rarely > used mechanism needs to be part of YANG 1.1. This is certainly possible, but I think it has the same drawbacks as if it was a built-in statement. I.e., if there is an IETF-defined extension, it could encourage misuse. /martin From nobody Wed Aug 27 02:51: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 21DC81A0442 for ; Wed, 27 Aug 2014 02:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 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.668] 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 q4qLqhyoR9eL for ; Wed, 27 Aug 2014 02:51:52 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8D1E1A0465 for ; Wed, 27 Aug 2014 02:51:51 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 3CF70141B7F; Wed, 27 Aug 2014 11:51:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409133110; bh=KnRAgc3b7wyuNqa+qZEBHEL7B6z5rMu2tor9Q0lZk90=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=WypYNK2+GZX+8xa4wkfKJT0TrN+bvg7M0WHjdG3lYkUQR8+HrCidBoP1dgU3NxSPM GQfvYTsrUeFp9SA6zFZK7fRWyvCv0gQy9PB9AMSXrUBEVwSkzIp4Sfy706u3RuzvVS ILbhchwMZZQZ77++x+7Hl3oavQOAiIHDXAwnYkaw= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140827093904.GB58388@elstar.local> Date: Wed, 27 Aug 2014 11:51:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140826.151955.1338003814359491302.mbj@tail-f.com> <3A525146-145D-42D8-8660-80FF6B159F0F@nic.cz> <20140826.153608.405577889262820806.mbj@tail-f.com> <20140826163426.GA56502@elstar.local> <20140827093904.GB58388@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4H7-UbDn6PaTuvNbsS7sulI8Wv8 Cc: netmod@ietf.org Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 09:51:53 -0000 On 27 Aug 2014, at 11:39, Juergen Schoenwaelder = wrote: > Hi, >=20 > when Y33 was discussed, there was generally an agreement that we will > only have a small set of metadata 'attributes' and there was a concern > that making 'attributes' a first class citizen of YANG 1.1 may > actually encourage misuse. This has never been proposed as a first-class citizen. Since it would be = allowed only at the top-level there would be no way for specifying the = place in the data model where it can appear. If we only had a small set of metadata, then we should avoid namespaces = as the plague, but I had the impression that you consider support for = distributed extensibility a necessity. >=20 > That said, if a formal way to define metadata 'attributes' can be > provided using a YANG extension, someone should write a concrete > proposal up as an I-D and then this may be considered independent of > the YANG 1.1 effort. It is not clear to me why this presumably rarely > used mechanism needs to be part of YANG 1.1. I can write such a draft. Lada >=20 > /js >=20 > On Wed, Aug 27, 2014 at 11:24:42AM +0200, Ladislav Lhotka wrote: >> Hi, >>=20 >> Andy once proposed to define metadata as YANG identities. I don=92t = think it is a good idea to overload identities for this purpose but, = well, maybe defining metadata with a top-level statement in YANG modules = is the best way for solving the metadata issues after all. There are = actually two options: >>=20 >> 1. Reconsider YANG 1.1 issue Y33 - the new statement could be called = e.g. =93annotation=94 to avoid any XML connotations. >>=20 >> 2. Define this statement as an extension. >>=20 >> Either way, benefits of doing so are: >>=20 >> - we immediately get the module name, namespace URI and prefix, so = the encoding can be the same as for YANG data (both in XML and JSON); >> - YANG module revision mechanism could be also handy; >> - the semantics can be explained in a description; >> - a data type can be specified. >>=20 >> For example: >>=20 >> annotation inactive { >> type boolean; >> description >> "If this annotation is attached to a configuration >> data node, and its value is 'true', then the server >> MUST behave as if the node was not present.";=20 >> } >>=20 >> Lada >>=20 >> On 27 Aug 2014, at 10:29, Ladislav Lhotka wrote: >>=20 >>> Juergen Schoenwaelder writes: >>>=20 >>>> On Tue, Aug 26, 2014 at 04:56:03PM +0200, Ladislav Lhotka wrote: >>>>>=20 >>>>> I don=92t know, perhaps the document can say that those who really = can=92t do without namespaces are on their own. This is also worth = reading: >>>>>=20 >>>>> = https://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json >>>>>=20 >>>>> Let me cite one paragraph from it: >>>>>=20 >>>>> "Starting with the obvious, I=92d say that if you can use JSON = without namespaces, you really, really should. In other words, if you = really need distributed extensibility, you need something like = namespaces, but for all other purposes, they should be avoided like the = plague; they make it too complex, and simplicity is the name of the game = in JSON.=94 >>>>>=20 >>>>> I tend to agree with you that metadata we are talking about are = mostly protocol-specific and then distributed extensibility is not = needed. >>>>>=20 >>>>=20 >>>> Unfortunately, name collisions will happen. So we need to deal with >>>> namespaces and (speaking as technical contributor) I prefer a = solution >>>> that is solving this problem in a consistent manner. >>>>=20 >>>> Even if your assumption is correct that metadata is mostly >>>> protocol-specific, this does not guarantee that meta-data attribute >>>> names will be collision free. >>>>=20 >>>> If we go with YANG module names as namespaces in JSON, another = option >>>> is to say that the general format is [:]. For YANG >>>> defined names, the namespace is the module name while for names not >>>> defined in YANG modules (like attribute names), it is unspecified = how >>>> namespaces with low collision probability will be derived. We could >>>> provide guidelines about possible ways to choose namespaces with = low >>>> collision probability. >>>>=20 >>>> My understanding is that the JSON I-D only requires to use explicit >>>> namespaces if there is actually a name collision. So ideally, >>>=20 >>> For YANG data nodes, we can find out whether there is a collision or = not >>> from the data model. To be able do it for metadata, we need to know >>> whether/how the server will advertise support for particular = metadata. >>>=20 >>> Lada >>>=20 >>>> namespace qualification would be rather an exception than the >>>> default. Perhaps advice should be given that vendor extensions >>>> for meta data should pick names that likely won't collide with >>>> a future standard usage. >>>>=20 >>>> /js >>>>=20 >>>> --=20 >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, = Germany >>>> Fax: +49 421 200 3103 >>>=20 >>> --=20 >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>>=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 >=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 Aug 27 03:00: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 69DA51A048C for ; Wed, 27 Aug 2014 03:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 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.668] 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 d85AjW3bsxIM for ; Wed, 27 Aug 2014 03:00:37 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073A31A0476 for ; Wed, 27 Aug 2014 03:00:36 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 533FB141B9D; Wed, 27 Aug 2014 12:00:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409133634; bh=rjMf4yAz69Tvr+LT05S6OuEmUgQNZJS1ucf951k9z8s=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=f+JrkasE8UCEDwutzdokrTZp3CDHOxyNQMjmjHCxxZR/5d8K/DhAkX6eLjSMDzKbm MQnpCYqG6GqzwQbspOvQgtv1fKPUslGAV8T5+ha/9DJACwfY1M9JZa65VmwZYIuNq0 RNUsc1isdGzZI0uxfDzTx4apgBk7Eh+fgN2V1Vx8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140827.114424.397838396.mbj@tail-f.com> Date: Wed, 27 Aug 2014 12:00:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2E480F0E-0283-4C82-9ED4-030895415D5E@nic.cz> References: <20140827093904.GB58388@elstar.local> <20140827.114424.397838396.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/EGqS0K0aeGKwg6KV34LOwkyI298 Cc: netmod@ietf.org Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 10:00:38 -0000 On 27 Aug 2014, at 11:44, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> Hi, >>=20 >> when Y33 was discussed, there was generally an agreement that we will >> only have a small set of metadata 'attributes' and there was a = concern >> that making 'attributes' a first class citizen of YANG 1.1 may >> actually encourage misuse. >=20 > Agreed. >=20 >> That said, if a formal way to define metadata 'attributes' can be >> provided using a YANG extension, someone should write a concrete >> proposal up as an I-D and then this may be considered independent of >> the YANG 1.1 effort. It is not clear to me why this presumably rarely >> used mechanism needs to be part of YANG 1.1. >=20 > This is certainly possible, but I think it has the same drawbacks as > if it was a built-in statement. I.e., if there is an IETF-defined > extension, it could encourage misuse. Why is the danger of misuse higher than in the case when vendors are = allowed to throw in metadata without further ado? If the set of permitted attributes is small and relatively fixed, then = let=92s forget about namespaces and just use what we already have. On = the other hand, distributed extensibility of metadata warrants a new = YANG statement. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Aug 27 03:06:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E581A0466 for ; Wed, 27 Aug 2014 03:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAQbASLtjwRs for ; Wed, 27 Aug 2014 03:06:21 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 964E21A0476 for ; Wed, 27 Aug 2014 03:06:20 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3AE7D1364; Wed, 27 Aug 2014 12:06:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id kwkRcZLwy3Ch; Wed, 27 Aug 2014 12:06:16 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 27 Aug 2014 12:06:18 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36F9D20036; Wed, 27 Aug 2014 12:06:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id bpIifQlewbz2; Wed, 27 Aug 2014 12:06:17 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4E33C20035; Wed, 27 Aug 2014 12:06:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 52B5D2E5182E; Wed, 27 Aug 2014 12:06:16 +0200 (CEST) Date: Wed, 27 Aug 2014 12:06:15 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140827100614.GA58615@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20140826.151955.1338003814359491302.mbj@tail-f.com> <3A525146-145D-42D8-8660-80FF6B159F0F@nic.cz> <20140826.153608.405577889262820806.mbj@tail-f.com> <20140826163426.GA56502@elstar.local> <20140827093904.GB58388@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SC1CWcLiPHKiZ4-WEJiabKfG3qM Cc: netmod@ietf.org Subject: Re: [netmod] metadata in JSON 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, 27 Aug 2014 10:06:23 -0000 On Wed, Aug 27, 2014 at 11:51:44AM +0200, Ladislav Lhotka wrote: > > On 27 Aug 2014, at 11:39, Juergen Schoenwaelder wrote: > > > Hi, > > > > when Y33 was discussed, there was generally an agreement that we will > > only have a small set of metadata 'attributes' and there was a concern > > that making 'attributes' a first class citizen of YANG 1.1 may > > actually encourage misuse. > > This has never been proposed as a first-class citizen. Since it would be allowed only at the top-level there would be no way for specifying the place in the data model where it can appear. > Your example shows the definition of a metadata 'attribute' that as far as I understand can appear on any data node. So apparently there is a difference where something is defined and where it is applied. > If we only had a small set of metadata, then we should avoid namespaces as the plague, but I had the impression that you consider support for distributed extensibility a necessity. > I have heard vendors use their own metadata 'attributes' already today and since I doubt they will coordinate their metadata 'attribute' names, we have to be prepared to handle collisions. My goal here is robustness on the protocol encoding level. For me, this is separate from how metadata 'attributes' are defined. The data encoding IMHO must be robust and interoperable. /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 Aug 27 04:08: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 1361F1A05C0 for ; Wed, 27 Aug 2014 04:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 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.668] 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 8wQWK7BTd1K0 for ; Wed, 27 Aug 2014 04:07:34 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A8B41A0642 for ; Wed, 27 Aug 2014 04:07:31 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 2FF0A141B98; Wed, 27 Aug 2014 13:07:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409137649; bh=AAgRSD+r9LTZbIASdub4nuZ95wYGGcmMTVSQsK33SZY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=rnK8bHmOQrF5Hvsv/ZwDAHWRWqYoZWy1i5Qerx+KtOtq1FILuW5FwedUS684vUv1H BfL9/1SkMKRABcvrT6BQbEV+8rmKzz3O/SHzdtxUs/Zl+VFTkQo/WQ51QT9eyliKMQ VM/So4vAW8NVWivx13WeNe2d3+LR/PkNl+Wy2vBo= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140827100614.GA58615@elstar.local> Date: Wed, 27 Aug 2014 13:07:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2E9A033F-9B9F-4779-93CA-8F5406F9EE10@nic.cz> References: <20140826.151955.1338003814359491302.mbj@tail-f.com> <3A525146-145D-42D8-8660-80FF6B159F0F@nic.cz> <20140826.153608.405577889262820806.mbj@tail-f.com> <20140826163426.GA56502@elstar.local> <20140827093904.GB58388@elstar.local> <20140827100614.GA58615@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/HBiBxGEvHvmdrNDxPR3h4jwTCVE Cc: netmod@ietf.org Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 11:07:36 -0000 On 27 Aug 2014, at 12:06, Juergen Schoenwaelder = wrote: > On Wed, Aug 27, 2014 at 11:51:44AM +0200, Ladislav Lhotka wrote: >>=20 >> On 27 Aug 2014, at 11:39, Juergen Schoenwaelder = wrote: >>=20 >>> Hi, >>>=20 >>> when Y33 was discussed, there was generally an agreement that we = will >>> only have a small set of metadata 'attributes' and there was a = concern >>> that making 'attributes' a first class citizen of YANG 1.1 may >>> actually encourage misuse. >>=20 >> This has never been proposed as a first-class citizen. Since it would = be allowed only at the top-level there would be no way for specifying = the place in the data model where it can appear. >>=20 >=20 > Your example shows the definition of a metadata 'attribute' that as > far as I understand can appear on any data node. So apparently there > is a difference where something is defined and where it is applied. No, that=92s why I wrote =93top-level statement=94. It would be a new = alternative in the =93body-stmts=94 production and nowhere else. >=20 >> If we only had a small set of metadata, then we should avoid = namespaces as the plague, but I had the impression that you consider = support for distributed extensibility a necessity. >>=20 >=20 > I have heard vendors use their own metadata 'attributes' already today > and since I doubt they will coordinate their metadata 'attribute' > names, we have to be prepared to handle collisions. My goal here is But then the set of metadata attributes needn=92t be necessarily small, = I=92d expect rather the opposite. > robustness on the protocol encoding level. For me, this is separate > from how metadata 'attributes' are defined. The data encoding IMHO > must be robust and interoperable. I think that defining them in YANG modules would make it as robust and = interoperable as possible. An advantage of having it as a regular statement and not an extension is = that these attributes could then also be used in XPath expressions, if = the module defining the attribute is imported. 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 Aug 27 04:25:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C6B1A0642 for ; Wed, 27 Aug 2014 04:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMx6nM5w_vyx for ; Wed, 27 Aug 2014 04:25:01 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D2C1A05F5 for ; Wed, 27 Aug 2014 04:25:00 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C491D1123; Wed, 27 Aug 2014 13:24:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id BA-1gV83Fgyv; Wed, 27 Aug 2014 13:24:56 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 27 Aug 2014 13:24:58 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE10820035; Wed, 27 Aug 2014 13:24:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Qd8CwQw5c-3W; Wed, 27 Aug 2014 13:24:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1636C20033; Wed, 27 Aug 2014 13:24:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 272A12E51915; Wed, 27 Aug 2014 13:24:55 +0200 (CEST) Date: Wed, 27 Aug 2014 13:24:55 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140827112455.GA58783@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <3A525146-145D-42D8-8660-80FF6B159F0F@nic.cz> <20140826.153608.405577889262820806.mbj@tail-f.com> <20140826163426.GA56502@elstar.local> <20140827093904.GB58388@elstar.local> <20140827100614.GA58615@elstar.local> <2E9A033F-9B9F-4779-93CA-8F5406F9EE10@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2E9A033F-9B9F-4779-93CA-8F5406F9EE10@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/PBGks_xz8hFuiEJLdHpXbNT4lho Cc: netmod@ietf.org Subject: Re: [netmod] metadata in JSON 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, 27 Aug 2014 11:25:03 -0000 On Wed, Aug 27, 2014 at 01:07:22PM +0200, Ladislav Lhotka wrote: > > On 27 Aug 2014, at 12:06, Juergen Schoenwaelder wrote: > > > On Wed, Aug 27, 2014 at 11:51:44AM +0200, Ladislav Lhotka wrote: > >> > >> On 27 Aug 2014, at 11:39, Juergen Schoenwaelder wrote: > >> > >>> Hi, > >>> > >>> when Y33 was discussed, there was generally an agreement that we will > >>> only have a small set of metadata 'attributes' and there was a concern > >>> that making 'attributes' a first class citizen of YANG 1.1 may > >>> actually encourage misuse. > >> > >> This has never been proposed as a first-class citizen. Since it would be allowed only at the top-level there would be no way for specifying the place in the data model where it can appear. > >> > > > > Your example shows the definition of a metadata 'attribute' that as > > far as I understand can appear on any data node. So apparently there > > is a difference where something is defined and where it is applied. > > No, that’s why I wrote “top-level statementâ€. It would be a new alternative in the “body-stmts†production and nowhere else. > We talk past each other. I meant: The metadata 'attribute' defined in the toplevel statement can be attached to every data node. > >> If we only had a small set of metadata, then we should avoid namespaces as the plague, but I had the impression that you consider support for distributed extensibility a necessity. > >> > > > > I have heard vendors use their own metadata 'attributes' already today > > and since I doubt they will coordinate their metadata 'attribute' > > names, we have to be prepared to handle collisions. My goal here is > > But then the set of metadata attributes needn’t be necessarily small, I’d expect rather the opposite. > Depends on how we define small. The point is that it might be small for each vendor but these small sets might have a high collision probability. > > robustness on the protocol encoding level. For me, this is separate > > from how metadata 'attributes' are defined. The data encoding IMHO > > must be robust and interoperable. > > I think that defining them in YANG modules would make it as robust and interoperable as possible. > > An advantage of having it as a regular statement and not an extension is that these attributes could then also be used in XPath expressions, if the module defining the attribute is imported. > Personally, I hope we can avoid that. It seems you really want to make metadata attributes first class citizens. /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 Aug 27 05:13: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 A68611A0668 for ; Wed, 27 Aug 2014 05:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 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.668] 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 y6qRBi_zkjre for ; Wed, 27 Aug 2014 05:13:23 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9860D1A065A for ; Wed, 27 Aug 2014 05:13:21 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 56A05141B89; Wed, 27 Aug 2014 14:13:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409141599; bh=NNFnLXJMiJ+kadKIYaPAQnTR7EOjFHjaMB1krvLS4p4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=DFfAKFc6OxM6j6wd3PaiBJY+/oDYuDlm07KO/SOVUlHyylFDxslwPzROeUe6ioQRK T6k1RoOUVGdAdQaCzK9W4vlkvn1J6rqo318Q97X4rbmuK1kXdf+ncsRywnb+1gVZiN 1v+gGEgz/UGSRAVvNsc4ePy/71k9P80cGB+T54GU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140827112455.GA58783@elstar.local> Date: Wed, 27 Aug 2014 14:13:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3A525146-145D-42D8-8660-80FF6B159F0F@nic.cz> <20140826.153608.405577889262820806.mbj@tail-f.com> <20140826163426.GA56502@elstar.local> <20140827093904.GB58388@elstar.local> <20140827100614.GA58615@elstar.local> <2E9A033F-9B9F-4779-93CA-8F5406F9EE10@nic.cz> <20140827112455.GA58783@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/X2oPE565SbjmKgf0leXeNUJvvRs Cc: netmod@ietf.org Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 12:13:24 -0000 On 27 Aug 2014, at 13:24, Juergen Schoenwaelder = wrote: > On Wed, Aug 27, 2014 at 01:07:22PM +0200, Ladislav Lhotka wrote: >>=20 >> On 27 Aug 2014, at 12:06, Juergen Schoenwaelder = wrote: >>=20 >>> On Wed, Aug 27, 2014 at 11:51:44AM +0200, Ladislav Lhotka wrote: >>>>=20 >>>> On 27 Aug 2014, at 11:39, Juergen Schoenwaelder = wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> when Y33 was discussed, there was generally an agreement that we = will >>>>> only have a small set of metadata 'attributes' and there was a = concern >>>>> that making 'attributes' a first class citizen of YANG 1.1 may >>>>> actually encourage misuse. >>>>=20 >>>> This has never been proposed as a first-class citizen. Since it = would be allowed only at the top-level there would be no way for = specifying the place in the data model where it can appear. >>>>=20 >>>=20 >>> Your example shows the definition of a metadata 'attribute' that as >>> far as I understand can appear on any data node. So apparently there >>> is a difference where something is defined and where it is applied. >>=20 >> No, that=92s why I wrote =93top-level statement=94. It would be a new = alternative in the =93body-stmts=94 production and nowhere else. >>=20 >=20 > We talk past each other. I meant: The metadata 'attribute' defined in > the toplevel statement can be attached to every data node. This confusion is due to YANG terminology: 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. So what you mean is =93an attribute can be attached to any instance of a = data node=94. Then yes, but this will be true for these metadata = attributes in any case, right? >=20 >>>> If we only had a small set of metadata, then we should avoid = namespaces as the plague, but I had the impression that you consider = support for distributed extensibility a necessity. >>>>=20 >>>=20 >>> I have heard vendors use their own metadata 'attributes' already = today >>> and since I doubt they will coordinate their metadata 'attribute' >>> names, we have to be prepared to handle collisions. My goal here is >>=20 >> But then the set of metadata attributes needn=92t be necessarily = small, I=92d expect rather the opposite. >>=20 >=20 > Depends on how we define small. The point is that it might be small > for each vendor but these small sets might have a high collision > probability. It won't be a problem unless one device uses attributes from different = vendors with colliding names. Using Randy=92s earlier example, a client = can use =93gift=94 attribute unambiguously with an English and German = server at the same time because the context is specific for each server. = =20 >=20 >>> robustness on the protocol encoding level. For me, this is separate >>> from how metadata 'attributes' are defined. The data encoding IMHO >>> must be robust and interoperable. >>=20 >> I think that defining them in YANG modules would make it as robust = and interoperable as possible. >>=20 >> An advantage of having it as a regular statement and not an extension = is that these attributes could then also be used in XPath expressions, = if the module defining the attribute is imported. >>=20 >=20 > Personally, I hope we can avoid that. It seems you really want to make > metadata attributes first class citizens. I don=92t know, you should tell me what you mean by =93first class = citizen=94. It is certainly, and intentionally, not the same as, e.g., = the =93attribute=94 pattern in RELAX NG. I am just trying to solve the = problems we have in an effective way. Metadata is not my idea. 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 Aug 27 05:42: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 D31591A0693 for ; Wed, 27 Aug 2014 05:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVtHxvCl4gq0 for ; Wed, 27 Aug 2014 05:42:38 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357891A02D0 for ; Wed, 27 Aug 2014 05:42:38 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 00DB1F5F; Wed, 27 Aug 2014 14:42:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id MJqOa702AAOL; Wed, 27 Aug 2014 14:42:33 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 27 Aug 2014 14:42:36 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2359020035; Wed, 27 Aug 2014 14:42:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id W2ksNwRmoa8f; Wed, 27 Aug 2014 14:42:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B4C0820033; Wed, 27 Aug 2014 14:42:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E7DFF2E51B1B; Wed, 27 Aug 2014 14:42:33 +0200 (CEST) Date: Wed, 27 Aug 2014 14:42:33 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140827124233.GA59003@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20140826163426.GA56502@elstar.local> <20140827093904.GB58388@elstar.local> <20140827100614.GA58615@elstar.local> <2E9A033F-9B9F-4779-93CA-8F5406F9EE10@nic.cz> <20140827112455.GA58783@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/E-SanDw4QBVAhUdEzpB9B1lD06M Cc: netmod@ietf.org Subject: Re: [netmod] metadata in JSON 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, 27 Aug 2014 12:42:40 -0000 On Wed, Aug 27, 2014 at 02:13:11PM +0200, Ladislav Lhotka wrote: > > >> But then the set of metadata attributes needn’t be necessarily small, I’d expect rather the opposite. > >> > > > > Depends on how we define small. The point is that it might be small > > for each vendor but these small sets might have a high collision > > probability. > > It won't be a problem unless one device uses attributes from different vendors with colliding names. Using Randy’s earlier example, a client can use “gift†attribute unambiguously with an English and German server at the same time because the context is specific for each server. > Vendors buy other vendors. Modular netconf servers may allow plugins from third parties, one written by a German programmer and one written by an English coder. My expectations that vendors will always sort these kind of things out when they merge are probably lower than yours. I would not be surprised if even different product groups within a big vendor manage to produce collisions. > I don’t know, you should tell me what you mean by “first class > citizenâ€. It is certainly, and intentionally, not the same as, e.g., > the “attribute†pattern in RELAX NG. I am just trying to solve the > problems we have in an effective way. Metadata is not my idea. As far as I can tell, making metadata 'attributes' accessible in must/when expressions was not proposed in any of the YANG 1.1 issues. The closest might have been solution Y48-01 but then Y48 got rejected. I prefer to keep YANG 1.1 scoped. /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 Aug 27 06:30: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 0CBEC1A06A5 for ; Wed, 27 Aug 2014 06:30:40 -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 bJmXDSYx4TbL for ; Wed, 27 Aug 2014 06:30:37 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967E61A068F for ; Wed, 27 Aug 2014 06:30:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 099C454075D for ; Wed, 27 Aug 2014 15:30:35 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69uYgnfvY3Gj for ; Wed, 27 Aug 2014 15:30:28 +0200 (CEST) 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 431CB540145 for ; Wed, 27 Aug 2014 15:30:28 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Wed, 27 Aug 2014 15:30:19 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/iCx0-7hUP2SLYLwGhXQA38ilZfk Subject: [netmod] I-JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 13:30:40 -0000 Hi, I-JSON spec (draft-ietf-json-i-json-03) defines a restricted profile of JSON that guarantees maximum interoperability for protocols that use JSON in their messages, no matter what JSON encoders/decoders are used in protocol implementations. This is exactly what e.g. RESTCONF needs, so it would be useful to make JSON defined in the yang-json document I-JSON compliant. A far as I can tell, these are the problematic parts: Encoding and Characters ======================= - I-JSON requires UTF-8 encoding. Yang-json should do the same, which may need recoding on the sender side. - I-JSON forbids Unicode surrogates or noncharacters. YANG "string" and other types inherit XML character set which excludes surrogates but not all noncharacters (for example, #xFDDO is allowed). The only robust solution I can see is to ban noncharacters in YANG 1.1 - yang-json cannot do it unilaterally. Numbers ======= - I-JSON messages SHOULD NOT include numbers which express greater magnitude or precision than an IEEE 754 double precision number. This affects YANG int64, uint64 and decimal64 types. Proposal: encode values of these types as strings. Binary Data =========== - In I-JSON, it is RECOMMENDED that this data be encoded in a string value in base64url. YANG's binary type requires base64. I raised this issue twice in the JSON WG mailing list (http://www.ietf.org/mail-archive/web/json/current/msg03129.html, http://www.ietf.org/mail-archive/web/json/current/msg03192.html). Nobody offered any arguments why base64url should be better than base64 for encoding field values, but I also found no support for changing the current text. So the only option seems to be not to follow this I-JSON recommendation (and provide reasoning). Please comment. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Aug 27 09: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 36E991A0233 for ; Wed, 27 Aug 2014 09:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRbZeDdkJnwD for ; Wed, 27 Aug 2014 09:23:37 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EF031A0B02 for ; Wed, 27 Aug 2014 09:23:37 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2231C1256 for ; Wed, 27 Aug 2014 18:23:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id GPWtFXuSP9hD for ; Wed, 27 Aug 2014 18:23:31 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 27 Aug 2014 18:23:34 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9662E20035 for ; Wed, 27 Aug 2014 18:23:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tyHs-gbQOFm9; Wed, 27 Aug 2014 18:23:34 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5C06820033; Wed, 27 Aug 2014 18:23:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 44FFB2E51F78; Wed, 27 Aug 2014 18:23:32 +0200 (CEST) Date: Wed, 27 Aug 2014 18:23:32 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140827162332.GC59474@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/s8C-AZCuUHOmGINdJSFxg4CDINU Subject: [netmod] draft minutes of the NETMOD 2014-08-27 virtual interim 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, 27 Aug 2014 16:23:39 -0000 Hi, attached are the draft minutes of today's virtual interim meeting. Please let me know if something needs fixing by the end of the week so that I can send the final version to the secretariat. You can also find all the virtual interim meeting minutes next to the YANG 1.1 issue list in the NETMOD WG subversion repository: http://svn.tools.ietf.org/svn/wg/netmod/yang-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 Wed Aug 27 09:41: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 270FA1A0B7C for ; Wed, 27 Aug 2014 09:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 C8IzFn55bs8B for ; Wed, 27 Aug 2014 09:41:27 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B5E1A0BE8 for ; Wed, 27 Aug 2014 09:41:27 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id fa1so597219pad.41 for ; Wed, 27 Aug 2014 09:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=qbg7vPMO9Szc20MbT0mO8XNlwXmnU0yUv3kOiJWIwA4=; b=EZROZSkadFqMWNCpuLbfWNwIKHMXO246uoe/p9GRjaI9082XFyWq5jioCJoxV8Fqgp hLZ0sCFNNzGG6QLGx5pSsIuVBuyT+syojOk66LTU2FRrq7Pmz9m0eNSz/RAU7lH+LcH1 wtUkoDzUrpHcUj7ae2lZVV+D0B2bN7kjxyqV65EAQDMUP/ZnY6nAqdOLgsNmcbHvkerC +QZnbeinjfkH77sCL0JEkTNl6hRqxy6/qcf2c1apYYXKrbvwOM9YdJ7WK9diUt6EFdOT y7X/zGm2SxARSSe7NF0IcdCa5Li6GCeGsl+p6BMuQHV3TW8pELxYhmAEE2gmTh7/cmud 6gTw== X-Received: by 10.68.69.71 with SMTP id c7mr47929881pbu.43.1409157683793; Wed, 27 Aug 2014 09:41:23 -0700 (PDT) Received: from [10.21.94.61] (128-107-239-235.cisco.com. [128.107.239.235]) by mx.google.com with ESMTPSA id c3sm1398214pdj.6.2014.08.27.09.41.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Aug 2014 09:41:22 -0700 (PDT) Message-ID: <53FE0A31.5000101@gmail.com> Date: Wed, 27 Aug 2014 09:41:21 -0700 From: Reinaldo Penno User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: netmod@ietf.org References: <20140826.151955.1338003814359491302.mbj@tail-f.com> <3A525146-145D-42D8-8660-80FF6B159F0F@nic.cz> <20140826.153608.405577889262820806.mbj@tail-f.com> <20140826163426.GA56502@elstar.local> <20140827093904.GB58388@elstar.local> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LwBtTA4lfdcYzCh18HtOB8WyMvE Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 16:41:29 -0000 Hi Lada, I would be willing to contribute to this effort. We are looking into using such metadata Yang statements in Opendaylight. thanks, Reinaldo On 8/27/14 2:51 AM, Ladislav Lhotka wrote: >> That said, if a formal way to define metadata 'attributes' can be >> >provided using a YANG extension, someone should write a concrete >> >proposal up as an I-D and then this may be considered independent of >> >the YANG 1.1 effort. It is not clear to me why this presumably rarely >> >used mechanism needs to be part of YANG 1.1. > I can write such a draft. > > Lada > From nobody Wed Aug 27 13:19: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 529D11A0294 for ; Wed, 27 Aug 2014 13:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 scCixGiTOxG3 for ; Wed, 27 Aug 2014 13:19:33 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5821A6F0B for ; Wed, 27 Aug 2014 13:19:31 -0700 (PDT) Received: from localhost (s193-12-221-208.cust.tele2.se [193.12.221.208]) by mail.tail-f.com (Postfix) with ESMTPSA id 04C821280098 for ; Wed, 27 Aug 2014 22:16:56 +0200 (CEST) Date: Wed, 27 Aug 2014 22:19:30 +0200 (CEST) Message-Id: <20140827.221930.227693858.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/dqNrvzOV2Ur6RoX6rTW-ZzsV65g Subject: [netmod] YANG unions in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 20:19:37 -0000 Hi, In the current json draft, a value of type 'union' is encoded in the same way as the "active" member type. For example, with: leaf foo { type union { type int32; type string; } } the leaf might be encoded as: "foo": 42 Now, suppose we use json to set this leaf like this: "foo": "4668" If we the read the value back, what do we get? Probably "4668". But if we instead set the value over xml: 4668 we will then get back: "foo": 4668 over json. What happens if leaf foo is the key in a list - can we create two list instances with key: "foo": 4668 and: "foo": "4668" at the same time? It seems the simplest solution would be to say that unions are encoded as strings in json. /martin From nobody Thu Aug 28 00:48:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5B41A06E3 for ; Thu, 28 Aug 2014 00:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4vqo2R-qgJZ for ; Thu, 28 Aug 2014 00:48:34 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE3AF1A06D6 for ; Thu, 28 Aug 2014 00:48:33 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7A82E1424 for ; Thu, 28 Aug 2014 09:48:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id YR_xFo5XDO3p for ; Thu, 28 Aug 2014 09:48:25 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 28 Aug 2014 09:48:31 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0BD920035 for ; Thu, 28 Aug 2014 09:48:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id T5Qp9t6Pfpv6; Thu, 28 Aug 2014 09:48:30 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F51120033; Thu, 28 Aug 2014 09:48:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2C6E92E52549; Thu, 28 Aug 2014 09:48:30 +0200 (CEST) Date: Thu, 28 Aug 2014 09:48:29 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140828074829.GA61114@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/YWB2IFKiuW4ymhrF77DOEkC0J5Y Subject: [netmod] yang json and anyxml 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, 28 Aug 2014 07:48:36 -0000 Hi, would it not make sense to encode anyxml data as a JSON string containing the XML content? I believe this would be more interoperable than saying the "translation of anyxml contents is necessarily application-specific and outside the scope of this document". The anyxml type says that the data is an arbitrary chunk of XML and hence we should just transport it without inviting implementations to try any fancy JSON encodings. [And if we introduce anydata in YANG 1.1, hopefully the need to use anyxml goes away and anydata content may be YANG encoded with the caveat that everything will be treated as a string due to a lack of a data model.] /js PS: An extreme position would be to encode everything in general as a JSON string since obviously the JSON type system and the YANG type system do not line up very well - I guess Lada will not like this at all. -- 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 Aug 28 03:48: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 A1BE91A6F5B for ; Thu, 28 Aug 2014 03:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 yzOGNpmZd6HR for ; Thu, 28 Aug 2014 03:48:43 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2901A1A6F50 for ; Thu, 28 Aug 2014 03:48:43 -0700 (PDT) Received: from localhost (173-38-208-169.cisco.com [173.38.208.169]) by mail.tail-f.com (Postfix) with ESMTPSA id 3FF4E1280992; Thu, 28 Aug 2014 12:46:03 +0200 (CEST) Date: Thu, 28 Aug 2014 12:48:39 +0200 (CEST) Message-Id: <20140828.124839.716000072014037611.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140828074829.GA61114@elstar.local> References: <20140828074829.GA61114@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/U_OyCvV4qeUpsBQPtX3XpKVRLhU Cc: netmod@ietf.org Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 28 Aug 2014 10:48:44 -0000 Juergen Schoenwaelder wrote: > Hi, > > would it not make sense to encode anyxml data as a JSON string > containing the XML content? I believe this would be more interoperable > than saying the "translation of anyxml contents is necessarily > application-specific and outside the scope of this document". Here is one problem with this approach (the root cause of the problem is how anyxml is defined (and the reason for this goes back to how netconf is defined...)): module x { namespace "urn:x"; prefix x; container x { anyxml y; } } Now, this is a valid XML instance: 4668 If we translate this to json with a simple string, it would look like this (modulo whitespaces): "x": { "y": " 4668 " } Note how the xml data in "y" cannot be properly interpreted, b/c the xmlns declaration for "foo" is missing. I guess we *could* solve this by stating that any xmlns declarations that are used within the anyxml data must be inserted by the encoder at the proper place, giving: "x": { "y": " 4668 " } /martin From nobody Thu Aug 28 04:31: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 14A771A0535 for ; Thu, 28 Aug 2014 04:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 R45U0TeSiUjs for ; Thu, 28 Aug 2014 04:31:18 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF421A050E for ; Thu, 28 Aug 2014 04:31:18 -0700 (PDT) Received: from localhost (173-38-208-169.cisco.com [173.38.208.169]) by mail.tail-f.com (Postfix) with ESMTPSA id A9A0A1280992; Thu, 28 Aug 2014 13:28:40 +0200 (CEST) Date: Thu, 28 Aug 2014 13:31:16 +0200 (CEST) Message-Id: <20140828.133116.2040434540660085637.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/ZhP6LMVEZjpoSkV-8KN8BbaGFnQ Cc: netmod@ietf.org Subject: Re: [netmod] I-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, 28 Aug 2014 11:31:20 -0000 Ladislav Lhotka wrote: > Hi, > > I-JSON spec (draft-ietf-json-i-json-03) defines a restricted profile of > JSON that guarantees maximum interoperability for protocols that use > JSON in their messages, no matter what JSON encoders/decoders are used > in protocol implementations. This is exactly what e.g. RESTCONF needs, > so it would be useful to make JSON defined in the yang-json document > I-JSON compliant. > > A far as I can tell, these are the problematic parts: > > Encoding and Characters > ======================= > > - I-JSON requires UTF-8 encoding. Yang-json should do the same, which > may need recoding on the sender side. Ok. > - I-JSON forbids Unicode surrogates or noncharacters. YANG "string" and > other types inherit XML character set which excludes surrogates but > not all noncharacters (for example, #xFDDO is allowed). The only > robust solution I can see is to ban noncharacters in YANG 1.1 - > yang-json cannot do it unilaterally. Hmm. Tricky. > Numbers > ======= > > - I-JSON messages SHOULD NOT include numbers which express greater > magnitude or precision than an IEEE 754 double precision number. This > affects YANG int64, uint64 and decimal64 types. Proposal: encode > values of these types as strings. Ok. This is also RECOMMENDED in the i-json draft. > Binary Data > =========== > > - In I-JSON, it is RECOMMENDED that this data be encoded in a string > value in base64url. YANG's binary type requires base64. I raised this > issue twice in the JSON WG mailing list > (http://www.ietf.org/mail-archive/web/json/current/msg03129.html, > http://www.ietf.org/mail-archive/web/json/current/msg03192.html). Nobody > offered any arguments why base64url should be better than base64 for > encoding field values, but I also found no support for changing the > current text. So the only option seems to be not to follow this I-JSON > recommendation (and provide reasoning). Ok; this is fine, since it is only RECOMMENDED in the i-json draft. /martin From nobody Thu Aug 28 04:39: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 E33371A00B0 for ; Thu, 28 Aug 2014 04:39: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 p9euzb2dDvPO for ; Thu, 28 Aug 2014 04:39:06 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 411371A0059 for ; Thu, 28 Aug 2014 04:39:06 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id w8so562519qac.12 for ; Thu, 28 Aug 2014 04:39: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:content-type; bh=8FBbXCYgCUtVGpcgiuZg8U0FkmqZLq6RRWb90rXDFvo=; b=lrDqGJAng4U3CgubTjPvMx5Ts8QItRq3Zopj+f2oBGrQxamYJVTCmdMsfqrlN6YAqn pIomyWNnv07z8idlp9angIi7cOe3aQuZSVSJEQGNM5YLX4nW3lUDtKpe2OlN5ZO66hOP 3+fe0DwhNes75tqxdLAuoU7q1YbIdFEew/bdisoEa8mz//FZcwp/TCVzw7Hky8WtabZS 9jNlKdxq6yF0yUTmOjJBuu2xGF+w8UPOMVtuEwX2XTgw10QyhchD6MnnLJ6b0Skcelqr ltQOPfS+O/m3GIk/Epkwsr7FhbxWvhYYmjkL/T1cLGZ78ejzHhzGreFO46T5ypIGItwL KCYQ== X-Gm-Message-State: ALoCoQlRY3ZqlyaATr6GftKCpjFFLdDAvWRAHG8drO7oavJakHoki4/OhxT9SV+Kh2UzVVaokuL+ MIME-Version: 1.0 X-Received: by 10.224.88.137 with SMTP id a9mr5636923qam.88.1409225945230; Thu, 28 Aug 2014 04:39:05 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Thu, 28 Aug 2014 04:39:05 -0700 (PDT) In-Reply-To: <20140828074829.GA61114@elstar.local> References: <20140828074829.GA61114@elstar.local> Date: Thu, 28 Aug 2014 04:39:05 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2bbc0dfc9690501aefb05 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xwX8Ine97akHUEPpZ7UOX4y2Gac Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 28 Aug 2014 11:39:09 -0000 --001a11c2bbc0dfc9690501aefb05 Content-Type: text/plain; charset=ISO-8859-1 Hi, I do not agree that anyxml needs to be encoded as a string, or treated special somehow. NETCONF does not allow mixed mode XML. Our tools fully support anyxml (for XML valid for NETCONF). This easily maps to JSON without any problems. Collections, arrays and leafs can be encoded and decoded just fine. I doubt the original arbitrary YANG data tree can be reproduced by the receiver from a string, vs. simple JSON structures. I do not view the message encoding as a first order problem. It should not get in the way of the protocol. We should find an encoding that suites our protocol, not the other way around. Andy On Thu, Aug 28, 2014 at 12:48 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > would it not make sense to encode anyxml data as a JSON string > containing the XML content? I believe this would be more interoperable > than saying the "translation of anyxml contents is necessarily > application-specific and outside the scope of this document". > > The anyxml type says that the data is an arbitrary chunk of XML and > hence we should just transport it without inviting implementations to > try any fancy JSON encodings. [And if we introduce anydata in YANG > 1.1, hopefully the need to use anyxml goes away and anydata content > may be YANG encoded with the caveat that everything will be treated > as a string due to a lack of a data model.] > > /js > > PS: An extreme position would be to encode everything in general as a > JSON string since obviously the JSON type system and the YANG type > system do not line up very well - I guess Lada will not like this > at all. > > -- > 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 > --001a11c2bbc0dfc9690501aefb05 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I do not agree that anyxml needs to= be encoded as a string, or treated
special somehow. =A0NETCONF d= oes not allow mixed mode XML.
Our tools fully support anyxml (for= XML valid for NETCONF).
This easily maps to JSON without any problems. Collections, arrays
and leafs can be encoded and decoded just fine.

=
I doubt the original arbitrary YANG data tree can be reproduced by
the receiver from a string, vs. simple JSON structures.

=
I do not view the message encoding as a first order problem.
It should not get in the way of the protocol. We should find
an encoding that suites our protocol, not the other way around.
<= div>

Andy



On Thu, Aug 28, 2014 at 12:48 AM, J= uergen Schoenwaelder <j.schoenwaelder@jacobs-university= .de> wrote:
Hi,

would it not make sense to encode anyxml data as a JSON string
containing the XML content? I believe this would be more interoperable
than saying the "translation of anyxml contents is necessarily
application-specific and outside the scope of this document".

The anyxml type says that the data is an arbitrary chunk of XML and
hence we should just transport it without inviting implementations to
try any fancy JSON encodings. [And if we introduce anydata in YANG
1.1, hopefully the need to use anyxml goes away and anydata content
may be YANG encoded with the caveat that everything will be treated
as a string due to a lack of a data model.]

/js

PS: An extreme position would be to encode everything in general as a
=A0 =A0 JSON string since obviously the JSON type system and the YANG type<= br> =A0 =A0 system do not line up very well - I guess Lada will not like this =A0 =A0 at all.

--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

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

--001a11c2bbc0dfc9690501aefb05-- From nobody Thu Aug 28 04:51: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 95B6D1A031D for ; Thu, 28 Aug 2014 04:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4slOs7i71Sr for ; Thu, 28 Aug 2014 04:51:41 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224F61A035B for ; Thu, 28 Aug 2014 04:51:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 0ED8A5406C1; Thu, 28 Aug 2014 13:51:39 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ljzVc4sErHS; Thu, 28 Aug 2014 13:51:34 +0200 (CEST) Received: from localhost (unknown [217.31.205.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id BC42E54043A; Thu, 28 Aug 2014 13:51:33 +0200 (CEST) From: Ladislav Lhotka To: Reinaldo Penno , netmod@ietf.org In-Reply-To: <53FE0A31.5000101@gmail.com> References: <20140826.151955.1338003814359491302.mbj@tail-f.com> <3A525146-145D-42D8-8660-80FF6B159F0F@nic.cz> <20140826.153608.405577889262820806.mbj@tail-f.com> <20140826163426.GA56502@elstar.local> <20140827093904.GB58388@elstar.local> <53FE0A31.5000101@gmail.com> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Thu, 28 Aug 2014 13:51:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/eopfNtFK28D36mZqwc61foglg7A Subject: Re: [netmod] metadata in 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, 28 Aug 2014 11:51:43 -0000 Hi Reinaldo, Reinaldo Penno writes: > Hi Lada, > > I would be willing to contribute to this effort. We are looking into > using such metadata Yang statements in Opendaylight. Great! I made a GitHub project for this work: https://github.com/yang-metadata/yang-metadata It already contains the module with extension definition. Please send me your GitHub ID, I will give you push access. Thanks, Lada > > thanks, > > Reinaldo > > On 8/27/14 2:51 AM, Ladislav Lhotka wrote: >>> That said, if a formal way to define metadata 'attributes' can be >>> >provided using a YANG extension, someone should write a concrete >>> >proposal up as an I-D and then this may be considered independent of >>> >the YANG 1.1 effort. It is not clear to me why this presumably rarely >>> >used mechanism needs to be part of YANG 1.1. >> I can write such a draft. >> >> Lada >> > > _______________________________________________ > 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 Aug 28 04:58: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 81D7D1A038A for ; Thu, 28 Aug 2014 04:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 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.668] 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 b9IFV1ZhkYOs for ; Thu, 28 Aug 2014 04:58:12 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 426D41A0390 for ; Thu, 28 Aug 2014 04:58:04 -0700 (PDT) Received: from ladislavs-air-2.labs.office.nic.cz (unknown [172.20.6.94]) by mail.nic.cz (Postfix) with ESMTPSA id C510A13F7CA; Thu, 28 Aug 2014 13:58:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409227081; bh=++LiZeKrn/3uvOBNEXc2oOoXi4F9c6XvwSCI3gAHbqo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=BCMY/bznMxE1szvFLWUGTQGqNNTBjNQ3x4cW8Feq3cLBAMnIY3Qny1AWSzeuXBvMO H/kdLPet9amDUIK/8HDYRVcXdD/wbJ+EX7MMm/3bXM81aWnzevJVyXY87ZzMRlWefC KWKoJ2PpbR/RZHSM0NA/kGRzA1BGpyzh0kxw8l5k= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140828.124839.716000072014037611.mbj@tail-f.com> Date: Thu, 28 Aug 2014 13:58:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140828074829.GA61114@elstar.local> <20140828.124839.716000072014037611.mbj@tail-f.com> To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fGREh-wjAQ6ONX7nm1NjMGGVEmo Cc: netmod@ietf.org Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 28 Aug 2014 11:58:13 -0000 On 28 Aug 2014, at 12:48, Martin Bjorklund wrote: > I guess we *could* solve this by stating that any xmlns declarations > that are used within the anyxml data must be inserted by the encoder > at the proper place, giving: >=20 > "x": { > "y": " 4668 " > } Right, this is one reason. Another is that some applications might want = to do something more clever, see the example in sec. 3.2.5. In any case, applications are free do what you propose, if it makes = sense, and this should be stated in the description of the anyxml = statement so interoperability is possible. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Aug 28 05:04: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 002771A0387 for ; Thu, 28 Aug 2014 05:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3Qcav-mAQp5 for ; Thu, 28 Aug 2014 05:03:58 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45CF41A0394 for ; Thu, 28 Aug 2014 05:03:45 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1748013E8; Thu, 28 Aug 2014 14:03:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id dAI_pJ4ggAaG; Thu, 28 Aug 2014 14:03:34 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 28 Aug 2014 14:03:41 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CC96A20033; Thu, 28 Aug 2014 14:03:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dP8I8cLKc6ly; Thu, 28 Aug 2014 14:03:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B7BBD20035; Thu, 28 Aug 2014 14:03:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 75BFA2E527FF; Thu, 28 Aug 2014 14:03:40 +0200 (CEST) Date: Thu, 28 Aug 2014 14:03:40 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140828120340.GA61647@elstar.local> Mail-Followup-To: Andy Bierman , "netmod@ietf.org" References: <20140828074829.GA61114@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kASscLlNEArvdHGCKqL3ykK-6Kw Cc: "netmod@ietf.org" Subject: Re: [netmod] yang json and anyxml 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, 28 Aug 2014 12:04:01 -0000 On Thu, Aug 28, 2014 at 04:39:05AM -0700, Andy Bierman wrote: > Hi, > > I do not agree that anyxml needs to be encoded as a string, or treated > special somehow. NETCONF does not allow mixed mode XML. RFC 6020 section 7.10: The "anyxml" statement is used to represent an unknown chunk of XML. No restrictions are placed on the XML. So are there restrictions or not? > Our tools fully support anyxml (for XML valid for NETCONF). > This easily maps to JSON without any problems. Collections, arrays > and leafs can be encoded and decoded just fine. How do you tell whether 123 is to be encoded as a string or a number in JSON? If there is a way to encode anyxml content in JSON, then I would say the YANG to JSON I-D needs to define that and not say this is implementation dependent. /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 Aug 28 05:05: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 5746B1A038A for ; Thu, 28 Aug 2014 05:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CyP7shO37nB for ; Thu, 28 Aug 2014 05:05:43 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8B71A0387 for ; Thu, 28 Aug 2014 05:05:40 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8CB2B128F; Thu, 28 Aug 2014 14:05:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Sransd3xbF00; Thu, 28 Aug 2014 14:05:31 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 28 Aug 2014 14:05:38 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D946620033; Thu, 28 Aug 2014 14:05:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ptSC5NROPVjn; Thu, 28 Aug 2014 14:05:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4E60D20036; Thu, 28 Aug 2014 14:05:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 953FE2E5282D; Thu, 28 Aug 2014 14:05:36 +0200 (CEST) Date: Thu, 28 Aug 2014 14:05:36 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140828120536.GB61647@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin =?iso-8859-1?Q?Bj=F6rklund?= , netmod@ietf.org References: <20140828074829.GA61114@elstar.local> <20140828.124839.716000072014037611.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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jSGjc2B_vY-40J4AcM4lPELStyk Cc: netmod@ietf.org Subject: Re: [netmod] yang json and anyxml 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, 28 Aug 2014 12:05:46 -0000 On Thu, Aug 28, 2014 at 01:58:01PM +0200, Ladislav Lhotka wrote: > On 28 Aug 2014, at 12:48, Martin Bjorklund wrote: > > > I guess we *could* solve this by stating that any xmlns declarations > > that are used within the anyxml data must be inserted by the encoder > > at the proper place, giving: > > > > "x": { > > "y": " 4668 " > > } > > Right, this is one reason. Another is that some applications might want to do something more clever, see the example in sec. 3.2.5. > > In any case, applications are free do what you propose, if it makes sense, and this should be stated in the description of the anyxml statement so interoperability is possible. > I want robust and interoperable encoding. I do not care about cleverness that only works for some applications. /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 Aug 28 05:06: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 AF53F1A039D for ; Thu, 28 Aug 2014 05:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNI0ZAqcVe5c for ; Thu, 28 Aug 2014 05:06:31 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A401A0398 for ; Thu, 28 Aug 2014 05:06:24 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 698E61123; Thu, 28 Aug 2014 14:06:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id xY4YfjTSCJ0h; Thu, 28 Aug 2014 14:06:15 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 28 Aug 2014 14:06:22 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9BC6C20036; Thu, 28 Aug 2014 14:06:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id QaHfP7Bf7kKh; Thu, 28 Aug 2014 14:06:21 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E2ED420033; Thu, 28 Aug 2014 14:06:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D8AE62E5284B; Thu, 28 Aug 2014 14:06:20 +0200 (CEST) Date: Thu, 28 Aug 2014 14:06:20 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140828120620.GC61647@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20140828074829.GA61114@elstar.local> <20140828.124839.716000072014037611.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140828.124839.716000072014037611.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/0SI4eVwrxlhNxEWUe87cT8g2hZ8 Cc: netmod@ietf.org Subject: Re: [netmod] yang json and anyxml 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, 28 Aug 2014 12:06:39 -0000 On Thu, Aug 28, 2014 at 12:48:39PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > Hi, > > > > would it not make sense to encode anyxml data as a JSON string > > containing the XML content? I believe this would be more interoperable > > than saying the "translation of anyxml contents is necessarily > > application-specific and outside the scope of this document". > > Here is one problem with this approach (the root cause of the problem > is how anyxml is defined (and the reason for this goes back to how > netconf is defined...)): > > module x { > namespace "urn:x"; > prefix x; > > container x { > anyxml y; > } > } > > Now, this is a valid XML instance: > > xmlns:foo="urn:foo"> > > > 4668 > > > > > If we translate this to json with a simple string, it would look like > this (modulo whitespaces): > > "x": { > "y": " 4668 " > } > > Note how the xml data in "y" cannot be properly interpreted, b/c the > xmlns declaration for "foo" is missing. > > > > I guess we *could* solve this by stating that any xmlns declarations > that are used within the anyxml data must be inserted by the encoder > at the proper place, giving: > > "x": { > "y": " 4668 " > } > Yes, this might be the price to pay. /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 Aug 28 05:13: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 0A93B1A038B for ; Thu, 28 Aug 2014 05:13:54 -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 i9OWKR0fV8lB for ; Thu, 28 Aug 2014 05:13:52 -0700 (PDT) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC311A038A for ; Thu, 28 Aug 2014 05:13:52 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id q108so598227qgd.23 for ; Thu, 28 Aug 2014 05:13:51 -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=hpzlLm8AqSd1qi7qguWJ8JM8ywv/Bhou8NktUn2uX4g=; b=jQ7e+m8slImCYThHPB8PW1nVIQxCw0a3DuYGZZhHOVVGL9yT3EfoN+XuitBnTSFmu2 EjRgKqxEU9Lfc+V98Y9ZMK04/rooO3ev/ITMAJYK9RAOqMUMdyWL8VBsP9mf9t6t6DUN NNObJHVFq8N/UBStGiEzLhNxuSmgb9DlbVjsZcsZK3yfevkHQlRPxA6AnW6kXDOJcTyu 6J5B1wpsJutlApdytOM+mlNW++ki2Xd+zZW8OTlw4SO2sGq6G7WTDz0CErrLhGuSQIYq Q1J1YkxDHY7GtLEV1mn6jIsXH6v45/v9axlUL1aXpOpXEr0geyUBEJMUKugn4Rxz4rCt gWbA== X-Gm-Message-State: ALoCoQnO1Yux+JXTSHUAcowOAWoWEAJ2+dMfR11M6L6elcxL5mPvbpVWrF4KA6RBbPs8Rw1rykF5 MIME-Version: 1.0 X-Received: by 10.140.95.101 with SMTP id h92mr5467835qge.35.1409228031439; Thu, 28 Aug 2014 05:13:51 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Thu, 28 Aug 2014 05:13:51 -0700 (PDT) In-Reply-To: <20140828120340.GA61647@elstar.local> References: <20140828074829.GA61114@elstar.local> <20140828120340.GA61647@elstar.local> Date: Thu, 28 Aug 2014 05:13:51 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c15c5038d0b40501af7805 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/XEDSL3MbPR0fXIWu4Gw9nOEikVw Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 28 Aug 2014 12:13:54 -0000 --001a11c15c5038d0b40501af7805 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 28, 2014 at 5:03 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Aug 28, 2014 at 04:39:05AM -0700, Andy Bierman wrote: > > Hi, > > > > I do not agree that anyxml needs to be encoded as a string, or treated > > special somehow. NETCONF does not allow mixed mode XML. > > RFC 6020 section 7.10: > > The "anyxml" statement is used to represent an unknown chunk of XML. > No restrictions are placed on the XML. > > So are there restrictions or not? > words on a page vs. running code. No customer has complained that the anyxml we support is too restrictive. > > Our tools fully support anyxml (for XML valid for NETCONF). > > This easily maps to JSON without any problems. Collections, arrays > > and leafs can be encoded and decoded just fine. > > How do you tell whether 123 is to be encoded as a string or a > number in JSON? > we encode as a string. Since there is no data type, what does it matter? > > If there is a way to encode anyxml content in JSON, then I would say > the YANG to JSON I-D needs to define that and not say this is > implementation dependent. > > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a11c15c5038d0b40501af7805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Aug 28, 2014 at 5:03 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Aug 28, 2014 at 04:39:05AM -0700, An= dy Bierman wrote:
> Hi,
>
> I do not agree that anyxml needs to be encoded as a string, or treated=
> special somehow.=A0 NETCONF does not allow mixed mode XML.

RFC 6020 section 7.10:

=A0 =A0The "anyxml" statement is used to represent an unknown chu= nk of XML.
=A0 =A0No restrictions are placed on the XML.

So are there restrictions or not?

words= on a page vs. running code.
No customer has complained that the = anyxml we support is too restrictive.


> Our tools fully support anyxml (for XML valid for NETCONF).
> This easily maps to JSON without any problems. Collections, arrays
> and leafs can be encoded and decoded just fine.

How do you tell whether <a>123</a> is to be encoded as a string= or a
number in JSON?

we encode as a string. = =A0Since there is no data type, what does it matter?
=A0

If there is a way to encode anyxml content in JSON, then I would say
the YANG to JSON I-D needs to define that and not say this is
implementation dependent.

/js


Andy
=A0
=
--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

--001a11c15c5038d0b40501af7805-- From nobody Thu Aug 28 05:36:21 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6511A03CC for ; Thu, 28 Aug 2014 05:36:20 -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 H9z_vCq76oTS for ; Thu, 28 Aug 2014 05:36:14 -0700 (PDT) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8F9F1A03BB for ; Thu, 28 Aug 2014 05:36:13 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id c9so671155qcz.11 for ; Thu, 28 Aug 2014 05:36:13 -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=2Hq4nTPK9yg7V9MLB+Mv2gJspU4qPrn/loVgYeDoep4=; b=HbTLois9pcqtNic5lll7HqHmbaV/UC8G74FcI5zHyAiIqP8coCG53ef4kL79EHoBNK 6/ZaRjBXMfu/8r3Y/lUu4CZVbixyNcYiRVsxtaDFT6nz9pZ1tQJqR5b6341T9NT0NCU8 UQHrhksFZdPC4BmJpMPRQk0JVE5knwb/AF+TPoLjBGtKmpHlxsbIGw3emTO6vbAsyjnr oV4Ps6lilTmSh4fP0bYoHCanVqmId2Db3BQWLqC/ih/pjOC+Wl/Cw8X/yrWSuZ+KpITo UJIJ4j7XgyJWN3kaoDloLjPQA/T06qH38JDtlKXPcvldCtNdnmUC098Sh/owe83PL8Ir 62dQ== X-Gm-Message-State: ALoCoQmYGTGHIBIp+6k0rFZI22tWxLiCTSygyZMQs1t8y0qUyLdKRlsJsPo5CnU91Ftw3GrbOeIl MIME-Version: 1.0 X-Received: by 10.224.20.9 with SMTP id d9mr5899339qab.7.1409229373027; Thu, 28 Aug 2014 05:36:13 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Thu, 28 Aug 2014 05:36:12 -0700 (PDT) In-Reply-To: <20140828120340.GA61647@elstar.local> References: <20140828074829.GA61114@elstar.local> <20140828120340.GA61647@elstar.local> Date: Thu, 28 Aug 2014 05:36:12 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1c5602fd0120501afc8f0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2xJPFVLbPXe1gxh9QiEDO6eurQU Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 28 Aug 2014 12:36:20 -0000 --001a11c1c5602fd0120501afc8f0 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 28, 2014 at 5:03 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Aug 28, 2014 at 04:39:05AM -0700, Andy Bierman wrote: > > Hi, > > > > I do not agree that anyxml needs to be encoded as a string, or treated > > special somehow. NETCONF does not allow mixed mode XML. > > RFC 6020 section 7.10: > > The "anyxml" statement is used to represent an unknown chunk of XML. > No restrictions are placed on the XML. > > So are there restrictions or not? > RFC 6020 defines a language that is only intended for use in NETCONF. Since NETCONF does not allow arbitrary XML, YANG anyxml is poorly defined. There are restrictions if the YANG is used in the NETCONF protocol. Since that is its only official purpose, there is no reason for YANG to be defined incorrectly. Andy > > Our tools fully support anyxml (for XML valid for NETCONF). > > This easily maps to JSON without any problems. Collections, arrays > > and leafs can be encoded and decoded just fine. > > How do you tell whether 123 is to be encoded as a string or a > number in JSON? > > If there is a way to encode anyxml content in JSON, then I would say > the YANG to JSON I-D needs to define that and not say this is > implementation dependent. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a11c1c5602fd0120501afc8f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Aug 28, 2014 at 5:03 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Aug 28, 2014 at 04:39:05AM -0700, An= dy Bierman wrote:
> Hi,
>
> I do not agree that anyxml needs to be encoded as a string, or treated=
> special somehow.=A0 NETCONF does not allow mixed mode XML.

RFC 6020 section 7.10:

=A0 =A0The "anyxml" statement is used to represent an unknown chu= nk of XML.
=A0 =A0No restrictions are placed on the XML.

So are there restrictions or not?


<= /div>
RFC 6020 defines a language that is only intended for use in NETC= ONF.
Since NETCONF does not allow arbitrary XML, YANG anyxml is
poorly defined. =A0There are restrictions if the YANG is used in the
NETCONF protocol. =A0Since that is its only official purpose,
there is no reason for YANG to be defined incorrectly.


Andy



> Our tools fully support anyxml (for XML valid for NETCONF).
> This easily maps to JSON without any problems. Collections, arrays
> and leafs can be encoded and decoded just fine.

How do you tell whether <a>123</a> is to be encoded as a string= or a
number in JSON?

If there is a way to encode anyxml content in JSON, then I would say
the YANG to JSON I-D needs to define that and not say this is
implementation dependent.

/js

--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

--001a11c1c5602fd0120501afc8f0-- From nobody Thu Aug 28 05:45: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 9E85F1A03E0 for ; Thu, 28 Aug 2014 05:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iH0TluCuJ_6 for ; Thu, 28 Aug 2014 05:45:11 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9370C1A03E3 for ; Thu, 28 Aug 2014 05:45:11 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 66721116D; Thu, 28 Aug 2014 14:45:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id pIdlwSchNfND; Thu, 28 Aug 2014 14:45:00 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 28 Aug 2014 14:45:08 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B38C20036; Thu, 28 Aug 2014 14:45:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id w2re4sDiH4eT; Thu, 28 Aug 2014 14:45:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A450F20035; Thu, 28 Aug 2014 14:45:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EB4C82E5299F; Thu, 28 Aug 2014 14:45:05 +0200 (CEST) Date: Thu, 28 Aug 2014 14:45:05 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140828124505.GA61827@elstar.local> Mail-Followup-To: Andy Bierman , "netmod@ietf.org" References: <20140828074829.GA61114@elstar.local> <20140828120340.GA61647@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9g2kvoI0iGku-sAUd5q-5SNJs6k Cc: "netmod@ietf.org" Subject: Re: [netmod] yang json and anyxml 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, 28 Aug 2014 12:45:13 -0000 On Thu, Aug 28, 2014 at 05:13:51AM -0700, Andy Bierman wrote: > On Thu, Aug 28, 2014 at 5:03 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Thu, Aug 28, 2014 at 04:39:05AM -0700, Andy Bierman wrote: > > > Hi, > > > > > > I do not agree that anyxml needs to be encoded as a string, or treated > > > special somehow. NETCONF does not allow mixed mode XML. > > > > RFC 6020 section 7.10: > > > > The "anyxml" statement is used to represent an unknown chunk of XML. > > No restrictions are placed on the XML. > > > > So are there restrictions or not? > > > > words on a page vs. running code. > No customer has complained that the anyxml we support is too restrictive. > So are you saying the discussion we had in Toronto about anyxml and anydata is pointless since in reality anyxml really is anydata? Can other implementations confirm this? If this is generally true, we should perhaps revisit the discussion and clarify in RFC 6020 bis that anyxml really means a rather restricted set of XML. Question: How do you deal with namespaces in the XML when you render it in JSON? The JSON I-D requires that you know the module name while all you have is a URI... /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 Aug 28 05:47: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 037401A03EF for ; Thu, 28 Aug 2014 05:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-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 8_tDXTAKsT6e for ; Thu, 28 Aug 2014 05:47:27 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3148A1A03F4 for ; Thu, 28 Aug 2014 05:47:26 -0700 (PDT) Received: from [192.168.1.150] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id C22E1286D947 for ; Thu, 28 Aug 2014 08:47:25 -0400 (EDT) From: "Thomas D. Nadeau" Content-Type: multipart/signed; boundary="Apple-Mail=_E6669AC7-09D1-4AF3-8BF0-1CF378033E26"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 28 Aug 2014 08:47:14 -0400 References: <509D1787-3526-448D-9D0E-B663A5129B46@xored.com> To: NETMOD Working Group Message-Id: <7BDB4429-0A8B-480B-86B1-15ECF45010AD@lucidvision.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/8hrbztaqHPLvyfLqHZxM45eXe94 Subject: [netmod] Fwd: [OpenDaylight Discuss] YangIDE 1.1.0 is released. X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 28 Aug 2014 12:47:30 -0000 --Apple-Mail=_E6669AC7-09D1-4AF3-8BF0-1CF378033E26 Content-Type: multipart/alternative; boundary="Apple-Mail=_3B4988C5-03B6-4885-8174-7F02565D9362" --Apple-Mail=_3B4988C5-03B6-4885-8174-7F02565D9362 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 =09 FYI... Begin forwarded message: > From: Andrey Sobolev > Subject: [OpenDaylight Discuss] YangIDE 1.1.0 is released. > Date: August 28, 2014 at 8:24:23 AM EDT > To: , = , = , Ed Warnicke (eaw) = > Cc: =D0=90=D0=BD=D0=B4=D1=80=D0=B5=D0=B9 =D0=9F=D0=BB=D0=B0=D1=82=D0=BE=D0= =B2 , yang-dev@xored.com >=20 > Hi all, >=20 > We are proud to announce new release of Yang-IDE 1.1.0. >=20 > It could be installed/updated from repository: = http://dl.xored.com/yang/releases/1.1.0 >=20 > Install instructions is here: = https://github.com/xored/yang-ide/wiki/Installing >=20 > Feature documentation is here: = https://github.com/xored/yang-ide/wiki/Features >=20 > Features included in this release: > * Yang code refactoring - = https://github.com/xored/yang-ide/wiki/Code%20Refactoring > ** Rename Refactoring > ** Inline Grouping > ** Extract Grouping > ** Change Revision > * Yang visual model editor - = https://github.com/xored/yang-ide/wiki/Diagram-Editor > ** 2-way synchronization between source code and diagram view. > ** Update YANG element properties from diagram view. > ** Palette with list of yang items to drop into diagram. > ** Visual decoration of YANG hierarchy and uses relationship. >=20 > For more details please refer to documentation available in wiki. >=20 > Video demonstrations are here:=20 > ** 1. Project wizard and highlighting. = http://www.youtube.com/watch?v=3D0TwAWuEfHXs > ** 2. Code completion and templates. = http://www.youtube.com/watch?v=3DAakHDCHeuCs > ** 3. Navigation and advanced completions. = http://www.youtube.com/watch?v=3D8k4A3r2KrZU) > ** 4. Outline and Formatting. = http://www.youtube.com/watch?v=3DedOvQRAGvVA > ** 5. Refactoring and Yang visual model Editor. = http://www.youtube.com/watch?v=3DtPDsU8aOUS4 >=20 > Best regards, > Andrey Sobolev. >=20 >=20 > PS: >=20 > List of other features of Yang-IDE: > * M2E Integration > ** Import maven project > ** Handle yang-maven-plugin lifecycle > * Yang Project Support > ** New YANG File Wizard > ** New YANG Project Wizard > ** Yang Code Syntax Validation > ** Yang Code Semantic Validation > * Code Editing > ** Syntax Highlight > ** Semantic Highlight > ** Documentation Hover > ** Code Completion > ** Smart Paste > ** Code Formatter > ** Toggle Comment > ** Code Templates > * Code Navigation > **Code Folding > ** Code Outline > ** Hyperlink navigation > ** Goto declaration >=20 >=20 > --=20 >=20 > Andrey Sobolev | Xored Software Inc, Principal Software Engineer | = http://www.xored.com | O: +7 383 363 1033 | M: +7 913 897 3747 | = E:andrey.sobolev@xored.com > _______________________________________________ > Discuss mailing list > Discuss@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/discuss --Apple-Mail=_3B4988C5-03B6-4885-8174-7F02565D9362 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 =
= FYI...

Begin forwarded = message:

From: = Andrey Sobolev = <andrey.sobolev@xored.com><= br>
Subject: = [OpenDaylight = Discuss] YangIDE 1.1.0 is released.
Date: August 28, 2014 at 8:24:23 AM = EDT
Cc: =D0=90=D0=BD=D0=B4=D1=80=D0=B5=D0=B9 = =D0=9F=D0=BB=D0=B0=D1=82=D0=BE=D0=B2 <andrey@xored.com>, yang-dev@xored.com
=
Hi all,

We are proud to announce new release of = Yang-IDE 1.1.0.

It could be installed/updated from repository: = http://dl.xored.com/yang/= releases/1.1.0



Features included in this release:
** Rename Refactoring
** Inline Grouping
** Extract Grouping
** Change Revision
** 2-way synchronization between source code and diagram = view.
** Update YANG element properties from diagram view.
** Palette with list of yang items to drop into diagram.
** Visual decoration of YANG hierarchy and uses relationship.

For more details please refer to documentation = available in wiki.

Video demonstrations are here: 
** 1. Project wizard and highlighting. http://www.youtube.c= om/watch?v=3D0TwAWuEfHXs
** 2. Code completion and templates. http://www.youtube.c= om/watch?v=3DAakHDCHeuCs
** 3. Navigation and advanced completions. http://www.youtube.c= om/watch?v=3D8k4A3r2KrZU)
** 4. Outline and Formatting. http://www.youtube.c= om/watch?v=3DedOvQRAGvVA
** 5. Refactoring and Yang visual model Editor. http://www.youtube.c= om/watch?v=3DtPDsU8aOUS4

Best regards,
Andrey Sobolev.


PS:

List of other features of Yang-IDE:
* M2E Integration
** Import maven project
** Handle yang-maven-plugin lifecycle
* Yang Project Support
** New YANG File Wizard
** New YANG Project Wizard
** Yang Code Syntax Validation
** Yang Code Semantic Validation
* Code Editing
** Syntax Highlight
** Semantic Highlight
** Documentation Hover
** Code Completion
** Smart Paste
** Code Formatter
** Toggle Comment
** Code Templates
* Code Navigation
**Code Folding
** Code Outline
** Hyperlink navigation
** Goto declaration


-- 

Andrey Sobolev | Xored Software = Inc, Principal = Software Engineer | http://www.xored.com | O: +7 383 363 1033 | M: +7 = 913 897 3747 | E:andrey.sobolev@xored.com
_______________________________________________=
Discuss mailing list
Discuss@lists.opendaylight.= org
https://lists.opendaylight.org/mailman/listinfo/discuss

= --Apple-Mail=_3B4988C5-03B6-4885-8174-7F02565D9362-- --Apple-Mail=_E6669AC7-09D1-4AF3-8BF0-1CF378033E26 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT/yTSAAoJEPcO+I7eiUJZpFkP/17yBjsNibun/yal8lR1p2YL J+U5kN1qvBEdb6j15AR7RjS6MYUbmvkC1XI/GXBAnvGdt7iGRaYOBCsJpSpOIrXi ov2jiar96M4kOSfDgHoCDhjaZf6HstAiev3yeajq/4iT34dqfGjmz9As2aBu8+cr GpKbTkBxpsKEsn9OODox7o2Sn9dYnOgHCg+ahe+gkrXrIiyCbkJJu68qulEX8Ywg LbZeznQUaIZib+vgQm3fWtLVPvuP8lj3KYFi665apanWTPgQOuseODHlkv8OAGBN mxp0degpq26lfplGABvXughM2aS4m2UleBwrfB52NyPpyVY+YTXkbjNmkNJKNbU5 rpR8JT7bShaUaes+UNVsB3ChjRoVg5E8fEn6fA9lZcSVjT6D2/xn6qoSgu9/ZIg2 OoDN9R7ZgNisw+/Kk5d4D+jbkqxZnrsHPkXWQvw6IQw8Sxa2jaiFIipe1uvrejEp CSwGqAd+KLjcb8MsvB4iIs9djZt6VbUp3MSz0NNuZEkUpUrYze+XH9gD3sYeld21 gTybb3Hi6C9ylvF0lcJcqqsrAIy2gJUrReWEomDEw69x9gkE3zYgRKom0+AXyI2C vXEDEJDmBDOBIB9yC+Mw1MXXa0gpT88Tzg5r+rxOcxgKAlLHwGDgWQWF3oHIofrB PNL91d2hsvCd1FB134Fb =2O5m -----END PGP SIGNATURE----- --Apple-Mail=_E6669AC7-09D1-4AF3-8BF0-1CF378033E26-- From nobody Thu Aug 28 05:53: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 722D81A03EE for ; Thu, 28 Aug 2014 05:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 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.668] 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 aZ5ByNFER8xU for ; Thu, 28 Aug 2014 05:53:23 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 225691A03EB for ; Thu, 28 Aug 2014 05:53:23 -0700 (PDT) Received: from [192.168.42.30] (cst-prg-96-12.cust.vodafone.cz [46.135.96.12]) by mail.nic.cz (Postfix) with ESMTPSA id E8FE013F7CA; Thu, 28 Aug 2014 14:53:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409230401; bh=9H2RW5c5OKqFgAJYwTw+3s6RLoA6YI0t7WBO9ylrs30=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=B7p+Cgg7Wp+7YpCc4WJkmI60elQTgZM6V+Nw9vg3pulqj4mcEjklBG5YyKM0iri9j 33ObidR/pqKapXlgynPfzAk0NQTM2LkaEVIQAxo4QYIdE+/7+q7sqL6NiDdHc46tRi cSNSNqpZJyWtZ+sIPA+76EuwhKxHh4uEZLH/esdw= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140828120536.GB61647@elstar.local> Date: Thu, 28 Aug 2014 14:53:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140828074829.GA61114@elstar.local> <20140828.124839.716000072014037611.mbj@tail-f.com> <20140828120536.GB61647@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wiBiu8kUYpKosuwcZo10GthGnAs Cc: netmod@ietf.org Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 28 Aug 2014 12:53:24 -0000 On 28 Aug 2014, at 14:05, Juergen Schoenwaelder = wrote: > On Thu, Aug 28, 2014 at 01:58:01PM +0200, Ladislav Lhotka wrote: >> On 28 Aug 2014, at 12:48, Martin Bjorklund wrote: >>=20 >>> I guess we *could* solve this by stating that any xmlns declarations >>> that are used within the anyxml data must be inserted by the encoder >>> at the proper place, giving: >>>=20 >>> "x": { >>> "y": " 4668 " >>> } >>=20 >> Right, this is one reason. Another is that some applications might = want to do something more clever, see the example in sec. 3.2.5. >>=20 >> In any case, applications are free do what you propose, if it makes = sense, and this should be stated in the description of the anyxml = statement so interoperability is possible. >>=20 >=20 > I want robust and interoperable encoding. I do not care about > cleverness that only works for some applications. One size fits all isn=92t the same as robust and interoperable. Every = anyxml is defined in a YANG module so why couldn=92t each have a = specific purpose, format, semantics and handling? Why is this = non-interoperable or non-robust? IMO moving around pieces of invalid XML = is worse. 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 Thu Aug 28 06:25: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 1C0161A03FF for ; Thu, 28 Aug 2014 06:25:28 -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 NoyQniLadL1C for ; Thu, 28 Aug 2014 06:25:26 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D87BD1A041C for ; Thu, 28 Aug 2014 06:25:25 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id f51so707494qge.16 for ; Thu, 28 Aug 2014 06:25:25 -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=Y8iqViVfw3g83NwPHTfUCRwcJ6d22rv+DDRZYjaC2cs=; b=B7gbWK+G7yrvsg1grcv+vtRMAUjhq0vczovGaPUS7IFtMHX7cGxtoI/2uFo26xxkEd xNuxfckAtlcAsIZzsGXqf7+51qu4FGFjEWsvp+N9RrOLIp/MO96CMjzQbRZaNOpWhY7L K/6/i6XRZ/tEuRWMZB0e1b1hXbyYZljrcxonP6MUfxqwDT0BpFy2qgUdP2JhO2bgP7m7 lhkxD7rcYYG0uLT5hXwlZ6Rx1FbdLcNuC00UY6070uehy1dcIayiGbLDa7RA20qEuMD3 p1mQ2VTVW2CJDGbwGTWIT9gIio5VgoNah7k5vZuvMsPktdFMShCTVuDdjpkv1pkm5lfL nURg== X-Gm-Message-State: ALoCoQl3apfhbijTVvqfqFcX6DYbABREwld1zeuI/H4cRKcUa2Xaij2hreSJ0RFbjOTqU+A74BNR MIME-Version: 1.0 X-Received: by 10.229.212.66 with SMTP id gr2mr6466227qcb.27.1409232324946; Thu, 28 Aug 2014 06:25:24 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Thu, 28 Aug 2014 06:25:24 -0700 (PDT) In-Reply-To: <20140828124505.GA61827@elstar.local> References: <20140828074829.GA61114@elstar.local> <20140828120340.GA61647@elstar.local> <20140828124505.GA61827@elstar.local> Date: Thu, 28 Aug 2014 06:25:24 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11339b582285cb0501b078fd Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1VDwdQ8vvTN0N6kpv4UpPf9jwIg Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 28 Aug 2014 13:25:28 -0000 --001a11339b582285cb0501b078fd Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 28, 2014 at 5:45 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Aug 28, 2014 at 05:13:51AM -0700, Andy Bierman wrote: > > On Thu, Aug 28, 2014 at 5:03 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Thu, Aug 28, 2014 at 04:39:05AM -0700, Andy Bierman wrote: > > > > Hi, > > > > > > > > I do not agree that anyxml needs to be encoded as a string, or > treated > > > > special somehow. NETCONF does not allow mixed mode XML. > > > > > > RFC 6020 section 7.10: > > > > > > The "anyxml" statement is used to represent an unknown chunk of XML. > > > No restrictions are placed on the XML. > > > > > > So are there restrictions or not? > > > > > > > words on a page vs. running code. > > No customer has complained that the anyxml we support is too restrictive. > > > > So are you saying the discussion we had in Toronto about anyxml and > anydata is pointless since in reality anyxml really is anydata? Can > other implementations confirm this? If this is generally true, we > should perhaps revisit the discussion and clarify in RFC 6020 bis > that anyxml really means a rather restricted set of XML. > > Question: How do you deal with namespaces in the XML when you render > it in JSON? The JSON I-D requires that you know the module name while > all you have is a URI... > > I have not implemented JSON attributes yet. In XML, the code needs to preserve attributes (including xmlns). I should stress that we rarely use anyxml as supposedly intended. It is usually tagged with a YANG extension so it is treated as a document root (, , etc.), and even then, these "root" containers are only used within RPC input or output. We support anyxml as config or state data, but recommend that real YANG be used instead. I would prefer to have a special container in YANG 1.1 (called "docroot"?) instead of anyxml or anydata. /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a11339b582285cb0501b078fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Aug 28, 2014 at 5:45 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Aug 28, 2014 at 05:13:51AM -0700, An= dy Bierman wrote:
> On Thu, Aug 28, 2014 at 5:03 AM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > On Thu, Aug 28, 2014 at 04:39:05AM -0700, Andy Bierman wrote:
> > > Hi,
> > >
> > > I do not agree that anyxml needs to be encoded as a string, = or treated
> > > special somehow.=A0 NETCONF does not allow mixed mode XML. > >
> > RFC 6020 section 7.10:
> >
> >=A0 =A0 The "anyxml" statement is used to represent an u= nknown chunk of XML.
> >=A0 =A0 No restrictions are placed on the XML.
> >
> > So are there restrictions or not?
> >
>
> words on a page vs. running code.
> No customer has complained that the anyxml we support is too restricti= ve.
>

So are you saying the discussion we had in Toronto about anyxml and
anydata is pointless since in reality anyxml really is anydata? Can
other implementations confirm this? If this is generally true, we
should perhaps revisit the discussion and clarify in RFC 6020 bis
that anyxml really means a rather restricted set of XML.

Question: How do you deal with namespaces in the XML when you render
it in JSON? The JSON I-D requires that you know the module name while
all you have is a URI...


I have not implemented JSON attributes yet. =A0In XM= L, the code needs to
preserve attributes (including xmlns).
=

I should stress that we rarely use anyxml as supposedly inte= nded.
It is usually tagged with a YANG extension so it is treated= as a document
root (<config>, <data>, etc.), and eve= n then, these "root" containers are
only used within RPC input or output. =A0We support anyxml as config o= r state data,
but recommend that real YANG be used instead.
=

I would prefer to have a special container in YANG 1.1 = (called "docroot"?) instead of anyxml or anydata.

/js


Andy
=A0
=
--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

--001a11339b582285cb0501b078fd-- From nobody Thu Aug 28 07:47: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 0EA8F1A7000 for ; Thu, 28 Aug 2014 07:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6] 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 Vgl4_F1GL8Uq for ; Thu, 28 Aug 2014 07:47:47 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A97541A6FF8 for ; Thu, 28 Aug 2014 07:47:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 5B49C5406C1; Thu, 28 Aug 2014 16:47:44 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsQpdMDn0YLB; Thu, 28 Aug 2014 16:47:39 +0200 (CEST) Received: from localhost (cst-prg-120-4.cust.vodafone.cz [46.135.120.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 3BFB854061B; Thu, 28 Aug 2014 16:47:36 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , netmod@ietf.org In-Reply-To: <20140827.221930.227693858.mbj@tail-f.com> References: <20140827.221930.227693858.mbj@tail-f.com> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Thu, 28 Aug 2014 16:47:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZKSnDvqgaZq8IGZ3irgK1miUIEM Subject: Re: [netmod] YANG unions in 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, 28 Aug 2014 14:47:49 -0000 Martin Bjorklund writes: > Hi, > > In the current json draft, a value of type 'union' is encoded in the > same way as the "active" member type. For example, with: First of all, I think it is a general problem of the union type that it is impossible (or at least not straightforward) to indicate which of the member types a given instance is supposed to have. For a leaf with the type inet:host, it can happen that an IPv4 address with a typo will be accepted and interpreted as domain-name. This might be another use case for a metadata annotation. > > leaf foo { > type union { > type int32; > type string; > } > } > > the leaf might be encoded as: > > "foo": 42 > > Now, suppose we use json to set this leaf like this: > > "foo": "4668" > > If we the read the value back, what do we get? Probably "4668". It depends, I would say it is more a question for the protocol what the server does with the values it receives. yang-json is about the mapping of XML to JSON and back. What it tells is that - 4668 maps to "foo": 4668, and - both "foo": 4668 and "foo": "4668" map to 4668. Hmm, but then the JSON -> XML mapping is not 1-1 as the draft claims. I have to think about it. > > But if we instead set the value over xml: > > 4668 > > we will then get back: > > "foo": 4668 > > over json. Yes, that's for sure. > > What happens if leaf foo is the key in a list - can we create two list > instances with key: > > "foo": 4668 > > and: > > "foo": "4668" I posted exactly the same question to the yang-doctors mailing list after the tutorial in Toronto. It can be even more fun: key foo; leaf foo { type union { type decimal64 { fraction-digits 2; } type string; } } Assume the client wants to edit list entry with key 1.00 but sends a key 1.000, and a new list entry with the string key "1.000" is created instead. This is really quite brittle. > > at the same time? > > > It seems the simplest solution would be to say that unions are encoded > as strings in json. This would be another step in making JSON more XML-like and gradually losing the main point of using JSON - simplicity. For unions that have no string members it really makes no sense. I would prefer if RESTCONF specifies the behaviour of the receiving side in such cases. Lada > > > /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 Thu Aug 28 08:06:01 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18F91A8026 for ; Thu, 28 Aug 2014 08:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qdM1y_PBEVy for ; Thu, 28 Aug 2014 08:05:59 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46D521A802E for ; Thu, 28 Aug 2014 08:05:59 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id m20so892646qcx.41 for ; Thu, 28 Aug 2014 08:05:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EniKhovOjut5KJn30WD0UjoXwXleUosEUZ7Bky/YYFo=; b=b58GEJGlkL1+0B5lvU5n3BoFJiB9ko2pm7QxZI9TlW/5diC4ETJb1MHicBok/8FRM7 Hx+35VrBgzk11xWvdYA2qQcwCm47uCfhLJVBnSM3sMiG0XUAlfS57+JIRNIi8sb6kUpe bC5EEAEwv9fFECd5LnVCEVoMVHIlQabtGqR3SkVhdX8jobRKdnwiOlDdv3d05kPULG4w VO0b31xYSYSoihGL+Uu4lnsGbX5AC/yCmJ3NemiKsYGgQ2dNl/hVx0IpYWfntwQXP+2n GycCWQfUX17AYEcm/5yzRgOJNVAxLvxrHgzLNi1t5u8Gfw7frbanp38Tpmyh26lWH3ef 5hSQ== X-Gm-Message-State: ALoCoQmQNs3eKFIp/r5XzuvDLS0Nq27PJJbHU3CBL31ZPq1ueLDzWtXjKmPTnOqhhkJeSWJ0dhFE MIME-Version: 1.0 X-Received: by 10.140.98.7 with SMTP id n7mr6971793qge.83.1409238358252; Thu, 28 Aug 2014 08:05:58 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Thu, 28 Aug 2014 08:05:58 -0700 (PDT) In-Reply-To: References: <20140827.221930.227693858.mbj@tail-f.com> Date: Thu, 28 Aug 2014 08:05:58 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113ac3c6bff7fd0501b1df45 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SUTIfoz7ihBQLFMjeUrmMcjOkcs Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG unions in 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, 28 Aug 2014 15:06:01 -0000 --001a113ac3c6bff7fd0501b1df45 Content-Type: text/plain; charset=ISO-8859-1 Hi, I realize that the standard text is important and needs to be correct, but when writing the code for this, I followed the Postel Principle. The YANG schema wins any conflict. The tools will try to figure out how to get the content to fit the YANG schema, even if the peer did not follow every detail in Lada's draft. Re, these examples: the 42 vs "42" would be treated as a duplicate-entry error. The "1.000" is a perfectly valid key by the (strange) YANG typedef rules, so it would be accepted. Andy On Thu, Aug 28, 2014 at 7:47 AM, Ladislav Lhotka wrote: > Martin Bjorklund writes: > > > Hi, > > > > In the current json draft, a value of type 'union' is encoded in the > > same way as the "active" member type. For example, with: > > First of all, I think it is a general problem of the union type that it is > impossible > (or at least not straightforward) to indicate which of the member types > a given instance is supposed to have. For a leaf with the type > inet:host, it can happen that an IPv4 address with a typo will be accepted > and interpreted as domain-name. This might be another use case for a > metadata annotation. > > > > > leaf foo { > > type union { > > type int32; > > type string; > > } > > } > > > > the leaf might be encoded as: > > > > "foo": 42 > > > > Now, suppose we use json to set this leaf like this: > > > > "foo": "4668" > > > > If we the read the value back, what do we get? Probably "4668". > > It depends, I would say it is more a question for the protocol what the > server does > with the values it receives. yang-json is about the mapping of XML to > JSON and back. What it tells is that > > - 4668 maps to "foo": 4668, and > - both "foo": 4668 and "foo": "4668" map to 4668. > > Hmm, but then the JSON -> XML mapping is not 1-1 as the draft claims. I > have to think about it. > > > > > But if we instead set the value over xml: > > > > > 4668 > > > > we will then get back: > > > > "foo": 4668 > > > > over json. > > Yes, that's for sure. > > > > > What happens if leaf foo is the key in a list - can we create two list > > instances with key: > > > > "foo": 4668 > > > > and: > > > > "foo": "4668" > > I posted exactly the same question to the yang-doctors mailing list after > the tutorial in Toronto. > > It can be even more fun: > > key foo; > leaf foo { > type union { > type decimal64 { > fraction-digits 2; > } > type string; > } > } > > Assume the client wants to edit list entry with key 1.00 but sends a key > 1.000, and a new list entry with the string key "1.000" is created > instead. This is really quite brittle. > > > > > > at the same time? > > > > > > It seems the simplest solution would be to say that unions are encoded > > as strings in json. > > This would be another step in making JSON more XML-like and gradually > losing the main point of using JSON - simplicity. For unions that have > no string members it really makes no sense. > > I would prefer if RESTCONF specifies the behaviour of the receiving side > in such cases. > > Lada > > > > > > > /martin > > > > > > > > _______________________________________________ > > 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 > --001a113ac3c6bff7fd0501b1df45 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I realize that the standard text is= important and needs to be correct, but when writing
the code for= this, I followed the Postel Principle. The YANG schema wins any conflict.<= /div>
The tools will try to figure out how to get the content to fit the YAN= G schema, even if
the peer did not follow every detail in Lada= 9;s draft.

Re, these examples: the 42 vs "42&= quot; would be treated as a duplicate-entry error.
The "1.000" is a perfectly valid key by the (strange) YANG t= ypedef rules, so
it would be accepted.

<= br>
Andy


On Thu, Aug 28, 2014 at 7:47 AM, Ladislav Lh= otka <lhotka@nic.cz> wrote:
Martin Bjorklund <mbj@tail-f.com&g= t; writes:

> Hi,
>
> In the current json draft, a value of type 'union' is encoded = in the
> same way as the "active" member type.=A0 For example, with:<= br>
First of all, I think it is a general problem of the union type that it is = impossible
(or at least not straightforward) to indicate which of the member types
a given instance is supposed to have. For a leaf with the type
inet:host, it can happen that an IPv4 address with a typo will be accepted<= br> and interpreted as domain-name. This might be another use case for a
metadata annotation.

>
>=A0 =A0 leaf foo {
>=A0 =A0 =A0 type union {
>=A0 =A0 =A0 =A0 type int32;
>=A0 =A0 =A0 =A0 type string;
>=A0 =A0 =A0 }
>=A0 =A0 }
>
> the leaf might be encoded as:
>
>=A0 =A0 "foo": 42
>
> Now, suppose we use json to set this leaf like this:
>
>=A0 =A0 "foo": "4668"
>
> If we the read the value back, what do we get?=A0 Probably "4668&= quot;.

It depends, I would say it is more a question for the protocol what the ser= ver does
with the values it receives. yang-json is about the mapping of XML to
JSON and back. What it tells is that

- <foo>4668</foo> maps to "foo": 4668, and
- both "foo": 4668 and "foo": "4668" map to &= lt;foo>4668</foo>.

Hmm, but then the JSON -> XML mapping is not 1-1 as the draft claims. I<= br> have to think about it.

>
> But if we instead set the value over xml:

>
>=A0 =A0<foo>4668</foo>
>
> we will then get back:
>
>=A0 =A0 "foo": 4668
>
> over json.

Yes, that's for sure.

>
> What happens if leaf foo is the key in a list - can we create two list=
> instances with key:
>
>=A0 =A0 "foo": 4668
>
> and:
>
>=A0 =A0 "foo": "4668"

I posted exactly the same question to the yang-doctors mailing list after the tutorial in Toronto.

It can be even more fun:

=A0 =A0 key foo;
=A0 =A0 leaf foo {
=A0 =A0 =A0 type union {
=A0 =A0 =A0 =A0 type decimal64 {
=A0 =A0 =A0 =A0 =A0 fraction-digits 2;
=A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 type string;
=A0 =A0 =A0 }
=A0 =A0 }

Assume the client wants to edit list entry with key 1.00 but sends a key 1.000, and a new list entry with the string key "1.000" is create= d
instead. This is really quite brittle.


>
> at the same time?
>
>
> It seems the simplest solution would be to say that unions are encoded=
> as strings in json.

This would be another step in making JSON more XML-like and gradually
losing the main point of using JSON - simplicity. For unions that have
no string members it really makes no sense.

I would prefer if RESTCONF specifies the behaviour of the receiving side in such cases.

Lada

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

--001a113ac3c6bff7fd0501b1df45-- From nobody Thu Aug 28 08:15: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 6611C1A86FD for ; Thu, 28 Aug 2014 08:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2u3EuXUla6T for ; Thu, 28 Aug 2014 08:15:23 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 428AD1A86F9 for ; Thu, 28 Aug 2014 08:14:33 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BE20A1286; Thu, 28 Aug 2014 17:14:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 4_Lh1SGVzg-j; Thu, 28 Aug 2014 17:14:23 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 28 Aug 2014 17:14:31 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 17E6B20036; Thu, 28 Aug 2014 17:14:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eLaIrgoHBkA2; Thu, 28 Aug 2014 17:14:30 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E9CFC20035; Thu, 28 Aug 2014 17:14:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 30A0C2E52AF0; Thu, 28 Aug 2014 17:14:27 +0200 (CEST) Date: Thu, 28 Aug 2014 17:14:27 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140828151427.GA62093@elstar.local> Mail-Followup-To: Andy Bierman , "netmod@ietf.org" References: <20140828074829.GA61114@elstar.local> <20140828120340.GA61647@elstar.local> <20140828124505.GA61827@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/JR1o7yCL9KpZ7NHQPW2YUtpqUgU Cc: "netmod@ietf.org" Subject: Re: [netmod] yang json and anyxml 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, 28 Aug 2014 15:15:25 -0000 On Thu, Aug 28, 2014 at 06:25:24AM -0700, Andy Bierman wrote: > On Thu, Aug 28, 2014 at 5:45 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Thu, Aug 28, 2014 at 05:13:51AM -0700, Andy Bierman wrote: > > > On Thu, Aug 28, 2014 at 5:03 AM, Juergen Schoenwaelder < > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > On Thu, Aug 28, 2014 at 04:39:05AM -0700, Andy Bierman wrote: > > > > > Hi, > > > > > > > > > > I do not agree that anyxml needs to be encoded as a string, or > > treated > > > > > special somehow. NETCONF does not allow mixed mode XML. > > > > > > > > RFC 6020 section 7.10: > > > > > > > > The "anyxml" statement is used to represent an unknown chunk of XML. > > > > No restrictions are placed on the XML. > > > > > > > > So are there restrictions or not? > > > > > > > > > > words on a page vs. running code. > > > No customer has complained that the anyxml we support is too restrictive. > > > > > > > So are you saying the discussion we had in Toronto about anyxml and > > anydata is pointless since in reality anyxml really is anydata? Can > > other implementations confirm this? If this is generally true, we > > should perhaps revisit the discussion and clarify in RFC 6020 bis > > that anyxml really means a rather restricted set of XML. > > > > Question: How do you deal with namespaces in the XML when you render > > it in JSON? The JSON I-D requires that you know the module name while > > all you have is a URI... > > > > > I have not implemented JSON attributes yet. In XML, the code needs to > preserve attributes (including xmlns). > My question was not about attributes... /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 Aug 28 08:23: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 E00841A0495 for ; Thu, 28 Aug 2014 08:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YpKcTnA5Enm for ; Thu, 28 Aug 2014 08:22:50 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5F091A030A for ; Thu, 28 Aug 2014 08:22:49 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7942DFE1; Thu, 28 Aug 2014 17:22:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id PMKd5FCjGawG; Thu, 28 Aug 2014 17:22:39 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 28 Aug 2014 17:22:47 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C158720035; Thu, 28 Aug 2014 17:22:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id USdP-lm0iWPn; Thu, 28 Aug 2014 17:22:47 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 661DC20033; Thu, 28 Aug 2014 17:22:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4EC432E52B1B; Thu, 28 Aug 2014 17:22:46 +0200 (CEST) Date: Thu, 28 Aug 2014 17:22:46 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140828152246.GB62093@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin =?iso-8859-1?Q?Bj=F6rklund?= , netmod@ietf.org References: <20140828074829.GA61114@elstar.local> <20140828.124839.716000072014037611.mbj@tail-f.com> <20140828120536.GB61647@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/X_0kAc89cwRm8oRNARuslhJ7vOk Cc: netmod@ietf.org Subject: Re: [netmod] yang json and anyxml 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, 28 Aug 2014 15:22:53 -0000 On Thu, Aug 28, 2014 at 02:53:19PM +0200, Ladislav Lhotka wrote: > > > > > I want robust and interoperable encoding. I do not care about > > cleverness that only works for some applications. > > One size fits all isn’t the same as robust and interoperable. Every anyxml is defined in a YANG module so why couldn’t each have a specific purpose, format, semantics and handling? Why is this non-interoperable or non-robust? IMO moving around pieces of invalid XML is worse. > I am not sure "every anyxml is defined in a YANG module" is true. I heard that Kent uses configlets that are anyxml and the configlets may actually be defined in XSD. Quoting draft-ietf-netmod-yang-json-00.txt: An XML element that is modeled as a YANG anyxml data node is translated to a name/object pair. The content of such an element is not modelled by YANG, and there may not be a straightforward mapping to JSON text (e.g., if it is a mixed XML content). Therefore, translation of anyxml contents is necessarily application-specific and outside the scope of this document. I do not think "translation of anyxml contents is necessarily application-specific" is interoperable. (I note that the second quoted sentence contradicts your statement that "every anyxml is defined in a YANG module"). And the example given in draft-ietf-netmod-yang-json-00.txt is actually supporting my concern. Why should something translate

This is very cool.

into an arbitrary markup notation { "bar": { "p": "This is *very* cool." } } if bar is of type anyxml? I would strongly prefer to get the unmodified xhtml content for bar and not some arbitrary rendering of it. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Aug 28 08:24: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 E2D9C1A030A; Thu, 28 Aug 2014 08:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.168 X-Spam-Level: X-Spam-Status: No, score=-13.168 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 BDtdGBpeqD9G; Thu, 28 Aug 2014 08:24:33 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C96D1A06FC; Thu, 28 Aug 2014 08:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29477; q=dns/txt; s=iport; t=1409239473; x=1410449073; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UUaWlJnTkIdT2jpeN2ooo6VAdPLfWpG3/ZUrZmZ7C7o=; b=haYGHHnGj4B1Y2Tx04CiPsMf2sKsQxzuhGAmkkvXrElFO6Ra94bOS4kG Ixc5ncHRZAYdoLggiZwDsm7CGKbmDBFuh2tpXZUkyqR0ctCz4DaFZjEsQ SlLkPv3Szn64ip29nnzxCJdyT1A+W37xaLUC3Jhge7MjN4QaQQTvbgU1G 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FACFJ/1OtJV2R/2dsb2JhbABbgkdGU1cE03YBgRkWd4QDAQEBBC05DAcQAgEIEQEDAQELFgcHMhQDBggBAQQBDQUIE4gnv0oXjnQnMQYBgy+BHQWRL6BIg15sgQYCHgYcgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,418,1406592000"; d="scan'208,217";a="351062464" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP; 28 Aug 2014 15:24:15 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s7SFOF8Q007812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 15:24:15 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.110]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Thu, 28 Aug 2014 10:24:15 -0500 From: "Tissa Senevirathne (tsenevir)" To: Gregory Mirsky , "'draft-tissa-netmod-oam@tools.ietf.org'" Thread-Topic: draft-tissa-netmod-oam Thread-Index: Ac+tKouGZjiF/7GjRZGwGunQsgwS9AVplJ1w Date: Thu, 28 Aug 2014 15:24:14 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B82567E@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B82567E@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.14.1] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562EF118C6xmbrcdx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/TECoc4z6JE1q033Y_odBCLV5ARc Cc: "l2vpn@ietf.org" , "mpls@ietf.org" , "spring@ietf.org" , "time@ietf.org" , "'netmod@ietf.org'" , "nvo3@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: [netmod] draft-tissa-netmod-oam X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 28 Aug 2014 15:24:39 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE193562EF118C6xmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg Before answering the specific questions below, would like explain few aspe= cts related to the extended CFM model used here. CFM originally was design= ed exclusively for Ethernet. As part of the TRILL OAM work we decoupled CFM= model from Ethernet based addressing and made it addressing independent. T= hat is the CFM model that is referred here. CFM defines a complete fault model that include fault domains, Test point, = Layering etc. Strict definition of such is needed to develop a complete OAM= solution regardless of the underline technology. CFM does a fantastic job = in accomplishing that and AFIK there is no other model. We are leveraging t= hat model. The word generic OAM is utilized here to indicate that the model can be app= lied regardless of the underlying technology. YANG model is not a one-one copy of CFM YANG defined in MEF. Rather it is d= efined with address independent and extensibility in mind. With the above in mind, specific answers in-line: From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Sunday, August 24, 2014 10:15 PM To: 'draft-tissa-netmod-oam@tools.ietf.org' Cc: l2vpn@ietf.org; mpls@ietf.org; spring@ietf.org; time@ietf.org; 'netmod@= ietf.org'; nvo3@ietf.org; rtg-bfd@ietf.org Subject: draft-tissa-netmod-oam Dear Authors, et.al, please kindly consider my comments and questions to this document: * Introduction o "... it is a reasonable choice to develop the unified OAM framework ba= sed on those (CFM) concepts." I agree that for packet switching connection-= oriented networks that are based on G.800 architecture CFM, but more so Y.1= 731, provides shared concepts. I think that the same cannot be said for con= nectionless packet switching networks. Thus extending CFM model onto arbitr= ary networks without consideration whether these are connection-oriented or= connectionless is very questionable approach, IMO; [Answer] As stated above it is the OAM Model that is leveraged here. Regard= less of connection oriented or not the model on Fault domains, Test points = etc is valid. In theory connection oriented can be broken in to connection establishment = and data forwarding. With that in mind, one can define Fault domain and tes= t points. Followed by definition of the Fault identifications tools accordi= ngly. Do you have a preferred OAM tool for fault verification/isolation and loss= and performance monitoring for connection oriented connectuons ?. If so wo= uld like to review and map to the model. o "...CFM, it is a reasonable choice to develop the unified OAM framework= based on those concepts" IP OAM is not based on Ethernet Service OAM model= or principles but, IMO, OAM of overlay networks more closer resemble IP OA= M as these networks are connectionless in their architecture; [Answer] Please see the answer above and extended CFM model. It is the mod= el that is presented here, regardless of the connectioness, OAM tools need= fault domains and fault boundaries. Addidtionally as stated in the explana= tion above, there is nothing Ethernet in CFM, once the addressing is decoup= led. o "The YANG model presented in this document is the base model and suppor= ts IP Ping and Traceroute." If only these and similar OAM tools, e.g. LSP p= ing, Loopback/Linktrace, are in scope of the document, then, I believe, the= title may say something like "YANG model of on-demand OAM tool to detect a= nd localize Loss of Continuity defect". Referring to ping/traceroute as "ge= neric OAM" comes as stretch too far; [Answer] I think there is a miss understanding this model is not limited to= Ping and Trace route. Ping and traceroute are only examples to get the wor= k stared and discussion going. As we go along other tools will be mapped to= the model. o "...initiate a performance monitoring session can do so in the same ma= nner regardless of the underlying protocol or technology" I'd point to work= of LMAP WG on informational model of performance measurements in large-sca= le access networks, work of ITU-T's SG15, MEF. Perhaps sentence can be stop= ped after "... or a Traceroute". [Answer] I did not fully understand your point. o "In this document we define the YANG model for Generic OAM" Can you pro= vide definition or reference to the definition of the "Generic OAM"? It is = challenging to validate informational model of something that not been suff= iciently defined. [Answer] As explained earlier terminology generic OAM is used to indicate = that the presented OAM model can be applied independent of the underlying t= echnology. In section 1, we have stated the following: "..In this document,= we take the [8021Q] CFM model and extend it to a technology independent fr= amework and build the corresponding YANG model accordingly. The YANG model = presented in this document is the base model and supports IP Ping and Trace= route. The generic OAM YANG model is designed such that it can be extended = to cover various technologies. Technology dependent nodes and RPC commands = are defined in technology specific YANG models, which use and extend the ba= se model defined here. .... " * Section 3 o "This allows users to traverse between OAM of different technologies at= ease through a uniform API set." Usually relationships between OAM layers = referred and viewed as OAM interworking. There are several examples of IETF= addressing aspects of OAM interworking. I think that interworking includes= not only scenarios of nested OAM layers but peering layers and thus is bro= ader than introduced in the document "nested OAM". [Answer] Can you please provide some example here, I am not quite clear. Guessing from the word peering, if we are referring to cascaded sections of= different technologies such as IP Cloud, MPLS cloud and another IP cloud. = Then the model presented here is the answer. You can have an end end OAM se= ssion at a higher MD-Level. Each of the clouds below can have separate OAM = at a lower MD-Level. These can be utilized for fault isolation. o Figure 1 depicts OAM of both connection-oriented and connectionless net= works. What you see common, generic in respective OAM of these networks? [Answer] Please see the answers above. * Section 4 o "In IP, the MA can be per IP Subnet ..." As there's no definition of MA= in IP, is this the definition or one of examples. Can MA in IP network be = other than per IP Subnet? [Answer] It is ".. can be", so it meant to be an example and other possibil= ities are not ruled out and model does not assume any such limitation. o "Under each MA, there can be two or more MEPs (Maintenance End Points)"= Firstly, since you adopt MA-centric terminology, MEP stands for Maintenanc= e Association End Point. Secondly, in some OAM models Down and Up MEP being= distinguished. Would your model consider that? As there's no definition of= MEP for several networks you've listed, e.g. IP, how the YANG model will a= bstract something that is not defined? And thirdly, how and where MIPs are = located in IP OAM? [Answer] Yes model accept both UP/Down. One cannot say for IP there is no MEP. MEP is a functional abstraction of a= test point that generate and respond to OAM messages. In that regard IP de= vices today have an implicit MEP at the CPU. The model allow to provide mor= e semantics to the MEP and allow to create UP/Down per interface or other s= cope, hence providing more granularity in fault isolation/verification and = monitoring. Thank you for your consideration of my notes and looking forward to the int= eresting discussion. Thank you for spending time to review and comment. We are updating the next= version with comments received so far and specifically during IETF in Cana= da. We are more than happy enhance where applicable or need more clarity. Regards, Greg --_000_FBEA3E19AA24F847BA3AE74E2FE193562EF118C6xmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greg=

 

Before answering the s= pecific questions below,  would like explain few aspects related to th= e extended CFM model used here. CFM  originally was designed exclusive= ly for Ethernet. As part of the TRILL OAM work we decoupled CFM model from Ethernet based addressing and made it addressi= ng independent. That is the CFM model that is referred here.

 

CFM defines a complete= fault model that include fault domains, Test point, Layering etc. Strict d= efinition of such is needed to develop a complete OAM solution regardless o= f the underline technology. CFM does a fantastic job in accomplishing that and AFIK there is no other model. We= are leveraging that model.

 

The word generic OAM i= s utilized here to indicate that the model can be applied regardless of the= underlying technology.

 

YANG model is not a on= e-one copy of CFM YANG defined in MEF. Rather it is defined with address in= dependent and extensibility in mind.

 

With the above in mind= , specific answers in-line:

 

From: L2vpn [m= ailto:l2vpn-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Sunday, August 24, 2014 10:15 PM
To: 'draft-tissa-netmod-oam@tools.ietf.org'
Cc: l2vpn@ietf.org; mpls@ietf.org; spring@ietf.org; time@ietf.org; '= netmod@ietf.org'; nvo3@ietf.org; rtg-bfd@ietf.org
Subject: draft-tissa-netmod-oam

 

Dear Authors, et.al,

please kindly consider my comments and questions to = this document:

·         Introduction

o    “… it is a reasonable choi= ce to develop the unified OAM framework based on those (CFM) concepts.̶= 1; I agree that for packet switching connection-oriented networks that are = based on G.800 architecture CFM, but more so Y.1731, provides shared concepts. I think that the same cannot be said for connectionless p= acket switching networks. Thus extending CFM model onto arbitrary networks = without consideration whether these are connection-oriented or connectionle= ss is very questionable approach, IMO;

 

 

[Answer] As stated abo= ve it is the OAM Model that is leveraged here. Regardless of connection ori= ented or not the model on Fault domains, Test points etc is valid.

 

In theory connection o= riented can be broken in to connection establishment and data forwarding. W= ith that in mind, one can define Fault domain and test points. Followed by = definition of the Fault identifications tools accordingly.

 

Do you have a preferre= d OAM tool  for fault verification/isolation and loss and performance = monitoring for connection oriented connectuons ?. If so would like to revie= w and map to the model.

 

 

o   “…CFM, it is a reasonable choice= to develop the unified OAM framework based on those concepts” IP OAM= is not based on Ethernet Service OAM model or principles but, IMO, OAM of = overlay networks more closer resemble IP OAM as these networks are connectionless in their architecture;

 

[Answer]  Please = see the answer above and extended CFM model. It is the model that is presen= ted here, regardless of the connectioness,  OAM tools need fault domai= ns and fault boundaries. Addidtionally as stated in the explanation above, there is nothing Ethernet in CFM, once the addre= ssing is decoupled.

 

o   “The YANG model presented in this docu= ment is the base model and supports IP Ping and Traceroute.” If only = these and similar OAM tools, e.g. LSP ping, Loopback/Linktrace, are in scop= e of the document, then, I believe, the title may say something like “YANG model of on-demand OAM tool to detect a= nd localize Loss of Continuity defect”. Referring to ping/traceroute = as “generic OAM” comes as stretch too far;

 

[Answer] I think there= is a miss understanding this model is not limited to Ping and Trace route.= Ping and traceroute are only examples to get the work stared and discussio= n going. As we go along other tools will be mapped to the model.

o    “…initiate a performance m= onitoring session can do so in the same manner regardless of the underlying= protocol or technology” I’d point to work of LMAP WG on inform= ational model of performance measurements in large-scale access networks, work of ITU-T’s SG15, MEF. Perhaps sentence can be stopped= after “… or a Traceroute”.

[Answer] I did not ful= ly understand your point.

 

o   “In this document we define the YANG m= odel for Generic OAM” Can you provide definition or reference to the = definition of the “Generic OAM”? It is challenging to validate = informational model of something that not been sufficiently defined.

 

[Answer]  As expl= ained earlier terminology generic OAM is used to indicate that the presente= d OAM model can be applied independent of the underlying technology. In sec= tion 1, we have stated the following: “..In this document, we take the [8021Q] CFM model and extend it to a technology= independent framework and build the corresponding YANG model accordingly. = The YANG model presented in this document is the base model and supports IP= Ping and Traceroute. The generic OAM YANG model is designed such that it can be extended to cover various t= echnologies. Technology dependent nodes and RPC commands are defined in tec= hnology specific YANG models, which use and extend the base model defined h= ere. …. “

 

 

·         Section 3

o   “This allows users to traverse between= OAM of different technologies at ease through a uniform API set.” Us= ually relationships between OAM layers referred and viewed as OAM interwork= ing. There are several examples of IETF addressing aspects of OAM interworking. I think that interworking includes not only s= cenarios of nested OAM layers but peering layers and thus is broader than i= ntroduced in the document “nested OAM”.

[Answer]  Can you= please provide some example here, I am not quite clear.<= /p>

 

Guessing from the word= peering, if we are referring to cascaded sections of different technologie= s such as IP Cloud, MPLS cloud and another IP cloud. Then the model present= ed here is the answer. You can have an end end OAM session at a higher MD-Level. Each of the clouds below can = have separate OAM at a lower MD-Level. These can be utilized for fault isol= ation.

 

o   Figure 1 depicts OAM of both connection-orie= nted and connectionless networks. What you see common, generic in respectiv= e OAM of these networks?

 

[Answer] Please see th= e answers above.

 

·         Section 4

o   “In IP, the MA can be per IP Subnet &#= 8230;” As there’s no definition of MA in IP, is this the defini= tion or one of examples. Can MA in IP network be other than per IP Subnet?<= o:p>

[Answer] It is “= .. can be”, so it meant to be an example and other possibilities are = not ruled out and model does not assume any such limitation.

 

o   “Under each MA, there can be two or mo= re MEPs (Maintenance End Points)” Firstly, since you adopt MA-centric= terminology, MEP stands for Maintenance Association End Point. Secondly, i= n some OAM models Down and Up MEP being distinguished. Would your model consider that? As there’s no definition of MEP for = several networks you’ve listed, e.g. IP, how the YANG model will abst= ract something that is not defined? And thirdly, how and where MIPs are loc= ated in IP OAM?

 

[Answer] Yes model acc= ept both UP/Down.

 

One cannot say for IP = there is no MEP. MEP is a functional abstraction of a test point that gener= ate and respond to OAM messages. In that regard IP devices today have an im= plicit MEP at the CPU. The model allow to provide more semantics to the MEP and allow to create UP/Down per inter= face or other scope, hence providing more granularity in fault isolation/ve= rification and monitoring.

 

Thank you for your consideration of my notes and loo= king forward to the interesting discussion.

 

Thank you for spending= time to review and comment. We are updating the next version with comments= received so far and specifically during IETF in Canada. We are more than h= appy enhance where applicable or need more clarity.

 

Regards,

    =     Greg

--_000_FBEA3E19AA24F847BA3AE74E2FE193562EF118C6xmbrcdx08ciscoc_-- From nobody Thu Aug 28 08:24: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 28CF91A06FC for ; Thu, 28 Aug 2014 08:24:47 -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 fQkWGO4MCQmQ for ; Thu, 28 Aug 2014 08:24:44 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CFE51A030A for ; Thu, 28 Aug 2014 08:24:43 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id e89so898642qgf.32 for ; Thu, 28 Aug 2014 08:24:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=fKQRAS/F1+HbyE3riN1dslfx/UbBhYSE3atjYZdWgjU=; b=DggvGAXlo8LbjTbMskSxctmTBG1YLqmj4PcVvDeQ/etSapA9X1RVTwyepvH5eP2Eri eX2bVChgKzO7CqmVvZaLpnjrtgStceIGQJXe74gJ6HCUxWJG+ih8KOp4YySSjTXLquEs nbtoJ8aXGlsOHHT/vDQ0hl0zFiWRvWRmuyCHmiCb/2rdMHxG38iWYyaGGFA5XtgV+RXL NzgruB/EFhIVXtULacOdVFjjl7w9w2zno8K0zkOjA7aGMRjDrm5wcGTlUZgoXCsOuTwE UdJFXJMDE5jk63O5QX+OB29gSE+DoNZB2NsC9GQy47T7vgsxymdrSNvZyXEeXTYTMkNu ugqA== X-Gm-Message-State: ALoCoQlX4gQxAMyPvp0PKDEDOVS6eWHTTiIww/AQX2wfL2294yLYFz3jkCRx2XLok3InVrcFt2Dd MIME-Version: 1.0 X-Received: by 10.224.60.129 with SMTP id p1mr7246301qah.99.1409239483164; Thu, 28 Aug 2014 08:24:43 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Thu, 28 Aug 2014 08:24:43 -0700 (PDT) In-Reply-To: <20140828151427.GA62093@elstar.local> References: <20140828074829.GA61114@elstar.local> <20140828120340.GA61647@elstar.local> <20140828124505.GA61827@elstar.local> <20140828151427.GA62093@elstar.local> Date: Thu, 28 Aug 2014 08:24:43 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3d8d4cc5b620501b22202 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KFO1i1p3YtQl4MurGSMS-jz0GtY Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 28 Aug 2014 15:24:47 -0000 --001a11c3d8d4cc5b620501b22202 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 28, 2014 at 8:14 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Aug 28, 2014 at 06:25:24AM -0700, Andy Bierman wrote: > > On Thu, Aug 28, 2014 at 5:45 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Thu, Aug 28, 2014 at 05:13:51AM -0700, Andy Bierman wrote: > > > > On Thu, Aug 28, 2014 at 5:03 AM, Juergen Schoenwaelder < > > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > > > On Thu, Aug 28, 2014 at 04:39:05AM -0700, Andy Bierman wrote: > > > > > > Hi, > > > > > > > > > > > > I do not agree that anyxml needs to be encoded as a string, or > > > treated > > > > > > special somehow. NETCONF does not allow mixed mode XML. > > > > > > > > > > RFC 6020 section 7.10: > > > > > > > > > > The "anyxml" statement is used to represent an unknown chunk of > XML. > > > > > No restrictions are placed on the XML. > > > > > > > > > > So are there restrictions or not? > > > > > > > > > > > > > words on a page vs. running code. > > > > No customer has complained that the anyxml we support is too > restrictive. > > > > > > > > > > So are you saying the discussion we had in Toronto about anyxml and > > > anydata is pointless since in reality anyxml really is anydata? Can > > > other implementations confirm this? If this is generally true, we > > > should perhaps revisit the discussion and clarify in RFC 6020 bis > > > that anyxml really means a rather restricted set of XML. > > > > > > Question: How do you deal with namespaces in the XML when you render > > > it in JSON? The JSON I-D requires that you know the module name while > > > all you have is a URI... > > > > > > > > I have not implemented JSON attributes yet. In XML, the code needs to > > preserve attributes (including xmlns). > > > > My question was not about attributes... > OK -- I would implement your proposed solution (use the XML namespace as the module name). That is not supported yet. > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a11c3d8d4cc5b620501b22202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Aug 28, 2014 at 8:14 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Aug 28, 2014 at 06:25:24AM -0700, An= dy Bierman wrote:
> On Thu, Aug 28, 2014 at 5:45 AM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > On Thu, Aug 28, 2014 at 05:13:51AM -0700, Andy Bierman wrote:
> > > On Thu, Aug 28, 2014 at 5:03 AM, Juergen Schoenwaelder <<= br> > > > j.sc= hoenwaelder@jacobs-university.de> wrote:
> > >
> > > > On Thu, Aug 28, 2014 at 04:39:05AM -0700, Andy Bierman = wrote:
> > > > > Hi,
> > > > >
> > > > > I do not agree that anyxml needs to be encoded as = a string, or
> > treated
> > > > > special somehow.=A0 NETCONF does not allow mixed m= ode XML.
> > > >
> > > > RFC 6020 section 7.10:
> > > >
> > > >=A0 =A0 The "anyxml" statement is used to repr= esent an unknown chunk of XML.
> > > >=A0 =A0 No restrictions are placed on the XML.
> > > >
> > > > So are there restrictions or not?
> > > >
> > >
> > > words on a page vs. running code.
> > > No customer has complained that the anyxml we support is too= restrictive.
> > >
> >
> > So are you saying the discussion we had in Toronto about anyxml a= nd
> > anydata is pointless since in reality anyxml really is anydata? C= an
> > other implementations confirm this? If this is generally true, we=
> > should perhaps revisit the discussion and clarify in RFC 6020 bis=
> > that anyxml really means a rather restricted set of XML.
> >
> > Question: How do you deal with namespaces in the XML when you ren= der
> > it in JSON? The JSON I-D requires that you know the module name w= hile
> > all you have is a URI...
> >
> >
> I have not implemented JSON attributes yet.=A0 In XML, the code needs = to
> preserve attributes (including xmlns).
>

My question was not about attributes...

OK -- I would implement your proposed solution (use the XML namespace as t= he module name).
=A0That is not supported yet.


/js

Andy
=A0

--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

--001a11c3d8d4cc5b620501b22202-- From nobody Thu Aug 28 08:32: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 7B0FB1A06F9 for ; Thu, 28 Aug 2014 08:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeHoDr2hWLC7 for ; Thu, 28 Aug 2014 08:32:33 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 170881A06FC for ; Thu, 28 Aug 2014 08:32:33 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id o8so945615qcw.17 for ; Thu, 28 Aug 2014 08:32: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:content-type; bh=OC56+r/D/dyW81CsT9nRfJKC3dakZvzWtlMHGqqA2zM=; b=L29IrxKNXwAU+8pxVKC5ZGxkkZWfCRaBebna2LVRQ2nKbYbr5qwjcyF0QZlTREJ2PW hfUruUMCQiJsKcM6a+xQVClWEJUekVrZ0/OoSMKQaCF1PWzkXQwOooaRMqwVo/gejerG 9NBayEONAYBkWNEij0qSQn7aakNqAOKwqS4bYBOZ7CyBBNjf/ToxY618erZQGjxoaIpo TpqfdZ0DDvaeRpRpZwfUAzVgan+CKA8qWhTZGIHg3cUHyHYy/qdUBQ0dUez9PqT7Rxp+ Y8bczLtn/zr7sKq29mQ4lTj4D/811F9RZBQfmMLZlSpeIu3BqBFvNVx1Rn55YQLm3nlh h34A== X-Gm-Message-State: ALoCoQmt6wqy8ax/0BRVIvSotkFseZ9nigpt42Hu+UHWsx8iHD7SWKv+Wfv9n3eUBPoPVTPCyb6T MIME-Version: 1.0 X-Received: by 10.224.20.9 with SMTP id d9mr7547096qab.7.1409239952181; Thu, 28 Aug 2014 08:32:32 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Thu, 28 Aug 2014 08:32:32 -0700 (PDT) In-Reply-To: <20140828152246.GB62093@elstar.local> References: <20140828074829.GA61114@elstar.local> <20140828.124839.716000072014037611.mbj@tail-f.com> <20140828120536.GB61647@elstar.local> <20140828152246.GB62093@elstar.local> Date: Thu, 28 Aug 2014 08:32:32 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Ladislav Lhotka , =?ISO-8859-1?Q?Martin_Bj=F6rklund?= , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1c560c0ee120501b23e2d Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/PNqqhFEsbdV9UEq3BG_hOUdN6Zk Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 28 Aug 2014 15:32:35 -0000 --001a11c1c560c0ee120501b23e2d Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 28, 2014 at 8:22 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Aug 28, 2014 at 02:53:19PM +0200, Ladislav Lhotka wrote: > > > > > > > > I want robust and interoperable encoding. I do not care about > > > cleverness that only works for some applications. > > > > One size fits all isn't the same as robust and interoperable. Every > anyxml is defined in a YANG module so why couldn't each have a specific > purpose, format, semantics and handling? Why is this non-interoperable or > non-robust? IMO moving around pieces of invalid XML is worse. > > > > I am not sure "every anyxml is defined in a YANG module" is true. I > heard that Kent uses configlets that are anyxml and the configlets may > actually be defined in XSD. > > Quoting draft-ietf-netmod-yang-json-00.txt: > > An XML element that is modeled as a YANG anyxml data node is > translated to a name/object pair. The content of such an element is > not modelled by YANG, and there may not be a straightforward mapping > to JSON text (e.g., if it is a mixed XML content). Therefore, > translation of anyxml contents is necessarily application-specific > and outside the scope of this document. > > I do not think "translation of anyxml contents is necessarily > application-specific" is interoperable. (I note that the second quoted > sentence contradicts your statement that "every anyxml is defined in a > YANG module"). > > And the example given in draft-ietf-netmod-yang-json-00.txt is > actually supporting my concern. Why should something translate > > >

> This is very cool. >

> > > But this would not be allowed in a NETCONF message. Why would we add this complexity to RESTCONF (the lightweight version)? How important is it for RESTCONF to manage arbitrary chunks of HTML? Nobody has asked for the NETCONF XML restrictions to be removed. > into an arbitrary markup notation > > { > "bar": { > "p": "This is *very* cool." > } > } > > if bar is of type anyxml? I would strongly prefer to get the > unmodified xhtml content for bar and not some arbitrary rendering of > it. > > Agreed -- if mixed mode XML and entities were allowed, then encoding the XML as a string would be best. > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c1c560c0ee120501b23e2d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Aug 28, 2014 at 8:22 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Aug 28, 2014 at 02:53:19PM +0200, La= dislav Lhotka wrote:
>
> >
> > I want robust and interoperable encoding. I do not care about
> > cleverness that only works for some applications.
>
> One size fits all isn’t the same as robust and interoperable. Ev= ery anyxml is defined in a YANG module so why couldn’t each have a sp= ecific purpose, format, semantics and handling? Why is this non-interoperab= le or non-robust? IMO moving around pieces of invalid XML is worse.
>

I am not sure "every anyxml is defined in a YANG module" is true.= I
heard that Kent uses configlets that are anyxml and the configlets may
actually be defined in XSD.

Quoting draft-ietf-netmod-yang-json-00.txt:

   An XML element that is modeled as a YANG anyxml data node is    translated to a name/object pair.  The content of such an= element is
   not modelled by YANG, and there may not be a straightforward m= apping
   to JSON text (e.g., if it is a mixed XML content).  There= fore,
   translation of anyxml contents is necessarily application-spec= ific
   and outside the scope of this document.

I do not think "translation of anyxml contents is necessarily
application-specific" is interoperable. (I note that the second quoted=
sentence contradicts your statement that "every anyxml is defined in a=
YANG module").

And the example given in draft-ietf-netmod-yang-json-00.txt is
actually supporting my concern. Why should something translate

       <bar>
         <p xmlns=3D"http://www.w3.org/1999/xhtml"= ;>
           This is <em>very</em> = cool.
         </p>
       </bar>


But this would not be allowed in a NET= CONF message.
Why would we add this complexity to RESTCONF (the l= ightweight version)?
How important is it for RESTCONF to manage a= rbitrary chunks of HTML?
Nobody has asked for the NETCONF XML restrictions to be removed.
=

 
into an arbitrary markup notation

       {
         "bar": {
           "p": "This is *very= * cool."
         }
       }

if bar is of type anyxml? I would strongly prefer to get the
unmodified xhtml content for bar and not some arbitrary rendering of
it.


Agreed -- if mixed mode XML and entities were allowe= d, then encoding
the XML as a string would be best.
 
/js


Andy
 
--
Juergen Schoenwaelder           Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 287= 59 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacob= s-university.de/>

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

--001a11c1c560c0ee120501b23e2d-- From nobody Thu Aug 28 08:59: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 5DB891A0719 for ; Thu, 28 Aug 2014 08:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.671 X-Spam-Level: X-Spam-Status: No, score=-0.671 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-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 4IngrJ0ZeAbC for ; Thu, 28 Aug 2014 08:58:46 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 76E1E1A8770 for ; Thu, 28 Aug 2014 08:58:44 -0700 (PDT) Received: from ncfs.snmp.com (ncfs.snmp.com [192.147.142.24]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA12039; Thu, 28 Aug 2014 11:58:40 -0400 (EDT) Received: from ncfs.snmp.com (localhost.snmp.com [127.0.0.1]) by ncfs.snmp.com (8.14.5/8.14.5) with ESMTP id s7SFwasJ073506; Thu, 28 Aug 2014 11:58:39 -0400 (EDT) (envelope-from reid@snmp.com) Message-Id: <201408281558.s7SFwasJ073506@ncfs.snmp.com> To: Andy Bierman From: David Reid In-reply-to: Your message of Thu, 28 Aug 2014 08:05:58 -0700. Date: Thu, 28 Aug 2014 11:58:36 -0400 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mN035iSaaBfnlpV6ccgP2NVXF5w Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG unions in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 15:58:53 -0000 How do you handle Martin's example where you use json to set "foo": "4668" and then read foo back. Do you return "foo": "4668" or "foo": 4668? Or to ask the same question from a different angle: Do you store the value of foo internally in C as an int or char *? -David Reid > Hi, > > I realize that the standard text is important and needs to be correct, but > when writing > the code for this, I followed the Postel Principle. The YANG schema wins > any conflict. > The tools will try to figure out how to get the content to fit the YANG > schema, even if > the peer did not follow every detail in Lada's draft. > > Re, these examples: the 42 vs "42" would be treated as a duplicate-entry > error. > The "1.000" is a perfectly valid key by the (strange) YANG typedef rules, so > it would be accepted. > > > Andy From nobody Thu Aug 28 09:32: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 A36C31A8754 for ; Thu, 28 Aug 2014 09:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.119 X-Spam-Level: X-Spam-Status: No, score=-0.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, RP_MATCHES_RCVD=-0.668] 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 eJxaevykSuCI for ; Thu, 28 Aug 2014 09:32:37 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C116D1A87AF for ; Thu, 28 Aug 2014 09:32:29 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 3271B140A83; Thu, 28 Aug 2014 18:32:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409243548; bh=0FZ4nGZzC7qmZp64PBkddHNSAWwDnP6H3I92wDi/kro=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=bDDScrN5ooY4rawc0xZeE0P1oTmT8hg175ER8myumen6y+SR+mGhR1IJurplODd98 vAVfNNudgRd1E7cEbEqCCvVwum+anVRa1B3mIqF9q54tQpAa9ulLa4Se8zDmAjwnUs 4/UeDmlRrOI+G5BfFNwDDpaxwwiRK4Y16iwz8Ox8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 28 Aug 2014 18:32:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <93EC9A42-3434-4272-9C52-7D97BB771688@nic.cz> References: <20140827.221930.227693858.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KNnwwEbQ1WkNGhBNySS7Pg2BwcE Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG unions in 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, 28 Aug 2014 16:32:38 -0000 On 28 Aug 2014, at 17:05, Andy Bierman wrote: > Hi, >=20 > I realize that the standard text is important and needs to be correct, = but when writing > the code for this, I followed the Postel Principle. The YANG schema = wins any conflict. > The tools will try to figure out how to get the content to fit the = YANG schema, even if > the peer did not follow every detail in Lada's draft. >=20 > Re, these examples: the 42 vs "42" would be treated as a = duplicate-entry error. > The "1.000" is a perfectly valid key by the (strange) YANG typedef = rules, so > it would be accepted. Hmm, pyangs flags an error on this module: module jtest { namespace "http://example.com/jtest"; prefix jt; leaf foo { type decimal64 { fraction-digits 1; } default "1.00"; } } $ pyang jtest.yang=20 jtest.yang:9: error: the value "1.00" does not match its base type - too = many fraction digits But maybe it shouldn=92t =85 Lada >=20 >=20 > Andy >=20 >=20 >=20 > On Thu, Aug 28, 2014 at 7:47 AM, Ladislav Lhotka = wrote: > Martin Bjorklund writes: >=20 > > Hi, > > > > In the current json draft, a value of type 'union' is encoded in the > > same way as the "active" member type. For example, with: >=20 > First of all, I think it is a general problem of the union type that = it is impossible > (or at least not straightforward) to indicate which of the member = types > a given instance is supposed to have. For a leaf with the type > inet:host, it can happen that an IPv4 address with a typo will be = accepted > and interpreted as domain-name. This might be another use case for a > metadata annotation. >=20 > > > > leaf foo { > > type union { > > type int32; > > type string; > > } > > } > > > > the leaf might be encoded as: > > > > "foo": 42 > > > > Now, suppose we use json to set this leaf like this: > > > > "foo": "4668" > > > > If we the read the value back, what do we get? Probably "4668". >=20 > It depends, I would say it is more a question for the protocol what = the server does > with the values it receives. yang-json is about the mapping of XML to > JSON and back. What it tells is that >=20 > - 4668 maps to "foo": 4668, and > - both "foo": 4668 and "foo": "4668" map to 4668. >=20 > Hmm, but then the JSON -> XML mapping is not 1-1 as the draft claims. = I > have to think about it. >=20 > > > > But if we instead set the value over xml: >=20 > > > > 4668 > > > > we will then get back: > > > > "foo": 4668 > > > > over json. >=20 > Yes, that's for sure. >=20 > > > > What happens if leaf foo is the key in a list - can we create two = list > > instances with key: > > > > "foo": 4668 > > > > and: > > > > "foo": "4668" >=20 > I posted exactly the same question to the yang-doctors mailing list = after > the tutorial in Toronto. >=20 > It can be even more fun: >=20 > key foo; > leaf foo { > type union { > type decimal64 { > fraction-digits 2; > } > type string; > } > } >=20 > Assume the client wants to edit list entry with key 1.00 but sends a = key > 1.000, and a new list entry with the string key "1.000" is created > instead. This is really quite brittle. >=20 >=20 > > > > at the same time? > > > > > > It seems the simplest solution would be to say that unions are = encoded > > as strings in json. >=20 > This would be another step in making JSON more XML-like and gradually > losing the main point of using JSON - simplicity. For unions that have > no string members it really makes no sense. >=20 > I would prefer if RESTCONF specifies the behaviour of the receiving = side > in such cases. >=20 > Lada >=20 > > > > > > /martin > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=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 Thu Aug 28 09:39: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 CB3AB1A0AF6 for ; Thu, 28 Aug 2014 09:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ne_Dy-PqNeqf for ; Thu, 28 Aug 2014 09:39:52 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2442F1A8756 for ; Thu, 28 Aug 2014 09:39:51 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id f12so961530qad.32 for ; Thu, 28 Aug 2014 09:39:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4DrcF8BWQr6I16N/9urHPjn1mz8kyfUWWbQJTsKy5kg=; b=LV19RQAiofX7NvxyteaYKlOqntZnjXVEyffB7YrI1pFRiHYBVPP87BUTBb5iMqLAkQ meN8q8lIggC4ZyeKfh5Oui2Vd1jtX2/1JFoqSXSHD79n+opuu9+kS2uEf4ONp19EHGqy I0YCW4n3rRvcUwDhDnPmGliAKFGIPdeK1dcGO62bHAFTvn6Cn+ZpKDuDj3bdsaHq/l+O qUu5Xp9VsbGPi2wlsOrsK+9tnqS6wFsyKu/gx3hn5RWaPy9tZpLyoITzgvvWEMhJ23zN gpWuFs76umyPs6EaK/NZCmKDwolfeMIDUlDnPmAQImgWF7lPHPE5xd8CeOWIs47tir09 toOw== X-Gm-Message-State: ALoCoQl7EyRAf7/ZOgUW1LXuS2dkGHIZypPq24y0V7fTDOdpACoCgEg1S4xB+66+dejeSfQj8Nzd MIME-Version: 1.0 X-Received: by 10.224.60.129 with SMTP id p1mr7957171qah.99.1409243990292; Thu, 28 Aug 2014 09:39:50 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Thu, 28 Aug 2014 09:39:50 -0700 (PDT) In-Reply-To: <201408281558.s7SFwasJ073506@ncfs.snmp.com> References: <201408281558.s7SFwasJ073506@ncfs.snmp.com> Date: Thu, 28 Aug 2014 09:39:50 -0700 Message-ID: From: Andy Bierman To: David Reid Content-Type: multipart/alternative; boundary=001a11c3d8d4719e1a0501b32f36 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/eL6HkOnYBDA8pKCPT4Xt84Mm5pE Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG unions in 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, 28 Aug 2014 16:39:53 -0000 --001a11c3d8d4719e1a0501b32f36 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 28, 2014 at 8:58 AM, David Reid wrote: > How do you handle Martin's example where you use json to set "foo": "4668" > and then read foo back. Do you return "foo": "4668" or "foo": 4668? > > Or to ask the same question from a different angle: Do you store the > value of foo internally in C as an int or char *? > > It is treated as a string because it is part of 'anyxml y'; Complex nodes are treated as containers. Simple nodes are treated as string leafs. Arrays are not used if the data is streamed (and the next sibling to be sent is unknown). (I know this is wrong). The IETF can write all the complex standards it wants, but developers are not going to bother spending massive $$$ to design for the pathological corner cases that serve no use-cases. Customers only complain about broken features they actually use ;-) We could add "docroot" to YANG 1.1 and deprecate anyxml if we really are that concerned about interoperability. Or we can say that you get limited interoperability when you abandon all schema and use anyxml. I can't think of anything more antithetical to the practice of data modeling than "anyxml", so maybe Martin is right. (get rid of it). > -David Reid > > Andy > > Hi, > > > > I realize that the standard text is important and needs to be correct, > but > > when writing > > the code for this, I followed the Postel Principle. The YANG schema wins > > any conflict. > > The tools will try to figure out how to get the content to fit the YANG > > schema, even if > > the peer did not follow every detail in Lada's draft. > > > > Re, these examples: the 42 vs "42" would be treated as a duplicate-entry > > error. > > The "1.000" is a perfectly valid key by the (strange) YANG typedef > rules, so > > it would be accepted. > > > > > > Andy > --001a11c3d8d4719e1a0501b32f36 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Aug 28, 2014 at 8:58 AM, David Reid <<= a href=3D"mailto:reid@snmp.com" target=3D"_blank">reid@snmp.com> wrote:
How do you handle Martin's example where= you use json to set "foo": "4668"
and then read foo back. Do you return "foo": "4668" or = "foo": 4668?

Or to ask the same question from a different angle: Do you store the
value of foo internally in C as an int or char *?


It is treated as a string because it i= s part of 'anyxml y';
Complex nodes are treated as contai= ners. Simple nodes are
treated as string leafs. =A0Arrays are not= used if the data is streamed
(and the next sibling to be sent is unknown). (I know this is wrong).<= /div>

The IETF can write all the complex standards it wa= nts, but developers are
not going to bother spending massive $$$ = to design for the pathological corner cases
that serve no use-cases. =A0Customers only complain about broken featu= res they actually use ;-)

We could add "docro= ot" to YANG 1.1 and deprecate anyxml if we really are that
concerned about interoperability. Or we can say that you get limited intero= perability
when you abandon all schema and use anyxml. =A0I can&#= 39;t think of anything more antithetical
to the practice of data = modeling than "anyxml", so maybe Martin is right. (get rid of it)= .


=A0
-David Reid


Andy=A0


<= /div>

> Hi,
>
> I realize that the standard text is important and needs to be correct,= but
> when writing
> the code for this, I followed the Postel Principle. The YANG schema wi= ns
> any conflict.
> The tools will try to figure out how to get the content to fit the YAN= G
> schema, even if
> the peer did not follow every detail in Lada's draft.
>
> Re, these examples: the 42 vs "42" would be treated as a dup= licate-entry
> error.
> The "1.000" is a perfectly valid key by the (strange) YANG t= ypedef rules, so
> it would be accepted.
>
>
> Andy

--001a11c3d8d4719e1a0501b32f36-- From nobody Thu Aug 28 10:00: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 BE92E1A87D1 for ; Thu, 28 Aug 2014 10:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 VEe8qb1fZT12 for ; Thu, 28 Aug 2014 10:00:38 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB9C1A8834 for ; Thu, 28 Aug 2014 09:59:30 -0700 (PDT) Received: from localhost (s193-12-221-208.cust.tele2.se [193.12.221.208]) by mail.tail-f.com (Postfix) with ESMTPSA id 980491280A02; Thu, 28 Aug 2014 18:56:51 +0200 (CEST) Date: Thu, 28 Aug 2014 18:59:28 +0200 (CEST) Message-Id: <20140828.185928.413443011.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140828152246.GB62093@elstar.local> References: <20140828120536.GB61647@elstar.local> <20140828152246.GB62093@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/tx7a-Yeet65fgg9eFD7fpY4Z14M Cc: netmod@ietf.org Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 28 Aug 2014 17:00:41 -0000 SnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku ZGU+IHdyb3RlOg0KPiBPbiBUaHUsIEF1ZyAyOCwgMjAxNCBhdCAwMjo1MzoxOVBNICswMjAwLCBM YWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+ID4gDQo+ID4gPiANCj4gPiA+IEkgd2FudCByb2J1c3Qg YW5kIGludGVyb3BlcmFibGUgZW5jb2RpbmcuIEkgZG8gbm90IGNhcmUgYWJvdXQNCj4gPiA+IGNs ZXZlcm5lc3MgdGhhdCBvbmx5IHdvcmtzIGZvciBzb21lIGFwcGxpY2F0aW9ucy4NCj4gPiANCj4g PiBPbmUgc2l6ZSBmaXRzIGFsbCBpc27igJl0IHRoZSBzYW1lIGFzIHJvYnVzdCBhbmQgaW50ZXJv cGVyYWJsZS4gRXZlcnkgYW55eG1sIGlzDQo+ID4gZGVmaW5lZCBpbiBhIFlBTkcgbW9kdWxlIHNv IHdoeSBjb3VsZG7igJl0IGVhY2ggaGF2ZSBhIHNwZWNpZmljIHB1cnBvc2UsDQo+ID4gZm9ybWF0 LCBzZW1hbnRpY3MgYW5kIGhhbmRsaW5nPyBXaHkgaXMgdGhpcyBub24taW50ZXJvcGVyYWJsZSBv ciBub24tcm9idXN0Pw0KPiA+IElNTyBtb3ZpbmcgYXJvdW5kIHBpZWNlcyBvZiBpbnZhbGlkIFhN TCBpcyB3b3JzZS4NCj4gPiANCj4gDQo+IEkgYW0gbm90IHN1cmUgImV2ZXJ5IGFueXhtbCBpcyBk ZWZpbmVkIGluIGEgWUFORyBtb2R1bGUiIGlzIHRydWUuIEkNCj4gaGVhcmQgdGhhdCBLZW50IHVz ZXMgY29uZmlnbGV0cyB0aGF0IGFyZSBhbnl4bWwgYW5kIHRoZSBjb25maWdsZXRzIG1heQ0KPiBh Y3R1YWxseSBiZSBkZWZpbmVkIGluIFhTRC4NCg0KVGhlIG1haW4gcmVhc29uIGZvciBhbnl4bWwg d2FzIHRvIGJlIGFibGUgdG8gZGVmaW5lIHRoZSBORVRDT05GDQpvcGVyYXRpb25zIGluIFlBTkcs IGFuZCBORVRDT05GIGNhbiAodGhlb3JldGljYWxseSkgYmUgdXNlZCB3aXRoIGFueQ0KeG1sLg0K DQpUaGUgcXVlc3Rpb24gaXMgaWYgdGhpcyBzdGlsbCBpcyBpbXBvcnRhbnQuICBDdXJyZW50bHks IHRoZSBvbmx5DQppbnRlcm9wZXJhYmxlIHdheSBvZiB1c2luZyBORVRDT05GIGlzIHdpdGggWUFO Ry4NCg0KSSB0aGluayB0aGUgc2FtZSBhcHBsaWVzIHRvIGFueW9uZSB0aGF0IGltcGxlbWVudHMg dGhlIHplcm90b3VjaCBzdHVmZiwNCmluY2x1ZGluZyB0aGUgWUFORyBtb2R1bGVzIGl0IGRlZmlu ZXM7IHRoZSBkYXRhIGZvciB0aGUgaW5pdGlhbCBjb25maWcNCmluIHRoZSBjb25maWdsZXRzIHdp bGwgYmUgbW9kZWxsZWQgd2l0aCBZQU5HLg0KDQpUaHVzLCBpZiB3ZSBhZGQgYW55ZGF0YSBpbiBZ QU5HIDEuMSwgYW5kIGV4cGxhaW4gdGhhdCBhbnl4bWwgcmVhbGx5DQpzaG91bGRuJ3QgYmUgdXNl ZCwgSSB0aGluayBMYWRhJ3MgY3VycmVudCBzb2x1dGlvbiBmb3IgYW55eG1sIGlzIGdvb2QNCmVu b3VnaC4NCg0KDQovbWFydGluDQo= From nobody Thu Aug 28 10:11: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 BB2C41A87AC for ; Thu, 28 Aug 2014 10:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_54=0.6, RP_MATCHES_RCVD=-0.668, 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 12SjoCB39AvD for ; Thu, 28 Aug 2014 10:10:58 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 06B061A883B for ; Thu, 28 Aug 2014 10:10:53 -0700 (PDT) Received: from localhost (s193-12-221-208.cust.tele2.se [193.12.221.208]) by mail.tail-f.com (Postfix) with ESMTPSA id 5E5B91280A02; Thu, 28 Aug 2014 19:08:15 +0200 (CEST) Date: Thu, 28 Aug 2014 19:10:52 +0200 (CEST) Message-Id: <20140828.191052.124500232.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <93EC9A42-3434-4272-9C52-7D97BB771688@nic.cz> References: <93EC9A42-3434-4272-9C52-7D97BB771688@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/YAtdRtXtTIXx1-IX6FllBo7oHKM Cc: netmod@ietf.org Subject: Re: [netmod] YANG unions in 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, 28 Aug 2014 17:11:00 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+IE9uIDI4IEF1ZyAy MDE0LCBhdCAxNzowNSwgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0K PiANCj4gPiBIaSwNCj4gPiANCj4gPiBJIHJlYWxpemUgdGhhdCB0aGUgc3RhbmRhcmQgdGV4dCBp cyBpbXBvcnRhbnQgYW5kIG5lZWRzIHRvIGJlIGNvcnJlY3QsIGJ1dA0KPiA+IHdoZW4gd3JpdGlu Zw0KPiA+IHRoZSBjb2RlIGZvciB0aGlzLCBJIGZvbGxvd2VkIHRoZSBQb3N0ZWwgUHJpbmNpcGxl LiBUaGUgWUFORyBzY2hlbWEgd2lucyBhbnkNCj4gPiBjb25mbGljdC4NCj4gPiBUaGUgdG9vbHMg d2lsbCB0cnkgdG8gZmlndXJlIG91dCBob3cgdG8gZ2V0IHRoZSBjb250ZW50IHRvIGZpdCB0aGUg WUFORw0KPiA+IHNjaGVtYSwgZXZlbiBpZg0KPiA+IHRoZSBwZWVyIGRpZCBub3QgZm9sbG93IGV2 ZXJ5IGRldGFpbCBpbiBMYWRhJ3MgZHJhZnQuDQo+ID4gDQo+ID4gUmUsIHRoZXNlIGV4YW1wbGVz OiB0aGUgNDIgdnMgIjQyIiB3b3VsZCBiZSB0cmVhdGVkIGFzIGEgZHVwbGljYXRlLWVudHJ5DQo+ ID4gZXJyb3IuDQo+ID4gVGhlICIxLjAwMCIgaXMgYSBwZXJmZWN0bHkgdmFsaWQga2V5IGJ5IHRo ZSAoc3RyYW5nZSkgWUFORyB0eXBlZGVmIHJ1bGVzLCBzbw0KPiA+IGl0IHdvdWxkIGJlIGFjY2Vw dGVkLg0KDQpBZ3JlZWQuDQoNCg0KPiBIbW0sIHB5YW5ncyBmbGFncyBhbiBlcnJvciBvbiB0aGlz IG1vZHVsZToNCj4gDQo+IG1vZHVsZSBqdGVzdCB7DQo+ICAgbmFtZXNwYWNlICJodHRwOi8vZXhh bXBsZS5jb20vanRlc3QiOw0KPiAgIHByZWZpeCBqdDsNCj4gDQo+ICAgbGVhZiBmb28gew0KPiAg ICAgdHlwZSBkZWNpbWFsNjQgew0KPiAgICAgICBmcmFjdGlvbi1kaWdpdHMgMTsNCj4gICAgIH0N Cj4gICAgIGRlZmF1bHQgIjEuMDAiOw0KPiAgIH0NCj4gfQ0KPiANCj4gJCBweWFuZyBqdGVzdC55 YW5nIA0KPiBqdGVzdC55YW5nOjk6IGVycm9yOiB0aGUgdmFsdWUgIjEuMDAiIGRvZXMgbm90IG1h dGNoIGl0cyBiYXNlIHR5cGUgLSB0b28gbWFueQ0KPiBmcmFjdGlvbiBkaWdpdHMNCj4gDQo+IEJ1 dCBtYXliZSBpdCBzaG91bGRu4oCZdCDigKYNCg0KUmVtZW1iZXIgdGhhdCB0aGUgb3JpZ2luYWwg dHlwZSB3YXMgYSB1bmlvbiwgc28gaWYgeW91IGNoYW5nZSB5b3VyDQpsZWFmIHRvOg0KDQogIGxl YWYgZm9vIHsNCiAgICB0eXBlIHVuaW9uIHsNCiAgICAgIHR5cGUgZGVjaW1hbDY0IHsNCiAgICAg ICAgZnJhY3Rpb24tZGlnaXRzIDE7DQogICAgICB9DQogICAgICB0eXBlIHN0cmluZzsNCiAgICB9 DQogICAgZGVmYXVsdCAiMS4wMCI7DQogIH0NCg0KcHlhbmcgZG9lc24ndCBjb21wbGFpbiwganVz dCBhcyBBbmR5IHNheS4NCg0KDQovbWFydGluDQo= From nobody Thu Aug 28 23:42: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 2BA8C1A064F; Thu, 28 Aug 2014 23:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.818 X-Spam-Level: X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POkQ0DraPKn3; Thu, 28 Aug 2014 23:42:13 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7925D1A0644; Thu, 28 Aug 2014 23:42:12 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DA443115A; Fri, 29 Aug 2014 08:42:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Qvxd32h9q1UY; Fri, 29 Aug 2014 08:41:59 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 29 Aug 2014 08:42:10 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 574E720035; Fri, 29 Aug 2014 08:42:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qjb92irVAy47; Fri, 29 Aug 2014 08:42:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 80BB520033; Fri, 29 Aug 2014 08:42:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3DD212E52F1F; Fri, 29 Aug 2014 08:42:08 +0200 (CEST) Date: Fri, 29 Aug 2014 08:42:07 +0200 From: Juergen Schoenwaelder To: i2rs@ietf.org Message-ID: <20140829064207.GA63316@elstar.local> Mail-Followup-To: i2rs@ietf.org, netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/CI3LCkymlVP4Z1cNC8Xaht46p0M Cc: netmod@ietf.org Subject: [netmod] netmod interim and i2rs requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 06:42:16 -0000 Hi, the NETMOD WG is holding an interim meeting on Sep. 17/18 [1] and one of the agenda items is to work on any requirements I2RS might have for YANG 1.1. For this, we need a clear definition of what the I2RS requirements are for YANG 1.1, ideally posted as an I-D a few days before the interim meeting so that people can come prepared. This means there are ~15 days left to produce such a requirements writeup. /js [1] https://www.ietf.org/meeting/interim/netmod-2014-09-17.txt -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Aug 29 01:11: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 30B431A06A0 for ; Fri, 29 Aug 2014 01:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_48=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668] 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 Jtc_dkYHUYEu for ; Fri, 29 Aug 2014 01:11:12 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FFF11A069C for ; Fri, 29 Aug 2014 01:11:11 -0700 (PDT) Received: from krejci.liberouter.org (pckrejci.fit.vutbr.cz [147.229.12.223]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 91CA2ED0939; Fri, 29 Aug 2014 10:11:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1409299868; bh=Z/n2r1jULMlVzLPFJ4a6yOsJrChl+QjKjbuu7OLNDWA=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=IdYunZnscAiU3kh2EBRTXLj/cg7m9ZTG8WX42gYe9pqLsCRcaGkpx00OMX/oTS/9J jjVe6inaAXeaHW17OiT5be/zTa3hGGviRLUabHnEBPGD23SpijaLmIkpeND67lWwwG MNIJ13EY+nr2sgj2B/Pbo9s0zhjOIzG+NdfQhygU= Message-ID: <540034B1.9060905@cesnet.cz> Date: Fri, 29 Aug 2014 10:07:13 +0200 From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Andy Bierman , "netmod@ietf.org" References: <20140828074829.GA61114@elstar.local> <20140828120340.GA61647@elstar.local> <20140828124505.GA61827@elstar.local> In-Reply-To: <20140828124505.GA61827@elstar.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xIM3ahEiskWHYglANWT2JUAndas Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 29 Aug 2014 08:11:14 -0000 Hi, Dne 28.8.2014 14:45, Juergen Schoenwaelder napsal(a): > On Thu, Aug 28, 2014 at 05:13:51AM -0700, Andy Bierman wrote: >> On Thu, Aug 28, 2014 at 5:03 AM, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: >> >>> On Thu, Aug 28, 2014 at 04:39:05AM -0700, Andy Bierman wrote: >>>> Hi, >>>> >>>> I do not agree that anyxml needs to be encoded as a string, or treated >>>> special somehow. NETCONF does not allow mixed mode XML. >>> RFC 6020 section 7.10: >>> >>> The "anyxml" statement is used to represent an unknown chunk of XML. >>> No restrictions are placed on the XML. >>> >>> So are there restrictions or not? >>> >> words on a page vs. running code. >> No customer has complained that the anyxml we support is too restrictive. >> > So are you saying the discussion we had in Toronto about anyxml and > anydata is pointless since in reality anyxml really is anydata? Can > other implementations confirm this? If this is generally true, we > should perhaps revisit the discussion and clarify in RFC 6020 bis > that anyxml really means a rather restricted set of XML. libnetconf put no restrictions on anyxml content. On the other hand, we don't use anyxml and I don't have any feedback regarding anyxml from the mailing list, so it wasn'theavily tested. Radek > Question: How do you deal with namespaces in the XML when you render > it in JSON? The JSON I-D requires that you know the module name while > all you have is a URI... > > /js > From nobody Fri Aug 29 01:31: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 D58871A035C for ; Fri, 29 Aug 2014 01:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 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.668] 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 cRGFBEPKQjoe for ; Fri, 29 Aug 2014 01:31:40 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1331A0306 for ; Fri, 29 Aug 2014 01:31:39 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id C25AD14085D; Fri, 29 Aug 2014 10:31:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409301098; bh=4qr3itip6PnfNBp8GF7JkSa+i/KPENNJwWiRCjtvTbE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=vGEbX/UbXduJuk9ezY2lpafP7vATKO01j/ZACTktPiTzcXpWXKYe7JQ2qpw2uaBe0 VM8YPONosnAZc+zl7EbdYCS3taC3NWMawzuy65+emkUhN/WFZW9s/c4bKgyvskHuuU gPummoHteG11C2Jc8j3GcjEVPTDvs47Ahs6VuFuw= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140828152246.GB62093@elstar.local> Date: Fri, 29 Aug 2014 10:31:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0ACDBCC7-D77B-47B4-8005-F7702DE603FB@nic.cz> References: <20140828074829.GA61114@elstar.local> <20140828.124839.716000072014037611.mbj@tail-f.com> <20140828120536.GB61647@elstar.local> <20140828152246.GB62093@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/EH9XivgWJAEgKG9jo9wuBSsHlZ0 Cc: netmod@ietf.org Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 29 Aug 2014 08:31:42 -0000 On 28 Aug 2014, at 17:22, Juergen Schoenwaelder = wrote: > On Thu, Aug 28, 2014 at 02:53:19PM +0200, Ladislav Lhotka wrote: >>=20 >>>=20 >>> I want robust and interoperable encoding. I do not care about >>> cleverness that only works for some applications. >>=20 >> One size fits all isn=92t the same as robust and interoperable. Every = anyxml is defined in a YANG module so why couldn=92t each have a = specific purpose, format, semantics and handling? Why is this = non-interoperable or non-robust? IMO moving around pieces of invalid XML = is worse. >>=20 >=20 > I am not sure "every anyxml is defined in a YANG module" is true. I > heard that Kent uses configlets that are anyxml and the configlets may > actually be defined in XSD. I know the term =93anyxml=94 only from YANG context. Therefore, if it=92s = not defined in a YANG module, it is not anyxml. >=20 > Quoting draft-ietf-netmod-yang-json-00.txt: >=20 > An XML element that is modeled as a YANG anyxml data node is > translated to a name/object pair. The content of such an element is > not modelled by YANG, and there may not be a straightforward mapping > to JSON text (e.g., if it is a mixed XML content). Therefore, > translation of anyxml contents is necessarily application-specific > and outside the scope of this document. >=20 > I do not think "translation of anyxml contents is necessarily > application-specific" is interoperable. (I note that the second quoted > sentence contradicts your statement that "every anyxml is defined in a > YANG module=94). No, the outermost XML element is defined in YANG and what=92s inside = (=93content of such an element=94) is not. >=20 > And the example given in draft-ietf-netmod-yang-json-00.txt is > actually supporting my concern. Why should something translate >=20 > >

> This is very cool. >

> >=20 > into an arbitrary markup notation >=20 > { > "bar": { > "p": "This is *very* cool." > } > } >=20 > if bar is of type anyxml? I would strongly prefer to get the Why not? The definition of this anyxml data note could be e. g. anyxml bar { description "Text of the banner page that is displayed to every user after login. XHTML markup can be used in XML and Markdown in JSON."; } Why should implementors have any trouble with this? I think it could be = actually quite useful. And yes, I agree with you that RFC 6020 allows anyxml node instances to = contain really any well-formed XML, including mixed content. =20 > unmodified xhtml content for bar and not some arbitrary rendering of > it. Sorry, I still don=92t see the reason. Could you give an example where = use-case-specific rendering can cause any problems? Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Aug 29 01:57: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 CA03E1A06E2 for ; Fri, 29 Aug 2014 01:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668] 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 gyo3m9tL6CWK for ; Fri, 29 Aug 2014 01:57:22 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64771A06D3 for ; Fri, 29 Aug 2014 01:57:22 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 51AAB14085D; Fri, 29 Aug 2014 10:57:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409302640; bh=DR0DL0P+Xpw/f9FT4ekWLlPPYhGiD7tehxh2H/ih97I=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pSESpCez4N5t6U8DFFcQBbv4ZHDnI0MUfpy0wWV+c+Fbt6W+RoF9bD93Skaj6m6Re AjYMN0jHXfncXCmzQ1u4DeKd6eqZA8Ut0AaTwKNNn+V7zH0R0HXK/rO4YNAhVKx/bG E4Lr0nVzSSBrkyN03rS8c+GsWzHubLyAMMq60QiY= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140828.191052.124500232.mbj@tail-f.com> Date: Fri, 29 Aug 2014 10:57:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <30428AB6-627B-4C13-B4BF-2BA0FE651D58@nic.cz> References: <93EC9A42-3434-4272-9C52-7D97BB771688@nic.cz> <20140828.191052.124500232.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/bgL45mw7maBWwNNCPb_zl1ud0IQ Cc: netmod@ietf.org Subject: Re: [netmod] YANG unions in 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, 29 Aug 2014 08:57:23 -0000 On 28 Aug 2014, at 19:10, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On 28 Aug 2014, at 17:05, Andy Bierman wrote: >>=20 >>> Hi, >>>=20 >>> I realize that the standard text is important and needs to be = correct, but >>> when writing >>> the code for this, I followed the Postel Principle. The YANG schema = wins any >>> conflict. >>> The tools will try to figure out how to get the content to fit the = YANG >>> schema, even if >>> the peer did not follow every detail in Lada's draft. >>>=20 >>> Re, these examples: the 42 vs "42" would be treated as a = duplicate-entry >>> error. >>> The "1.000" is a perfectly valid key by the (strange) YANG typedef = rules, so >>> it would be accepted. >=20 > Agreed. >=20 >=20 >> Hmm, pyangs flags an error on this module: >>=20 >> module jtest { >> namespace "http://example.com/jtest"; >> prefix jt; >>=20 >> leaf foo { >> type decimal64 { >> fraction-digits 1; >> } >> default "1.00"; >> } >> } >>=20 >> $ pyang jtest.yang=20 >> jtest.yang:9: error: the value "1.00" does not match its base type - = too many >> fraction digits >>=20 >> But maybe it shouldn=92t =85 >=20 > Remember that the original type was a union, so if you change your > leaf to: >=20 > leaf foo { > type union { > type decimal64 { > fraction-digits 1; > } > type string; > } > default "1.00"; > } >=20 > pyang doesn't complain, just as Andy say. It doesn=92t complain because it treats =931.00=94 as a string and not = as decimal64. And that was my point: if it is a list key, then we could = have one entry with 1.0 (decimal64) and another with =931.00" (string). I understood that Andy said 1.00 would be classified as decimal64 with 1 = fractional digit, too, and it would therefore be equal to 1.0. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Aug 29 02: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 364581A06F1 for ; Fri, 29 Aug 2014 02:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.081 X-Spam-Level: X-Spam-Status: No, score=0.081 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, RP_MATCHES_RCVD=-0.668] 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 qKgMpheeC7ti for ; Fri, 29 Aug 2014 02:31:05 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D68841A06ED for ; Fri, 29 Aug 2014 02:31:04 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 37129140868; Fri, 29 Aug 2014 11:31:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409304662; bh=QYrvcKg/LiYl44nmclz31YWTTPxMdl9+TACUgsaT+lY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=l9BKfIh7A0xj6pEcrs66kcjRzTkJsK7zMU7yalgrfvv1uihzFSnGHMOVsMDCdGHjy iXvVr5TGzdpPQLeC8XSfmQYOJSWwd4qaAr+V90KtdbIhSrWljqtyZMGyVbj5/mtfKj GoBB521PZe3oGm9h+QKuFHqmwQnJI6al3VdJdXn4= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 29 Aug 2014 11:31:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140828074829.GA61114@elstar.local> <20140828.124839.716000072014037611.mbj@tail-f.com> <20140828120536.GB61647@elstar.local> <20140828152246.GB62093@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hxAVpXPpXjJcNDrcy2xdnnodjx8 Cc: "netmod@ietf.org" Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 29 Aug 2014 09:31:06 -0000 On 28 Aug 2014, at 17:32, Andy Bierman wrote: > Agreed -- if mixed mode XML and entities were allowed, then encoding > the XML as a string would be best. >=20 OK, so would a string be better than an object? Something like this: An XML element that is an instance of a YANG anyxml data node is = translated to a name/value pair where the value is a JSON string. The = XML-JSON mapping of this string is not defined by this document. That = is, the content of the XML instance may appear unchanged in this string = value, or it may be processed in any way that=92s appropriate for a = given application. In the latter case, the definition of the anyxml data = node SHOULD contain a description specifying the mapping of the XML = content to JSON and vice versa.=20 Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Aug 29 03:01: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 AC12A1A0041 for ; Fri, 29 Aug 2014 03:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMSihLfkQZqD for ; Fri, 29 Aug 2014 03:01:19 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95E3F1A002B for ; Fri, 29 Aug 2014 03:01:19 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id m20so2070753qcx.7 for ; Fri, 29 Aug 2014 03:01:18 -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=6mNvR77hoEYdRhix0P4mW4mDILa81Neu49VTew0VYFs=; b=mH6HG1FQ7VMX5+zZgIgZ/rpopzjK5vWMs29Ky4qycnIxT8KlCz/zZw5f8h2mABF/D3 tOwULLcNfz9WM3Qf7mQb5grqDcT+uIyTcC1kU6aDm4gTjULWDH+iDF/Pois73kcgzjhj 6eyP6zyk9aOjxIGW0+k5AU3C5G3ZOcFMkBN8WV2Jy32BBT3P2Ta8CqECbvMWNc9fLBnm /jQFx/01sMYO0DN+vyN0gegFOhxAXVW/bYQHoPJYijPzqTJ7d3PiUwFx3sqrc68l18N8 IZZZFAqFt/HdOJNjM8VS5NNu355t3RcBhDGbsMVSCKimkjOUYjb4xcW5kMj5rbqwIEHh 2heg== X-Gm-Message-State: ALoCoQmdQvRmSbEe9iZEjfEkYw2ccsxiY1zddpDtLMJpaIL0uAK2AxM0f3rb0yNKm2ra6lt979Km MIME-Version: 1.0 X-Received: by 10.140.98.147 with SMTP id o19mr2874641qge.21.1409306478652; Fri, 29 Aug 2014 03:01:18 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Fri, 29 Aug 2014 03:01:18 -0700 (PDT) In-Reply-To: <30428AB6-627B-4C13-B4BF-2BA0FE651D58@nic.cz> References: <93EC9A42-3434-4272-9C52-7D97BB771688@nic.cz> <20140828.191052.124500232.mbj@tail-f.com> <30428AB6-627B-4C13-B4BF-2BA0FE651D58@nic.cz> Date: Fri, 29 Aug 2014 03:01:18 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113a923c0a4be20501c1bcc3 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/psxu6XPiUKZ-HTEBW4g2NLlPHl4 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG unions in 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, 29 Aug 2014 10:01:24 -0000 --001a113a923c0a4be20501c1bcc3 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 29, 2014 at 1:57 AM, Ladislav Lhotka wrote: > > On 28 Aug 2014, at 19:10, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > >> > >> On 28 Aug 2014, at 17:05, Andy Bierman wrote: > >> > >>> Hi, > >>> > >>> I realize that the standard text is important and needs to be correct, > but > >>> when writing > >>> the code for this, I followed the Postel Principle. The YANG schema > wins any > >>> conflict. > >>> The tools will try to figure out how to get the content to fit the YANG > >>> schema, even if > >>> the peer did not follow every detail in Lada's draft. > >>> > >>> Re, these examples: the 42 vs "42" would be treated as a > duplicate-entry > >>> error. > >>> The "1.000" is a perfectly valid key by the (strange) YANG typedef > rules, so > >>> it would be accepted. > > > > Agreed. > > > > > >> Hmm, pyangs flags an error on this module: > >> > >> module jtest { > >> namespace "http://example.com/jtest"; > >> prefix jt; > >> > >> leaf foo { > >> type decimal64 { > >> fraction-digits 1; > >> } > >> default "1.00"; > >> } > >> } > >> > >> $ pyang jtest.yang > >> jtest.yang:9: error: the value "1.00" does not match its base type - > too many > >> fraction digits > >> > >> But maybe it shouldn't ... > > > > Remember that the original type was a union, so if you change your > > leaf to: > > > > leaf foo { > > type union { > > type decimal64 { > > fraction-digits 1; > > } > > type string; > > } > > default "1.00"; > > } > > > > pyang doesn't complain, just as Andy say. > > It doesn't complain because it treats "1.00" as a string and not as > decimal64. And that was my point: if it is a list key, then we could have > one entry with 1.0 (decimal64) and another with "1.00" (string). > > I understood that Andy said 1.00 would be classified as decimal64 with 1 > fractional digit, too, and it would therefore be equal to 1.0. > > no - I said it would be treated as a string, not a number. The test for decimal64 will fail and "1.00" will match the next (string) type instead. 1.0 and "1.00" are both valid values for the union typedef for leaf 'foo'. > Lada > Andy > > > > > > > /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a113a923c0a4be20501c1bcc3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Aug 29, 2014 at 1:57 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 28 Aug 2014, at 19:10, Martin Bjorklund <mbj@tail-f.com> wrote:

> Ladislav Lhotka <lhotka@nic.cz= > wrote:
>>
>> On 28 Aug 2014, at 17:05, Andy Bierman <andy@yumaworks.com> wrote:
>>
>>> Hi,
>>>
>>> I realize that the standard text is important and needs to be = correct, but
>>> when writing
>>> the code for this, I followed the Postel Principle. The YANG s= chema wins any
>>> conflict.
>>> The tools will try to figure out how to get the content to fit= the YANG
>>> schema, even if
>>> the peer did not follow every detail in Lada's draft.
>>>
>>> Re, these examples: the 42 vs "42" would be treated = as a duplicate-entry
>>> error.
>>> The "1.000" is a perfectly valid key by the (strange= ) YANG typedef rules, so
>>> it would be accepted.
>
> Agreed.
>
>
>> Hmm, pyangs flags an error on this module:
>>
>> module jtest {
>>  namespace "http://example.com/jtest";
>>  prefix jt;
>>
>>  leaf foo {
>>    type decimal64 {
>>      fraction-digits 1;
>>    }
>>    default "1.00";
>>  }
>> }
>>
>> $ pyang jtest.yang
>> jtest.yang:9: error: the value "1.00" does not match its= base type - too many
>> fraction digits
>>
>> But maybe it shouldn’t …
>
> Remember that the original type was a union, so if you change your
> leaf to:
>
>  leaf foo {
>    type union {
>      type decimal64 {
>        fraction-digits 1;
>      }
>      type string;
>    }
>    default "1.00";
>  }
>
> pyang doesn't complain, just as Andy say.

It doesn’t complain because it treats “1.00” as a string = and not as decimal64. And that was my point: if it is a list key, then we c= ould have one entry with 1.0 (decimal64) and another with “1.00"= (string).

I understood that Andy said 1.00 would be classified as decimal64 with 1 fr= actional digit, too, and it would therefore be equal to 1.0.


no - I said it would be treated as a s= tring, not a number.
The test for decimal64 will fail and "1= .00" will match the
next (string) type instead. 1.0 and &quo= t;1.00" are both valid values
for the union typedef for leaf 'foo'.

 
Lada

Andy
 

>
>
> /martin

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





--001a113a923c0a4be20501c1bcc3-- From nobody Fri Aug 29 03:06: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 C0B361A004C for ; Fri, 29 Aug 2014 03:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_54=0.6, RP_MATCHES_RCVD=-0.668] 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 HYOtyyza8eUz for ; Fri, 29 Aug 2014 03:06:44 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 477AA1A0041 for ; Fri, 29 Aug 2014 03:06:43 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 8EAD913F7CA; Fri, 29 Aug 2014 12:06:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409306801; bh=tPo9hNYxqUvtzRlk1oYMO6O8O194LsUSbqnJmkGQ4x4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=jwoniTIOUUdZTcsPfuE/6r1Oyec8dkp438o7s7T9L/kjleDnLg0ofurR28dsGPosR WntyHjospSjChdNFOYsn3cxdLmaXVEo+w9h4PwVp4ql94t6whhkPNbL3jHo50EQCfn UshT207XGimjEun0zPnKgT+64Mt4wcQomZnJg+Zs= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 29 Aug 2014 12:06:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <18707828-D759-4E34-92EC-408953682685@nic.cz> References: <93EC9A42-3434-4272-9C52-7D97BB771688@nic.cz> <20140828.191052.124500232.mbj@tail-f.com> <30428AB6-627B-4C13-B4BF-2BA0FE651D58@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/tpFg62cwfjt16yROrs-g_N5RJB8 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG unions in 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, 29 Aug 2014 10:06:47 -0000 On 29 Aug 2014, at 12:01, Andy Bierman wrote: >=20 >=20 >=20 > On Fri, Aug 29, 2014 at 1:57 AM, Ladislav Lhotka = wrote: >=20 > On 28 Aug 2014, at 19:10, Martin Bjorklund wrote: >=20 > > Ladislav Lhotka wrote: > >> > >> On 28 Aug 2014, at 17:05, Andy Bierman wrote: > >> > >>> Hi, > >>> > >>> I realize that the standard text is important and needs to be = correct, but > >>> when writing > >>> the code for this, I followed the Postel Principle. The YANG = schema wins any > >>> conflict. > >>> The tools will try to figure out how to get the content to fit the = YANG > >>> schema, even if > >>> the peer did not follow every detail in Lada's draft. > >>> > >>> Re, these examples: the 42 vs "42" would be treated as a = duplicate-entry > >>> error. > >>> The "1.000" is a perfectly valid key by the (strange) YANG typedef = rules, so > >>> it would be accepted. > > > > Agreed. > > > > > >> Hmm, pyangs flags an error on this module: > >> > >> module jtest { > >> namespace "http://example.com/jtest"; > >> prefix jt; > >> > >> leaf foo { > >> type decimal64 { > >> fraction-digits 1; > >> } > >> default "1.00"; > >> } > >> } > >> > >> $ pyang jtest.yang > >> jtest.yang:9: error: the value "1.00" does not match its base type = - too many > >> fraction digits > >> > >> But maybe it shouldn=92t =85 > > > > Remember that the original type was a union, so if you change your > > leaf to: > > > > leaf foo { > > type union { > > type decimal64 { > > fraction-digits 1; > > } > > type string; > > } > > default "1.00"; > > } > > > > pyang doesn't complain, just as Andy say. >=20 > It doesn=92t complain because it treats =931.00=94 as a string and not = as decimal64. And that was my point: if it is a list key, then we could = have one entry with 1.0 (decimal64) and another with =931.00" (string). >=20 > I understood that Andy said 1.00 would be classified as decimal64 with = 1 fractional digit, too, and it would therefore be equal to 1.0. >=20 >=20 > no - I said it would be treated as a string, not a number. > The test for decimal64 will fail and "1.00" will match the > next (string) type instead. 1.0 and "1.00" are both valid values > for the union typedef for leaf 'foo=92. OK, but then these two values aren=92t equal in terms of list key = uniqueness. I apparently misunderstood what you said. Lada=20 >=20 > =20 > Lada >=20 > Andy > =20 >=20 > > > > > > /martin >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Aug 29 03:14:30 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3541A005B for ; Fri, 29 Aug 2014 03:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.381 X-Spam-Level: * X-Spam-Status: No, score=1.381 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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.668] 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 v5EXKZ9CJUMx for ; Fri, 29 Aug 2014 03:14:26 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B66B1A004E for ; Fri, 29 Aug 2014 03:14:26 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 2FF2413F7CA for ; Fri, 29 Aug 2014 12:14:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409307265; bh=nzJH3A9iiRSrmKcD4YHrK6JC8G1BIDeMAYilFpU0BTM=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id: Date:To:Mime-Version; b=rTfvADgQtxyNRC9k9oUyTGYInmHnKpBpJpVQBDkX2989zAf3wjnZAHHq8KpyDAQgB Ewn2VfnurTHQ8S6/XMIf0FL+x1MhtRlYIHcdc3uagg/oY6+WJ6NKebHsM1yjHKEa+T wKPspCpG4H/yzMp3QFI3hhCa0f/zGEkDHuIM0oIw= From: Ladislav Lhotka Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <79D32E69-4E3F-482D-937D-1D12C44CEF7B@nic.cz> Date: Fri, 29 Aug 2014 12:14:24 +0200 To: NETMOD Working Group Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nFJXWZo1UzjwnmlLdeJoEz1DZ1U Subject: [netmod] decimal64 type X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 29 Aug 2014 10:14:27 -0000 Hi, after re-reading section 9.3 in RFC 6020, I wonder whether 1.00 is a = valid value of type decimal64 { fractional-digits 1; } I can=92t find anything in the text that makes it invalid because that = number is expressible as 10 x 10^-1 and therefore belongs to the value space of that type. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Aug 29 03:21: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 D1BCD1A0068 for ; Fri, 29 Aug 2014 03:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 0Ea6P0v9r9AJ for ; Fri, 29 Aug 2014 03:21:13 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id AE3A61A0070 for ; Fri, 29 Aug 2014 03:21:13 -0700 (PDT) Received: from localhost (173-38-208-169.cisco.com [173.38.208.169]) by mail.tail-f.com (Postfix) with ESMTPSA id C9C2A128048B; Fri, 29 Aug 2014 12:18:31 +0200 (CEST) Date: Fri, 29 Aug 2014 12:21:12 +0200 (CEST) Message-Id: <20140829.122112.55164837007353995.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <79D32E69-4E3F-482D-937D-1D12C44CEF7B@nic.cz> References: <79D32E69-4E3F-482D-937D-1D12C44CEF7B@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/dgLIJIRz7nhHAwP-1jmWG7OfiW0 Cc: netmod@ietf.org Subject: Re: [netmod] decimal64 type X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 29 Aug 2014 10:21:15 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gSGksDQo+IA0KPiBhZnRl ciByZS1yZWFkaW5nIHNlY3Rpb24gOS4zIGluIFJGQyA2MDIwLCBJIHdvbmRlciB3aGV0aGVyIDEu MDAgaXMgYQ0KPiB2YWxpZCB2YWx1ZSBvZg0KPiANCj4gdHlwZSBkZWNpbWFsNjQgew0KPiAgIGZy YWN0aW9uYWwtZGlnaXRzIDE7DQo+IH0NCj4gDQo+IEkgY2Fu4oCZdCBmaW5kIGFueXRoaW5nIGlu IHRoZSB0ZXh0IHRoYXQgbWFrZXMgaXQgaW52YWxpZCBiZWNhdXNlIHRoYXQNCj4gbnVtYmVyIGlz IGV4cHJlc3NpYmxlIGFzDQo+IA0KPiAxMCB4IDEwXi0xDQo+IA0KPiBhbmQgdGhlcmVmb3JlIGJl bG9uZ3MgdG8gdGhlIHZhbHVlIHNwYWNlIG9mIHRoYXQgdHlwZS4NCg0KSSB0aGluayB5b3UgYXJl IHJpZ2h0LiAgSXQgYWxzbyBzZWVtcyB0aGF0IDkuMy4yICh3aGljaCBzYXlzIHRoYXQNCnRyYWls aW5nIHplcm9zIGFyZSBwcm9oaWJpdGVkIGluIHRoZSBjYW5vbmljYWwgZm9ybWF0KSBpbXBsaWVz IHRoaXMuDQoNCg0KDQovbWFydGluDQo= From nobody Fri Aug 29 07:38: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 24DAB1A0407 for ; Fri, 29 Aug 2014 07:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7RSqdqSomeH for ; Fri, 29 Aug 2014 07:38:46 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DBD91A03BB for ; Fri, 29 Aug 2014 07:38:46 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 45D2EA9A for ; Fri, 29 Aug 2014 16:38:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id FrTkgrclmMWj for ; Fri, 29 Aug 2014 16:38:43 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 29 Aug 2014 16:38:44 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BC14920035 for ; Fri, 29 Aug 2014 16:38:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zoDjXNARkxkk; Fri, 29 Aug 2014 16:38:44 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 00A8720033; Fri, 29 Aug 2014 16:38:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CCAA52E542A0; Fri, 29 Aug 2014 16:38:42 +0200 (CEST) Date: Fri, 29 Aug 2014 16:38:42 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140829143841.GA64903@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/tbYXHi_4lDIXW77ujrk3gD47gSQ Subject: [netmod] IETF 90 (Toronto) meeting minutes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 14:38:48 -0000 Hi, I have posted the Toronto meeting minutes: http://www.ietf.org/proceedings/90/minutes/minutes-90-netmod Please review and let me know if something needs to be fixed. Sorry for being late with 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 Fri Aug 29 08:44:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55F91A0640 for ; Fri, 29 Aug 2014 08:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 BlfGrKFrFXfK for ; Fri, 29 Aug 2014 08:43:58 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 398851A0654 for ; Fri, 29 Aug 2014 08:43:54 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id f12so2290924qad.18 for ; Fri, 29 Aug 2014 08:43: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:date:message-id:subject:from:to :content-type; bh=k11Eng0m30Ty4u36pYbCbBFSXJm5tpz9TWETZXNd1Z0=; b=WQEtDh56k6zQtH4cYhz8z5tSVeTZg9cja7YNEdwLYm110269z7E1umxscRfyiIBgrP zedmLRnYa3NjInjuG1x0D/toVLhVDngwTnkuh0z1snIv+cbUzuuiHFp5dhCytpRECtz4 5Ly08cNdma/se6TCa92gHbjnMY+pNM5uJ6jbHeMQNBnT4pzdUWqN3qAMUoRWEr3y5j/A 1Hxv8J2S2i2kOM1bQV5X9qnu02f8EP6CG1NCYg+rER7i2rIinFbbmG5wQylt5GvFgVKY 8y1OSB+o1PNT9CC+FQmDBqtn6sqPBCU3r7YhXssSYBM5nN230nnObRdlZiyaXC/ahGNx 7ZQw== X-Gm-Message-State: ALoCoQkcmPpp2/cE2jqttTHJT1dAbI/rf3dmQFHyeMU+wUTUo/tw5kExLYHGzm61SXjkZIEyfulq MIME-Version: 1.0 X-Received: by 10.224.122.83 with SMTP id k19mr18840227qar.78.1409327032793; Fri, 29 Aug 2014 08:43:52 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Fri, 29 Aug 2014 08:43:52 -0700 (PDT) Date: Fri, 29 Aug 2014 08:43:52 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=047d7bf0c3462992520501c6850a Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/8mCw5bJUmHIxZSSrTMJTx6wCoH8 Subject: [netmod] optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 29 Aug 2014 15:44:00 -0000 --047d7bf0c3462992520501c6850a Content-Type: text/plain; charset=ISO-8859-1 Hi, My understanding of the optional keys proposal is that at least one key has to be mandatory. Is that correct? Consider a simple address list: list address { key "last-name first-name middle-name"; leaf last-name { type string; mandatory false; } leaf middle-name { type string; mandatory false; } leaf first-name { type string; mandatory false; } leaf street { type string; } leaf city { type string; } leaf zipcode { type string; } } What is needed in this case is that at least one key be present in any protocol request to create this list. The number of 'mandatory false' statements may not be the correct criteria. Let's say I have 2 entries for "Cher" and "Cher Baker". There does not seem to be any way in subtree or XPath filtering to request just the "Cher" entry. The absence of a key will be interpreted as "match all" in both cases. How will NETCONF and RESTCONF fully manage YANG lists with optional keys? (Perhaps an interim meeting topic?) Andy --047d7bf0c3462992520501c6850a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

My understanding of the optional ke= ys proposal is that at least one key has
to be mandatory. Is that= correct? =A0Consider a simple address list:

= =A0 list address {
=A0 =A0 key "last-name first-name middle-name";
=A0 =A0 leaf last-name {
=A0 =A0 =A0 type string;
=A0 =A0 =A0 mandatory false;
=A0 =A0 }
=A0 =A0 = leaf middle-name {
=A0 =A0 =A0 type string;
=A0 =A0 =A0 mandatory false;
<= div>=A0 =A0 }
=A0 =A0 leaf first-name {
=A0 =A0 =A0 typ= e string;
=A0 =A0 =A0 mandatory false;
=A0 =A0 }
<= div>=A0 =A0 leaf street { type string; }
=A0 =A0 leaf city { type string; }
=A0 =A0 leaf zipcode { ty= pe string; }
=A0 }

What is n= eeded in this case is that at least one key be present in any
pro= tocol request to create this list. The number of 'mandatory false'<= /div>
statements may not be the correct criteria.

L= et's say I have 2 entries for "Cher" and "Cher Baker&quo= t;.
There does not seem to be any way in subtree or XPath filteri= ng
to request just the "Cher" entry. The absence of a key will = be interpreted
as "match all" in both cases.
=
How will NETCONF and RESTCONF fully manage YANG lists with
optional keys? (Perhaps an interim meeting topic?)



Andy



--047d7bf0c3462992520501c6850a-- From nobody Fri Aug 29 09:36: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 C1FAF1A0669 for ; Fri, 29 Aug 2014 09:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.58 X-Spam-Level: X-Spam-Status: No, score=0.58 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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.668] 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 d9bDhJ7LwxST for ; Fri, 29 Aug 2014 09:35:57 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68AD81A0659 for ; Fri, 29 Aug 2014 09:35:56 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 356BD1409DC; Fri, 29 Aug 2014 18:35:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409330154; bh=Tf52FMEya2Eu68Fp5twEq9c6v1D9Voz5sLfgHxb2Nx0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=q7lTfDkRoAlr0fKKBRAQjq1bPd7739OFHeujzSsn8VtJFMPfSVaCvhy1n/zYcJHwp RKGf7FGvyxIHklMz+qzNHTb7XbPSd3We0pa5R3xXk1JwCYH9mg0eoHEhFVvRa3WVaV vqB4xBChzhJmEnWEPrAXDmTnJZ3d6Qx/E3tywIJc= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 29 Aug 2014 18:35:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/QuE-DrMDYuWJN3YKNoaBx_ItdVM Cc: "netmod@ietf.org" Subject: Re: [netmod] optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 29 Aug 2014 16:35:58 -0000 On 29 Aug 2014, at 17:43, Andy Bierman wrote: > Hi, >=20 > My understanding of the optional keys proposal is that at least one = key has > to be mandatory. Is that correct? Consider a simple address list: I don=92t see much difference between solutions Y09-01 and -02 but at = least -02 clearly says that all key leafs can be optional. The only = requirement is that each entry has a unique combination of keys. >=20 > list address { > key "last-name first-name middle-name"; >=20 > leaf last-name { > type string; > mandatory false; > } > leaf middle-name { > type string; > mandatory false; > } > leaf first-name { > type string; > mandatory false; > } > leaf street { type string; } > leaf city { type string; } > leaf zipcode { type string; } > } >=20 > What is needed in this case is that at least one key be present in any > protocol request to create this list. The number of 'mandatory false' > statements may not be the correct criteria. >=20 > Let's say I have 2 entries for "Cher" and "Cher Baker". > There does not seem to be any way in subtree or XPath filtering > to request just the "Cher" entry. The absence of a key will be = interpreted > as "match all" in both cases. XPath should work: first-name=3D'Cher' and not(last-name) Lada >=20 > How will NETCONF and RESTCONF fully manage YANG lists with > optional keys? (Perhaps an interim meeting topic?) >=20 >=20 >=20 > Andy >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Aug 31 18:59: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 C35251A90B6; Sun, 31 Aug 2014 18:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 ya9VS8_rjjYg; Sun, 31 Aug 2014 18:58:59 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768841A90B3; Sun, 31 Aug 2014 18:58:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 42A9D2606D2; Sun, 31 Aug 2014 18:58:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-35.clppva.east.verizon.net [70.106.135.35]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 94B6C1D26B4; Sun, 31 Aug 2014 18:58:58 -0700 (PDT) Message-ID: <5403D2E1.6090502@joelhalpern.com> Date: Sun, 31 Aug 2014 21:58:57 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: i2rs@ietf.org, netmod@ietf.org References: <20140829064207.GA63316@elstar.local> In-Reply-To: <20140829064207.GA63316@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/oMzvhlNS276YIHdm_zaxAg4bido Subject: Re: [netmod] [i2rs] netmod interim and i2rs requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Sep 2014 01:59:01 -0000 Juergen, While I understand the request, I presume that such a request can not be met as a working group agreement in the time frame suggested. WHile I hope that some of the folks who have been involved in proposing the use of YANG for I2RS will write such a draft, I can not see how we could even get tot eh point of WG adoption of such a draft, much less WG rough consensus on the content, in the time frame you outline. Of course, I am not one of the chairs or ADs, but it seems pretty clear cut to me. Yours, Joel On 8/29/14, 2:42 AM, Juergen Schoenwaelder wrote: > Hi, > > the NETMOD WG is holding an interim meeting on Sep. 17/18 [1] and one > of the agenda items is to work on any requirements I2RS might have for > YANG 1.1. For this, we need a clear definition of what the I2RS > requirements are for YANG 1.1, ideally posted as an I-D a few days > before the interim meeting so that people can come prepared. This > means there are ~15 days left to produce such a requirements writeup. > > /js > > [1] https://www.ietf.org/meeting/interim/netmod-2014-09-17.txt > From nobody Sun Aug 31 19:58: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 358A61A899E; Sun, 31 Aug 2014 19:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.081 X-Spam-Level: * X-Spam-Status: No, score=1.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 DB2iDOvqVU9D; Sun, 31 Aug 2014 19:58:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48EA41A898F; Sun, 31 Aug 2014 19:58:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLZ02088; Mon, 01 Sep 2014 02:58:09 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 1 Sep 2014 03:58:09 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.209]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 1 Sep 2014 10:57:56 +0800 From: Haoweiguo To: "trill@ietf.org" , "netmod@ietf.org" Thread-Topic: New Version Notification for draft-hao-trill-yang-01.txt Thread-Index: AQHPxZAJ1fltAgEguUe9wGQOWP2bd5vrlUAc Date: Mon, 1 Sep 2014 02:57:55 +0000 Message-ID: References: <20140901025416.22806.3070.idtracker@ietfa.amsl.com> In-Reply-To: <20140901025416.22806.3070.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/trMx5_t3yzd1N881ZHqSb6R4ghA Cc: "Xialiang \(Frank\)" , Liyizhou Subject: [netmod] =?gb2312?b?tPC4tDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv?= =?gb2312?b?ciBkcmFmdC1oYW8tdHJpbGwteWFuZy0wMS50eHQ=?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Sep 2014 02:58:13 -0000 SGkgQWxsLA0KSSBoYXZlIHBvc3RlZCBhIG5ldyBkcmFmdCBvZiBUUklMTCBZQU5HIGRhdGEgbW9k ZWwuIElmIHlvdSBjYW4gZ2l2ZSB1cyBzb21lIHN1Z2dlc3Rpb25zIGFuZCBjb21tZW50cywgaSB3 aWxsIGFwcHJlY2lhdGUuDQpUaGFua3MNCndlaWd1bw0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQq3orz+yMs6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0Kt6LLzcqxvOQ6IDIwMTTE6jnUwjHI1SAxMDo1NA0KytW8 /sjLOiBMaXlpemhvdTsgWGlhbGlhbmcgKEZyYW5rKTsgSGFvd2VpZ3VvOyBMaXlpemhvdTsgSGFv d2VpZ3VvOyBYaWFsaWFuZyAoRnJhbmspDQrW98ziOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWhhby10cmlsbC15YW5nLTAxLnR4dA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQtaGFvLXRyaWxsLXlhbmctMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IHdlaWd1byBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1l OiAgICAgICAgICAgZHJhZnQtaGFvLXRyaWxsLXlhbmcNClJldmlzaW9uOiAgICAgICAwMQ0KVGl0 bGU6ICAgICAgICAgIFRSSUxMIFlBTkcgRGF0YSBNb2RlbA0KRG9jdW1lbnQgZGF0ZTogIDIwMTQt MDktMDENCkdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAg ICAgICAyNw0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWhhby10cmlsbC15YW5nLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhhby10cmlsbC15YW5nLw0KSHRtbGl6ZWQ6 ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhby10cmlsbC15YW5nLTAx DQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt aGFvLXRyaWxsLXlhbmctMDENCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHByZXNlbnRz IFlBTkcgZGF0YSBtb2RlbCBmb3IgVFJJTEwgcHJvdG9jb2wgW1JGQzYzMjVdLg0KDQoNCg0KDQpQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA== From nobody Sun Aug 31 22:03:53 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CF21A9123; Sun, 31 Aug 2014 22:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.482 X-Spam-Level: X-Spam-Status: No, score=0.482 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEbZXiKzz6TI; Sun, 31 Aug 2014 22:03:38 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDA5A1A6F8D; Sun, 31 Aug 2014 22:03:37 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4C79D2809; Mon, 1 Sep 2014 07:03:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id WLEpdLVGNAVt; Mon, 1 Sep 2014 07:03:33 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 1 Sep 2014 07:03:34 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5FF3720036; Mon, 1 Sep 2014 07:03:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JzVQHA20YYeT; Mon, 1 Sep 2014 07:03:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 02E4B20035; Mon, 1 Sep 2014 07:03:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 384522E556D4; Mon, 1 Sep 2014 07:03:32 +0200 (CEST) Date: Mon, 1 Sep 2014 07:03:31 +0200 From: Juergen Schoenwaelder To: "Joel M. Halpern" Message-ID: <20140901050331.GA70583@elstar.local> Mail-Followup-To: "Joel M. Halpern" , i2rs@ietf.org, netmod@ietf.org References: <20140829064207.GA63316@elstar.local> <5403D2E1.6090502@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5403D2E1.6090502@joelhalpern.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mEfOLJplnq-EBG0nY8k0umay3y0 Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [netmod] [i2rs] netmod interim and i2rs requirements 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, 01 Sep 2014 05:03:43 -0000 On Sun, Aug 31, 2014 at 09:58:57PM -0400, Joel M. Halpern wrote: > Juergen, > While I understand the request, I presume that such a request can > not be met as a working group agreement in the time frame suggested. > WHile I hope that some of the folks who have been involved in proposing > the use of YANG for I2RS will write such a draft, I can not see how we > could even get tot eh point of WG adoption of such a draft, much less WG > rough consensus on the content, in the time frame you outline. > Of course, I am not one of the chairs or ADs, but it seems pretty > clear cut to me. Joel, all I need is reasonably agreed upon input. Note that this request for input is not coming out of the blue, at least not for those I2RS folks who have been at the NETMOD meeting in Toronto. As NETMOD chair, I do have a target date to deliver YANG 1.1 and I take that milestone serious. My motivation to delay this by N months waiting for I2RS to get their input submitted is very small. I recall that there were presentations about "what is missing" bach in London, that is March 2014. The regular submission period for YANG 1.1 issues was 2014-02-23 until 2014-05-07. The interim meeting is mid September. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103