From andy@netconfcentral.com Wed Apr 1 00:11:04 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3653C3A6C63 for ; Wed, 1 Apr 2009 00:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZDOAd9tMjUa for ; Wed, 1 Apr 2009 00:11:03 -0700 (PDT) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 6B5283A6823 for ; Wed, 1 Apr 2009 00:11:03 -0700 (PDT) Received: (qmail 79371 invoked from network); 1 Apr 2009 07:12:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 1 Apr 2009 07:12:03 -0000 X-YMail-OSG: tyaT9LoVM1nR1n.JKyX6faXG.gAZ96XaeK9tXWZDN_6KRr6xcGBPT9WrDbqljmQECsXILxzmwl5kA_aRRxlKNd8HhIMDtbErg8zCXCN0TLqUHUTnZDxN44ioFSoMg6oqShZWh_MBL10pe18bbH0HzRZ6wJwK90yvkwapb9b9DWThOlTCB5am53XnJFSdisb9Cb1l.tp7n99CuM6x8jpwIBpnIs4VoLzwLndeVvnCm7I9X6C0ijuf0zgM1SndOZmkoSdZaIFwwzOdFD36lY9TKnHQG.hQXEZVBZc_k4lG77QqLmmImtzE_o61psdKH29esUzAC7JR0IP3hQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D313C1.6040501@netconfcentral.com> Date: Wed, 01 Apr 2009 00:12:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <49CECE25.5000603@netconfcentral.com> <20090401.080128.11777848.mbj@tail-f.com> <49D30747.9010609@netconfcentral.com> <20090401.082933.83225477.mbj@tail-f.com> In-Reply-To: <20090401.082933.83225477.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 07:11:04 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> 1) YANG writers MUST know the minimum safe length value that >> can be used on all YANG tools >> 2) no YANG/NETCONF implementation can possibly support infinite >> length identifiers, and letting implementors pick any arbitrary limit >> is not inter-operable > > Why don't you think the same rule is important for the other > constructs I mentioned? What makes the identifier special? > Identifiers are special because they cannot be optimized away. They are mandatory-to-use within agent code to handle incoming PDUs. In order to support small embedded NETCONF agents, setting minimum resource limits that are reasonable is a good idea. The current text follows the similar 'C' rules, which simply set the minimum requirements for all tools, and do not prevent any tools from supporting more than the minimum. If a minimum of 63 was a problem, we would have already raised the limit in SMIv2 a decade ago. > > /martin > > Andy From mbj@tail-f.com Wed Apr 1 01:14:52 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F4013A699C for ; Wed, 1 Apr 2009 01:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.962 X-Spam-Level: X-Spam-Status: No, score=-1.962 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3Og3IbjTI6X for ; Wed, 1 Apr 2009 01:14:51 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7B8373A6879 for ; Wed, 1 Apr 2009 01:14:51 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id D23E476C50C; Wed, 1 Apr 2009 10:15:49 +0200 (CEST) Date: Wed, 01 Apr 2009 10:15:49 +0200 (CEST) Message-Id: <20090401.101549.19604411.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49D30D34.7040709@netconfcentral.com> References: <20090401.080128.11777848.mbj@tail-f.com> <49D30747.9010609@netconfcentral.com> <49D30D34.7040709@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 08:14:52 -0000 Andy Bierman wrote: > > > >> Regarding a limit as in (2), IMO this is pretty arbitrary. Why do we > >> have a limit on this particular thing, but not on namespace uri > >> length; not on the 'contact', 'description' clause data; not on the > >> number of leafs in a container; not on the number of features; not on > >> the nested levels in the hierarchy; not on anything else! What makes > >> the identifier special? > > The difference is between data stored in the agent and data that is not. > > Good catch on the namespace-URI. > We need a similar rule for that (for the agent) > > Implementations MUST support namespace URIs at least 1023 characters > in length. > > The other clauses are not stored in the agent so they do not matter. The depth is stored in the agent; the number of leafs is storeed in the agent; the number of typedefs etc. These identifiers are comparable to XML element names, and as has been pointed out before, XML seems to be quite interoperable. /martin From andy@netconfcentral.com Wed Apr 1 03:37:10 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9DA28C14E for ; Wed, 1 Apr 2009 03:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPVZP2RZ9ttE for ; Wed, 1 Apr 2009 03:37:09 -0700 (PDT) Received: from n21.bullet.mail.mud.yahoo.com (n21.bullet.mail.mud.yahoo.com [68.142.206.160]) by core3.amsl.com (Postfix) with SMTP id 36FEA28C0FC for ; Wed, 1 Apr 2009 03:37:09 -0700 (PDT) Received: from [68.142.194.244] by n21.bullet.mail.mud.yahoo.com with NNFMP; 01 Apr 2009 10:38:09 -0000 Received: from [68.142.201.64] by t2.bullet.mud.yahoo.com with NNFMP; 01 Apr 2009 10:38:09 -0000 Received: from [127.0.0.1] by omp416.mail.mud.yahoo.com with NNFMP; 01 Apr 2009 10:38:09 -0000 X-Yahoo-Newman-Id: 417082.93524.bm@omp416.mail.mud.yahoo.com Received: (qmail 88022 invoked from network); 1 Apr 2009 10:38:09 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 1 Apr 2009 10:38:08 -0000 X-YMail-OSG: FKcPMCUVM1l.oGWIdOsifksFf1ddAhHs_abSBAdt4JG4tzAAnYJizOLw.yNaO.c_1jf2pEZwPVOHamKp7YBBAS.po4fLgcVU63fj0hmgtXsN2j7h2ly6gPzT81s0u20944Gxl8Yb0.vt.lmJZWXW.8W.7sd3WuBqrgyKJ.5Ucq_86rVhcqK.lz6NcxBrczfSIdpfuSOdLE4mNMHDuJudfxJ8.BVIVS.7jzQc4z_EOlyRS4LXfCQoC99z.GzPG2A9uTCIz0uSX.RbAbwTlDDvQUek2LkUwxEyMzD6GGHxRV2uiIi2FxJUP8q.00CiAQltwj3WTKsjhOsWyA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D3440E.3070305@netconfcentral.com> Date: Wed, 01 Apr 2009 03:38:06 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <20090401.080128.11777848.mbj@tail-f.com> <49D30747.9010609@netconfcentral.com> <49D30D34.7040709@netconfcentral.com> <20090401.101549.19604411.mbj@tail-f.com> In-Reply-To: <20090401.101549.19604411.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 10:37:10 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> >>>> Regarding a limit as in (2), IMO this is pretty arbitrary. Why do we >>>> have a limit on this particular thing, but not on namespace uri >>>> length; not on the 'contact', 'description' clause data; not on the >>>> number of leafs in a container; not on the number of features; not on >>>> the nested levels in the hierarchy; not on anything else! What makes >>>> the identifier special? >> The difference is between data stored in the agent and data that is not. >> >> Good catch on the namespace-URI. >> We need a similar rule for that (for the agent) >> >> Implementations MUST support namespace URIs at least 1023 characters >> in length. >> >> The other clauses are not stored in the agent so they do not matter. > > The depth is stored in the agent; the number of leafs is storeed in > the agent; the number of typedefs etc. > > These identifiers are comparable to XML element names, and as has been > pointed out before, XML seems to be quite interoperable. > They are more comparable to SMIv2 descriptors for out purposes, and SMIv2 has proven to be quite inter-operable. Please provide at least ONE use-case demonstrating that adopting the same guideline as SMIv2 will cause some actual problem in an actual network somewhere. I realize that in theory somebody could want a 6 billion character identifier, but I don't this is a real problem the IETF needs to solve. The IETF just needs to make sure some reasonable defaults are supported on every NETCONF/YANG implementation. > > /martin > > Andy From andy@netconfcentral.com Wed Apr 1 03:44:40 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E9353A6981 for ; Wed, 1 Apr 2009 03:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p64KOYGv4yfs for ; Wed, 1 Apr 2009 03:44:39 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id DFCD13A67A7 for ; Wed, 1 Apr 2009 03:44:39 -0700 (PDT) Received: (qmail 45731 invoked from network); 1 Apr 2009 10:45:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 1 Apr 2009 10:45:39 -0000 X-YMail-OSG: nTI0k1sVM1kTDh6zW.wa7U3mZiiaBQPceMcYIMz8vqz0kfLtqWrKYt8GKsWOU5z_EHAIM39ou1bk6Xsw0cklbbpRshNCGfpW09QVPFLzR2vtFUGIAgo1gijUmUWEOy7cjdlv4x3Fgrvyv80NnnACUJxevzY05eDv5S2y.5SY_pNDrwoPVhYgYgs_xaL0QxAq_qauVon45q3qibYB5yXhcwR3pw5GLvC1sFYUXgwSn0LsajB4ZfbiWBVzSXunO_VxqHoUXTsM525R_EfMudJJ4jWXmcGDqdz_2hX4o3zu7DZTPdyKvj102zlzHO2QWveLzAyIEmrMmPCHKg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D345D1.2020702@netconfcentral.com> Date: Wed, 01 Apr 2009 03:45:37 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <20090401.080128.11777848.mbj@tail-f.com> <49D30747.9010609@netconfcentral.com> <49D30D34.7040709@netconfcentral.com> <20090401.101549.19604411.mbj@tail-f.com> In-Reply-To: <20090401.101549.19604411.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 10:44:40 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> >>>> Regarding a limit as in (2), IMO this is pretty arbitrary. Why do we >>>> have a limit on this particular thing, but not on namespace uri >>>> length; not on the 'contact', 'description' clause data; not on the >>>> number of leafs in a container; not on the number of features; not on >>>> the nested levels in the hierarchy; not on anything else! What makes >>>> the identifier special? >> The difference is between data stored in the agent and data that is not. >> >> Good catch on the namespace-URI. >> We need a similar rule for that (for the agent) >> >> Implementations MUST support namespace URIs at least 1023 characters >> in length. >> >> The other clauses are not stored in the agent so they do not matter. > > The depth is stored in the agent; the number of leafs is storeed in > the agent; the number of typedefs etc. > > These identifiers are comparable to XML element names, and as has been > pointed out before, XML seems to be quite interoperable. > Then why does your agent need to force the list keys to be ordered first? Your agent should be able to deal with this. Every other XML application can deal with the elements delivered in schema order. Why is it OK for NETCONF to be special in this one aspect of XML usage, but no others? > > /martin > > Andy From mbj@tail-f.com Wed Apr 1 03:45:25 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB36B28C18E for ; Wed, 1 Apr 2009 03:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-ayeo4Tr+h5 for ; Wed, 1 Apr 2009 03:45:25 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E31383A67A7 for ; Wed, 1 Apr 2009 03:45:24 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id E737876C50C; Wed, 1 Apr 2009 12:46:23 +0200 (CEST) Date: Wed, 01 Apr 2009 12:46:23 +0200 (CEST) Message-Id: <20090401.124623.107717663.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49D3440E.3070305@netconfcentral.com> References: <49D30D34.7040709@netconfcentral.com> <20090401.101549.19604411.mbj@tail-f.com> <49D3440E.3070305@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 10:45:25 -0000 Andy Bierman wrote: > They are more comparable to SMIv2 descriptors for out purposes, > and SMIv2 has proven to be quite inter-operable. > > Please provide at least ONE use-case demonstrating that > adopting the same guideline as SMIv2 will cause some actual > problem in an actual network somewhere. rfc 2578 says: For all descriptors appearing in an information module, the descriptor shall be unique and mnemonic, and shall not exceed 64 characters in length. Assuming "shall not" means "SHALL NOT" as in rfc 2119, this would correspond to your alternative (2), i.e. a fixed max lentgh. Noone has claimed that this would be non-interoperable. We have claimed that the current text is. > I realize that in theory somebody could want a 6 billion character > identifier, but I don't this is a real problem the IETF needs to solve. Do you think anyone will ever want 6 billion nested levels in the hierarchy? 64 levels? 32? Should we limit the nest level because of this? /martin From andy@netconfcentral.com Wed Apr 1 03:52:43 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B215B3A6C55 for ; Wed, 1 Apr 2009 03:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAlN7WZ7y9Em for ; Wed, 1 Apr 2009 03:52:42 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id EEE643A67F3 for ; Wed, 1 Apr 2009 03:52:42 -0700 (PDT) Received: (qmail 38576 invoked from network); 1 Apr 2009 10:53:43 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 1 Apr 2009 10:53:42 -0000 X-YMail-OSG: ym6bdYMVM1mdgQOpbvD35mBtQ2DNm0jTrh_D2ZtU31SDfigMhg2nZHu3nDws_KreWDzZ3ImX7ZBIw.f2Wjw0k8LMZ6zqK_to4RpN0EsgR56S_t8XF4IOmSr7e1kXWAqGRIq_ASCuzK5JlhuEZAKG4CHHhIjKvIzT0Bwgk8_oh.aqO_QSATN7NIapKNV2izJhNqjAP.5Y6l3OF0hyCWxQTGsCN7_866Wzohg.YzqwxpNyIIhVlkhP_dFKxJGfOCK0bZWrbYWBBm8ugPWzCdAOYH4R0aB_OYo6OPkyNvn9AzJtw48UA0TYm.R09CweEqgZ4bgx5zNT1dZpfA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D347B5.1080608@netconfcentral.com> Date: Wed, 01 Apr 2009 03:53:41 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <49D30D34.7040709@netconfcentral.com> <20090401.101549.19604411.mbj@tail-f.com> <49D3440E.3070305@netconfcentral.com> <20090401.124623.107717663.mbj@tail-f.com> In-Reply-To: <20090401.124623.107717663.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 10:52:43 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> They are more comparable to SMIv2 descriptors for out purposes, >> and SMIv2 has proven to be quite inter-operable. >> >> Please provide at least ONE use-case demonstrating that >> adopting the same guideline as SMIv2 will cause some actual >> problem in an actual network somewhere. > > rfc 2578 says: > > For all descriptors appearing in an information module, the > descriptor shall be unique and mnemonic, and shall not exceed 64 > characters in length. > > Assuming "shall not" means "SHALL NOT" as in rfc 2119, this would > correspond to your alternative (2), i.e. a fixed max lentgh. Noone > has claimed that this would be non-interoperable. We have claimed > that the current text is. > >> I realize that in theory somebody could want a 6 billion character >> identifier, but I don't this is a real problem the IETF needs to solve. > > Do you think anyone will ever want 6 billion nested levels in the > hierarchy? 64 levels? 32? Should we limit the nest level because of > this? > > Stop answering my question with irrelevant questions. Several people have offered reasons why supporting infinite length descriptors are a memory, tools compatibility, and/or implementation burden. The SMIv2 rule is more strict than YANG, and it has never caused any problem at all. You have not demonstrated that the "at least 63" rule will cause any problems whatsoever. If you really want to use large descriptors in your data models, you can do it. Several people agree there is a need to force implementations to support at least 63 chars. IMO, nobody agrees that forcing the agent to support infinity is needed. > /martin > > Andy From mbj@tail-f.com Wed Apr 1 04:08:21 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043F93A67F3 for ; Wed, 1 Apr 2009 04:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hQVSziTk6rQ for ; Wed, 1 Apr 2009 04:08:20 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D71D83A677C for ; Wed, 1 Apr 2009 04:08:19 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 9AF9676C50C; Wed, 1 Apr 2009 13:09:19 +0200 (CEST) Date: Wed, 01 Apr 2009 13:09:14 +0200 (CEST) Message-Id: <20090401.130914.53766637.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49D347B5.1080608@netconfcentral.com> References: <49D3440E.3070305@netconfcentral.com> <20090401.124623.107717663.mbj@tail-f.com> <49D347B5.1080608@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 11:08:21 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> They are more comparable to SMIv2 descriptors for out purposes, > >> and SMIv2 has proven to be quite inter-operable. > >> > >> Please provide at least ONE use-case demonstrating that > >> adopting the same guideline as SMIv2 will cause some actual > >> problem in an actual network somewhere. > > rfc 2578 says: > > For all descriptors appearing in an information module, the > > descriptor shall be unique and mnemonic, and shall not exceed 64 > > characters in length. > > Assuming "shall not" means "SHALL NOT" as in rfc 2119, this would > > correspond to your alternative (2), i.e. a fixed max lentgh. Noone > > has claimed that this would be non-interoperable. We have claimed > > that the current text is. > > > >> I realize that in theory somebody could want a 6 billion character > >> identifier, but I don't this is a real problem the IETF needs to solve. > > Do you think anyone will ever want 6 billion nested levels in the > > hierarchy? 64 levels? 32? Should we limit the nest level because of > > this? > > > > Stop answering my question with irrelevant questions. I'm sorry, but you asked one question (a use-case for when SMIv2 rules lead to interoperability), and I replied to that. > Several people have offered reasons why supporting infinite length > descriptors are a memory, tools compatibility, and/or implementation burden. [re-reading this thread] I cannot find those reasons from "several people" in this thread. > The SMIv2 rule is more strict than YANG, and it has never > caused any problem at all. Which is fine. As I have stated earlier, I prefer the SMIv2 rule before the current text. > You have not demonstrated that the "at least 63" rule > will cause any problems whatsoever. See e.g. Phil's message http://www.ietf.org/mail-archive/web/netmod/current/msg02317.html. I think we have reached an end in this discussion. Maybe the chairs can see if there's consensus to be found in this thread? /martin From andy@netconfcentral.com Wed Apr 1 04:19:03 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E2383A6B20 for ; Wed, 1 Apr 2009 04:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phnUHJg6wWK7 for ; Wed, 1 Apr 2009 04:19:02 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 8C72F3A68EE for ; Wed, 1 Apr 2009 04:19:02 -0700 (PDT) Received: (qmail 81666 invoked from network); 1 Apr 2009 11:20:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 1 Apr 2009 11:20:02 -0000 X-YMail-OSG: mA0ZJV0VM1nvvGhcNr.ogH7OTpwjTPW.Pu4b_jhsC32KNtfSchPGMaGE1BizTQEWvGtSFKOqNdBgCU5tZ_60VcbAwhZRuDUJvdfhbK5oaQmBB0rzGE.4UZ9butORZvl92cxTMAkagjTvbuxMv8r_41j7uKQQftBwoO3J5pgPuFBPOjBOIZhSyV.pUThQuxNVmSxVwcskNRsicXNLcXNwCUz5lA2LYcoeVETeq2tsVjPjEB3LTxdBWy4zf6rr8o.yREOIXlsxwtAoR_GXI6eg82FzLkKGgrBvULnvb0sAeFlEsGw6 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D34DDF.3020701@netconfcentral.com> Date: Wed, 01 Apr 2009 04:19:59 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <49D3440E.3070305@netconfcentral.com> <20090401.124623.107717663.mbj@tail-f.com> <49D347B5.1080608@netconfcentral.com> <20090401.130914.53766637.mbj@tail-f.com> In-Reply-To: <20090401.130914.53766637.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 11:19:03 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: ... >> You have not demonstrated that the "at least 63" rule >> will cause any problems whatsoever. > > See e.g. Phil's message > http://www.ietf.org/mail-archive/web/netmod/current/msg02317.html. > I do not accept the premise of Phil's mail that anybody wants to use super-long descriptors. It does not matter if every toolkit supports it unless the IETF agrees it is a MUST instead of a SHOULD or MAY. There is no reason to make it a MUST. If the limit of 63 is too short then suggest a higher number. How about 1023? That is fine with me too. But nobody has an actual use-case for anything above 63. Pick a positive finite number, because infinite length strings are hard to store on small embedded devices ;-) > > I think we have reached an end in this discussion. Maybe the chairs > can see if there's consensus to be found in this thread? > > > /martin > > Andy From lhotka@cesnet.cz Wed Apr 1 04:31:53 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 414923A6A69 for ; Wed, 1 Apr 2009 04:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.367 X-Spam-Level: X-Spam-Status: No, score=0.367 tagged_above=-999 required=5 tests=[AWL=-0.983, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q52PtGXOgrxJ for ; Wed, 1 Apr 2009 04:31:52 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7EB653A6A09 for ; Wed, 1 Apr 2009 04:31:52 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id B38F3D800C8 for ; Wed, 1 Apr 2009 13:32:51 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <49D347B5.1080608@netconfcentral.com> References: <49D30D34.7040709@netconfcentral.com> <20090401.101549.19604411.mbj@tail-f.com> <49D3440E.3070305@netconfcentral.com> <20090401.124623.107717663.mbj@tail-f.com> <49D347B5.1080608@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 01 Apr 2009 13:32:55 +0200 Message-Id: <1238585575.27888.97.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 11:31:53 -0000 Andy Bierman píše v St 01. 04. 2009 v 03:53 -0700: > > Stop answering my question with irrelevant questions. > Several people have offered reasons why supporting infinite length > descriptors are a memory, tools compatibility, and/or implementation burden. Nobody wants to support infinite length, but somebody might want an identifier with 64 characters, which is considerably less than infinity. On the other hand, allocating 64 bytes for every identifier can be waste of memory, too. BTW, one of the main virtues of the new GNU utilities over the old Unix ones is the absence of such hard limits, and they all run on my pocket devices. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Wed Apr 1 05:26:19 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CBE028C1DF for ; Wed, 1 Apr 2009 05:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIU5Eqly0FlQ for ; Wed, 1 Apr 2009 05:26:18 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id F16D328DE40 for ; Wed, 1 Apr 2009 05:08:47 -0700 (PDT) Received: (qmail 93742 invoked from network); 1 Apr 2009 12:09:48 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 1 Apr 2009 12:09:47 -0000 X-YMail-OSG: CzTSBN0VM1lbNzN5wX1.FjOjpZGjZT3zKJVn2Wyet7cWhHpWRxkQlBSRBsKdTIp3thH__pM_38HqKWqOiCh7abxGh0T3VdsAd97H1wTr6xy_DLpdUFC3cngBFXBMNsCpxPbMQ8WVR.pMcsE.Tql.a5ZQ9eYpK0lm2RJJZl8YvYCFf9p0bufk61k0jiRz3OEGvmr.14TAJZJlGecZHaqIVtiC37fpLhNgciBe_.AtQNM70JLoiprhtLhaaLiAh_Av0k1RVUnuQbHPJi17 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D3598A.5040107@netconfcentral.com> Date: Wed, 01 Apr 2009 05:09:46 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <49D3440E.3070305@netconfcentral.com> <20090401.124623.107717663.mbj@tail-f.com> <49D347B5.1080608@netconfcentral.com> <20090401.130914.53766637.mbj@tail-f.com> In-Reply-To: <20090401.130914.53766637.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 12:26:19 -0000 Martin Bjorklund wrote: >.... > > I think we have reached an end in this discussion. Maybe the chairs > can see if there's consensus to be found in this thread? > My only strong objection is to 'infinity' or 'unspecified' as the minimum limit. I have no problem with changing the current text to "MUST be between 1 and 63 characters". I have no problem with picking a higher value than 63, if that is considered too short. > > /martin > > Andy From reid@snmp.com Wed Apr 1 06:50:20 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D2143A6CA5 for ; Wed, 1 Apr 2009 06:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pICMaExymbaV for ; Wed, 1 Apr 2009 06:50:19 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 616573A6BA4 for ; Wed, 1 Apr 2009 06:50:19 -0700 (PDT) Received: from fileserver.snmp.com (fileserver.snmp.com [192.147.142.16]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id JAA24501; Wed, 1 Apr 2009 09:51:17 -0400 (EDT) Received: from LOCALHOST.snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by fileserver.snmp.com (8.9.3/snmpclient.mc-990525) with SMTP id JAA13393; Wed, 1 Apr 2009 09:51:16 -0400 (EDT) Message-Id: <200904011351.JAA13393@fileserver.snmp.com> X-Authentication-Warning: fileserver.snmp.com: LOCALHOST.snmp.com [127.0.0.1] didn't use HELO protocol To: Andy Bierman From: David Reid In-reply-to: Your message of Sat, 28 Mar 2009 18:25:57 -0700. <49CECE25.5000603@netconfcentral.com> Date: Wed, 01 Apr 2009 09:51:16 -0400 Sender: reid@snmp.com Cc: NETMOD Working Group Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 01 Apr 2009 13:50:20 -0000 > Hi, > > There seems to be 3 options wrt/ identifier length > in the YANG language: > > > 1) 1 .. infinity (no rule at all) > 2) 1 .. N (MUST for every module: > "identifiers MUST be 1 to N chars long") > 3) 1 .. N (MUST only for standard modules: > current text: "tools MUST accept 1 to N chars") > > Which do you prefer and why? I prefer 2, with a value for N of 64, because my code generator can't support infinite lengths and because I have never seen a problem with the SMI 64 limit. I'd be happy copying the text exactly from rfc 2578. -David Reid From moulton@snmp.com Wed Apr 1 07:16:38 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACD073A6888 for ; Wed, 1 Apr 2009 07:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vldvK3mD7zWF for ; Wed, 1 Apr 2009 07:16:37 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 6E7883A69EC for ; Wed, 1 Apr 2009 07:16:37 -0700 (PDT) Received: from ws4.snmp.com (ws4.snmp.com [192.147.142.78]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA26562 for ; Wed, 1 Apr 2009 10:17:37 -0400 (EDT) Received: from ws4.snmp.com (localhost.localdomain [127.0.0.1]) by ws4.snmp.com (8.13.1/8.13.1) with ESMTP id n31EHat9005610 for ; Wed, 1 Apr 2009 10:17:37 -0400 Message-Id: <200904011417.n31EHat9005610@ws4.snmp.com> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.1-RC3 To: NETMOD Working Group In-reply-to: <49CECE25.5000603@netconfcentral.com> References: <49CECE25.5000603@netconfcentral.com> Comments: In-reply-to Andy Bierman message dated "Sat, 28 Mar 2009 18:25:57 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Apr 2009 10:17:36 -0400 From: Steve Moulton Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 14:16:38 -0000 On Saturday, March 28 2009, Andy Bierman wrote: > Hi, > > There seems to be 3 options wrt/ identifier length > in the YANG language: > > > 1) 1 .. infinity (no rule at all) > 2) 1 .. N (MUST for every module: > "identifiers MUST be 1 to N chars long") > 3) 1 .. N (MUST only for standard modules: > current text: "tools MUST accept 1 to N chars") > > Which do you prefer and why? > > If the result is (2) or (3), then the WG needs to pick a value for N, > which will hopefully be 63. I'd prefer 2 (though I'd kinda prefer 64 but won't refuse the bit at 63). Either of these is adequately long to generate unique leaf node identifiers, and for those of us who do source code tools, will make life across various development environments easier. - Steve --- Steve Moulton SNMP Research, Inc voice: +1 865 573 1434 Sr Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 moulton at snmp.com Knoxville, TN 37920-9716 USA http://www.snmp.com From andy@netconfcentral.com Wed Apr 1 09:49:24 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA9673A69EB for ; Wed, 1 Apr 2009 09:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.586 X-Spam-Level: X-Spam-Status: No, score=-1.586 tagged_above=-999 required=5 tests=[AWL=-0.476, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjRJeITrTwKc for ; Wed, 1 Apr 2009 09:49:24 -0700 (PDT) Received: from n15a.bullet.mail.mud.yahoo.com (n15a.bullet.mail.mud.yahoo.com [68.142.207.125]) by core3.amsl.com (Postfix) with SMTP id 1C35C3A6842 for ; Wed, 1 Apr 2009 09:49:24 -0700 (PDT) Received: from [68.142.194.244] by n15.bullet.mail.mud.yahoo.com with NNFMP; 01 Apr 2009 16:50:24 -0000 Received: from [68.142.201.245] by t2.bullet.mud.yahoo.com with NNFMP; 01 Apr 2009 16:50:24 -0000 Received: from [127.0.0.1] by omp406.mail.mud.yahoo.com with NNFMP; 01 Apr 2009 16:50:24 -0000 X-Yahoo-Newman-Id: 569908.65300.bm@omp406.mail.mud.yahoo.com Received: (qmail 14006 invoked from network); 1 Apr 2009 16:50:24 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 1 Apr 2009 16:50:23 -0000 X-YMail-OSG: OhDBvY4VM1l1QKRNIxKpIt.YN1i1e3RR5lfpWgxCrbdadJmF0uCqEa5p73TQVUudK6qWMRMvVYqYGNAgwwnW.W72MwbzTLVM3_E3WMX5CuFFZ1OzSq4ZsdfRYVEymobvBXhNwUFoZU1BBhkFBbuSJ5S6neSTvLmzEqlnW9Ai8PLwNPmpWpAU.4qGi7HKYHEW1DS7l3W.H8VsK3PTP_lvxHrE4d4TC7U3H75U4CcJ.yLIK.MVKJFraUtPDcTIjKUpxpzu7LH5gv3vERw7 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D39B4D.7080402@netconfcentral.com> Date: Wed, 01 Apr 2009 09:50:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ladislav Lhotka References: <49D30D34.7040709@netconfcentral.com> <20090401.101549.19604411.mbj@tail-f.com> <49D3440E.3070305@netconfcentral.com> <20090401.124623.107717663.mbj@tail-f.com> <49D347B5.1080608@netconfcentral.com> <1238585575.27888.97.camel@missotis> In-Reply-To: <1238585575.27888.97.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 16:49:25 -0000 Ladislav Lhotka wrote: ..... > BTW, one of the main virtues of the new GNU utilities over the old Unix > ones is the absence of such hard limits, and they all run on my pocket > devices. > really? they invented a malloc() function that never fails?! I wish you told me sooner, 'cause I just wasted $48 on memory sticks recently, upgrading a couple servers. > Lada > Andy From reid@snmp.com Wed Apr 1 11:09:38 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7D693A67F7 for ; Wed, 1 Apr 2009 11:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u99bg+mR39EC for ; Wed, 1 Apr 2009 11:09:37 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id A4C833A67E3 for ; Wed, 1 Apr 2009 11:09:37 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id OAA13408 for ; Wed, 1 Apr 2009 14:10:37 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id OAA04716 for ; Wed, 1 Apr 2009 14:10:36 -0400 (EDT) Message-Id: <200904011810.OAA04716@adminfs.snmp.com> To: netmod@ietf.org Date: Wed, 01 Apr 2009 14:10:36 -0400 From: David Reid Subject: [netmod] SMIv2 to YANG mapping: OBJECT-IDENTITY X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 18:09:38 -0000 I'd like to start some discussion on SMIv2 to YANG mapping. Several of us have implementations which are very similar, but not exactly the same. There are also several unresolved issues in my implementation (and probably everyone else). Juergen published a document on the subject (draft-schoenw-netmod-smi-yang-00.txt), which is a good place to start the discussion. The first topic in the Open Issues section of Juergen's document is: > o Need to add support for the translation of OBJECT-IDENTITY macro > invocations to YANG identity statements. The biggest problem I'm having with OBJECT-IDENTITY is knowing when to map a SYNTAX clause of a MIB object with a SYNTAX of OBJECT IDENTIFIER to a YANG identityref. For example, RFC 3413 defines: snmpTargetAddrTDomain OBJECT-TYPE SYNTAX TDomain <--- note: this resolves to an OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the transport type of the address contained in the snmpTargetAddrTAddress object." ::= { snmpTargetAddrEntry 2 } Possible values for snmpTargetAddrTDomain are things like snmpUDPDomain from RFC 3417: snmpUDPDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP over UDP over IPv4 transport domain. The corresponding transport address is of type SnmpUDPAddress." ::= { snmpDomains 1 } I want to map snmpUDPDomain to a YANG identity and map snmpTargetAddrTDomain to a YANG leaf with type identityref. In this case, I could treat the TDomain textual convention special, but in general, the syntax could have been OBJECT IDENTIFIER or a vendor defined textual convention. So I don't know when to map OBJECT IDENTIFIER to identityref and when to map it to something else, like object-identifier. Of course, if I read the description clause I can figure it out. But I want my tool to work automatically. -David Reid From reid@snmp.com Wed Apr 1 11:17:02 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 676683A67F7 for ; Wed, 1 Apr 2009 11:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuLYOqRJvJBo for ; Wed, 1 Apr 2009 11:17:01 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 75A9D3A6911 for ; Wed, 1 Apr 2009 11:17:01 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id OAA13831 for ; Wed, 1 Apr 2009 14:18:01 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id OAA04826 for ; Wed, 1 Apr 2009 14:18:01 -0400 (EDT) Message-Id: <200904011818.OAA04826@adminfs.snmp.com> To: netmod@ietf.org Date: Wed, 01 Apr 2009 14:18:00 -0400 From: David Reid Subject: [netmod] SMIv2 to YANG mapping: OCTET STRING X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 18:17:02 -0000 When converting an SMIv2 OCTET STRING to YANG, should the YANG type be string or binary? Juergen has a clever solution: if the OCTET STRING has a DISPLAY-HINT, map to string, otherwise, map to binary. The only problem I have with that approach is that it is legal to add a DISPLAY-HINTS clause when revising a MIB module, but that would cause the YANG type to change, which is not a legal revision. Here are some possibilities. None of them are great. Hopefully, someone else will have a better idea: 1. If it has DISPLAY-HINTS, use string, otherwise, use binary. 2. Always use binary 3. Use a union: type union { type string; type binary; } 4. Require a human to read the MIB and decide since it is usually obvious from the description clause (yuk) -David Reid From andy@netconfcentral.com Wed Apr 1 12:13:01 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1153A6AB0 for ; Wed, 1 Apr 2009 12:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GA68yeBwnoyb for ; Wed, 1 Apr 2009 12:13:00 -0700 (PDT) Received: from n79.bullet.mail.sp1.yahoo.com (n79.bullet.mail.sp1.yahoo.com [98.136.44.39]) by core3.amsl.com (Postfix) with SMTP id 83E4D3A68C2 for ; Wed, 1 Apr 2009 12:13:00 -0700 (PDT) Received: from [216.252.122.219] by n79.bullet.mail.sp1.yahoo.com with NNFMP; 01 Apr 2009 19:14:01 -0000 Received: from [68.142.200.227] by t4.bullet.sp1.yahoo.com with NNFMP; 01 Apr 2009 19:14:01 -0000 Received: from [68.142.201.66] by t8.bullet.mud.yahoo.com with NNFMP; 01 Apr 2009 19:14:01 -0000 Received: from [127.0.0.1] by omp418.mail.mud.yahoo.com with NNFMP; 01 Apr 2009 19:14:01 -0000 X-Yahoo-Newman-Id: 144958.56604.bm@omp418.mail.mud.yahoo.com Received: (qmail 7910 invoked from network); 1 Apr 2009 19:14:00 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 1 Apr 2009 19:14:00 -0000 X-YMail-OSG: xOEPoQ4VM1mVJISYSN3pMAy8SiPMRGCWvhESwsILlJ51fyAfb0ZO5vFOae5ig0OSknyySJ.YCyeD1k0wULWvTvAdJRHJwvdPGR23Wzo_s8auI2q7weX5Rgu_Y8.SXQaDpuSXa_L4dL9aNexDxAiHgxXdO2X9SFGbkI674gTDPqZngcrNoCodz_E1oVvLsk250avzGcZZkOewLyF3UsA.JK.StBkXQxGyg3R92yq.oEwioR_HEMJCAQJ6uoVCdLB4EopVmykN0g8PyC3tcoLbSksyU.xZK17_x23ywPq6vpjmP6cT91Fr.zV4j.9rS7oBmPS9Inh4muLOow-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D3BCF6.5070309@netconfcentral.com> Date: Wed, 01 Apr 2009 12:13:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Steve Moulton References: <49CECE25.5000603@netconfcentral.com> <200904011417.n31EHat9005610@ws4.snmp.com> In-Reply-To: <200904011417.n31EHat9005610@ws4.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 19:13:01 -0000 Steve Moulton wrote: > On Saturday, March 28 2009, Andy Bierman wrote: > >> Hi, >> >> There seems to be 3 options wrt/ identifier length >> in the YANG language: >> >> >> 1) 1 .. infinity (no rule at all) >> 2) 1 .. N (MUST for every module: >> "identifiers MUST be 1 to N chars long") >> 3) 1 .. N (MUST only for standard modules: >> current text: "tools MUST accept 1 to N chars") >> >> Which do you prefer and why? >> >> If the result is (2) or (3), then the WG needs to pick a value for N, >> which will hopefully be 63. > > I'd prefer 2 (though I'd kinda prefer 64 but won't refuse the bit at 63). SMIv2 translation is the best (and only valid) use-case for changing the current text. It is supported in the WG charter. I like the idea of cut-and-pasting the corresponding text from SMIv2. MUST be 1 to 64, and recommend 1 to 32. I think that solves the concerns about somebody ignoring the "identifier over 63 chars" warnings and a module that works on 1 toolset stops working (because the same vendor decides to change it or another vendor uses a different limit.) > Either of these is adequately long to generate unique leaf node identifiers, > and for those of us who do source code tools, will make life across > various development environments easier. > > - Steve Andy From reid@snmp.com Wed Apr 1 12:29:30 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FC073A6911 for ; Wed, 1 Apr 2009 12:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsqUFxZRxQRw for ; Wed, 1 Apr 2009 12:29:29 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 8F2023A6829 for ; Wed, 1 Apr 2009 12:29:29 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id PAA19512 for ; Wed, 1 Apr 2009 15:30:29 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id PAA07624 for ; Wed, 1 Apr 2009 15:30:29 -0400 (EDT) Message-Id: <200904011930.PAA07624@adminfs.snmp.com> To: netmod@ietf.org Date: Wed, 01 Apr 2009 15:30:28 -0400 From: David Reid Subject: [netmod] question about unions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 19:29:30 -0000 If I have the following union: leaf foo { type union { type int32; type string; } } and I get the following data on the wire: 10 How do I know if that is the number 10 or the string "10"? Do I need a discriminator in my data model if I can't tell from the context? -David Reid From andy@netconfcentral.com Wed Apr 1 12:50:27 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 285363A6AA5 for ; Wed, 1 Apr 2009 12:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0Br4R5qmvlf for ; Wed, 1 Apr 2009 12:50:26 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id 7E72E3A6A09 for ; Wed, 1 Apr 2009 12:50:26 -0700 (PDT) Received: (qmail 60522 invoked from network); 1 Apr 2009 19:51:27 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 1 Apr 2009 19:51:26 -0000 X-YMail-OSG: OZ55HH0VM1kXMR8sEmx81v9iSjLa5iG1EFoT5djFDhY4bSLMvuzz6Z9cPDQsS7._ZhsMi6C78Gv6rAg.bTYkbPTXT1ULIEyWDThLl8qyTAjHUT1BO6UMrtelgLwXTbJ5drtEtJ1n2vXaXQ5GOGMD_FvQMWkqXKzwDwMdiFvkfVRiWw2ubFAKaRlDV_WnsP5n5FxL0vgorYOLSINufjEXfugvN9_v4z8TdY36RZaT7stDSOOCV3RHPPo2rYSgQCeWmhqGZnuiU_uXQzRP X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D3C5BC.5090405@netconfcentral.com> Date: Wed, 01 Apr 2009 12:51:24 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Reid References: <200904011930.PAA07624@adminfs.snmp.com> In-Reply-To: <200904011930.PAA07624@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] question about unions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 19:50:27 -0000 David Reid wrote: > If I have the following union: > > leaf foo { > type union { > type int32; > type string; > } > } > > and I get the following data on the wire: > > 10 > > How do I know if that is the number 10 or the string "10"? > Do I need a discriminator in my data model if I can't tell from the context? > It is really easy to implement. You test the string "10" as a valid value for each typedef in the union (recurse for nested unions). The first typedef to accept the string-to-whatever conversion 'wins'. They are evaluated in schema order. You probably want to save the actual builtin type that won, not just 'union'. > -David Reid Andy From andy@netconfcentral.com Wed Apr 1 12:59:19 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F2893A6B8F for ; Wed, 1 Apr 2009 12:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4e8phj5ItG8O for ; Wed, 1 Apr 2009 12:59:18 -0700 (PDT) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id BF3CE3A6A09 for ; Wed, 1 Apr 2009 12:59:18 -0700 (PDT) Received: (qmail 90887 invoked from network); 1 Apr 2009 20:00:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 1 Apr 2009 20:00:19 -0000 X-YMail-OSG: FGWrpBsVM1mniGGbh4uVrn75Ct13jiChH3u.nutVodbZSZvpjDQk6EoEejj0JT71B1m5urYep.o._zzPkcTpxCHHSOm65t3zu.Kt9kzjCIqk.tt2MH_0b51IYFmCLxBhW8m9z105q2vV1FWkjmt25Hl86mEAZyUZVT1Vy4xFEXRlQ4LQQdrkcjIkKB63WBQH_EApjZAqk5ti_rz.SRwYIIpqR7ubjxBa8wj55Z0Kj6LPXFJdQjI8RUuEoyB9KGyW81tmRMVbUTkyU0ji5vCxvxLUxjalAB059pxmy4psW_zo7dq6 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D3C7D2.3070006@netconfcentral.com> Date: Wed, 01 Apr 2009 13:00:18 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Reid References: <200904011810.OAA04716@adminfs.snmp.com> In-Reply-To: <200904011810.OAA04716@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] SMIv2 to YANG mapping: OBJECT-IDENTITY X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 19:59:19 -0000 David Reid wrote: > I'd like to start some discussion on SMIv2 to YANG mapping. Several of > us have implementations which are very similar, but not exactly the > same. There are also several unresolved issues in my implementation > (and probably everyone else). Juergen published a document on the subject > (draft-schoenw-netmod-smi-yang-00.txt), which is a good place to start > the discussion. The first topic in the Open Issues section of Juergen's > document is: > >> o Need to add support for the translation of OBJECT-IDENTITY macro >> invocations to YANG identity statements. > Translate type OBJECT IDENTIFIER and all the possible registration OIDs as identities. It is not exact, because SMIv2 OID is not restricted like YANG identityref. But you cannot automatically determine the 'base' can you? So you are stuck making one base for all SMIv2 OIDs, e.g.: typedef RegistrationOid { type identityref { base SmiV2OidBase; } } identity SmiV2OidBase { description "Base for all SMIv2 OBJECT-IDENTITY definitions."; } identity snmpUDPDomain { base SmiV2OidBase; } leaf snmpTargetAddrTDomain { type RegistrationOid; } Andy > The biggest problem I'm having with OBJECT-IDENTITY is knowing when to map > a SYNTAX clause of a MIB object with a SYNTAX of OBJECT IDENTIFIER to > a YANG identityref. > > For example, RFC 3413 defines: > > snmpTargetAddrTDomain OBJECT-TYPE > SYNTAX TDomain <--- note: this resolves to an OBJECT IDENTIFIER > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This object indicates the transport type of the address > contained in the snmpTargetAddrTAddress object." > ::= { snmpTargetAddrEntry 2 } > > > Possible values for snmpTargetAddrTDomain are things like snmpUDPDomain from > RFC 3417: > > snmpUDPDomain OBJECT-IDENTITY > STATUS current > DESCRIPTION > "The SNMP over UDP over IPv4 transport domain. > The corresponding transport address is of type > SnmpUDPAddress." > ::= { snmpDomains 1 } > > > I want to map snmpUDPDomain to a YANG identity and map snmpTargetAddrTDomain > to a YANG leaf with type identityref. In this case, I could treat the TDomain > textual convention special, but in general, the syntax could have been > OBJECT IDENTIFIER or a vendor defined textual convention. So I don't know when > to map OBJECT IDENTIFIER to identityref and when to map it to something else, > like object-identifier. Of course, if I read the description clause I can > figure it out. But I want my tool to work automatically. > > -David Reid > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > From reid@snmp.com Wed Apr 1 13:09:43 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B0EF28C144 for ; Wed, 1 Apr 2009 13:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7yELt87aMY1 for ; Wed, 1 Apr 2009 13:09:42 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id EB7A028C0CE for ; Wed, 1 Apr 2009 13:08:42 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id QAA22430; Wed, 1 Apr 2009 16:09:42 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id QAA08056; Wed, 1 Apr 2009 16:09:42 -0400 (EDT) Message-Id: <200904012009.QAA08056@adminfs.snmp.com> To: Andy Bierman From: David Reid In-reply-to: Your message of Wed, 01 Apr 2009 12:51:24 -0700. <49D3C5BC.5090405@netconfcentral.com> Date: Wed, 01 Apr 2009 16:09:42 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] question about unions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 01 Apr 2009 20:09:43 -0000 > > If I have the following union: > > > > leaf foo { > > type union { > > type int32; > > type string; > > } > > } > > > > and I get the following data on the wire: > > > > 10 > > > > How do I know if that is the number 10 or the string "10"? > > Do I need a discriminator in my data model if I can't tell from the context? > > > > It is really easy to implement. > You test the string "10" as a valid value for > each typedef in the union (recurse for nested unions). > The first typedef to accept the string-to-whatever conversion 'wins'. > They are evaluated in schema order. You probably want to save > the actual builtin type that won, not just 'union'. If I receive 010 in edit-config, is that a string or int32. Do I return 10 or 010 in a subsequent get-config? -David Reid From andy@netconfcentral.com Wed Apr 1 13:15:23 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9CF83A6C06 for ; Wed, 1 Apr 2009 13:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.586 X-Spam-Level: X-Spam-Status: No, score=-1.586 tagged_above=-999 required=5 tests=[AWL=-0.476, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2DwbuXae9sV for ; Wed, 1 Apr 2009 13:15:23 -0700 (PDT) Received: from n22a.bullet.mail.mud.yahoo.com (n22a.bullet.mail.mud.yahoo.com [68.142.207.188]) by core3.amsl.com (Postfix) with SMTP id 0438F3A6BEE for ; Wed, 1 Apr 2009 13:15:22 -0700 (PDT) Received: from [209.191.108.96] by n22.bullet.mail.mud.yahoo.com with NNFMP; 01 Apr 2009 20:16:23 -0000 Received: from [68.142.201.242] by t3.bullet.mud.yahoo.com with NNFMP; 01 Apr 2009 20:16:23 -0000 Received: from [127.0.0.1] by omp403.mail.mud.yahoo.com with NNFMP; 01 Apr 2009 20:16:23 -0000 X-Yahoo-Newman-Id: 454609.11362.bm@omp403.mail.mud.yahoo.com Received: (qmail 32024 invoked from network); 1 Apr 2009 20:16:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp108.sbc.mail.sp1.yahoo.com with SMTP; 1 Apr 2009 20:16:22 -0000 X-YMail-OSG: QFdnq_IVM1mUITZgsXpMMvACI.JJ8HzoD0j7.xOLdGpdCo8u5qUjpyqzBMcVlsLmyHhAVuxzLNIj3QOx3vZSNi3LRIyD1FrTzk8A3Ucblz293ztbpH8l1ACjZrgJejJy9DXN40R7ZBNPqg_XZwz8lZysDgOZihA.NR_XNoouvpNr7sdvONLG40MjBuIyJnoFDoypFAxC2CSRF5z.7n7tVo_VYHJWM237449S0WmfWWxBBg.7ufYMrjKaUuPHPi4rQ_H9T6ctFLUSKHwT X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D3CB94.2080508@netconfcentral.com> Date: Wed, 01 Apr 2009 13:16:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] namespace URI length X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 20:15:23 -0000 Hi, RFC 2396 is silent about URI length (as one would expect). RFC 2068, sec. 3.2.1 (HTTP 1.1) says: Note: Servers should be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations may not properly support these lengths. Clearly the same issue exists for namespace URI as identifier length, only worse, because a tool is allowed to accept 1 char URIs and be considered compliant. YANG writers provide the URI value directly, and they need to know every compiler will always accept (or reject) a given length URI. IMO, "MUST support 1 to 1024 characters" should be sufficient. Andy From reid@snmp.com Wed Apr 1 13:16:10 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFDAA3A6C11 for ; Wed, 1 Apr 2009 13:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBiCpbWUu7fB for ; Wed, 1 Apr 2009 13:16:10 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id BC1193A6C06 for ; Wed, 1 Apr 2009 13:16:09 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id QAA23720; Wed, 1 Apr 2009 16:17:10 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id QAA13034; Wed, 1 Apr 2009 16:17:09 -0400 (EDT) Message-Id: <200904012017.QAA13034@adminfs.snmp.com> To: Andy Bierman From: David Reid In-reply-to: Your message of Wed, 01 Apr 2009 13:00:18 -0700. <49D3C7D2.3070006@netconfcentral.com> Date: Wed, 01 Apr 2009 16:17:09 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] SMIv2 to YANG mapping: OBJECT-IDENTITY X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 01 Apr 2009 20:16:10 -0000 > >> o Need to add support for the translation of OBJECT-IDENTITY macro > >> invocations to YANG identity statements. > > > > Translate type OBJECT IDENTIFIER and all the possible registration > OIDs as identities. It is not exact, because SMIv2 OID is not > restricted like YANG identityref. > > But you cannot automatically determine the 'base' can you? > So you are stuck making one base for all SMIv2 OIDs, e.g.: > > typedef RegistrationOid { > type identityref { base SmiV2OidBase; } > } > > identity SmiV2OidBase { > description "Base for all SMIv2 OBJECT-IDENTITY definitions."; > } > > identity snmpUDPDomain { > base SmiV2OidBase; > } > > leaf snmpTargetAddrTDomain { > type RegistrationOid; > } > How do I know that snmpTargetAddrTDomain should be of type RegistrationOid, but snmpNotifyFilterSubtree (from the same module, RFC 3413), which also has SYNTAX OBJECT IDENTIFIER, should be a different type? It is clear from the description clause, but how does my tool know. -David Reid From andy@netconfcentral.com Wed Apr 1 13:20:15 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426013A68A7 for ; Wed, 1 Apr 2009 13:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+F+7Kdg5i4W for ; Wed, 1 Apr 2009 13:20:14 -0700 (PDT) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id 563D83A67C1 for ; Wed, 1 Apr 2009 13:20:14 -0700 (PDT) Received: from [68.142.200.226] by n17.bullet.mail.mud.yahoo.com with NNFMP; 01 Apr 2009 20:21:15 -0000 Received: from [68.142.201.67] by t7.bullet.mud.yahoo.com with NNFMP; 01 Apr 2009 20:21:15 -0000 Received: from [127.0.0.1] by omp419.mail.mud.yahoo.com with NNFMP; 01 Apr 2009 20:21:15 -0000 X-Yahoo-Newman-Id: 9822.51203.bm@omp419.mail.mud.yahoo.com Received: (qmail 24062 invoked from network); 1 Apr 2009 20:21:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 1 Apr 2009 20:21:13 -0000 X-YMail-OSG: gzGSr7MVM1m8Tp01_SA1NStVWbZJgpJxHPmt.rvEUHKIoX5roONBWXS8CMyCXHw9i2nUFj5l8mC093izw1BhKBFB_oi74TqixWnczklmKfv_X7guz7JPByaKqEb91ie.IlVSWqWGXkJF9DGZYOaFovQtgZwWswJbKVc9U4mX8T_1uN6786Djm.mSBdaU1mle999FO39Pe6p33OPkjaHf2AMod19nTKkGUXc1jHCbZI9n.ggE6qnKOBCgJukeHtqFtHCxqx5vnEO6qwug X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D3CCB8.7050806@netconfcentral.com> Date: Wed, 01 Apr 2009 13:21:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Reid References: <200904012009.QAA08056@adminfs.snmp.com> In-Reply-To: <200904012009.QAA08056@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] question about unions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 20:20:15 -0000 David Reid wrote: >>> If I have the following union: >>> >>> leaf foo { >>> type union { >>> type int32; >>> type string; >>> } >>> } >>> >>> and I get the following data on the wire: >>> >>> 10 >>> >>> How do I know if that is the number 10 or the string "10"? >>> Do I need a discriminator in my data model if I can't tell from the context? >>> >> It is really easy to implement. >> You test the string "10" as a valid value for >> each typedef in the union (recurse for nested unions). >> The first typedef to accept the string-to-whatever conversion 'wins'. >> They are evaluated in schema order. You probably want to save >> the actual builtin type that won, not just 'union'. > > If I receive 010 in edit-config, is that a string or int32. Do I > return 10 or 010 in a subsequent get-config? > int32. you return 8 in your reply because the original value was given to you in octal notation. > -David Reid > > Andy From mbj@tail-f.com Wed Apr 1 13:21:15 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18F43A685C for ; Wed, 1 Apr 2009 13:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbzghaUch2FX for ; Wed, 1 Apr 2009 13:21:14 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B4C213A67C1 for ; Wed, 1 Apr 2009 13:21:14 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 07E67616006; Wed, 1 Apr 2009 22:22:14 +0200 (CEST) Date: Wed, 01 Apr 2009 22:22:13 +0200 (CEST) Message-Id: <20090401.222213.222094337.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <200904012009.QAA08056@adminfs.snmp.com> References: <49D3C5BC.5090405@netconfcentral.com> <200904012009.QAA08056@adminfs.snmp.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] question about unions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 20:21:15 -0000 David Reid wrote: > > > If I have the following union: > > > > > > leaf foo { > > > type union { > > > type int32; > > > type string; > > > } > > > } > If I receive 010 in edit-config, is that a string or > int32. Do I > return 10 or 010 in a subsequent get-config? The idea is that you match the union's member types in the order they are specified. This is consistent with XSD. Looking at the text, I realize that this description is missing. I suggest we add this in the section about unions: When a string representing a union data type is validated, the string is validated against each member type, in the order they are specified in the type statement, until a match is found. Can the text be more clear? /martin From mbj@tail-f.com Wed Apr 1 13:22:32 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8A063A6AA5 for ; Wed, 1 Apr 2009 13:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qvTe9CPw4Nw for ; Wed, 1 Apr 2009 13:22:32 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0907B3A67C1 for ; Wed, 1 Apr 2009 13:22:31 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 20F80616006; Wed, 1 Apr 2009 22:23:32 +0200 (CEST) Date: Wed, 01 Apr 2009 22:23:31 +0200 (CEST) Message-Id: <20090401.222331.114698374.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49D3CCB8.7050806@netconfcentral.com> References: <200904012009.QAA08056@adminfs.snmp.com> <49D3CCB8.7050806@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] question about unions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 20:22:32 -0000 Andy Bierman wrote: > David Reid wrote: > > If I receive 010 in edit-config, is that a string or > > int32. Do I > > return 10 or 010 in a subsequent get-config? > > > > int32. Yes. > you return 8 in your reply because the original > value was given to you in octal notation. No, the octal represention is not allowed in the XML encoding, so 010 is interpreted as 10. /martin From andy@netconfcentral.com Wed Apr 1 13:25:31 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4252F3A67C1 for ; Wed, 1 Apr 2009 13:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VYUktwj2tGh for ; Wed, 1 Apr 2009 13:25:30 -0700 (PDT) Received: from n13.bullet.mail.mud.yahoo.com (n13.bullet.mail.mud.yahoo.com [68.142.206.40]) by core3.amsl.com (Postfix) with SMTP id B0A853A6982 for ; Wed, 1 Apr 2009 13:25:29 -0700 (PDT) Received: from [209.191.108.97] by n13.bullet.mail.mud.yahoo.com with NNFMP; 01 Apr 2009 20:26:30 -0000 Received: from [68.142.201.244] by t4.bullet.mud.yahoo.com with NNFMP; 01 Apr 2009 20:26:30 -0000 Received: from [127.0.0.1] by omp405.mail.mud.yahoo.com with NNFMP; 01 Apr 2009 20:26:30 -0000 X-Yahoo-Newman-Id: 453351.65391.bm@omp405.mail.mud.yahoo.com Received: (qmail 44093 invoked from network); 1 Apr 2009 20:26:29 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp108.sbc.mail.sp1.yahoo.com with SMTP; 1 Apr 2009 20:26:29 -0000 X-YMail-OSG: R9dqL1sVM1mB8l6.VSPiwx3QsqsxdtHcW2xRE9Hhub8DGQIGxPB8gv5In9bugx.PwYqq7PTBWTHeCSFsfg6dIypvntESQv2eUUt4MOljflfEgUT1aLg5YF8AtPP2VDYnCsetUG6nB36b_FpygsCkNXOBq0HCAb7mBzXQc0_EuwC5KzzSysKS_Wz2zDatI8j22iC7yeWgufPdzVuma599yc6kC2F4ltdFyTXLyZ5Pdpp9wzfs1jTSDJ0z.FVzs0wyfvdLg7de2GQbvM_upL8ZyBJzLFUxdHp0groG8ApDd6fAqWn726imGCg8V4PvhidgynJ.Db6IgMkrmg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D3CDF3.8060502@netconfcentral.com> Date: Wed, 01 Apr 2009 13:26:27 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <200904012009.QAA08056@adminfs.snmp.com> <49D3CCB8.7050806@netconfcentral.com> <20090401.222331.114698374.mbj@tail-f.com> In-Reply-To: <20090401.222331.114698374.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] question about unions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 20:25:31 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> David Reid wrote: >>> If I receive 010 in edit-config, is that a string or >>> int32. Do I >>> return 10 or 010 in a subsequent get-config? >>> >> int32. > > Yes. > >> you return 8 in your reply because the original >> value was given to you in octal notation. > > No, the octal represention is not allowed in the XML encoding, so 010 > is interpreted as 10. > You are right. I'm sorry. Just 'default 010;' would be interpreted that way. > > /martin > > > Andy From reid@snmp.com Wed Apr 1 13:47:02 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3539C3A686E for ; Wed, 1 Apr 2009 13:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rcYEGoGra-c for ; Wed, 1 Apr 2009 13:47:01 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 3EBB23A67C1 for ; Wed, 1 Apr 2009 13:47:01 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id QAA26431; Wed, 1 Apr 2009 16:48:01 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id QAA13297; Wed, 1 Apr 2009 16:48:00 -0400 (EDT) Message-Id: <200904012048.QAA13297@adminfs.snmp.com> To: Martin Bjorklund From: David Reid In-reply-to: Your message of Wed, 01 Apr 2009 22:22:13 +0200. <20090401.222213.222094337.mbj@tail-f.com> Date: Wed, 01 Apr 2009 16:48:00 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] question about unions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 01 Apr 2009 20:47:02 -0000 > > If I receive 010 in edit-config, is that a string or > > int32. Do I > > return 10 or 010 in a subsequent get-config? > > The idea is that you match the union's member types in the order they > are specified. This is consistent with XSD. Looking at the text, I > realize that this description is missing. I suggest we add this in > the section about unions: > > When a string representing a union data type is validated, the > string is validated against each member type, in the order they are > specified in the type statement, until a match is found. That text helps considerably. I definitely agree that it should be added. Let me make sure I understand. Given the following unions: leaf foo { type union { type int32; type string; } } leaf fum { type union { type string; type int32; } } and the following values in edit-config: 010 010 A subsequent get-config would return: 10 010 -David Reid From mbj@tail-f.com Wed Apr 1 13:59:59 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E6E63A672F for ; Wed, 1 Apr 2009 13:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkMYHNrSYbJS for ; Wed, 1 Apr 2009 13:59:58 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A66DC3A6988 for ; Wed, 1 Apr 2009 13:59:58 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id B61B961600D; Wed, 1 Apr 2009 23:00:58 +0200 (CEST) Date: Wed, 01 Apr 2009 23:00:58 +0200 (CEST) Message-Id: <20090401.230058.262215951.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49D34DDF.3020701@netconfcentral.com> References: <49D347B5.1080608@netconfcentral.com> <20090401.130914.53766637.mbj@tail-f.com> <49D34DDF.3020701@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 20:59:59 -0000 Andy Bierman wrote: > If the limit of 63 is too short then suggest a higher number. > How about 1023? That is fine with me too. > > But nobody has an actual use-case for anything above 63. > Pick a positive finite number, because infinite length > strings are hard to store on small embedded devices ;-) Of course. But the point is that even with 63 bytes (or whatever fixed length) a small embedded device cannot handle an infinite number of identifiers. So should we also limit the total number of identifiers? I really do not understand this memory allocation argument. /martin From mbj@tail-f.com Wed Apr 1 14:00:31 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41F7C28C0FC for ; Wed, 1 Apr 2009 14:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.973 X-Spam-Level: X-Spam-Status: No, score=-1.973 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhb50n0i3B2J for ; Wed, 1 Apr 2009 14:00:30 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6D39528C0CE for ; Wed, 1 Apr 2009 14:00:30 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A6EA3616006; Wed, 1 Apr 2009 23:01:30 +0200 (CEST) Date: Wed, 01 Apr 2009 23:01:30 +0200 (CEST) Message-Id: <20090401.230130.01450254.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <200904012048.QAA13297@adminfs.snmp.com> References: <20090401.222213.222094337.mbj@tail-f.com> <200904012048.QAA13297@adminfs.snmp.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] question about unions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 21:00:31 -0000 David Reid wrote: > Let me make sure I understand. > > Given the following unions: > > leaf foo { > type union { > type int32; > type string; > } > } > leaf fum { > type union { > type string; > type int32; > } > } > > and the following values in edit-config: > > 010 > 010 > > A subsequent get-config would return: > > 10 > 010 Yes. /martin From j.schoenwaelder@jacobs-university.de Wed Apr 1 14:41:58 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F39EB28C16C for ; Wed, 1 Apr 2009 14:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXhUWO62GO7c for ; Wed, 1 Apr 2009 14:41:57 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id F130428C1C1 for ; Wed, 1 Apr 2009 14:41:56 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 357A1C0025; Wed, 1 Apr 2009 23:42:57 +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 BZ-ZdHGFdncU; Wed, 1 Apr 2009 23:42:56 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 00FECC001A; Wed, 1 Apr 2009 23:42:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1619AA4A231; Wed, 1 Apr 2009 23:42:39 +0200 (CEST) Date: Wed, 1 Apr 2009 23:42:38 +0200 From: Juergen Schoenwaelder To: David Reid Message-ID: <20090401214238.GA16843@elstar.local> Mail-Followup-To: David Reid , "netmod@ietf.org" References: <200904011810.OAA04716@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904011810.OAA04716@adminfs.snmp.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] SMIv2 to YANG mapping: OBJECT-IDENTITY X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2009 21:41:58 -0000 On Wed, Apr 01, 2009 at 08:10:36PM +0200, David Reid wrote: > > o Need to add support for the translation of OBJECT-IDENTITY macro > > invocations to YANG identity statements. > > The biggest problem I'm having with OBJECT-IDENTITY is knowing when to map > a SYNTAX clause of a MIB object with a SYNTAX of OBJECT IDENTIFIER to > a YANG identityref. There is likely no good answer since the SMIv2 does not distinguish how OBJECT IDENTIFIERs are used. We could perhaps special case some well known TCs but a generic solution that does the right thing on all cases likely does not exist. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Wed Apr 1 14:48:14 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2A93A6DB3 for ; Wed, 1 Apr 2009 14:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpdEDI-FJ+MP for ; Wed, 1 Apr 2009 14:48:14 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3EFED28C1DE for ; Wed, 1 Apr 2009 14:47:57 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A3CD8C0025; Wed, 1 Apr 2009 23:48:57 +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 DuxwXo8GAot1; Wed, 1 Apr 2009 23:48:56 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7CD9C001A; Wed, 1 Apr 2009 23:48:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 34E2EA4A271; Wed, 1 Apr 2009 23:48:40 +0200 (CEST) Date: Wed, 1 Apr 2009 23:48:40 +0200 From: Juergen Schoenwaelder To: David Reid Message-ID: <20090401214840.GB16843@elstar.local> Mail-Followup-To: David Reid , "netmod@ietf.org" References: <200904011818.OAA04826@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904011818.OAA04826@adminfs.snmp.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] SMIv2 to YANG mapping: OCTET STRING X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2009 21:48:14 -0000 On Wed, Apr 01, 2009 at 08:18:00PM +0200, David Reid wrote: > When converting an SMIv2 OCTET STRING to YANG, should the YANG type be string > or binary? Juergen has a clever solution: if the OCTET STRING has a > DISPLAY-HINT, map to string, otherwise, map to binary. The only problem I > have with that approach is that it is legal to add a DISPLAY-HINTS clause > when revising a MIB module, but that would cause the YANG type to change, > which is not a legal revision. Good catch. Too bad that this approach can fail... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Wed Apr 1 17:02:49 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 377F53A69A9 for ; Wed, 1 Apr 2009 17:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSXDkQTFQzbK for ; Wed, 1 Apr 2009 17:02:48 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id E13673A67D4 for ; Wed, 1 Apr 2009 17:02:44 -0700 (PDT) Received: (qmail 17934 invoked from network); 2 Apr 2009 00:03:45 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 2 Apr 2009 00:03:45 -0000 X-YMail-OSG: rlpPIqUVM1lv_WxP66f1ewI277SoKk6nqCoc4dYftMAf1ITY71e0q8QmsC6OxIsyKcnYExvjw.S9efY1fxhM.fBdjbjsKaHNdlaVq0i.9MsUq5xeYqr8FeTTj0BtrzLotQwDEHJNy2xhtzeFMgBFNCEZoRmglO20yK2uyBNZ5jFEnkgbY7Z5uRHsL.uriLWeq.WteMKtiEk.f2q7Ii.aPLgKV8XG.UR85CfIsI3zFe0D7CqkDqbhHazcuOyCHk8NufgGDtRILMoIquRircMX3SbEao_XvuQMMNlpnEOfElu4zKmMXVEyjpRyD7lVaDdYOQoaazXWAoq1sQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D400DF.6050103@netconfcentral.com> Date: Wed, 01 Apr 2009 17:03:43 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <49D347B5.1080608@netconfcentral.com> <20090401.130914.53766637.mbj@tail-f.com> <49D34DDF.3020701@netconfcentral.com> <20090401.230058.262215951.mbj@tail-f.com> In-Reply-To: <20090401.230058.262215951.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 00:02:49 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> If the limit of 63 is too short then suggest a higher number. >> How about 1023? That is fine with me too. >> >> But nobody has an actual use-case for anything above 63. >> Pick a positive finite number, because infinite length >> strings are hard to store on small embedded devices ;-) > > Of course. But the point is that even with 63 bytes (or whatever > fixed length) a small embedded device cannot handle an infinite number > of identifiers. So should we also limit the total number of > identifiers? I think a small embedded device is unlikely to have even a 1000 identifiers, let alone a billion or so. Although saving memory is the reason for some other YANG decisions, it is not the reason for this one. IMO, the only answer is, for all strings defined in a YANG file while are used in the protocol (module-name, namespace-stmt, identifier), a fixed length for all implementation MUST be specified. That way for all implementations of 'yang-version 1', these values will be the only ones allowed on any implementation. So Phil's argument is valid: - warnings are not reliable so all implementations need to support the same values But nobody wants to support huge (infinite!) strings, so the arbitrary values already in use within the industry are good arbitrary values to use in YANG. > > I really do not understand this memory allocation argument. > > I don't understand the 'put the keys first' argument, but they are about the same I think. We could all construct arbitrary examples (like 6 billion bytes in the PDU between the end of the list start-tag and the list keys), so maybe it is better to leave implementation details out of debates completely. > /martin > > Andy From kawamucho@mesh.ad.jp Wed Apr 1 17:11:52 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5613A6A86 for ; Wed, 1 Apr 2009 17:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[AWL=1.240, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nisOeqSH9eKZ for ; Wed, 1 Apr 2009 17:11:52 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by core3.amsl.com (Postfix) with ESMTP id 055713A6A28 for ; Wed, 1 Apr 2009 17:11:51 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.162]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id n320CpRg004609; Thu, 2 Apr 2009 09:12:51 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id n320CpT10706; Thu, 2 Apr 2009 09:12:51 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id n320CpPU026049; Thu, 2 Apr 2009 09:12:51 +0900 (JST) Received: from bsac29088.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id n320CoHl026154; Thu, 2 Apr 2009 09:12:50 +0900 Received: from mail.sys.biglobe.nec.co.jp (bgsx5626.sys.biglobe.nec.co.jp [10.18.151.10]) by bsac29088.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id n320Co4c011775; Thu, 2 Apr 2009 09:12:50 +0900 Received: from [127.0.0.1] (bdonet119.sys.biglobe.nec.co.jp [10.19.136.119]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id n320CopQ027789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Apr 2009 09:12:50 +0900 Message-ID: <49D40301.2040004@mesh.ad.jp> Date: Thu, 02 Apr 2009 09:12:49 +0900 From: Seiichi Kawamura User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "netmod@ietf.org" , j.schoenwaelder@jacobs-university.de References: <49D17E45.7010907@mesh.ad.jp> <20090331060020.GB13951@elstar.local> In-Reply-To: <20090331060020.GB13951@elstar.local> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] ipv6 address representation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 00:11:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Juergen > So what is your suggestion? Note that the format produced by > inet_ntop() implementations seems to differ slightly on some > platforms: Yes. I confirmed the difference of inet_ntop(), and thank you for pointing it out. My personal recommendation is, to use :: and use it to its max, use it in the former in case of a tie-breaker. That's what we see most oftenly used, and is more human friendly. But then what do I know. I'm just an operator. I do know for sure that the "preferred form" as noted on RFC4291 Sec 2.2 item 1 is almost never followed. Nobody wants to count how many zeros they have to fill in. But its still just a personal recommendation since I haven't started a discussion yet on ipv6 WGs. > What do you plan to do with your document? Has it been discussed > somewhere at the last IETF? If your plan is to write down how an I'm already asking the area directors and the chairs if this is worth discussing, an if so, which WG. I'll let you know how things turn out. Thanks Seiichi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) iD8DBQFJ1AMBcrhTYfxyMkIRAhUOAJwL7nz6dSusiHJPbQyXgFZ5yVS3uwCeMTTv 3Srpw1kZi+iJMtoLfQyC6o8= =wAUn -----END PGP SIGNATURE----- From mbj@tail-f.com Wed Apr 1 21:00:41 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401B93A685A for ; Wed, 1 Apr 2009 21:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrJCguuwsF7R for ; Wed, 1 Apr 2009 21:00:40 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 62ECE3A6AA0 for ; Wed, 1 Apr 2009 21:00:40 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 8CDFB616006; Thu, 2 Apr 2009 06:01:39 +0200 (CEST) Date: Thu, 02 Apr 2009 06:01:39 +0200 (CEST) Message-Id: <20090402.060139.186939214.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49D400DF.6050103@netconfcentral.com> References: <49D34DDF.3020701@netconfcentral.com> <20090401.230058.262215951.mbj@tail-f.com> <49D400DF.6050103@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 04:00:41 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> If the limit of 63 is too short then suggest a higher number. > >> How about 1023? That is fine with me too. > >> > >> But nobody has an actual use-case for anything above 63. > >> Pick a positive finite number, because infinite length > >> strings are hard to store on small embedded devices ;-) > > Of course. But the point is that even with 63 bytes (or whatever > > fixed length) a small embedded device cannot handle an infinite number > > of identifiers. So should we also limit the total number of > > identifiers? > > I think a small embedded device is unlikely to have even > a 1000 identifiers, let alone a billion or so. > Although saving memory is the reason for some > other YANG decisions, it is not the reason for this one. > > IMO, the only answer is, for all strings defined in a YANG file > while are used in the protocol (module-name, namespace-stmt, identifier), > a fixed length for all implementation MUST be specified. I understand that this is your proposal. But if saving memory is not the reason for this rule, then what is the reason? In an earlier email in this thread you wrote: andy> Code is generated using these descriptors. andy> andy> The memory impact from these descriptors is already andy> non-trivial at 63 chars. I assume it boils down to code generation, which also David Reid listed as the reason for having a fixed limit. > > I really do not understand this memory allocation argument. > > > > I don't understand the 'put the keys first' argument, > but they are about the same I think. The difference is that the 'put the keys' first argument *is* about saving memory, which apparently the identifier rule is not. To be even more specific, it is about saving *dynamic* memory. /martin From muenz@net.in.tum.de Thu Apr 2 01:34:01 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B82253A6A73 for ; Thu, 2 Apr 2009 01:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cvn1+Q35y-rI for ; Thu, 2 Apr 2009 01:33:57 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 7AD373A6982 for ; Thu, 2 Apr 2009 01:33:57 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 5CBC547372 for ; Thu, 2 Apr 2009 10:34:53 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 4FD0024A4 for ; Thu, 2 Apr 2009 10:34:53 +0200 (CEST) Message-ID: <49D478B0.9060402@net.in.tum.de> Date: Thu, 02 Apr 2009 10:34:56 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: netmod@ietf.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000309010807050007030606" X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 08:34:01 -0000 This is a cryptographically signed message in MIME format. --------------ms000309010807050007030606 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all, Just a small comment from an outsider and mere module author: Arguments like "we must add a restriction because we currently do not see a use-case where this restriction hurts" do not convince me. Rather, it seems to me that this might provoke a new kind of Y2K-problem in future. Valid arguments would sound like "we must make this restriction because otherwise we cannot guarantee compatibility". Regards, Gerhard > Andy Bierman wrote: >> Martin Bjorklund wrote: >> > Andy Bierman wrote: >> >> If the limit of 63 is too short then suggest a higher number. >> >> How about 1023? That is fine with me too. >> >> >> >> But nobody has an actual use-case for anything above 63. >> >> Pick a positive finite number, because infinite length >> >> strings are hard to store on small embedded devices ;-) >> > Of course. But the point is that even with 63 bytes (or whatever >> > fixed length) a small embedded device cannot handle an infinite number >> > of identifiers. So should we also limit the total number of >> > identifiers? >> >> I think a small embedded device is unlikely to have even >> a 1000 identifiers, let alone a billion or so. >> Although saving memory is the reason for some >> other YANG decisions, it is not the reason for this one. >> >> IMO, the only answer is, for all strings defined in a YANG file >> while are used in the protocol (module-name, namespace-stmt, identifier), >> a fixed length for all implementation MUST be specified. > > I understand that this is your proposal. But if saving memory is not > the reason for this rule, then what is the reason? > > In an earlier email in this thread you wrote: > > andy> Code is generated using these descriptors. > andy> > andy> The memory impact from these descriptors is already > andy> non-trivial at 63 chars. > > I assume it boils down to code generation, which also David Reid > listed as the reason for having a fixed limit. > >> > I really do not understand this memory allocation argument. >> > >> >> I don't understand the 'put the keys first' argument, >> but they are about the same I think. > > The difference is that the 'put the keys' first argument *is* about > saving memory, which apparently the identifier rule is not. To be > even more specific, it is about saving *dynamic* memory. > > > /martin --------------ms000309010807050007030606 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNDAyMDgzNDU2WjAjBgkqhkiG9w0BCQQxFgQU SOdyzpYFf/dFTIDZzzRtR5eH6+IwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBACAu4iyXf3h8osARCVcfDdSiKREwqKzdaAJjnZiItgtZUadx SMyATyKyPZAJ9/z44K7jPJ3DKerHqv1JyZFifY3L1ewGiiP60QglugIHkG4XADDCprKkWO3F CSDFMhee1GmW3uixHnKsNukxlepfdF5jrP/odoT2/SW6QTJOxIprpO/QtccNHojM60O8OUqA gJNzMxMpYNm2oyhvUA1aP502YJskkhyW0Qpdqu/pxf9Ui8oJzBi3PtslHAG40/wxJrVLqbOh 2hxUrovY8WdnP9vqvpVpdBnol9yOxQIjTrnb5G3mdoGRRTtuE4WfqTOLwz1VSVvdo5VoQ8ne hV+Q0dUAAAAAAAA= --------------ms000309010807050007030606-- From andy@netconfcentral.com Thu Apr 2 03:27:42 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3B8B3A6B51 for ; Thu, 2 Apr 2009 03:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5oe7qWhGC9L for ; Thu, 2 Apr 2009 03:27:41 -0700 (PDT) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id 360D83A6AD4 for ; Thu, 2 Apr 2009 03:27:41 -0700 (PDT) Received: from [209.191.108.97] by n17.bullet.mail.mud.yahoo.com with NNFMP; 02 Apr 2009 10:28:42 -0000 Received: from [68.142.201.68] by t4.bullet.mud.yahoo.com with NNFMP; 02 Apr 2009 10:28:42 -0000 Received: from [127.0.0.1] by omp420.mail.mud.yahoo.com with NNFMP; 02 Apr 2009 10:28:42 -0000 X-Yahoo-Newman-Id: 524633.58837.bm@omp420.mail.mud.yahoo.com Received: (qmail 76574 invoked from network); 2 Apr 2009 10:28:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 2 Apr 2009 10:28:41 -0000 X-YMail-OSG: rYCw8.0VM1lfHwhugwwLaeHWNCP1pXwX3WZNjH2flBhtMy6ziSNiX10_0SXfBUaxCOV_1sCgX3_fZc45pzUlfHLVf4Zmzg9b20X2asa2b784a_1k2RuaB7q9HQ.DdG9itP6QVQ4ucQKGLk51R5IJgjjcCQgN5TKWWz8r6_cBTXVzkVb6e9441NADyQqkOuiSksZhK1L1QHrQdHbWB_CGikqq2CayUJA4298pdAWf8js9XcxvNyekpzA0vgCYaA1ZeXBd11aRocADUXt. X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D49357.8020109@netconfcentral.com> Date: Thu, 02 Apr 2009 03:28:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Gerhard Muenz References: <49D478B0.9060402@net.in.tum.de> In-Reply-To: <49D478B0.9060402@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 10:27:42 -0000 Gerhard Muenz wrote: > Hi all, > > Just a small comment from an outsider and mere module author: > > Arguments like "we must add a restriction because we currently do not > see a use-case where this restriction hurts" do not convince me. > Rather, it seems to me that this might provoke a new kind of Y2K-problem > in future. > > Valid arguments would sound like "we must make this restriction because > otherwise we cannot guarantee compatibility". > We not only would like NETCONF/YANG to be compatible, we want it to be implementable. Simply stating that everybody MUST support infinite length strings, yet not ONE vendor says they can implement that, does not help solve any real problems. > Regards, > Gerhard Andy From andy@netconfcentral.com Thu Apr 2 03:44:35 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45DBE3A6BCB for ; Thu, 2 Apr 2009 03:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuvwXfH4NOio for ; Thu, 2 Apr 2009 03:44:34 -0700 (PDT) Received: from n27.bullet.mail.mud.yahoo.com (n27.bullet.mail.mud.yahoo.com [68.142.206.222]) by core3.amsl.com (Postfix) with SMTP id F34773A6AD4 for ; Thu, 2 Apr 2009 03:43:04 -0700 (PDT) Received: from [68.142.200.226] by n27.bullet.mail.mud.yahoo.com with NNFMP; 02 Apr 2009 10:44:06 -0000 Received: from [68.142.201.67] by t7.bullet.mud.yahoo.com with NNFMP; 02 Apr 2009 10:44:06 -0000 Received: from [127.0.0.1] by omp419.mail.mud.yahoo.com with NNFMP; 02 Apr 2009 10:44:06 -0000 X-Yahoo-Newman-Id: 169956.91231.bm@omp419.mail.mud.yahoo.com Received: (qmail 80204 invoked from network); 2 Apr 2009 10:44:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 2 Apr 2009 10:44:05 -0000 X-YMail-OSG: fDBUJwEVM1keV2emRHX0oOtK_0BmRrl6.ef1NwqqyuCHzCQ8Zp.0UOJkYSX8_B5EOqRYYAXtCTLyTeJv7P.pESU3GU2Nk1al_sLYjGbJZluCnT_mubG08Oa273hm6NgVs0Ul3pDpB5zB4NRgrJJyUDgdEBN_Z50o6kpH5dv2wOMWOiCkqpPHY12Dq2RBOXidoRAFnKk_Qdx6Iv4PmDZLtP57Y.b7Xy_Y3wsSIQSWcx0bcIafyVWg2m1Tj5Tk9oDUzPM3EqV.WGiVAckmf4.390WTmj6tR1DQ75fOM3e1BJTBAU05OA0hH9rbITfgQBtfOTXuuhn7EoReaQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D496F3.4020807@netconfcentral.com> Date: Thu, 02 Apr 2009 03:44:03 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <49D34DDF.3020701@netconfcentral.com> <20090401.230058.262215951.mbj@tail-f.com> <49D400DF.6050103@netconfcentral.com> <20090402.060139.186939214.mbj@tail-f.com> In-Reply-To: <20090402.060139.186939214.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 10:44:35 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: ..... >> I don't understand the 'put the keys first' argument, >> but they are about the same I think. > > The difference is that the 'put the keys' first argument *is* about > saving memory, which apparently the identifier rule is not. To be > even more specific, it is about saving *dynamic* memory. > I think the compatibility argument is the only one that is relevant, because the memory argument is relatively weak. Memory is memory. Whether you allocate it out of the static pool, the stack or the heap makes no difference, especially to the standards definition. IMO, an XML application that barfs on element order is kind of fragile. Forcing all YANG applications to order keys first ripples that fragility out of the agent, into the network. The amount of PDU fragment that needs to be buffered in (in reality) quite small, especially since YANG is brand new, there are no data models yet, and the problem is completely avoidable unless the key(s) come from a grouping. > > /martin > > Andy From phil@juniper.net Thu Apr 2 07:09:23 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C3A83A69DC for ; Thu, 2 Apr 2009 07:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uolh99u5q85K for ; Thu, 2 Apr 2009 07:09:22 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id D7E803A6AA6 for ; Thu, 2 Apr 2009 07:09:16 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKSdTHSFznMTjSzWl/XRvQzXYH6eYSdhLk@postini.com; Thu, 02 Apr 2009 07:10:24 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 2 Apr 2009 07:06:28 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 07:06:28 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 07:06:27 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 07:06:27 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n32E6QM10028; Thu, 2 Apr 2009 07:06:26 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n32DxFQB013254; Thu, 2 Apr 2009 13:59:15 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904021359.n32DxFQB013254@idle.juniper.net> To: Andy Bierman In-Reply-To: <49D496F3.4020807@netconfcentral.com> Date: Thu, 2 Apr 2009 09:59:15 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 Apr 2009 14:06:27.0366 (UTC) FILETIME=[36DF8C60:01C9B39C] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 14:09:23 -0000 Andy Bierman writes: >The amount of PDU fragment >that needs to be buffered in (in reality) quite small, >especially since YANG is brand new, there are no >data models yet, and the problem is completely >avoidable unless the key(s) come from a grouping. Buffering needs are small if you have small configs, but this isn't the case for me. We're hitting 10-15MB configs now and it's sure to get worse. This is my reality. The lack of published data models isn't relevant, since we want vendors to publish their existing config schema as yang modules. Hopefully the number of published models will balloon as soon as the spec is finalized. >We not only would like NETCONF/YANG to be >compatible, we want it to be implementable. >Simply stating that everybody MUST support >infinite length strings, yet not ONE vendor >says they can implement that, does not help solve >any real problems. As Lada mentioned, removing length limits from unix tools doesn't mean that these tools cannot function in a limited memory environment. Any tool is ultimately limited by available memory, but that is a distinct issue from artificially limiting individual tokens without a convincing reason. In a modern world, there's no need to limit these identifiers. If the thought is that C only allows 63 character symbols, then limiting YANG to 63 doesn't solve the problem, since there must be some sort of translation between YANG identifiers and C symbols to prevent conflicts between "leaf sleep" and sleep(), and using some sort of prefix or suffix will further reduce C's 63 limit to something even less acceptable. Fortunately modern tools (gcc) avoid this limit, allowing us to sidestep the issue. C is a good parallel, since I'm sure that K&R never envisioned C symbols like: __ZNK10__cxxabiv119__pointer_type_info15__pointer_catchEPKNS_17__pbase_type_infoEPPvj Given that I've already seen a 45 byte leaf and given that no one can predict the future needs and evolution, a 64 character limit is an unneeded CLR. Thanks, Phil (who will try to hold his tongue for longer this time) From andy@netconfcentral.com Thu Apr 2 08:21:17 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E93513A6A29 for ; Thu, 2 Apr 2009 08:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P64XBEJswsrm for ; Thu, 2 Apr 2009 08:21:17 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 218C23A686A for ; Thu, 2 Apr 2009 08:21:17 -0700 (PDT) Received: (qmail 26096 invoked from network); 2 Apr 2009 15:22:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 2 Apr 2009 15:22:18 -0000 X-YMail-OSG: pSVag3UVM1lQi7bB3zNzHP_qHw0DoiHQkL5UPYWoF2uh_JUhTHBE8_mjs_EZ90pzBgyYDpBXuLgDi1VyXT1elXzSMRwCVDxeNjo1Tp4.OUyDoNDA8KGqyvjDSb_6Lv5y1.udXMcSfDvWJW5ma2b5mKFmU26IUU6mLWBqnXwozRLbWkiCvbVnB3wwIM0.LaRTjTQIdAuZxuEY99YGnEECYUFljXZxpdCXv7EyV4q5uW.BfCoJziA0IRRynK9amp5Ogf25bT4WJjQCA_Xw X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D4D828.4070205@netconfcentral.com> Date: Thu, 02 Apr 2009 08:22:16 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200904021359.n32DxFQB013254@idle.juniper.net> In-Reply-To: <200904021359.n32DxFQB013254@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 15:21:18 -0000 Phil Shafer wrote: > Andy Bierman writes: >> The amount of PDU fragment >> that needs to be buffered in (in reality) quite small, >> especially since YANG is brand new, there are no >> data models yet, and the problem is completely >> avoidable unless the key(s) come from a grouping. > > Buffering needs are small if you have small configs, but this isn't > the case for me. We're hitting 10-15MB configs now and it's sure > to get worse. This is my reality. > > The lack of published data models isn't relevant, since we want > vendors to publish their existing config schema as yang modules. > Hopefully the number of published models will balloon as > soon as the spec is finalized. > But you control your own YANG module contents. You can put your own keys first in the YANG module. But debating the number of bytes that need to be buffered is pointless. It's just another implementation detail out of dozens that can be optimized for robustness or optimized for speed. >> We not only would like NETCONF/YANG to be >> compatible, we want it to be implementable. >> Simply stating that everybody MUST support >> infinite length strings, yet not ONE vendor >> says they can implement that, does not help solve >> any real problems. > > As Lada mentioned, removing length limits from unix tools doesn't > mean that these tools cannot function in a limited memory environment. > Any tool is ultimately limited by available memory, but that is a > distinct issue from artificially limiting individual tokens without > a convincing reason. > This does not help the IETF define a common data modeling language. If a majority of vendors had said they can support infinite length strings, then forcing everybody to support them might be reasonable. Since you are the only vendor who claims to be able to implement arbitrary length identifiers, there is not any consensus for that change in the text. I think the SMIv2 style text has the most consensus, and that will solve your concerns about every platform supporting the same limits. Everybody will support 1 - 64 chars. > In a modern world, there's no need to limit these identifiers. If > the thought is that C only allows 63 character symbols, then limiting > YANG to 63 doesn't solve the problem, since there must be some sort > of translation between YANG identifiers and C symbols to prevent > conflicts between "leaf sleep" and sleep(), and using some sort of > prefix or suffix will further reduce C's 63 limit to something even > less acceptable. Fortunately modern tools (gcc) avoid this limit, > allowing us to sidestep the issue. > > C is a good parallel, since I'm sure that K&R never envisioned C > symbols like: > > __ZNK10__cxxabiv119__pointer_type_info15__pointer_catchEPKNS_17__pbase_type_infoEPPvj > > Given that I've already seen a 45 byte leaf and given that no one can > predict the future needs and evolution, a 64 character limit is an > unneeded CLR. > > Thanks, > Phil (who will try to hold his tongue for longer this time) > > Andy From andy@netconfcentral.com Thu Apr 2 08:42:37 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8F928C1CB for ; Thu, 2 Apr 2009 08:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ui8AbAzPYkf4 for ; Thu, 2 Apr 2009 08:42:36 -0700 (PDT) Received: from n29.bullet.mail.mud.yahoo.com (n29.bullet.mail.mud.yahoo.com [68.142.207.48]) by core3.amsl.com (Postfix) with SMTP id 986CF3A6C23 for ; Thu, 2 Apr 2009 08:42:36 -0700 (PDT) Received: from [68.142.200.227] by n29.bullet.mail.mud.yahoo.com with NNFMP; 02 Apr 2009 15:43:38 -0000 Received: from [68.142.201.249] by t8.bullet.mud.yahoo.com with NNFMP; 02 Apr 2009 15:43:38 -0000 Received: from [127.0.0.1] by omp410.mail.mud.yahoo.com with NNFMP; 02 Apr 2009 15:43:38 -0000 X-Yahoo-Newman-Id: 211385.98099.bm@omp410.mail.mud.yahoo.com Received: (qmail 45697 invoked from network); 2 Apr 2009 15:43:37 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 2 Apr 2009 15:43:37 -0000 X-YMail-OSG: anxtMv4VM1lFiQwJWHRqu8szFm2xqDPL2fuR5gTdmGEaa4Y9bIXqGmtjSpN_Q9evS5Xi5cF7YeoBj12mamdNdhDuegKchmCTl9Ilqe2qgkb59ntYFjBi1YnRzpC3h0GI4Ua63profIb6CiRbpb0pU3.5DTFf5iR_XCkXPB9zQy_7903kcvRx7Y6lvjLCxp0nMzWW69R9BUq.uVXQFhKtfn0owgBkXS.JXDdGe5w1urW9VJ6zN2zcem3tYpwtlu32_JB2Thf2lz8JMYdi X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D4DD27.2020401@netconfcentral.com> Date: Thu, 02 Apr 2009 08:43:35 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] CLRs and use-cases X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 15:42:37 -0000 Hi, This thread on identifier length got out of control, and it is partly my fault. I apologize to the WG for that. I think it would be really helpful to have some (one?) guiding principle when resolving these debates. First of all, every standard could be called a CLR in itself. Unless we specify rules for interoperability, it will not happen. If multi-vendor distributed systems could work just because everybody (of course) will do the right thing, we would not need any SDOs. Second, the WG should examine the use-cases for the text that gets added or removed from the drafts. Claiming "this is just a CLR" is not a use-case. If somebody has a legitimate use-case (e.g. SMIv2 compatibility or tools compatibility) then it should not be ignored. Andy From phil@juniper.net Thu Apr 2 09:00:17 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F29D93A6895 for ; Thu, 2 Apr 2009 09:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0RRqIfOGmyj for ; Thu, 2 Apr 2009 09:00:16 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 20E903A6E20 for ; Thu, 2 Apr 2009 09:00:07 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSdThQqncuu22x431h+OJpGH69iTG5E+M@postini.com; Thu, 02 Apr 2009 09:01:11 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 2 Apr 2009 08:58:36 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 08:58:36 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 08:58:36 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 08:58:35 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n32FwZM66028; Thu, 2 Apr 2009 08:58:35 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n32FpN5N014641; Thu, 2 Apr 2009 15:51:23 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904021551.n32FpN5N014641@idle.juniper.net> To: Andy Bierman In-Reply-To: <49D4D828.4070205@netconfcentral.com> Date: Thu, 2 Apr 2009 11:51:23 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 Apr 2009 15:58:35.0424 (UTC) FILETIME=[E11BBA00:01C9B3AB] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 16:00:17 -0000 Andy Bierman writes: >Since you are the only vendor who claims to be able to >implement arbitrary length identifiers, there is not any >consensus for that change in the text. I think the SMIv2 style >text has the most consensus, and that will solve your >concerns about every platform supporting the same limits. I don't agree with any of this. I'm not the only one in this debate that sees no reason for the limit. I'm certainly not the only one that sees the current text as flawed. In fact this whole topic was one you raised at the WG meeting, pointing out the interoperability issues with the current text. You've been backpedaling, but I think these is a problem as it sits. In any case, this whole thread continues to devolve into mud wrestling. Would the WG chairs please step in and determine if a concensus exists? Thanks, Phil (the lean mean fighting machine) From andy@netconfcentral.com Thu Apr 2 09:08:50 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC14A3A6A7F for ; Thu, 2 Apr 2009 09:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ck4gwsvsATx2 for ; Thu, 2 Apr 2009 09:08:50 -0700 (PDT) Received: from n30.bullet.mail.mud.yahoo.com (n30.bullet.mail.mud.yahoo.com [68.142.207.49]) by core3.amsl.com (Postfix) with SMTP id 138A83A681D for ; Thu, 2 Apr 2009 09:08:50 -0700 (PDT) Received: from [68.142.194.244] by n30.bullet.mail.mud.yahoo.com with NNFMP; 02 Apr 2009 16:09:51 -0000 Received: from [68.142.201.254] by t2.bullet.mud.yahoo.com with NNFMP; 02 Apr 2009 16:09:51 -0000 Received: from [127.0.0.1] by omp415.mail.mud.yahoo.com with NNFMP; 02 Apr 2009 16:09:51 -0000 X-Yahoo-Newman-Id: 672777.33368.bm@omp415.mail.mud.yahoo.com Received: (qmail 92038 invoked from network); 2 Apr 2009 16:09:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 2 Apr 2009 16:09:50 -0000 X-YMail-OSG: eqYMJ6sVM1lldL5H6672JlmYUfXpOl4ddRKHamSU_7ZvCDJDVsNfqM8dv.L6OE09NO03J65FXDzFTsgnEO2WSB9GL1BQpLw.o5czJ.NOySc3ivCCwrJVvK4geS6E_Iv2mn7jbB_8VMxLCV6XMPGWhoVGIG9Mj.gmNafyZVai_oFDG_Kz0g5eQDLeRYvdc01W.RWuzxreJPl89RwZr4Lt7DItC2kkPNKike2pasp.g.TgS2VJWN9CiiISKVOboVikBQ2Uf3Uidj4roG9j X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D4E34D.4060107@netconfcentral.com> Date: Thu, 02 Apr 2009 09:09:49 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200904021551.n32FpN5N014641@idle.juniper.net> In-Reply-To: <200904021551.n32FpN5N014641@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 16:08:51 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Since you are the only vendor who claims to be able to >> implement arbitrary length identifiers, there is not any >> consensus for that change in the text. I think the SMIv2 style >> text has the most consensus, and that will solve your >> concerns about every platform supporting the same limits. > > I don't agree with any of this. I'm not the only one in this debate > that sees no reason for the limit. I'm certainly not the only one > that sees the current text as flawed. In fact this whole topic was > one you raised at the WG meeting, pointing out the interoperability > issues with the current text. You've been backpedaling, but I think > these is a problem as it sits. > At least 2 tool vendors have said they cannot implement infinite length identifiers, and that SMIv2 compatibility is important to them. Since we all have to support the same range, 1 to infinity cannot be it. It seems 1 to 64 has the most consensus. > In any case, this whole thread continues to devolve into mud > wrestling. Would the WG chairs please step in and determine if a > concensus exists? > > Thanks, > Phil (the lean mean fighting machine) > > Andy From phil@juniper.net Thu Apr 2 09:50:31 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7173A6C42 for ; Thu, 2 Apr 2009 09:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-vZ-RV8ZdCi for ; Thu, 2 Apr 2009 09:50:30 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id C0AD53A6B34 for ; Thu, 2 Apr 2009 09:50:24 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSdTtDH2UAhNX/Rt9F0R8IWAedXKgIhUf@postini.com; Thu, 02 Apr 2009 09:51:32 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 2 Apr 2009 09:49:47 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 09:49:47 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 09:49:47 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 09:49:46 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n32GnkM91327; Thu, 2 Apr 2009 09:49:46 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n32GgY3O015234; Thu, 2 Apr 2009 16:42:34 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904021642.n32GgY3O015234@idle.juniper.net> To: Andy Bierman In-Reply-To: <49D4E34D.4060107@netconfcentral.com> Date: Thu, 2 Apr 2009 12:42:34 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 Apr 2009 16:49:46.0662 (UTC) FILETIME=[07B57460:01C9B3B3] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 16:50:31 -0000 Andy Bierman writes: >At least 2 tool vendors have said >they cannot implement infinite length identifiers, Yup, and at least 2 have said the opposite. Plus some others. I'll leave it to the chairs to do the counting. >and that SMIv2 compatibility is important to them. >Since we all have to support the same range, >1 to infinity cannot be it. It seems 1 to 64 has >the most consensus. The WG is concerned only with SMIv2->YANG, not with mapping YANG back into the restrictions of SMIv2. Since an unlimited string is capable of holding 63/64 characters, using SMI's legacy restrictions to push for a 63/64 limit in YANG doesn't hold water. Thanks, Phil From andy@netconfcentral.com Thu Apr 2 10:00:04 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 535B63A6C32 for ; Thu, 2 Apr 2009 10:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzLe7pcAnNYN for ; Thu, 2 Apr 2009 10:00:03 -0700 (PDT) Received: from n64.bullet.mail.sp1.yahoo.com (n64.bullet.mail.sp1.yahoo.com [98.136.44.189]) by core3.amsl.com (Postfix) with SMTP id 923A13A6A14 for ; Thu, 2 Apr 2009 10:00:03 -0700 (PDT) Received: from [216.252.122.218] by n64.bullet.mail.sp1.yahoo.com with NNFMP; 02 Apr 2009 17:01:05 -0000 Received: from [209.191.108.97] by t3.bullet.sp1.yahoo.com with NNFMP; 02 Apr 2009 17:01:05 -0000 Received: from [68.142.201.241] by t4.bullet.mud.yahoo.com with NNFMP; 02 Apr 2009 17:01:05 -0000 Received: from [127.0.0.1] by omp402.mail.mud.yahoo.com with NNFMP; 02 Apr 2009 17:01:05 -0000 X-Yahoo-Newman-Id: 300906.55308.bm@omp402.mail.mud.yahoo.com Received: (qmail 21820 invoked from network); 2 Apr 2009 17:01:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp108.sbc.mail.sp1.yahoo.com with SMTP; 2 Apr 2009 17:01:04 -0000 X-YMail-OSG: NAsyiIcVM1kz149HMvMNthLhRUYjmjJLHAJgijNbEKfqaXlJoxi.cLiCkEhU93GaDjYBICldWpIKtsPDZ3PP4kbkV9CRinA5eO46jWN6zIEyTHjwHoj_FHy1MeAwJnirXkPmbwoXLnDnrWQo3Lj_4msH7WoUwx4z5CrfpcX1NgvMlAF3MEjcJUT_kTREyuCrM4cRKR02qNM2wwrNtczz0J.UNcg7sUDRLKjKCD5b_dDHYdsz3RBY6L09nVpfAX7la_eUn4oNvi3CDND6 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D4EF4E.2020006@netconfcentral.com> Date: Thu, 02 Apr 2009 10:01:02 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200904021642.n32GgY3O015234@idle.juniper.net> In-Reply-To: <200904021642.n32GgY3O015234@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 17:00:04 -0000 Phil Shafer wrote: > Andy Bierman writes: >> At least 2 tool vendors have said >> they cannot implement infinite length identifiers, > > Yup, and at least 2 have said the opposite. Plus some > others. I'll leave it to the chairs to do the counting. > >> and that SMIv2 compatibility is important to them. >> Since we all have to support the same range, >> 1 to infinity cannot be it. It seems 1 to 64 has >> the most consensus. > > The WG is concerned only with SMIv2->YANG, not with mapping YANG > back into the restrictions of SMIv2. Since an unlimited string is > capable of holding 63/64 characters, using SMI's legacy restrictions > to push for a 63/64 limit in YANG doesn't hold water. > 1) You said we all need to implement the same range for identifiers 2) I reluctantly agreed 3) By definition, that means we need to select a finite number for the upper bound. Infinity is not a number, and it is not implementable. 4) Nobody actually wants to use identifiers over 64 characters in length > Thanks, > Phil > > Andy From phil@juniper.net Thu Apr 2 10:33:20 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB84B3A6DDD for ; Thu, 2 Apr 2009 10:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFEUE9R94DId for ; Thu, 2 Apr 2009 10:33:20 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id B857E3A68C8 for ; Thu, 2 Apr 2009 10:33:14 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSdT3Fd1s8C/NZEYKA5Fcz13MKG4UOLSR@postini.com; Thu, 02 Apr 2009 10:34:22 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 2 Apr 2009 10:31:11 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 10:31:11 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 10:31:11 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 10:31:10 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n32HV9M13479; Thu, 2 Apr 2009 10:31:09 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n32HNwP9015674; Thu, 2 Apr 2009 17:23:58 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904021723.n32HNwP9015674@idle.juniper.net> To: Andy Bierman In-Reply-To: <49D4EF4E.2020006@netconfcentral.com> Date: Thu, 2 Apr 2009 13:23:58 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 Apr 2009 17:31:10.0355 (UTC) FILETIME=[D01AEE30:01C9B3B8] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 17:33:21 -0000 Andy Bierman writes: >4) Nobody actually wants to use identifiers over 64 characters in length All roads seem to lead you to this same outcome (64), but I'm still stuck on the initial question: Why do we need to limit identifier length? If there's no convincing reason, then it is just a Crummy Little Rule. We don't need it for YANG to be implementable, since we know that XML functions perfectly well in multiple independent implementations without a limit. We don't need it for code generation, since we know that C++ loves to generate symbols that are insanely large. We don't need it for SMIv2 compatibility, since we are only interested in mapping from SMIv2 into YANG, not vice versa, and SMIv2's restricted strings will happily fit into our unlimited ones. We don't need it to save memory, since the expectation is that one uses a dictionary (or cons creation or similar approach) to ensure that the implementation needs only one copy of the identifier, not one per instance. Are there any strong reasons to keep this restriction? Isn't it just a CLR? Will it just be one of the list of "oh no one will ever need that"? ("No one will ever need more that 640K", "no one will ever need more that 8.3 filenames", "no one will ever need more that four partitions", "no one will ever need more than one display on their computer", "no one will ever need a book on towel origami" (http://tinyurl.com/dygpfr)). Thanks, Phil From andy@netconfcentral.com Thu Apr 2 10:45:14 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C0AB3A69EB for ; Thu, 2 Apr 2009 10:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVdUmVgvdsr2 for ; Thu, 2 Apr 2009 10:45:13 -0700 (PDT) Received: from n8a.bullet.mail.mud.yahoo.com (n8a.bullet.mail.mud.yahoo.com [209.191.87.104]) by core3.amsl.com (Postfix) with SMTP id 585193A6AAD for ; Thu, 2 Apr 2009 10:45:13 -0700 (PDT) Received: from [209.191.108.97] by n8.bullet.mail.mud.yahoo.com with NNFMP; 02 Apr 2009 17:46:15 -0000 Received: from [68.142.201.241] by t4.bullet.mud.yahoo.com with NNFMP; 02 Apr 2009 17:46:15 -0000 Received: from [127.0.0.1] by omp402.mail.mud.yahoo.com with NNFMP; 02 Apr 2009 17:46:15 -0000 X-Yahoo-Newman-Id: 50624.61206.bm@omp402.mail.mud.yahoo.com Received: (qmail 62656 invoked from network); 2 Apr 2009 17:46:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 2 Apr 2009 17:46:14 -0000 X-YMail-OSG: ukf2rcoVM1k4MuCvrw.lSI2l5POjTwQU3wmNs43gSl6HiYAip0.v6vYw9VmNqn9BOb0KiTDthoY1bb0aqsuB7lt0JDJuztt9tnOsH8ZeP2abnRpQ4Bp6Q7j_uiyY8H1Gu5iIn5Rl65j.6NgMFq6q7W_pPX79G2YYyzyeqfPk0yz7BrVMvPfy71Yi3bZg2KYmbiP8hADgKdGXuB8T60VZthTkLwniJDqVLuZEckDMnsujiJD6_xQfODEJqELgDhTM8FQzM37BaruFYRK4DTUXMKHGenuNkhYQZRzDVIHLnPgKvScu7q6E X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D4F9E3.3080008@netconfcentral.com> Date: Thu, 02 Apr 2009 10:46:11 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200904021723.n32HNwP9015674@idle.juniper.net> In-Reply-To: <200904021723.n32HNwP9015674@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 17:45:14 -0000 Phil Shafer wrote: > Andy Bierman writes: >> 4) Nobody actually wants to use identifiers over 64 characters in length > > All roads seem to lead you to this same outcome (64), but I'm still > stuck on the initial question: > > Why do we need to limit identifier length? > > If there's no convincing reason, then it is just a Crummy Little > Rule. > > We don't need it for YANG to be implementable, since we know that > XML functions perfectly well in multiple independent implementations > without a limit. > > We don't need it for code generation, since we know that C++ loves > to generate symbols that are insanely large. > > We don't need it for SMIv2 compatibility, since we are only interested > in mapping from SMIv2 into YANG, not vice versa, and SMIv2's > restricted strings will happily fit into our unlimited ones. > > We don't need it to save memory, since the expectation is that one > uses a dictionary (or cons creation or similar approach) to ensure > that the implementation needs only one copy of the identifier, not > one per instance. > > Are there any strong reasons to keep this restriction? Isn't it > just a CLR? Will it just be one of the list of "oh no one will > ever need that"? ("No one will ever need more that 640K", "no one > will ever need more that 8.3 filenames", "no one will ever need > more that four partitions", "no one will ever need more than one > display on their computer", "no one will ever need a book on towel > origami" (http://tinyurl.com/dygpfr)). > I am convinced that interoperability will not be achieved without a specific rule, and that is why we are writing this standard. Wes, Juergen, David, Steve, and I have all stated use-cases for picking a specific finite upper-bound instead of infinity. > Thanks, > Phil > > Andy From phil@juniper.net Thu Apr 2 12:19:12 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD5783A6D01 for ; Thu, 2 Apr 2009 12:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUpZb2mCYZM4 for ; Thu, 2 Apr 2009 12:19:12 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 943253A672F for ; Thu, 2 Apr 2009 12:19:07 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSdUP5r4VraVDmYr0sxz4n/hDzH61/ayn@postini.com; Thu, 02 Apr 2009 12:20:14 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 2 Apr 2009 12:18:47 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 12:18:47 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 12:18:47 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 12:18:46 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n32JIjM70716; Thu, 2 Apr 2009 12:18:45 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n32JBXv4016691; Thu, 2 Apr 2009 19:11:34 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904021911.n32JBXv4016691@idle.juniper.net> To: Andy Bierman In-Reply-To: <49D4F9E3.3080008@netconfcentral.com> Date: Thu, 2 Apr 2009 15:11:33 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 Apr 2009 19:18:46.0028 (UTC) FILETIME=[D7FC74C0:01C9B3C7] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 19:19:12 -0000 Andy Bierman writes: >I am convinced that interoperability will not be achieved >without a specific rule, and that is why we are writing this standard. I understand that you believe that we need a 63 or 64 character limit on identifiers. But what I keep asking for is a reason behind this belief. You've given several, which I think Martin, Lada, and I have addressed. I tried to recap this in my last email. Have I misunderstood or misstated your reasoning? Are there holes in the logic behind the counter arguments? Or have we slipped to the point where this is quasi-religious, and logic yields to faith? My worry is that this CLR is required by the way your tools encode identifiers in your SQL tables. Should that be the key issue in defining standards? Can this encoding scheme be changed to use table lookups via a dictionary so the database keys are, say, small numbers instead of strings? What happen when you get a customer that requires >15 depth and you are forced to use a different encoding scheme? Or a different database that doesn't have this 900-odd byte restriction? Will we be able to remove the CLR at that point? >Wes, Juergen, David, Steve, and I have all stated use-cases >for picking a specific finite upper-bound instead of infinity. They may have stated a preference for keeping a CLR, but not a use case that necessitates it. David's comment was about his toolset. I couldn't find Juergen's comment on point and if Wes posted something, I can't find it in the netmod archives. Here's Steve and David's comments: Steve: >I'd prefer 2 (though I'd kinda prefer 64 but won't refuse the bit at 63). >Either of these is adequately long to generate unique leaf node identifiers, >and for those of us who do source code tools, will make life across >various development environments easier. David: >I prefer 2, with a value for N of 64, because my code generator can't >support infinite lengths and because I have never seen a problem with the >SMI 64 limit. I'd be happy copying the text exactly from rfc 2578. I dislike having a hard limit without a strong reason. I strongly dislike having a low limit, since I have existing tags that are 45 bytes, which is ~3/4 of the way to that limit. If I'm approaching the limit without trying, what happens when YANG++ (YAYANG?) starts making C++-like butt-ugly tags? Just because "no one needs it today" is no reason to make a rule to prevent someone in the future from using it. Similarly, just because it's the SMIv2 works does not mean that YANG needs the same restriction. Thanks, Phil "Unlimited" Shafer From j.schoenwaelder@jacobs-university.de Thu Apr 2 12:30:40 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E03D23A6B38 for ; Thu, 2 Apr 2009 12:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHgp5aRLxH18 for ; Thu, 2 Apr 2009 12:30:40 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E0B213A6D4B for ; Thu, 2 Apr 2009 12:30:39 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2DEDDC001F; Thu, 2 Apr 2009 21:31:41 +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 9FtNgf4wol5S; Thu, 2 Apr 2009 21:31:40 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6EB50C0014; Thu, 2 Apr 2009 21:31:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 93B47A4C28B; Thu, 2 Apr 2009 21:31:21 +0200 (CEST) Date: Thu, 2 Apr 2009 21:31:21 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090402193121.GA24821@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , "netmod@ietf.org" References: <200904021723.n32HNwP9015674@idle.juniper.net> <49D4F9E3.3080008@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D4F9E3.3080008@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 02 Apr 2009 19:30:41 -0000 On Thu, Apr 02, 2009 at 07:46:11PM +0200, Andy Bierman wrote: > I am convinced that interoperability will not be achieved > without a specific rule, and that is why we are writing this standard. > Wes, Juergen, David, Steve, and I have all stated use-cases > for picking a specific finite upper-bound instead of infinity. Clarification: The current sentence does _not_ define a specific upper-bound - it establishes a minimum baseline everybody has to implement but leaves the upper bound open. I thought this was a workable compromise but it seems I was wrong... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Thu Apr 2 13:25:30 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC8328C26A for ; Thu, 2 Apr 2009 13:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cf3raV34wpR for ; Thu, 2 Apr 2009 13:25:29 -0700 (PDT) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 3042628C262 for ; Thu, 2 Apr 2009 13:25:26 -0700 (PDT) Received: (qmail 34821 invoked from network); 2 Apr 2009 20:26:27 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 2 Apr 2009 20:26:27 -0000 X-YMail-OSG: FrmOX_sVM1nnXWbVU8XSprPotmnxshFI5.vOAVpSsNf1U0NpI_4XMhZ1kexDHj9yItJwQdhfmGWY__BvbloB1DPNvWKQE6DtMjkm.qFKCPfQogSi5lsI4KS5udCP2igxJq.hBpr_JE1Grijws1xrkCbEitvMSAHhETAeIzHwaijKub4_WfNXoggsWTcEmEjA8nQZin5FaBdxvmX2z3z5UqAo81lE7s4yUcNTsqLx8E7Ec0gSUxCCAVgLqqChQ0XToXaiP6JpzGC45I2B X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D51F71.9040605@netconfcentral.com> Date: Thu, 02 Apr 2009 13:26:25 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200904021911.n32JBXv4016691@idle.juniper.net> In-Reply-To: <200904021911.n32JBXv4016691@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 20:25:30 -0000 Phil Shafer wrote: > Andy Bierman writes: >> I am convinced that interoperability will not be achieved >> without a specific rule, and that is why we are writing this standard. > Just because XML does not specify a limit does not mean that the NETCONF protocol does not have practical limits imposed from legacy and code generation considerations. If we were creating a generic XML standard for the W3C then I would completely agree with you. But we're not. YANG is a specialized XML language for NETCONF. It adds protocol operations to NETCONF. It does not support XML attributes, among other XML constructs, so it could not possibly be considered as a generalized XML language (good -- that was not our charter). Andy > I understand that you believe that we need a 63 or 64 character > limit on identifiers. But what I keep asking for is a reason behind > this belief. You've given several, which I think Martin, Lada, and > I have addressed. I tried to recap this in my last email. Have I > misunderstood or misstated your reasoning? Are there holes in the > logic behind the counter arguments? Or have we slipped to the point > where this is quasi-religious, and logic yields to faith? > > My worry is that this CLR is required by the way your tools encode > identifiers in your SQL tables. Should that be the key issue in > defining standards? Can this encoding scheme be changed to use > table lookups via a dictionary so the database keys are, say, small > numbers instead of strings? What happen when you get a customer > that requires >15 depth and you are forced to use a different > encoding scheme? Or a different database that doesn't have this > 900-odd byte restriction? Will we be able to remove the CLR at > that point? > >> Wes, Juergen, David, Steve, and I have all stated use-cases >> for picking a specific finite upper-bound instead of infinity. > > They may have stated a preference for keeping a CLR, but not a use > case that necessitates it. David's comment was about his toolset. > I couldn't find Juergen's comment on point and if Wes posted > something, I can't find it in the netmod archives. Here's Steve > and David's comments: > > Steve: > >I'd prefer 2 (though I'd kinda prefer 64 but won't refuse the bit at 63). > >Either of these is adequately long to generate unique leaf node identifiers, > >and for those of us who do source code tools, will make life across > >various development environments easier. > > David: > >I prefer 2, with a value for N of 64, because my code generator can't > >support infinite lengths and because I have never seen a problem with the > >SMI 64 limit. I'd be happy copying the text exactly from rfc 2578. > > I dislike having a hard limit without a strong reason. I strongly > dislike having a low limit, since I have existing tags that are 45 > bytes, which is ~3/4 of the way to that limit. If I'm approaching > the limit without trying, what happens when YANG++ (YAYANG?) starts > making C++-like butt-ugly tags? > > Just because "no one needs it today" is no reason to make a rule > to prevent someone in the future from using it. Similarly, just > because it's the SMIv2 works does not mean that YANG needs the > same restriction. > > Thanks, > Phil "Unlimited" Shafer > > From phil@juniper.net Thu Apr 2 14:06:16 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E87F3A6A5D for ; Thu, 2 Apr 2009 14:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+wE51x24YIs for ; Thu, 2 Apr 2009 14:06:15 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 5089F28C143 for ; Thu, 2 Apr 2009 14:06:08 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSdUo/GeopynbaKdJQ1VQuvzIkNsigYSF@postini.com; Thu, 02 Apr 2009 14:07:17 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 2 Apr 2009 14:04:57 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 14:04:58 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 14:04:57 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 14:04:56 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n32L4uM24300; Thu, 2 Apr 2009 14:04:56 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n32KvifM017904; Thu, 2 Apr 2009 20:57:45 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904022057.n32KvifM017904@idle.juniper.net> To: Andy Bierman In-Reply-To: <49D51F71.9040605@netconfcentral.com> Date: Thu, 2 Apr 2009 16:57:44 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 Apr 2009 21:04:56.0997 (UTC) FILETIME=[AD612D50:01C9B3D6] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 21:06:16 -0000 Andy Bierman writes: >Just because XML does not specify a limit does not mean >that the NETCONF protocol does not have practical >limits imposed from legacy and code generation considerations. Please elaborate on what aspects of YANG differ XML, WRT limits. No one has the expection that an XML language will use 48M element names, since no sane person will do this, but no one ever felt the need in XML to say "no element name may exceed 64 bytes". What is there about NETCONF or YANG that requires a different attitude, that requires a CLR where XML does not? If XML can be interoperable without such a rule, why does YANG require it? Is the expectation that YANG authors will be less sane than XML authors? Thanks, Phil From andy@netconfcentral.com Thu Apr 2 14:30:13 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D36F73A6803 for ; Thu, 2 Apr 2009 14:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27NeoIoID86V for ; Thu, 2 Apr 2009 14:30:13 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 264AC3A6781 for ; Thu, 2 Apr 2009 14:30:13 -0700 (PDT) Received: (qmail 67541 invoked from network); 2 Apr 2009 21:31:15 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 2 Apr 2009 21:31:14 -0000 X-YMail-OSG: _j_lfQQVM1mCjfu43DaRVi_2P9MZLg.S68qGpRPZgAJeoyFZt1bEg4aHEnKy65QLt1ncaEb6ImPEv4Ew_GQByxeBSyT8cUPBG.AhfZ1E15nymT9YCWNx6nrgXQjzzKz1eXz9r9MeIHhuEnH4Z5ldsgE_fi.32OKg4FxcHgDIRSFtE8HqJlChzz8hjreMHKZqtq5xsPAgw13iC.kJcJnKqVHvwUf0xRsVKkH756rrE_fkxPg37X.Q1MN6_AWdQ5jJJGKhOn9_.y__cSL. X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D52EA0.3020608@netconfcentral.com> Date: Thu, 02 Apr 2009 14:31:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200904022057.n32KvifM017904@idle.juniper.net> In-Reply-To: <200904022057.n32KvifM017904@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 21:30:13 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Just because XML does not specify a limit does not mean >> that the NETCONF protocol does not have practical >> limits imposed from legacy and code generation considerations. > > Please elaborate on what aspects of YANG differ XML, WRT limits. > No one has the expection that an XML language will use 48M element > names, since no sane person will do this, but no one ever felt > the need in XML to say "no element name may exceed 64 bytes". > From the NETMOD charter: While it is desirable to provide a migration path from existing MIB modules to YANG data models (modules), it is not a requirement to provide full compatibility between SMIv2 and YANG. The Working Group will determine which constructs (e.g., conformance statements) are not relevant for translation from SMIv2 to YANG. YANG is also permitted to introduce constructs that cannot be expressed in SMIv2. However, all basic types that can be represented in SMIv2 must be expressible in YANG. I interpret this text to mean that the NETMOD WG should take every reasonable opportunity to remain compatible with SMIv2. YANG uses a subset of XML. It is arbitrary to say we MUST support this one aspect of XML when we leave out so many parts of XML and use XPath so 'liberally'. YANG makes its own XML order rules, its own NETCONF rules, its own rules for everything. A perfectly reasonable implementation strategy for a transition product might be a NETCONF to SNMP proxy, in which the SNMP uses a MIB module algorithmically translated from the YANG module to interface with legacy agent instrumentation. > What is there about NETCONF or YANG that requires a different > attitude, that requires a CLR where XML does not? If XML can > be interoperable without such a rule, why does YANG require it? > > Is the expectation that YANG authors will be less sane than XML > authors? > Nobody can implement infinite length strings in their agent. Nobody wants to use identifiers over 64 chars -- ever. It is bad for readability to use super-long identifiers. The 1 to 64 rule helps some implementation use-cases and helps inter-operability. > Thanks, > Phil > > Andy From andy@netconfcentral.com Thu Apr 2 14:49:25 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D9423A67A1 for ; Thu, 2 Apr 2009 14:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijb4T4yllILV for ; Thu, 2 Apr 2009 14:49:24 -0700 (PDT) Received: from n27.bullet.mail.mud.yahoo.com (n27.bullet.mail.mud.yahoo.com [68.142.206.222]) by core3.amsl.com (Postfix) with SMTP id 134D128C117 for ; Thu, 2 Apr 2009 14:48:39 -0700 (PDT) Received: from [68.142.194.243] by n27.bullet.mail.mud.yahoo.com with NNFMP; 02 Apr 2009 21:49:40 -0000 Received: from [68.142.201.250] by t1.bullet.mud.yahoo.com with NNFMP; 02 Apr 2009 21:49:40 -0000 Received: from [127.0.0.1] by omp411.mail.mud.yahoo.com with NNFMP; 02 Apr 2009 21:49:40 -0000 X-Yahoo-Newman-Id: 950917.68000.bm@omp411.mail.mud.yahoo.com Received: (qmail 8848 invoked from network); 2 Apr 2009 21:49:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 2 Apr 2009 21:49:39 -0000 X-YMail-OSG: W6CLQuAVM1n333LWt1gSfVQJbbkBLaeV45vIoOyvSpSZtfuuqiPfdEi_6DQJ4GlY9mvvz.AO00y1zLX7sMqS27f8k4Ec_TTXWNUxLmbCQkxrQr49tFWmY7LFrDLslGPWLQ1PAQ64yIMX0eySLbh.5iI55GEMuUGCJncbKA4I5CxJylUQpykE8.v7zyzaSLkkAnfFEh9bO9CXe8AF.ipI7Pi6yIl7KFxEihp8rrVnC0kiST5RzAnFYZkaHx72YAfOX.nD1qrfaK8nI3jL X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D532F1.7060700@netconfcentral.com> Date: Thu, 02 Apr 2009 14:49:37 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200904022057.n32KvifM017904@idle.juniper.net> In-Reply-To: <200904022057.n32KvifM017904@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 21:49:25 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Just because XML does not specify a limit does not mean >> that the NETCONF protocol does not have practical >> limits imposed from legacy and code generation considerations. > Actually, remembering back to when the RFC 2578 rule was written, it was done to protect operators, not implementors. The full test from sec. 3.1, para 3: For all descriptors appearing in an information module, the descriptor shall be unique and mnemonic, and shall not exceed 64 characters in length. (However, descriptors longer than 32 characters are not recommended.) This promotes a common language for humans to use when discussing the information module and also facilitates simple table mappings for user-interfaces. Operators need to be familiar with NETCONF identifiers for the YANG modules they use. It is even more important than SNMP, because these YANG identifiers are used in the instance-identifier data-type. The "max 64" rule ensures that the YANG readers and network operators (amongst others) never have to read super-long identifiers in NETCONF/YANG. Andy From lhotka@cesnet.cz Thu Apr 2 15:35:38 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B97F73A6D63 for ; Thu, 2 Apr 2009 15:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.913 X-Spam-Level: X-Spam-Status: No, score=-0.913 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AE9e-pBc0riw for ; Thu, 2 Apr 2009 15:35:38 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B25943A6D5B for ; Thu, 2 Apr 2009 15:35:37 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id CD43ED800BD for ; Fri, 3 Apr 2009 00:36:35 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <49D4DD27.2020401@netconfcentral.com> References: <49D4DD27.2020401@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 03 Apr 2009 00:36:37 +0200 Message-Id: <1238711797.7254.132.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] CLRs and use-cases X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 22:35:38 -0000 Andy Bierman píše v Čt 02. 04. 2009 v 08:43 -0700: > Hi, > > This thread on identifier length got out of control, > and it is partly my fault. I apologize to the WG for that. > > I think it would be really helpful to have some (one?) > guiding principle when resolving these debates. > > First of all, every standard could be called a CLR > in itself. Unless we specify rules for interoperability, In my view, every rule is a CLR unless and until it is proven to be necessary, and I am not convinced it is the case with the identifier length. If XML can live without such a restriction, why couldn't YANG? Lada > it will not happen. If multi-vendor distributed systems > could work just because everybody (of course) > will do the right thing, we would not need any SDOs. > > Second, the WG should examine the use-cases for > the text that gets added or removed from the drafts. > Claiming "this is just a CLR" is not a use-case. > If somebody has a legitimate use-case (e.g. SMIv2 > compatibility or tools compatibility) then it should > not be ignored. > > > > Andy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Thu Apr 2 15:41:46 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFD453A6D6E for ; Thu, 2 Apr 2009 15:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nktKZL9EgK7E for ; Thu, 2 Apr 2009 15:41:46 -0700 (PDT) Received: from n27.bullet.mail.mud.yahoo.com (n27.bullet.mail.mud.yahoo.com [68.142.206.222]) by core3.amsl.com (Postfix) with SMTP id EA37E3A6C13 for ; Thu, 2 Apr 2009 15:41:45 -0700 (PDT) Received: from [68.142.194.243] by n27.bullet.mail.mud.yahoo.com with NNFMP; 02 Apr 2009 22:42:47 -0000 Received: from [68.142.201.69] by t1.bullet.mud.yahoo.com with NNFMP; 02 Apr 2009 22:42:47 -0000 Received: from [127.0.0.1] by omp421.mail.mud.yahoo.com with NNFMP; 02 Apr 2009 22:42:47 -0000 X-Yahoo-Newman-Id: 882860.91709.bm@omp421.mail.mud.yahoo.com Received: (qmail 35983 invoked from network); 2 Apr 2009 22:42:47 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 2 Apr 2009 22:42:46 -0000 X-YMail-OSG: YmOUF7IVM1ns2Ih0PxTe1baisvK7MyOA.QWGhzLbrs7I52Uxqk2xtXT5OpkyzK5VuR_v78_kKEh.HGjYT.bbQSKhAsnfOGjKGKpN03V2VrQVYMANUOaOW.hHW4HmOHDyj.KaILxmVj4M3hSGU46jy6MRqX9wjv03bBJL1GgmLZgKCXaNTEX7kQ0ANY22nfn8riJrJFvzJLB2PpBf479gnkqtKr_7U9V8pN82P2XLTglHiCgj1RVU6Xnf59cRjkSXQx5wYnMTPqNOFWje X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D53F64.3000309@netconfcentral.com> Date: Thu, 02 Apr 2009 15:42:44 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ladislav Lhotka References: <49D4DD27.2020401@netconfcentral.com> <1238711797.7254.132.camel@missotis> In-Reply-To: <1238711797.7254.132.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] CLRs and use-cases X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 22:41:46 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Čt 02. 04. 2009 v 08:43 -0700: >> Hi, >> >> This thread on identifier length got out of control, >> and it is partly my fault. I apologize to the WG for that. >> >> I think it would be really helpful to have some (one?) >> guiding principle when resolving these debates. >> >> First of all, every standard could be called a CLR >> in itself. Unless we specify rules for interoperability, > > In my view, every rule is a CLR unless and until it is proven to be > necessary, and I am not convinced it is the case with the identifier > length. If XML can live without such a restriction, why couldn't YANG? > Because XML is just a generic encoding mechanism that doesn't actually do anything by itself. But the most important reason is to protect operator readability and usability, not to protect implementors. Code can always be changed. > Lada Andy From saperia@jdscons.com Thu Apr 2 18:56:15 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51B63A67EE for ; Thu, 2 Apr 2009 18:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKPyaP3+RPZp for ; Thu, 2 Apr 2009 18:56:14 -0700 (PDT) Received: from rs34.luxsci.com (rs34.luxsci.com [65.61.166.74]) by core3.amsl.com (Postfix) with ESMTP id B7C6428C21D for ; Thu, 2 Apr 2009 18:56:14 -0700 (PDT) Received: from rs34.luxsci.com (localhost [127.0.0.1]) by rs34.luxsci.com (8.13.1/8.13.7) with ESMTP id n331vFD4022397; Thu, 2 Apr 2009 20:57:15 -0500 Received: (from lshttpd@localhost) by rs34.luxsci.com (8.13.1/8.13.7/Submit) id n331vFtN022394; Fri, 3 Apr 2009 01:57:15 GMT Message-Id: <200904030157.n331vFtN022394@rs34.luxsci.com> From: "Jon Saperia" Date: Fri, 03 Apr 2009 01:57:15 +0000 To: netmod@ietf.org Errors-To: saperia@jdscons.com MIME-Version: 1.0 X-Comment: Charset encoding changed from (utf-8) to (UTF-8) for compatibility with message contents. X-Comment: 42010-3632-1 Content-Type: multipart/mixed; boundary="------------------_Boundary_60322838.8485956"; charset="utf-8" Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: saperia@jdscons.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 01:56:16 -0000 This is a multi-part message in MIME format. If you cannot view the attachment(s), then your email client does not support MIME. --------------------_Boundary_60322838.8485956 Content-Type: multipart/alternative; boundary="-------------355491.937195895" ---------------355491.937195895 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I will not say what the correct exact number should be (64 seems ok) but a limit from a couple perspectives does seem to matter: 1. I have seen mail in this thread talking about the size of configuration files. Things that tend to make them larger are not as helpful. 2. From the perspective of an NM application and DB building perspective larger is problematic, especially for larger networks, unspecified leaves a bit too much to the imagination of the application developer. I think an important objective is better tools - leaving this unspecified works in the opposite direction. 3. From the perspective of people that are concerned with bandwidth utilization - some of the people I work with - efficiency over the wire does make a difference and this (no limit) seems also to point in the opposite direction. So while XML might not have limits, the whole purpose/justification for YANG from what I recall is that we need this for the specialized purpose of defining and transmitting config information. As a result, the limit is not a CLR, it is something that makes the tool appropriate to the purpose it is being created for. /jon On Apr 2, 2009, at 1:46 PM, Andy Bierman wrote: Phil Shafer wrote: Andy Bierman writes: 4) Nobody actually wants to use identifiers over 64 characters in length All roads seem to lead you to this same outcome (64), but I'm still stuck on the initial question: Why do we need to limit identifier length? If there's no convincing reason, then it is just a Crummy Little Rule. We don't need it for YANG to be implementable, since we know that XML functions perfectly well in multiple independent implementations without a limit. We don't need it for code generation, since we know that C++ loves to generate symbols that are insanely large. We don't need it for SMIv2 compatibility, since we are only interested in mapping from SMIv2 into YANG, not vice versa, and SMIv2's restricted strings will happily fit into our unlimited ones. We don't need it to save memory, since the expectation is that one uses a dictionary (or cons creation or similar approach) to ensure that the implementation needs only one copy of the identifier, not one per instance. Are there any strong reasons to keep this restriction? Isn't it just a CLR? Will it just be one of the list of "oh no one will ever need that"? ("No one will ever need more that 640K", "no one will ever need more that 8.3 filenames", "no one will ever need more that four partitions", "no one will ever need more than one display on their computer", "no one will ever need a book on towel origami" (http://tinyurl.com/dygpfr)). I am convinced that interoperability will not be achieved without a specific rule, and that is why we are writing this standard. Wes, Juergen, David, Steve, and I have all stated use-cases for picking a specific finite upper-bound instead of infinity. Thanks, Phil Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ---------------355491.937195895 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdj5JIHdpbGwgbm90IHNheSB3aGF0IHRoZSBjb3JyZWN0IGV4YWN0IG51bWJlciBzaG91bGQg YmUgKDY0IHNlZW1zIG9rKSBidXQgYSBsaW1pdCBmcm9tIGEgY291cGxlIHBlcnNwZWN0aXZlcyBk b2VzIHNlZW0gdG8gbWF0dGVyOjxiciAvPiZuYnNwOyZuYnNwOyZuYnNwOyAxLiBJIGhhdmUgc2Vl biBtYWlsIGluIHRoaXMgdGhyZWFkIHRhbGtpbmcgYWJvdXQgdGhlIHNpemUgb2YgY29uZmlndXJh dGlvbiBmaWxlcy4mbmJzcDsgVGhpbmdzIHRoYXQgdGVuZCB0byBtYWtlIHRoZW0gbGFyZ2VyIGFy ZSBub3QgYXMgaGVscGZ1bC48YnIgLz4mbmJzcDsmbmJzcDsmbmJzcDsgMi4gRnJvbSB0aGUgcGVy c3BlY3RpdmUgb2YgYW4gTk0gYXBwbGljYXRpb24gYW5kIERCIGJ1aWxkaW5nIHBlcnNwZWN0aXZl IGxhcmdlciBpcyBwcm9ibGVtYXRpYywgZXNwZWNpYWxseSBmb3IgbGFyZ2VyIG5ldHdvcmtzLCB1 bnNwZWNpZmllZCBsZWF2ZXMgYSBiaXQgdG9vIG11Y2ggdG8gdGhlIGltYWdpbmF0aW9uIG9mIHRo ZSBhcHBsaWNhdGlvbiBkZXZlbG9wZXIuIEkgdGhpbmsgYW4gaW1wb3J0YW50IG9iamVjdGl2ZSBp cyBiZXR0ZXIgdG9vbHMgLSBsZWF2aW5nIHRoaXMgdW5zcGVjaWZpZWQgd29ya3MgaW4gdGhlIG9w cG9zaXRlIGRpcmVjdGlvbi48YnIgLz4mbmJzcDsmbmJzcDsmbmJzcDsgMy4gRnJvbSB0aGUgcGVy c3BlY3RpdmUgb2YgcGVvcGxlIHRoYXQgYXJlIGNvbmNlcm5lZCB3aXRoIGJhbmR3aWR0aCB1dGls aXphdGlvbiAtIHNvbWUgb2YgdGhlIHBlb3BsZSBJIHdvcmsgd2l0aCAtIGVmZmljaWVuY3kgb3Zl ciB0aGUgd2lyZSBkb2VzIG1ha2UgYSBkaWZmZXJlbmNlIGFuZCB0aGlzIChubyBsaW1pdCkgc2Vl bXMgYWxzbyB0byBwb2ludCBpbiB0aGUgb3Bwb3NpdGUgZGlyZWN0aW9uLjxiciAvPjxiciAvPlNv IHdoaWxlIFhNTCBtaWdodCBub3QgaGF2ZSBsaW1pdHMsIHRoZSB3aG9sZSBwdXJwb3NlL2p1c3Rp ZmljYXRpb24gZm9yIFlBTkcgZnJvbSB3aGF0IEkgcmVjYWxsIGlzIHRoYXQgd2UgbmVlZCB0aGlz IGZvciB0aGUgc3BlY2lhbGl6ZWQgcHVycG9zZSBvZiBkZWZpbmluZyBhbmQgdHJhbnNtaXR0aW5n IGNvbmZpZyBpbmZvcm1hdGlvbi4mbmJzcDsgQXMgYSByZXN1bHQsIHRoZSBsaW1pdCBpcyBub3Qg YSBDTFIsIGl0IGlzIHNvbWV0aGluZyB0aGF0IG1ha2VzIHRoZSB0b29sIGFwcHJvcHJpYXRlIHRv IHRoZSBwdXJwb3NlIGl0IGlzIGJlaW5nIGNyZWF0ZWQgZm9yLjxiciAvPjxiciAvPi9qb248YnIg Lz5PbiBBcHIgMiwgMjAwOSwgYXQgMTo0NiBQTSwgQW5keSBCaWVybWFuIHdyb3RlOjxiciAvPjxi ciAvPlBoaWwgU2hhZmVyIHdyb3RlOjxiciAvPkFuZHkgQmllcm1hbiB3cml0ZXM6PGJyIC8+NCkg Tm9ib2R5IGFjdHVhbGx5IHdhbnRzIHRvIHVzZSBpZGVudGlmaWVycyBvdmVyIDY0IGNoYXJhY3Rl cnMgaW4gbGVuZ3RoPGJyIC8+QWxsIHJvYWRzIHNlZW0gdG8gbGVhZCB5b3UgdG8gdGhpcyBzYW1l IG91dGNvbWUgKDY0KSwgYnV0IEknbSBzdGlsbDxiciAvPnN0dWNrIG9uIHRoZSBpbml0aWFsIHF1 ZXN0aW9uOjxiciAvPldoeSBkbyB3ZSBuZWVkIHRvIGxpbWl0IGlkZW50aWZpZXIgbGVuZ3RoPzxi ciAvPklmIHRoZXJlJ3Mgbm8gY29udmluY2luZyByZWFzb24sIHRoZW4gaXQgaXMganVzdCBhIENy dW1teSBMaXR0bGU8YnIgLz5SdWxlLjxiciAvPldlIGRvbid0IG5lZWQgaXQgZm9yIFlBTkcgdG8g YmUgaW1wbGVtZW50YWJsZSwgc2luY2Ugd2Uga25vdyB0aGF0PGJyIC8+WE1MIGZ1bmN0aW9ucyBw ZXJmZWN0bHkgd2VsbCBpbiBtdWx0aXBsZSBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnM8YnIg Lz53aXRob3V0IGEgbGltaXQuPGJyIC8+V2UgZG9uJ3QgbmVlZCBpdCBmb3IgY29kZSBnZW5lcmF0 aW9uLCBzaW5jZSB3ZSBrbm93IHRoYXQgQysrIGxvdmVzPGJyIC8+dG8gZ2VuZXJhdGUgc3ltYm9s cyB0aGF0IGFyZSBpbnNhbmVseSBsYXJnZS48YnIgLz5XZSBkb24ndCBuZWVkIGl0IGZvciBTTUl2 MiBjb21wYXRpYmlsaXR5LCBzaW5jZSB3ZSBhcmUgb25seSBpbnRlcmVzdGVkPGJyIC8+aW4gbWFw cGluZyBmcm9tIFNNSXYyIGludG8gWUFORywgbm90IHZpY2UgdmVyc2EsIGFuZCBTTUl2MidzPGJy IC8+cmVzdHJpY3RlZCBzdHJpbmdzIHdpbGwgaGFwcGlseSBmaXQgaW50byBvdXIgdW5saW1pdGVk IG9uZXMuPGJyIC8+V2UgZG9uJ3QgbmVlZCBpdCB0byBzYXZlIG1lbW9yeSwgc2luY2UgdGhlIGV4 cGVjdGF0aW9uIGlzIHRoYXQgb25lPGJyIC8+dXNlcyBhIGRpY3Rpb25hcnkgKG9yIGNvbnMgY3Jl YXRpb24gb3Igc2ltaWxhciBhcHByb2FjaCkgdG8gZW5zdXJlPGJyIC8+dGhhdCB0aGUgaW1wbGVt ZW50YXRpb24gbmVlZHMgb25seSBvbmUgY29weSBvZiB0aGUgaWRlbnRpZmllciwgbm90PGJyIC8+ b25lIHBlciBpbnN0YW5jZS48YnIgLz5BcmUgdGhlcmUgYW55IHN0cm9uZyByZWFzb25zIHRvIGtl ZXAgdGhpcyByZXN0cmljdGlvbj8mbmJzcDsgSXNuJ3QgaXQ8YnIgLz5qdXN0IGEgQ0xSPyZuYnNw OyBXaWxsIGl0IGp1c3QgYmUgb25lIG9mIHRoZSBsaXN0IG9mICZxdW90O29oIG5vIG9uZSB3aWxs PGJyIC8+ZXZlciBuZWVkIHRoYXQmcXVvdDs/ICgmcXVvdDtObyBvbmUgd2lsbCBldmVyIG5lZWQg bW9yZSB0aGF0IDY0MEsmcXVvdDssICZxdW90O25vIG9uZTxiciAvPndpbGwgZXZlciBuZWVkIG1v cmUgdGhhdCA4LjMgZmlsZW5hbWVzJnF1b3Q7LCAmcXVvdDtubyBvbmUgd2lsbCBldmVyIG5lZWQ8 YnIgLz5tb3JlIHRoYXQgZm91ciBwYXJ0aXRpb25zJnF1b3Q7LCAmcXVvdDtubyBvbmUgd2lsbCBl dmVyIG5lZWQgbW9yZSB0aGFuIG9uZTxiciAvPmRpc3BsYXkgb24gdGhlaXIgY29tcHV0ZXImcXVv dDssICZxdW90O25vIG9uZSB3aWxsIGV2ZXIgbmVlZCBhIGJvb2sgb24gdG93ZWw8YnIgLz5vcmln YW1pJnF1b3Q7IChodHRwOi8vdGlueXVybC5jb20vZHlncGZyKSkuPGJyIC8+PGJyIC8+SSBhbSBj b252aW5jZWQgdGhhdCBpbnRlcm9wZXJhYmlsaXR5IHdpbGwgbm90IGJlIGFjaGlldmVkPGJyIC8+ d2l0aG91dCBhIHNwZWNpZmljIHJ1bGUsIGFuZCB0aGF0IGlzIHdoeSB3ZSBhcmUgd3JpdGluZyB0 aGlzIHN0YW5kYXJkLjxiciAvPldlcywgSnVlcmdlbiwgRGF2aWQsIFN0ZXZlLCBhbmQgSSBoYXZl IGFsbCBzdGF0ZWQgdXNlLWNhc2VzPGJyIC8+Zm9yIHBpY2tpbmcgYSBzcGVjaWZpYyBmaW5pdGUg dXBwZXItYm91bmQgaW5zdGVhZCBvZiBpbmZpbml0eS48YnIgLz48YnIgLz48YnIgLz5UaGFua3Ms PGJyIC8+UGhpbDxiciAvPjxiciAvPkFuZHk8YnIgLz48YnIgLz48YnIgLz5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciAvPm5ldG1vZCBtYWlsaW5nIGxp c3Q8YnIgLz5uZXRtb2RAaWV0Zi5vcmc8YnIgLz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldG1vZDxiciAvPjxiciAvPiZuYnNwOzwvZGl2Pg== ---------------355491.937195895-- --------------------_Boundary_60322838.8485956-- From randy_presuhn@mindspring.com Thu Apr 2 19:29:34 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65B263A685E for ; Thu, 2 Apr 2009 19:29:34 -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=[AWL=-1.066, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHoVci2vWb4R for ; Thu, 2 Apr 2009 19:29:33 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 5B6703A67F8 for ; Thu, 2 Apr 2009 19:27:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=eki0dJbKfZhom2Yu8xrcGt8gCDbPrTa5SM0U4Dk1mdmcIWKDA/YEA7Fyl1m8Sd0n; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [69.3.145.86] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LpZ9N-0006G5-71 for netmod@ietf.org; Thu, 02 Apr 2009 22:28:57 -0400 Message-ID: <000c01c9b404$2f1d7ba0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200904021551.n32FpN5N014641@idle.juniper.net> Date: Thu, 2 Apr 2009 19:30:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173e2063de682837ed27f00b042a9867e48350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.145.86 Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 02:29:34 -0000 Hi - > From: "Phil Shafer" > To: "Andy Bierman" > Cc: > Sent: Thursday, April 02, 2009 8:51 AM > Subject: Re: [netmod] identifier length survey ... > In any case, this whole thread continues to devolve into mud > wrestling. Would the WG chairs please step in and determine if a > concensus exists? ... I have to admit being rather astonished by this thread. The existing text, which simply puts a limit to the longest identifier implementations are *required* to support (and in no way prevents implementations from supporting longer things) seems eminently reasonable. Consider it from the perspective of someone attempting to test whether a tool conforms to the specification. If there is no "minimum maximum length" requirement, then any tool which *ever* emits an "identifier too long" error is arguably non-conformant, and conformance test tools will almost certainly include grotesquely and ever- increasingly long identifiers as part of their test cases. This would seen to be a type of pathological behaviour we should not encourage. Randy From phil@juniper.net Fri Apr 3 05:25:29 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C7143A6358 for ; Fri, 3 Apr 2009 05:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4omAPRmGOlW for ; Fri, 3 Apr 2009 05:25:22 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id D16BA3A682A for ; Fri, 3 Apr 2009 05:25:13 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSdYAZt6S/jf1N79UJm8o5NqwVdnqqqp4@postini.com; Fri, 03 Apr 2009 05:26:22 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Fri, 3 Apr 2009 05:25:29 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 05:25:29 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 05:25:29 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 05:25:28 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n33CPRM46552; Fri, 3 Apr 2009 05:25:28 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n33CIF9b022912; Fri, 3 Apr 2009 12:18:15 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904031218.n33CIF9b022912@idle.juniper.net> To: Andy Bierman Date: Fri, 3 Apr 2009 08:18:15 -0400 From: Phil Shafer X-OriginalArrivalTime: 03 Apr 2009 12:25:28.0595 (UTC) FILETIME=[45FA3630:01C9B457] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: [netmod] A way forward? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 12:25:29 -0000 Andy Bierman writes: >But the most important reason is to protect >operator readability and usability, not to >protect implementors. Code can always be changed. If this is the key reason, perhaps we can work a compromise. Readability of identifiers is a usability and style issue, and is more suitable for the IETF guidelines document than for YANG itself. Can I suggest that we fix the YANG draft to remove the wording on identifier length (and the minor interoperability issue that it brings) and that we make this "64 character hard limit" part of the "IETF Guidelines for YANG" document? This allows us to make other identifier guidelines like: - Do not use multiple adjacent dashes (like 'watch--out') - Do not mix dashes and underscores (like 'oh-no_you_did-not') - Do not end with a dash (like 'error-') - Do not use profanity (like, um, well, you get the idea) or whatever additional guidelines we want. Such guidelines are not suitable for YANG itself, but will make a perfect addition to the guidelines document. This proposal would allow future-proofing, removes the CLR, but still allow toolsets that are only targeting IETF work to rely on this restriction. Thanks, Phil From lhotka@cesnet.cz Fri Apr 3 06:00:52 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85DE23A6AC4 for ; Fri, 3 Apr 2009 06:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1wAM+FJF9Bi for ; Fri, 3 Apr 2009 06:00:51 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id AF0F53A683F for ; Fri, 3 Apr 2009 06:00:51 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id CBD2ED800F0 for ; Fri, 3 Apr 2009 15:01:51 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <200904031218.n33CIF9b022912@idle.juniper.net> References: <200904031218.n33CIF9b022912@idle.juniper.net> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 03 Apr 2009 15:01:51 +0200 Message-Id: <1238763711.1145.16.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] A way forward? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 13:00:52 -0000 Phil Shafer píše v Pá 03. 04. 2009 v 08:18 -0400: > Andy Bierman writes: > >But the most important reason is to protect > >operator readability and usability, not to > >protect implementors. Code can always be changed. > > If this is the key reason, perhaps we can work a compromise. > Readability of identifiers is a usability and style issue, and is > more suitable for the IETF guidelines document than for YANG itself. > > Can I suggest that we fix the YANG draft to remove the wording on > identifier length (and the minor interoperability issue that it > brings) and that we make this "64 character hard limit" part of the > "IETF Guidelines for YANG" document? +1 Lada > > This allows us to make other identifier guidelines like: > > - Do not use multiple adjacent dashes (like 'watch--out') > - Do not mix dashes and underscores (like 'oh-no_you_did-not') > - Do not end with a dash (like 'error-') > - Do not use profanity (like, um, well, you get the idea) > > or whatever additional guidelines we want. Such guidelines are not > suitable for YANG itself, but will make a perfect addition to the > guidelines document. > > This proposal would allow future-proofing, removes the CLR, but > still allow toolsets that are only targeting IETF work to rely on > this restriction. > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Fri Apr 3 08:21:43 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB51128C288 for ; Fri, 3 Apr 2009 08:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vt4tFf010nix for ; Fri, 3 Apr 2009 08:21:43 -0700 (PDT) Received: from n12a.bullet.mail.mud.yahoo.com (n12a.bullet.mail.mud.yahoo.com [209.191.125.177]) by core3.amsl.com (Postfix) with SMTP id 226B528C283 for ; Fri, 3 Apr 2009 08:21:43 -0700 (PDT) Received: from [68.142.200.225] by n12.bullet.mail.mud.yahoo.com with NNFMP; 03 Apr 2009 15:22:45 -0000 Received: from [68.142.201.243] by t6.bullet.mud.yahoo.com with NNFMP; 03 Apr 2009 15:22:45 -0000 Received: from [127.0.0.1] by omp404.mail.mud.yahoo.com with NNFMP; 03 Apr 2009 15:22:45 -0000 X-Yahoo-Newman-Id: 407225.52900.bm@omp404.mail.mud.yahoo.com Received: (qmail 48246 invoked from network); 3 Apr 2009 15:22:44 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 3 Apr 2009 15:22:44 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D629C2.6050003@netconfcentral.com> Date: Fri, 03 Apr 2009 08:22:42 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200904031218.n33CIF9b022912@idle.juniper.net> In-Reply-To: <200904031218.n33CIF9b022912@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] A way forward? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:21:44 -0000 Phil Shafer wrote: > Andy Bierman writes: >> But the most important reason is to protect >> operator readability and usability, not to >> protect implementors. Code can always be changed. > > If this is the key reason, perhaps we can work a compromise. > Readability of identifiers is a usability and style issue, and is > more suitable for the IETF guidelines document than for YANG itself. > > Can I suggest that we fix the YANG draft to remove the wording on > identifier length (and the minor interoperability issue that it > brings) and that we make this "64 character hard limit" part of the > "IETF Guidelines for YANG" document? > This does not fix anything. Either keep the current text or change it to match the SMIv2 text. > This allows us to make other identifier guidelines like: > > - Do not use multiple adjacent dashes (like 'watch--out') > - Do not mix dashes and underscores (like 'oh-no_you_did-not') > - Do not end with a dash (like 'error-') > - Do not use profanity (like, um, well, you get the idea) > > or whatever additional guidelines we want. Such guidelines are not > suitable for YANG itself, but will make a perfect addition to the > guidelines document. > > This proposal would allow future-proofing, removes the CLR, but > still allow toolsets that are only targeting IETF work to rely on > this restriction. > > Thanks, > Phil > > Andy From reid@snmp.com Fri Apr 3 14:05:09 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF5763A6940 for ; Fri, 3 Apr 2009 14:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qm8MU7Ai+xv1 for ; Fri, 3 Apr 2009 14:05:09 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id E94373A691E for ; Fri, 3 Apr 2009 14:05:08 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA17329; Fri, 3 Apr 2009 17:06:10 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id RAA02039; Fri, 3 Apr 2009 17:06:10 -0400 (EDT) Message-Id: <200904032106.RAA02039@adminfs.snmp.com> To: David Reid , "netmod@ietf.org" From: David Reid In-reply-to: Your message of Wed, 01 Apr 2009 23:48:40 +0200. <20090401214840.GB16843@elstar.local> Date: Fri, 03 Apr 2009 17:06:09 -0400 Sender: reid@snmp.com Subject: Re: [netmod] SMIv2 to YANG mapping: OCTET STRING X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 03 Apr 2009 21:05:09 -0000 > On Wed, Apr 01, 2009 at 08:18:00PM +0200, David Reid wrote: > > > When converting an SMIv2 OCTET STRING to YANG, should the YANG type be > > string or binary? Juergen has a clever solution: if the OCTET STRING has a > > DISPLAY-HINT, map to string, otherwise, map to binary. The only problem I > > have with that approach is that it is legal to add a DISPLAY-HINTS clause > > when revising a MIB module, but that would cause the YANG type to change, > > which is not a legal revision. > > Good catch. Too bad that this approach can fail... Does anyone have a better idea? We could always use binary in every case, but that's ugly. -David Reid From reid@snmp.com Fri Apr 3 14:21:13 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 990FF3A67AE for ; Fri, 3 Apr 2009 14:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqUcfhdxn69M for ; Fri, 3 Apr 2009 14:21:12 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id A6F123A63CB for ; Fri, 3 Apr 2009 14:21:12 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA18977; Fri, 3 Apr 2009 17:22:13 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id RAA02614; Fri, 3 Apr 2009 17:22:08 -0400 (EDT) Message-Id: <200904032122.RAA02614@adminfs.snmp.com> To: Juergen Schoenwaelder From: David Reid In-reply-to: Your message of Wed, 01 Apr 2009 23:42:38 +0200. <20090401214238.GA16843@elstar.local> Date: Fri, 03 Apr 2009 17:22:08 -0400 Sender: reid@snmp.com Cc: "netmod@ietf.org" Subject: Re: [netmod] SMIv2 to YANG mapping: OBJECT-IDENTITY X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 03 Apr 2009 21:21:13 -0000 > On Wed, Apr 01, 2009 at 08:10:36PM +0200, David Reid wrote: > > > > o Need to add support for the translation of OBJECT-IDENTITY macro > > > invocations to YANG identity statements. > > > > The biggest problem I'm having with OBJECT-IDENTITY is knowing when to map > > a SYNTAX clause of a MIB object with a SYNTAX of OBJECT IDENTIFIER to > > a YANG identityref. > > There is likely no good answer since the SMIv2 does not distinguish > how OBJECT IDENTIFIERs are used. I was afraid of that. I can't come up with a good answer. Here is a possibility: use a yang extension to carry the SMIv2 OID information from the SMIv2 OBJECT-IDENTITY to the YANG identity and then just convert the SMIv2 OBJECT IDENTIFIER SYNTAX to a YANG object-identifier type in all cases. identity snmpUDPDomain { smiv2:oid "1.3.6.1.6.1.1"; base "smiv2-global-base"; description "The SNMP over UDP over IPv4 transport..."; } leaf snmpTargetAddrTDomain { type object-identifier; config true; description "This object indicates the transport type of the address..."; } That doesn't seem very YANG-like, but I think it could work. -David Reid From Washam.Fan@huaweisymantec.com Fri Apr 3 20:57:20 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5772D3A687F for ; Fri, 3 Apr 2009 20:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXHGQ85qFeU6 for ; Fri, 3 Apr 2009 20:57:19 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 606B13A6810 for ; Fri, 3 Apr 2009 20:57:19 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHI001V8867TO40@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Fri, 03 Apr 2009 10:56:33 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHI00H2O8657A00@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Fri, 03 Apr 2009 10:56:31 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Fri, 03 Apr 2009 10:56:29 +0800 From: WashamFan To: Juergen Schoenwaelder Message-id: Date: Fri, 03 Apr 2009 10:56:29 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090402193121.GA24821@elstar.local> References: <200904021723.n32HNwP9015674@idle.juniper.net> <49D4F9E3.3080008@netconfcentral.com> <20090402193121.GA24821@elstar.local> Cc: "netmod@ietf.org" Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 03:57:20 -0000 Hi, The interpretation by Juergen makes more sence to me. 63 or 64 limit is a minimum baseline for interoperability, but not expected to impose a upper-bound at all. When I write a identifier within 63 or 64 characters, I don't worry about compliant implementation would reject it. But I still can write a identifier beyond the limit, when I know the peer could handle it or at the risk of rejection. So the limit means it is safe to write identifier with the limit even I don't know you much but you are compliant. BTW, any implementation supporting beyond the limit is compliant. Unless all implementation can support infinity, limit MATTERS for interoperability, then, readability. washam > On Thu, Apr 02, 2009 at 07:46:11PM +0200, Andy Bierman wrote: > > > I am convinced that interoperability will not be achieved > > without a specific rule, and that is why we are writing this standard. > > Wes, Juergen, David, Steve, and I have all stated use-cases > > for picking a specific finite upper-bound instead of infinity. > > Clarification: The current sentence does _not_ define a specific > upper-bound - it establishes a minimum baseline everybody has to > implement but leaves the upper bound open. > > I thought this was a workable compromise but it seems I was wrong... > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 < > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From lhotka@cesnet.cz Sat Apr 4 02:46:42 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8724A3A6978 for ; Sat, 4 Apr 2009 02:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.926 X-Spam-Level: X-Spam-Status: No, score=-0.926 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wduZR0QKLdkH for ; Sat, 4 Apr 2009 02:46:41 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 5B8BE3A6870 for ; Sat, 4 Apr 2009 02:46:41 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 75C3ED800C5 for ; Sat, 4 Apr 2009 11:47:43 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <000c01c9b404$2f1d7ba0$6801a8c0@oemcomputer> References: <200904021551.n32FpN5N014641@idle.juniper.net> <000c01c9b404$2f1d7ba0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Sat, 04 Apr 2009 11:47:42 +0200 Message-Id: <1238838462.6401.20.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 09:46:42 -0000 Randy Presuhn píše v Čt 02. 04. 2009 v 19:30 -0700: > Hi - > > > From: "Phil Shafer" > > To: "Andy Bierman" > > Cc: > > Sent: Thursday, April 02, 2009 8:51 AM > > Subject: Re: [netmod] identifier length survey > ... > > In any case, this whole thread continues to devolve into mud > > wrestling. Would the WG chairs please step in and determine if a > > concensus exists? > ... > > I have to admit being rather astonished by this thread. The > existing text, which simply puts a limit to the longest identifier > implementations are *required* to support (and in no way > prevents implementations from supporting longer things) > seems eminently reasonable. Consider it from the perspective > of someone attempting to test whether a tool conforms to the > specification. If there is no "minimum maximum length" > requirement, then any tool which *ever* emits an "identifier > too long" error is arguably non-conformant, and conformance I don't agree. If there is no limit specified in the language, there is also no way to become non-conformant. This of course doesn't mean that a device is required to support arbitrarily long identifiers. Imagine a really simple device that is to support a given data model. Its designer can find out by reading the data model the *actual* identifier length that has to be supported and implements the identifier type to be, e.g., 32 chars long. This should IMO be perfectly fine, whereas with the current wording the implementation can be potentially accused as being non-conformant. The solution suggested by Phil (no limit in the language spec and 63-char limit in the guidelines) should IMO be sufficient to avoid any problems with identifier length. Lada > test tools will almost certainly include grotesquely and ever- > increasingly long identifiers as part of their test cases. > This would seen to be a type of pathological behaviour > we should not encourage. > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Sat Apr 4 06:47:59 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C9ED3A6817 for ; Sat, 4 Apr 2009 06:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Sn2ms3PwgFN for ; Sat, 4 Apr 2009 06:47:58 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 9B2CB3A689A for ; Sat, 4 Apr 2009 06:47:58 -0700 (PDT) Received: (qmail 9670 invoked from network); 4 Apr 2009 13:48:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 4 Apr 2009 13:48:58 -0000 X-YMail-OSG: vpRDRFoVM1mxsyjTjjfXeiQrKUUK5H.xusUbVjLSOXdVlWo9eNfGAHBjdCoBvVCnY9mJbcP7QadBD9_OSC1PfYe9yomzlLeEa_lHIG18wj1zg1BVaOlpzkeXHnlKUmL2e156ICpNHzFpOoGyQz.msoowUFVwr.Kfpj7DSsZfhImPrEDbmLCi5WdDqMnHigV5uReorGC01EFZb1bUVsgXOMZrXBdGXDjBIglaIgI8DuXoYw5vx0xYf2J.mOUNbxUmpUVYVMkKZiV7wPh.Uh9BS6aKzkIaiNwXtgVgwvPvFWCB8_ny X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D76548.5040103@netconfcentral.com> Date: Sat, 04 Apr 2009 06:48:56 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ladislav Lhotka References: <200904021551.n32FpN5N014641@idle.juniper.net> <000c01c9b404$2f1d7ba0$6801a8c0@oemcomputer> <1238838462.6401.20.camel@missotis> In-Reply-To: <1238838462.6401.20.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 13:47:59 -0000 Ladislav Lhotka wrote: > Randy Presuhn píše v Čt 02. 04. 2009 v 19:30 -0700: >> Hi - >> >>> From: "Phil Shafer" >>> To: "Andy Bierman" >>> Cc: >>> Sent: Thursday, April 02, 2009 8:51 AM >>> Subject: Re: [netmod] identifier length survey >> ... >>> In any case, this whole thread continues to devolve into mud >>> wrestling. Would the WG chairs please step in and determine if a >>> concensus exists? >> ... >> >> I have to admit being rather astonished by this thread. The >> existing text, which simply puts a limit to the longest identifier >> implementations are *required* to support (and in no way >> prevents implementations from supporting longer things) >> seems eminently reasonable. Consider it from the perspective >> of someone attempting to test whether a tool conforms to the >> specification. If there is no "minimum maximum length" >> requirement, then any tool which *ever* emits an "identifier >> too long" error is arguably non-conformant, and conformance > > I don't agree. If there is no limit specified in the language, there is > also no way to become non-conformant. This of course doesn't mean that a > device is required to support arbitrarily long identifiers. > really? I agree with Randy. It seems to me that unless your tools have infinite memory, there is no way to implement a compliant tool. > Imagine a really simple device that is to support a given data model. > Its designer can find out by reading the data model the *actual* > identifier length that has to be supported and implements the identifier > type to be, e.g., 32 chars long. This should IMO be perfectly fine, > whereas with the current wording the implementation can be potentially > accused as being non-conformant. > this is a fragile hack. imagine 2 siblings with the same length identifier. since XML node order is not enforced except for list keys, any heuristic used to optimize away the identifier names is fragile. This hack does not address readability or bandwidth concerns at all. > The solution suggested by Phil (no limit in the language spec and > 63-char limit in the guidelines) should IMO be sufficient to avoid any > problems with identifier length. > The guidelines spec is an Informational RPC, and not part of the standard. > Lada > Andy > >> test tools will almost certainly include grotesquely and ever- >> increasingly long identifiers as part of their test cases. >> This would seen to be a type of pathological behaviour >> we should not encourage. >> >> Randy >> From andy@netconfcentral.com Sat Apr 4 07:04:10 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35A893A67D2 for ; Sat, 4 Apr 2009 07:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fG5cDdFZJKw4 for ; Sat, 4 Apr 2009 07:04:09 -0700 (PDT) Received: from n20.bullet.mail.mud.yahoo.com (n20.bullet.mail.mud.yahoo.com [68.142.206.147]) by core3.amsl.com (Postfix) with SMTP id 469703A6784 for ; Sat, 4 Apr 2009 07:04:09 -0700 (PDT) Received: from [68.142.200.221] by n20.bullet.mail.mud.yahoo.com with NNFMP; 04 Apr 2009 14:05:12 -0000 Received: from [68.142.201.73] by t9.bullet.mud.yahoo.com with NNFMP; 04 Apr 2009 14:05:12 -0000 Received: from [127.0.0.1] by omp425.mail.mud.yahoo.com with NNFMP; 04 Apr 2009 14:05:12 -0000 X-Yahoo-Newman-Id: 842144.94062.bm@omp425.mail.mud.yahoo.com Received: (qmail 48469 invoked from network); 4 Apr 2009 14:05:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 4 Apr 2009 14:05:11 -0000 X-YMail-OSG: _wiGwasVM1n3HyO5H.ph8zFNt5gGUjuLlO.G8__Cyh3Cn5CS05Z.M4EPPbWD_6ZuCetcxsdr_1AGa7__FpmyeTq6LkIqRexDx.8c4BkRn89Doosk6zL1bGAUppHdBOjMXVo3Bqa9hs0U4N7FVvbKAlTZxNXPb9gHIOyP1LmYemTGxA0fZc27w1rRNIl8bMPP4VlZJiLaf72kERSRpoyXSqL.X40CybpypF6LSVQUMM6PV5YTA25LJcOI2v_fbbnq3unCmVCfqRcPh.NpYbWAuzwkGT3vYNe5RV4T6PVMGmXQDbyL X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D76916.30801@netconfcentral.com> Date: Sat, 04 Apr 2009 07:05:10 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Randy Presuhn References: <200904021551.n32FpN5N014641@idle.juniper.net> <000c01c9b404$2f1d7ba0$6801a8c0@oemcomputer> In-Reply-To: <000c01c9b404$2f1d7ba0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 14:04:10 -0000 Randy Presuhn wrote: > Hi - > >> From: "Phil Shafer" >> To: "Andy Bierman" >> Cc: >> Sent: Thursday, April 02, 2009 8:51 AM >> Subject: Re: [netmod] identifier length survey > ... >> In any case, this whole thread continues to devolve into mud >> wrestling. Would the WG chairs please step in and determine if a >> concensus exists? > ... > > I have to admit being rather astonished by this thread. me too. Usually, changes in an I-D are driven by use-cases. One would think that there was a real need somewhere to use > 64 char identifiers. But nobody *wants* to use > 64 identifiers. There have been some bad effects listed from using long identifiers, but no benefits. XML allows PIs, DTDs, XML attributes, etc. and NETCONF/YANG supports none of it. It seems rather arbitrary to say YANG MUST support infinite length names just because XML supports it. There are plenty of features YANG has removed from XML because they are not needed in NETCONF. This is just one more. > existing text, which simply puts a limit to the longest identifier > implementations are *required* to support (and in no way > prevents implementations from supporting longer things) > seems eminently reasonable. Consider it from the perspective > of someone attempting to test whether a tool conforms to the > specification. If there is no "minimum maximum length" > requirement, then any tool which *ever* emits an "identifier > too long" error is arguably non-conformant, and conformance > test tools will almost certainly include grotesquely and ever- > increasingly long identifiers as part of their test cases. > This would seen to be a type of pathological behaviour > we should not encourage. > > Randy > Andy From lhotka@cesnet.cz Sat Apr 4 07:34:51 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A8623A6980 for ; Sat, 4 Apr 2009 07:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5Zk6FZI0V6y for ; Sat, 4 Apr 2009 07:34:50 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B6B143A6860 for ; Sat, 4 Apr 2009 07:34:50 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id D830FD800BD; Sat, 4 Apr 2009 16:35:51 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49D76548.5040103@netconfcentral.com> References: <200904021551.n32FpN5N014641@idle.juniper.net> <000c01c9b404$2f1d7ba0$6801a8c0@oemcomputer> <1238838462.6401.20.camel@missotis> <49D76548.5040103@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Sat, 04 Apr 2009 16:35:52 +0200 Message-Id: <1238855752.6401.45.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 14:34:51 -0000 Andy Bierman píše v So 04. 04. 2009 v 06:48 -0700: > > really? > I agree with Randy. > It seems to me that unless your tools have infinite memory, > there is no way to implement a compliant tool. Just the opposite - implementations will be compliant even if they only support single byte identifiers. It is the same in XML. Although there is no limit on element name length, a program using for instance RSS can get along with 32 bytes, perhaps even 16, I am not sure. Does it mean that it doesn't conform to XML 1.0? > > > Imagine a really simple device that is to support a given data model. > > Its designer can find out by reading the data model the *actual* > > identifier length that has to be supported and implements the identifier > > type to be, e.g., 32 chars long. This should IMO be perfectly fine, > > whereas with the current wording the implementation can be potentially > > accused as being non-conformant. > > > > this is a fragile hack. > imagine 2 siblings with the same length identifier. > since XML node order is not enforced except for list keys, > any heuristic used to optimize away the identifier names > is fragile. This hack does not address readability or > bandwidth concerns at all. I am not sure where the hack is. My point is that the manager cannot throw arbitrary identifiers on the device (and vice versa), but only the ones present in the data model that the device supports. > > > The solution suggested by Phil (no limit in the language spec and > > 63-char limit in the guidelines) should IMO be sufficient to avoid any > > problems with identifier length. > > > > The guidelines spec is an Informational RPC, > and not part of the standard. > For sane people this should be enough, and insane people are not limited by the current wording of the YANG spec anyway. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Sat Apr 4 08:55:56 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAB103A6A3F for ; Sat, 4 Apr 2009 08:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOVcOeBV+U5J for ; Sat, 4 Apr 2009 08:55:56 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 062C43A6A31 for ; Sat, 4 Apr 2009 08:55:55 -0700 (PDT) Received: (qmail 4631 invoked from network); 4 Apr 2009 15:56:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 4 Apr 2009 15:56:59 -0000 X-YMail-OSG: SfGbCkYVM1kZSBnPXqQmGmviQ9DmCAsTjUJj.VepnBAYUz_mIpHTrZM3nEklwz1Q0.wwUYF0lnafl5ylxfeloEg4_MFEBZ2m4P.S1mvwZKcSjfLfCjhclSbCu.t.yZjpvwFneHaJ9IWzTQmAYvIbkRb1fQ6FWZuQHDusAIq1bLTHU.bLtssw8LvXIByb8OSV0bjaltZqx7TSbGRhs59EXy1TLhvK1jqDmjhL321TiIIxtwZiQsR8oloH_tdNlfErsyScRXTKwrHUhFI0 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D78349.4010404@netconfcentral.com> Date: Sat, 04 Apr 2009 08:56:57 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] yang-04: when-stmt and rpc/input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 15:55:56 -0000 Hi, The section on the rpc input statement is not clear enough. I don't know what para 2 means: If a container in the input tree has a "presence" statement, the container need not be present in a NETCONF RPC invocation. An NP container does not have to be present unless it has 1 or more mandatory descendants. Let's not override the mandatory true/false flag in this special case (rpc/input). If the container is mandatory=false then it is optional. The presence-stmt is still relevant. Somebody could define an RPC method where an empty container meant something and they would put it in the presence-stmt. The when-stmt is not mentioned at all. IMO, the agent should ignore when-stmt for rpc/input. The 'delete-all-false-when-stmts' procedure does not make any sense on an RPC invocation, if the XPath expression includes any nodes in the RPC definition itself. A procedure for processing when-stmt on rpc/input is needed, or some text that says it does not apply to the agent. 7.19.5. The when Statement The "when" statement makes its parent data definition statement conditional. The node defined by the parent data definition statement is only valid when the condition specified by the "when" statement is satisfied. I don't know exactly what 'valid' means in sentence 2 above. I know what it means for must-stmt: for a , or an on , the result must satisfy the must expressions. For when-stmt, it seems the agent just silently deletes false nodes. This does not seem like a good idea on /rpc/input contents. It seems strange to return an 'unknown-element' error in this case, but that is the closest error code. Maybe another error-app-tag (false-when-expr?) might help applications figure out what went wrong. Andy From phil@juniper.net Sat Apr 4 09:46:59 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A3D3A6A38 for ; Sat, 4 Apr 2009 09:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbiChoduNQWC for ; Sat, 4 Apr 2009 09:46:59 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 19B293A6A03 for ; Sat, 4 Apr 2009 09:46:56 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSdePPgh4wOo1uar6J1Ngebn5OmYRgpGu@postini.com; Sat, 04 Apr 2009 09:48:03 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Sat, 4 Apr 2009 09:47:18 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Apr 2009 09:47:18 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Apr 2009 09:47:18 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 4 Apr 2009 09:47:17 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n34GlGM84625; Sat, 4 Apr 2009 09:47:16 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n34Ge3du030432; Sat, 4 Apr 2009 16:40:03 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904041640.n34Ge3du030432@idle.juniper.net> To: Andy Bierman In-Reply-To: <49D76548.5040103@netconfcentral.com> Date: Sat, 4 Apr 2009 12:40:03 -0400 From: Phil Shafer X-OriginalArrivalTime: 04 Apr 2009 16:47:17.0469 (UTC) FILETIME=[039BE8D0:01C9B545] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 16:46:59 -0000 Andy Bierman writes: >It seems to me that unless your tools have infinite memory, >there is no way to implement a compliant tool. Are you saying that if a spec allows arbitrary length strings, then it's not possible to implement compliant tools? Let's go the other way: How many times have the words "oh they couldn't possibly need more than that" turned out to be wrong in a painful and/or expensive way? How many specs have been repaired to remove limits or expand the number of bits in a fixed- width value (ipv6, 32bit ASes, etc)? How many times do we just have to live with someone else's idea of a great limit? Thanks, Phil From andy@netconfcentral.com Sat Apr 4 09:56:08 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 597393A69D2 for ; Sat, 4 Apr 2009 09:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTTyL+UOLEUb for ; Sat, 4 Apr 2009 09:56:07 -0700 (PDT) Received: from n21.bullet.mail.mud.yahoo.com (n21.bullet.mail.mud.yahoo.com [68.142.206.160]) by core3.amsl.com (Postfix) with SMTP id 514253A68B5 for ; Sat, 4 Apr 2009 09:56:07 -0700 (PDT) Received: from [68.142.200.221] by n21.bullet.mail.mud.yahoo.com with NNFMP; 04 Apr 2009 16:57:11 -0000 Received: from [68.142.201.246] by t9.bullet.mud.yahoo.com with NNFMP; 04 Apr 2009 16:57:11 -0000 Received: from [127.0.0.1] by omp407.mail.mud.yahoo.com with NNFMP; 04 Apr 2009 16:57:11 -0000 X-Yahoo-Newman-Id: 128080.92896.bm@omp407.mail.mud.yahoo.com Received: (qmail 93697 invoked from network); 4 Apr 2009 16:57:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 4 Apr 2009 16:57:09 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D79164.8000301@netconfcentral.com> Date: Sat, 04 Apr 2009 09:57:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ladislav Lhotka References: <200904021551.n32FpN5N014641@idle.juniper.net> <000c01c9b404$2f1d7ba0$6801a8c0@oemcomputer> <1238838462.6401.20.camel@missotis> <49D76548.5040103@netconfcentral.com> <1238855752.6401.45.camel@missotis> In-Reply-To: <1238855752.6401.45.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey (resend) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 16:56:08 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v So 04. 04. 2009 v 06:48 -0700: >> really? >> I agree with Randy. >> It seems to me that unless your tools have infinite memory, >> there is no way to implement a compliant tool. > > Just the opposite - implementations will be compliant even if they only > support single byte identifiers. > That would be a problem, not a feature. That is exactly why I have been debating this issue from the start, since it is the only real use-case for removing the '64' rule. Somebody could ask the IPFIX WG to rename every single object in the ipfix-psamp data model to 1 char names because their fully compliant YANG implementation only supports 1-char names. The point of the YANG standard is to define a data modeling language that all NETCONF/YANG implementations MUST support. That way, a WG like IPFIX can write a standard data model using 1 to 64 char names, and know that it will be accepted by every single compliant YANG implementation. If long names were really important, then they are supported by Juergen's current text. If not, the SMIv2 text is most appropriate. > It is the same in XML. Although there is no limit on element name > length, a program using for instance RSS can get along with 32 bytes, > perhaps even 16, I am not sure. Does it mean that it doesn't conform to > XML 1.0? > >>> Imagine a really simple device that is to support a given data model. >>> Its designer can find out by reading the data model the *actual* >>> identifier length that has to be supported and implements the identifier >>> type to be, e.g., 32 chars long. This should IMO be perfectly fine, >>> whereas with the current wording the implementation can be potentially >>> accused as being non-conformant. >>> >> this is a fragile hack. >> imagine 2 siblings with the same length identifier. >> since XML node order is not enforced except for list keys, >> any heuristic used to optimize away the identifier names >> is fragile. This hack does not address readability or >> bandwidth concerns at all. > > I am not sure where the hack is. My point is that the manager cannot > throw arbitrary identifiers on the device (and vice versa), but only the > ones present in the data model that the device supports. > >>> The solution suggested by Phil (no limit in the language spec and >>> 63-char limit in the guidelines) should IMO be sufficient to avoid any >>> problems with identifier length. >>> >> The guidelines spec is an Informational RPC, >> and not part of the standard. >> > > For sane people this should be enough, and insane people are not limited > by the current wording of the YANG spec anyway. > > Lada > Andy From phil@juniper.net Sat Apr 4 09:57:48 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C023A6963 for ; Sat, 4 Apr 2009 09:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0vL-GjvGazM for ; Sat, 4 Apr 2009 09:57:47 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 7D9333A6956 for ; Sat, 4 Apr 2009 09:57:43 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSdeRxpPguvcgLo25wwtzegON8J5fFf9u@postini.com; Sat, 04 Apr 2009 09:58:51 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Sat, 4 Apr 2009 09:57:23 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Apr 2009 09:57:23 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Apr 2009 09:57:23 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 4 Apr 2009 09:57:22 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n34GvLM87965; Sat, 4 Apr 2009 09:57:21 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n34Go8Fg030533; Sat, 4 Apr 2009 16:50:08 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904041650.n34Go8Fg030533@idle.juniper.net> To: Andy Bierman In-Reply-To: <49D76916.30801@netconfcentral.com> Date: Sat, 4 Apr 2009 12:50:08 -0400 From: Phil Shafer X-OriginalArrivalTime: 04 Apr 2009 16:57:22.0145 (UTC) FILETIME=[6C062510:01C9B546] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 16:57:48 -0000 Andy Bierman writes: >Usually, changes in an I-D are driven by use-cases. We don't need a use case to remove a CLR; we should have a use case to keep it. >It seems rather arbitrary >to say YANG MUST support infinite length names >just because XML supports it. There are plenty >of features YANG has removed from XML because they >are not needed in NETCONF. This is just one more. I don't think anyone said this. XML's lack of a length limit was used to disprove your claim that a specification with no limit cannot be implemented on machines without unlimited memory. My phone groks XML, so clearly this claim is false. Thanks, Phil From phil@juniper.net Sat Apr 4 10:04:41 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DD783A6A63 for ; Sat, 4 Apr 2009 10:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EaLFNECCChl for ; Sat, 4 Apr 2009 10:04:40 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id A51CF3A68DF for ; Sat, 4 Apr 2009 10:04:38 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSdeTZSyv//97D7PJZ4agbQdHtm0Sw8g6@postini.com; Sat, 04 Apr 2009 10:05:45 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Sat, 4 Apr 2009 10:02:27 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Apr 2009 10:02:27 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Apr 2009 10:02:26 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 4 Apr 2009 10:02:25 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n34H2PM90051; Sat, 4 Apr 2009 10:02:25 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n34GtCqi030613; Sat, 4 Apr 2009 16:55:12 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904041655.n34GtCqi030613@idle.juniper.net> To: Andy Bierman In-Reply-To: <49D79164.8000301@netconfcentral.com> Date: Sat, 4 Apr 2009 12:55:11 -0400 From: Phil Shafer X-OriginalArrivalTime: 04 Apr 2009 17:02:25.0858 (UTC) FILETIME=[210D1220:01C9B547] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey (resend) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 17:04:41 -0000 >Ladislav Lhotka wrote: > Just the opposite - implementations will be compliant even if they only > support single byte identifiers. I disagree with this. An SSH implementation called support a 1-character username or comment just because the spec lists these as "arbitrary length strings". Thanks, Phil From lhotka@cesnet.cz Sat Apr 4 10:11:20 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 076CD3A6A26 for ; Sat, 4 Apr 2009 10:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbpFJw5cOM2A for ; Sat, 4 Apr 2009 10:11:19 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3F4153A68C1 for ; Sat, 4 Apr 2009 10:11:18 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 9986CD800C8; Sat, 4 Apr 2009 19:12:22 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49D77654.3020103@netconfcentral.com> References: <200904021551.n32FpN5N014641@idle.juniper.net> <000c01c9b404$2f1d7ba0$6801a8c0@oemcomputer> <1238838462.6401.20.camel@missotis> <49D76548.5040103@netconfcentral.com> <1238855752.6401.45.camel@missotis> <49D77654.3020103@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Sat, 04 Apr 2009 19:12:22 +0200 Message-Id: <1238865142.6401.60.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 17:11:20 -0000 Andy Bierman píše v So 04. 04. 2009 v 08:01 -0700: > That way, a WG like IPFIX can write a standard data model > using 1 to 64 char names, and know that it will be > accepted by every single compliant YANG implementation. > > If long names were really important, then they > are supported by Juergen's current text. > If not, the SMIv2 text is most appropriate. > Right, so for IPFIX you can use your implementation with 64-byte identifiers, in severely resource-constrained devices you may want use a small footprint implementation limited to 8-byte identifiers and three levels of hierarchy (because the data models were designed accordingly), and if very long identifiers are needed, yet another implementation might be necessary. I don't know why any of these should be labelled as non-compliant. Supported identifier length, together will other important parameters, will just be a property of an implementation. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From jmh@joelhalpern.com Sat Apr 4 10:20:59 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 862DD3A6826 for ; Sat, 4 Apr 2009 10:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.48 X-Spam-Level: X-Spam-Status: No, score=-3.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ED5IKy67DRdc for ; Sat, 4 Apr 2009 10:20:58 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id D51253A67B0 for ; Sat, 4 Apr 2009 10:20:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id F06F643042A; Sat, 4 Apr 2009 10:22:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-88.clppva.btas.verizon.net [71.161.52.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 303A143040F; Sat, 4 Apr 2009 10:22:02 -0700 (PDT) Message-ID: <49D79734.2080603@joelhalpern.com> Date: Sat, 04 Apr 2009 13:21:56 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ladislav Lhotka References: <200904021551.n32FpN5N014641@idle.juniper.net> <000c01c9b404$2f1d7ba0$6801a8c0@oemcomputer> <1238838462.6401.20.camel@missotis> <49D76548.5040103@netconfcentral.com> <1238855752.6401.45.camel@missotis> <49D77654.3020103@netconfcentral.com> <1238865142.6401.60.camel@missotis> In-Reply-To: <1238865142.6401.60.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 17:20:59 -0000 I keep reading this discussion and wondering if I am misunderstanding all of the participants. As I understand things, our primary goal here is interoperability. It would seem that the key definition of interoperability for netmod is that all models can be processed by all implementations. If so, then the message below seems to amount to a statement that without some sort of length limit, we will fail interoperability. I under stand Phil's point that any specific limit we pick looks like a silly rule that we picked out of thin air. But it would seem that interoperability requires some mandatory limit, somewhere. (I suppose it can go in some document other than the protocol document, but since it is a piece of information needed by all protocol implementors and virtually all model writers, the protocol would seem the place to put it.) Yours, Joel M. Halpern Ladislav Lhotka wrote: > Andy Bierman píše v So 04. 04. 2009 v 08:01 -0700: > >> That way, a WG like IPFIX can write a standard data model >> using 1 to 64 char names, and know that it will be >> accepted by every single compliant YANG implementation. >> >> If long names were really important, then they >> are supported by Juergen's current text. >> If not, the SMIv2 text is most appropriate. >> > > Right, so for IPFIX you can use your implementation with 64-byte > identifiers, in severely resource-constrained devices you may want use a > small footprint implementation limited to 8-byte identifiers and three > levels of hierarchy (because the data models were designed accordingly), > and if very long identifiers are needed, yet another implementation > might be necessary. I don't know why any of these should be labelled as > non-compliant. > > Supported identifier length, together will other important parameters, > will just be a property of an implementation. > > Lada > From andy@netconfcentral.com Sat Apr 4 10:42:28 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FD443A6963 for ; Sat, 4 Apr 2009 10:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwsmXnLA98Z5 for ; Sat, 4 Apr 2009 10:42:27 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id D725C3A659B for ; Sat, 4 Apr 2009 10:42:27 -0700 (PDT) Received: (qmail 8976 invoked from network); 4 Apr 2009 17:43:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 4 Apr 2009 17:43:31 -0000 X-YMail-OSG: shEt6P0VM1m8YwkNggIbcNkp0Gip3.IJhhXgJWeVow1f67CbuMYdd0CBMokI5AHGxc3lwtFrQlQTJZNODcuhbGkUL5ZdM69z0TwGAy2Yt4kykB9Svz9PYKbb_ryXur7oZmqKx1LTvsk2SaqSs8M8KDwX35SAgida1nZUbY1J.OlenJj9_ZaAsgn47JGMPLdAOr55vITSFFgRMyh6rR75gf1vdKKxwNj7sm4uYHfXBB9mgo7U2XhAiq8Tr1C9vc.C39KNao8Bed3QNY5Z X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D79C41.9080003@netconfcentral.com> Date: Sat, 04 Apr 2009 10:43:29 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Joel M. Halpern" References: <200904021551.n32FpN5N014641@idle.juniper.net> <000c01c9b404$2f1d7ba0$6801a8c0@oemcomputer> <1238838462.6401.20.camel@missotis> <49D76548.5040103@netconfcentral.com> <1238855752.6401.45.camel@missotis> <49D77654.3020103@netconfcentral.com> <1238865142.6401.60.camel@missotis> <49D79734.2080603@joelhalpern.com> In-Reply-To: <49D79734.2080603@joelhalpern.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 17:42:28 -0000 Joel M. Halpern wrote: > I keep reading this discussion and wondering if I am misunderstanding > all of the participants. > > As I understand things, our primary goal here is interoperability. > > It would seem that the key definition of interoperability for netmod is > that all models can be processed by all implementations. > IMO, that would be the point of a standard data modeling language > If so, then the message below seems to amount to a statement that > without some sort of length limit, we will fail interoperability. > I under stand Phil's point that any specific limit we pick looks like a > silly rule that we picked out of thin air. But it would seem that > interoperability requires some mandatory limit, somewhere. (I suppose > it can go in some document other than the protocol document, but since > it is a piece of information needed by all protocol implementors and > virtually all model writers, the protocol would seem the place to put it.) > It is not the document that matters, but rather the status of the document. It MUST be normative text in a standards-track RFC. Unless there is an arbitrary limit that every tool MUST support for identifier length, then no IETF WG can use YANG to produce inter-operable standard data models. That is more than an inconvenience -- it is a show-stopper. The SMIv2 limit of 64 chars has not caused any problems in 2 decades, so it seems quite reasonable to continue using that limit. > Yours, > Joel M. Halpern Andy From randy_presuhn@mindspring.com Sat Apr 4 16:43:23 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2C2F3A6814 for ; Sat, 4 Apr 2009 16:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=-0.609, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoSOdxg+6tLC for ; Sat, 4 Apr 2009 16:43:23 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id ECAC93A67B6 for ; Sat, 4 Apr 2009 16:43:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=nKZBAybdIEUCxEXxHKnX6giYirE5JRRl46agqp3urLiridz4Vu2+uIBZf+8Pg6Gh; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.35.38] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LqFXG-0002wX-Us for netmod@ietf.org; Sat, 04 Apr 2009 19:44:27 -0400 Message-ID: <003c01c9b57f$8bbf1680$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200904021551.n32FpN5N014641@idle.juniper.net> <000c01c9b404$2f1d7ba0$6801a8c0@oemcomputer> <1238838462.6401.20.camel@missotis> <49D76548.5040103@netconfcentral.com> <1238855752.6401.45.camel@missotis> <49D77654.3020103@netconfcentral.com><1238865142.6401.60.camel@missotis><49D79734.2080603@joelhalpern.com> <49D79C41.9080003@netconfcentral.com> Date: Sat, 4 Apr 2009 16:46:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f1732371774da26048d9012dbc4e7e6b89ba350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.35.38 Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 23:43:23 -0000 Hi - > From: "Andy Bierman" > To: "Joel M. Halpern" > Cc: > Sent: Saturday, April 04, 2009 10:43 AM > Subject: Re: [netmod] identifier length survey ... > Unless there is an arbitrary limit that every tool MUST support > for identifier length, then no IETF WG can use YANG to > produce inter-operable standard data models. That is more than > an inconvenience -- it is a show-stopper. ... Calling it an "arbitrary limit" is probably partially to blame for the adverse reaction. It is *not* a "limit" in an normal sense. It's a "minimum maximum". No tool is forbidden from supporting longer things. It also does not take the place of a guideline for module developers. It just sets a mimum expectation for what tools must be able to support. Randy From Washam.Fan@huaweisymantec.com Sat Apr 4 22:12:00 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FB2B3A69A2 for ; Sat, 4 Apr 2009 22:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbPAV6ld8YEn for ; Sat, 4 Apr 2009 22:11:59 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 4BFA43A689D for ; Sat, 4 Apr 2009 22:11:58 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHM00BG63TK8050@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Sun, 05 Apr 2009 13:12:58 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHM005843TIDC00@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Sun, 05 Apr 2009 13:12:56 +0800 (CST) Received: from [121.101.220.178] by hstml01-in.huaweisymantec.com (mshttpd) ; Sun, 05 Apr 2009 13:12:54 +0800 From: WashamFan To: Randy Presuhn Message-id: Date: Sun, 05 Apr 2009 13:12:54 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <003c01c9b57f$8bbf1680$6801a8c0@oemcomputer> References: <200904021551.n32FpN5N014641@idle.juniper.net> <000c01c9b404$2f1d7ba0$6801a8c0@oemcomputer> <1238838462.6401.20.camel@missotis> <49D76548.5040103@netconfcentral.com> <1238855752.6401.45.camel@missotis> <49D77654.3020103@netconfcentral.com> <1238865142.6401.60.camel@missotis> <49D79734.2080603@joelhalpern.com> <49D79C41.9080003@netconfcentral.com> <003c01c9b57f$8bbf1680$6801a8c0@oemcomputer> Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 05:12:00 -0000 Hi, Yes, I agree as I commented before. We must admit some implementations have their limits in reality unless every implementation is able to support infinity, mustn't we? So, 63/64 limit is a minumum baseline for all compliant implementations, i.e., identifiers within 63/64 chars are safe for interoperation, but you can still have identifiers beyond the limit but with the risk of rejection. the limit constraint MATTERS interoperability. washam > ... > > Unless there is an arbitrary limit that every tool MUST support > > for identifier length, then no IETF WG can use YANG to > > produce inter-operable standard data models. That is more than > > an inconvenience -- it is a show-stopper. > ... > > Calling it an "arbitrary limit" is probably partially to blame for the > adverse reaction. It is *not* a "limit" in an normal sense. It's a > "minimum maximum". No tool is forbidden from supporting > longer things. It also does not take the place of a guideline for > module developers. It just sets a mimum expectation for what > tools must be able to support. > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From muenz@net.in.tum.de Sun Apr 5 02:46:00 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62D063A6A0E for ; Sun, 5 Apr 2009 02:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLLDq9SVtN9j for ; Sun, 5 Apr 2009 02:45:59 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 5208F3A67F1 for ; Sun, 5 Apr 2009 02:45:57 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 10E4B47BD3 for ; Sun, 5 Apr 2009 11:47:00 +0200 (CEST) Received: from [131.159.20.248] (vpn-4.net.informatik.tu-muenchen.de [131.159.20.248]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 984918DF for ; Sun, 5 Apr 2009 11:46:59 +0200 (CEST) Message-ID: <49D87E18.4010604@net.in.tum.de> Date: Sun, 05 Apr 2009 11:47:04 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: netmod@ietf.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030205080003050504000103" X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 09:46:00 -0000 This is a cryptographically signed message in MIME format. --------------ms030205080003050504000103 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, WashamFan wrote: > Hi, > > Yes, I agree as I commented before. > > We must admit some implementations have their limits in reality > unless every implementation is able to support infinity, mustn't we? > So, 63/64 limit is a minumum baseline for all compliant > implementations, i.e., identifiers within 63/64 chars are > safe for interoperation, but you can still have identifiers > beyond the limit but with the risk of rejection. If you (and others) argument like this, we also have to standardize the minimum maximum number of identifiers per module, the minimum maximum string length, the minimum maximum element depth in XML,....... And at the and, we could standardize something like "the module must be implementable with 64kB of memory only". To me, it seems arbitrary to start restricting the identifier length while leaving all the other parameters unlimited. If you interpret the lack of a limit as "infinity MUST be supported", then not putting a limit to the number of identifiers also leads to a standard that no real-world implementation can comply with. There will always be situations where a device returns "out of memory". Also, it is not necessary that all YANG-implementations support all modules. An agent can be optimized for the IPFIX-PSAMP module. It does not need to support longer identifiers than those specified in the module. Yet, it must be able to parse and possibly ignore longer identifiers. > the limit constraint MATTERS interoperability. As I understand, it matters because certain prototype implementations do not support longer identifiers. Regardless of a minimum maximum identifier length in the standard, I would not call such implementations non-conform, they just have certain restrictions (or capabilities). Recommending identifier lengths less or equal 64 is a good idea. Yet, I'm still not convinced that a minimum maximum length must be standardized. Cheers, Gerhard > > washam > >> ... >> > Unless there is an arbitrary limit that every tool MUST support >> > for identifier length, then no IETF WG can use YANG to >> > produce inter-operable standard data models. That is more than >> > an inconvenience -- it is a show-stopper. >> ... >> >> Calling it an "arbitrary limit" is probably partially to blame for the >> adverse reaction. It is *not* a "limit" in an normal sense. It's a >> "minimum maximum". No tool is forbidden from supporting >> longer things. It also does not take the place of a guideline for >> module developers. It just sets a mimum expectation for what >> tools must be able to support. >> >> Randy --------------ms030205080003050504000103 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNDA1MDk0NzA0WjAjBgkqhkiG9w0BCQQxFgQU yHEHAxEdfK2wKoJ0M9mHRXU7zMIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBALs0RNqfzdYtyXlyZneN09xU6rQhZk3V2kn286nhX17WM80I FblHTQXTso+zk7uyGjbSZ1EfCWE8oQhIMqzakgPWzdkqIicVcoFPzrI32SuVUD6ljhBeYvBW I3xTBhkjS7XEzbw/lgO50hIjvpLXhcKFVmgeDWFum6PYz8ILmqPHjy51DEx3H56+xu1lm6Ge KGx2ZQC4em4x0DooIgtE07syCxaxdL/lxe5hMinxlHfDkjYk1kw8g4fNkWuigN6qf5/rKHEK JDIJWYUef9UXIASCQvAL9lOQB2y2GoYtj8pK9KBh5BdJU1ePJMCBvycl6uYHNb+5KdmLuDeF BBUDgVEAAAAAAAA= --------------ms030205080003050504000103-- From lhotka@cesnet.cz Sun Apr 5 03:52:14 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4878E3A68F9 for ; Sun, 5 Apr 2009 03:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBq-XUo7a+-W for ; Sun, 5 Apr 2009 03:52:13 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 268A13A69D4 for ; Sun, 5 Apr 2009 03:52:13 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 74FD3D800BD for ; Sun, 5 Apr 2009 12:53:16 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <49D87E18.4010604@net.in.tum.de> References: <49D87E18.4010604@net.in.tum.de> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Sun, 05 Apr 2009 12:53:15 +0200 Message-Id: <1238928795.6399.25.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 10:52:14 -0000 Hi, I fully share Gerhard's view. Interoperability means that any device can talk to any manager, provided that the manager implements the device's data model. It is the particular data model that determines the identifier length that both parties have to support. YANG language specification needn't care about this. Lada Gerhard Muenz píše v Ne 05. 04. 2009 v 11:47 +0200: > > > > Yes, I agree as I commented before. > > > > We must admit some implementations have their limits in reality > > unless every implementation is able to support infinity, mustn't we? > > So, 63/64 limit is a minumum baseline for all compliant > > implementations, i.e., identifiers within 63/64 chars are > > safe for interoperation, but you can still have identifiers > > beyond the limit but with the risk of rejection. > > If you (and others) argument like this, we also have to standardize the > minimum maximum number of identifiers per module, the minimum maximum > string length, the minimum maximum element depth in XML,....... > And at the and, we could standardize something like "the module must be > implementable with 64kB of memory only". > > To me, it seems arbitrary to start restricting the identifier length > while leaving all the other parameters unlimited. If you interpret the > lack of a limit as "infinity MUST be supported", then not putting a > limit to the number of identifiers also leads to a standard that no > real-world implementation can comply with. > > There will always be situations where a device returns "out of memory". > Also, it is not necessary that all YANG-implementations support all > modules. An agent can be optimized for the IPFIX-PSAMP module. It does > not need to support longer identifiers than those specified in the > module. Yet, it must be able to parse and possibly ignore longer > identifiers. > > > the limit constraint MATTERS interoperability. > > As I understand, it matters because certain prototype implementations do > not support longer identifiers. Regardless of a minimum maximum > identifier length in the standard, I would not call such implementations > non-conform, they just have certain restrictions (or capabilities). > > Recommending identifier lengths less or equal 64 is a good idea. Yet, > I'm still not convinced that a minimum maximum length must be standardized. > > Cheers, > Gerhard > > > > > washam > > > >> ... > >> > Unless there is an arbitrary limit that every tool MUST support > >> > for identifier length, then no IETF WG can use YANG to > >> > produce inter-operable standard data models. That is more than > >> > an inconvenience -- it is a show-stopper. > >> ... > >> > >> Calling it an "arbitrary limit" is probably partially to blame for the > >> adverse reaction. It is *not* a "limit" in an normal sense. It's a > >> "minimum maximum". No tool is forbidden from supporting > >> longer things. It also does not take the place of a guideline for > >> module developers. It just sets a mimum expectation for what > >> tools must be able to support. > >> > >> Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Sun Apr 5 06:28:44 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37D63A67FA for ; Sun, 5 Apr 2009 06:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OU2JPKnbdoyv for ; Sun, 5 Apr 2009 06:28:43 -0700 (PDT) Received: from n6.bullet.mud.yahoo.com (n6.bullet.mud.yahoo.com [216.252.100.57]) by core3.amsl.com (Postfix) with SMTP id E604B3A69D7 for ; Sun, 5 Apr 2009 06:28:42 -0700 (PDT) Received: from [209.191.108.97] by n6.bullet.mud.yahoo.com with NNFMP; 05 Apr 2009 13:29:47 -0000 Received: from [68.142.201.252] by t4.bullet.mud.yahoo.com with NNFMP; 05 Apr 2009 13:29:47 -0000 Received: from [127.0.0.1] by omp413.mail.mud.yahoo.com with NNFMP; 05 Apr 2009 13:29:47 -0000 X-Yahoo-Newman-Id: 653472.72880.bm@omp413.mail.mud.yahoo.com Received: (qmail 67256 invoked from network); 5 Apr 2009 13:29:47 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 5 Apr 2009 13:29:46 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D8B248.9070904@netconfcentral.com> Date: Sun, 05 Apr 2009 06:29:44 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ladislav Lhotka References: <49D87E18.4010604@net.in.tum.de> <1238928795.6399.25.camel@missotis> In-Reply-To: <1238928795.6399.25.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 13:28:44 -0000 Ladislav Lhotka wrote: > Hi, > > I fully share Gerhard's view. > So it's OK if I ask the IPFIX WG to check the ipfix-psamp data model so all identifiers are 8 chars or less? If my compliant implementation can pick any identifier length to support, then why can't I pick 8? or 1? I want the IPFIX WG to ONLY produce standards that will work on compliant YANG implementations. The identifier string is used on-the-wire quite a bit. It is used by readers and operators even more. Andy > Interoperability means that any device can talk to any manager, provided > that the manager implements the device's data model. It is the > particular data model that determines the identifier length that both > parties have to support. YANG language specification needn't care about > this. > > Lada > > Gerhard Muenz píše v Ne 05. 04. 2009 v 11:47 +0200: >>> Yes, I agree as I commented before. >>> >>> We must admit some implementations have their limits in reality >>> unless every implementation is able to support infinity, mustn't we? >>> So, 63/64 limit is a minumum baseline for all compliant >>> implementations, i.e., identifiers within 63/64 chars are >>> safe for interoperation, but you can still have identifiers >>> beyond the limit but with the risk of rejection. >> If you (and others) argument like this, we also have to standardize the >> minimum maximum number of identifiers per module, the minimum maximum >> string length, the minimum maximum element depth in XML,....... >> And at the and, we could standardize something like "the module must be >> implementable with 64kB of memory only". >> >> To me, it seems arbitrary to start restricting the identifier length >> while leaving all the other parameters unlimited. If you interpret the >> lack of a limit as "infinity MUST be supported", then not putting a >> limit to the number of identifiers also leads to a standard that no >> real-world implementation can comply with. >> >> There will always be situations where a device returns "out of memory". >> Also, it is not necessary that all YANG-implementations support all >> modules. An agent can be optimized for the IPFIX-PSAMP module. It does >> not need to support longer identifiers than those specified in the >> module. Yet, it must be able to parse and possibly ignore longer >> identifiers. >> >>> the limit constraint MATTERS interoperability. >> As I understand, it matters because certain prototype implementations do >> not support longer identifiers. Regardless of a minimum maximum >> identifier length in the standard, I would not call such implementations >> non-conform, they just have certain restrictions (or capabilities). >> >> Recommending identifier lengths less or equal 64 is a good idea. Yet, >> I'm still not convinced that a minimum maximum length must be standardized. >> >> Cheers, >> Gerhard >> >>> washam >>> >>>> ... >>>>> Unless there is an arbitrary limit that every tool MUST support >>>>> for identifier length, then no IETF WG can use YANG to >>>>> produce inter-operable standard data models. That is more than >>>>> an inconvenience -- it is a show-stopper. >>>> ... >>>> >>>> Calling it an "arbitrary limit" is probably partially to blame for the >>>> adverse reaction. It is *not* a "limit" in an normal sense. It's a >>>> "minimum maximum". No tool is forbidden from supporting >>>> longer things. It also does not take the place of a guideline for >>>> module developers. It just sets a mimum expectation for what >>>> tools must be able to support. >>>> >>>> Randy >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From andy@netconfcentral.com Sun Apr 5 06:38:15 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF093A6B44 for ; Sun, 5 Apr 2009 06:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uYKj1IRFJjw for ; Sun, 5 Apr 2009 06:38:14 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id ADC773A6B36 for ; Sun, 5 Apr 2009 06:38:14 -0700 (PDT) Received: (qmail 32016 invoked from network); 5 Apr 2009 13:39:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 5 Apr 2009 13:39:19 -0000 X-YMail-OSG: .LAQQd0VM1myQUhMSYKGoMXHQT1edK1Zb21DE9_Ml2Irw3C6_CJpGtbOGK9MHS0yWTKoAOf8Sbnxq0yz4A8htctNy7JG3VrdIQAjAtEohqhJr8.LxJeJj_2a5yDYKHxw7ztxsfd4AA0552tA4BE_sLcc8qEbWserdPV.ny16q0VnpekO4PTDIQAPdjeRjFNW_gn5WHUO7M.aViqoElBLGiheuQG7vCuhuZabI.fKZDJW3d5v5vAMhA21Ru0aweNPU9oxHUbcjUPZgsAf X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D8B485.3050703@netconfcentral.com> Date: Sun, 05 Apr 2009 06:39:17 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ladislav Lhotka References: <49D87E18.4010604@net.in.tum.de> <1238928795.6399.25.camel@missotis> In-Reply-To: <1238928795.6399.25.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 13:38:15 -0000 Ladislav Lhotka wrote: > Hi, > > I fully share Gerhard's view. > > Interoperability means that any device can talk to any manager, provided > that the manager implements the device's data model. It is the > particular data model that determines the identifier length that both > parties have to support. YANG language specification needn't care about > this. > If we make this change, then we also need to remove any other CLRs in YANG related to saving memory, starting with reordering list keys. This is extremely disruptive to ordinary XML applications that do not know YANG agents are fragile. If a YANG agent can handle infinite length identifiers, then it should have no problems whatsoever buffering just 1 element. > Lada Andy From andy@netconfcentral.com Sun Apr 5 07:36:25 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F92F3A6A74 for ; Sun, 5 Apr 2009 07:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuISKtF12p6x for ; Sun, 5 Apr 2009 07:36:24 -0700 (PDT) Received: from n25.bullet.mail.mud.yahoo.com (n25.bullet.mail.mud.yahoo.com [68.142.206.220]) by core3.amsl.com (Postfix) with SMTP id 4E3023A67D4 for ; Sun, 5 Apr 2009 07:36:24 -0700 (PDT) Received: from [209.191.108.96] by n25.bullet.mail.mud.yahoo.com with NNFMP; 05 Apr 2009 14:37:29 -0000 Received: from [68.142.201.251] by t3.bullet.mud.yahoo.com with NNFMP; 05 Apr 2009 14:37:29 -0000 Received: from [127.0.0.1] by omp412.mail.mud.yahoo.com with NNFMP; 05 Apr 2009 14:37:29 -0000 X-Yahoo-Newman-Id: 284272.47491.bm@omp412.mail.mud.yahoo.com Received: (qmail 94342 invoked from network); 5 Apr 2009 14:37:28 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 5 Apr 2009 14:37:28 -0000 X-YMail-OSG: t_mGRJIVM1mBhxoFCzkpxlOQ69pLDSPKUWAnW5vuZy2LKmKZvfOvByJTL0WUO_eYeaMNkcuMDW0j.eT_PRJ.6GCRgptnFEww3hec9y7e9Md66U7g3eYcmVb9AgZ21ZaXwpnYPsiYLzI42WgI6aDDWcB1pM.umPjpq.Zd9UFplc5MYPaydAqhhIbSwAGkFXCmW.WLQq2WuYW2l08jiXMv2bKLZIfdNdTHKsG58MeR9pN84JY_syQMQOKDxRolNcBWuyO9oS8pYCmEd2Cj X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D8C226.8040509@netconfcentral.com> Date: Sun, 05 Apr 2009 07:37:26 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ladislav Lhotka References: <49D87E18.4010604@net.in.tum.de> <1238928795.6399.25.camel@missotis> In-Reply-To: <1238928795.6399.25.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 14:36:25 -0000 Ladislav Lhotka wrote: > Hi, > > I fully share Gerhard's view. > > Interoperability means that any device can talk to any manager, provided > that the manager implements the device's data model. It is the > particular data model that determines the identifier length that both > parties have to support. YANG language specification needn't care about > this. > I do not understand why the current text is such a problem. It allows implementations to use any size identifiers they want, just like C. It insures for all users that a 'minimum maximum' is supported by all implementations, just like C. If you turn off or ignore all warnings, then you get what you get, and it's your own fault, just like C. I think the current text is fine and there is no need to change it, except s/63/64/ to support SMIv2. > Lada Andy From andy@netconfcentral.com Sun Apr 5 09:28:10 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B0233A697B for ; Sun, 5 Apr 2009 09:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPUO4WQNIyIA for ; Sun, 5 Apr 2009 09:28:09 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 05E833A6900 for ; Sun, 5 Apr 2009 09:28:08 -0700 (PDT) Received: (qmail 98455 invoked from network); 5 Apr 2009 16:29:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 5 Apr 2009 16:29:13 -0000 X-YMail-OSG: yqo0CZgVM1lQE_QI.t8QmClMaK3RyIx92CkgLDGtGG8Rm.s9IvG9MsJIRks5fIOOToJcVSIPuRpmjJ5fBenanzMTotVNnysUh.kJFo8vZvy2M1v1pctATbm_bUhp5yEiCzbChgnNhRdJ05fFmpo5a2xWnusPRHSUPpQ7S8.B4u_4XvpXKR30PpusVPDs1HhdqFpfieg6qHIMhJTqkKh7QLEAilGSzIsi4GIcqbzxLQ4cLTt1YLRb8gYp_9JjPtA5ZXrVRqqy9y09PcHWJ7bt8nz4tkMJVIkJwIdZMhfRjxFpqjjp6gqvbjvDGOsSkZomaUA.SsLiRyui4UL9Ln8eMVTKsslyqRyTJDRDjrvn.8fbbJoCEg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D8DC57.3050607@netconfcentral.com> Date: Sun, 05 Apr 2009 09:29:11 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Gerhard Muenz References: <49D87E18.4010604@net.in.tum.de> In-Reply-To: <49D87E18.4010604@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 16:28:10 -0000 Gerhard Muenz wrote: > Hi, > > WashamFan wrote: >> Hi, >> >> Yes, I agree as I commented before. >> >> We must admit some implementations have their limits in reality >> unless every implementation is able to support infinity, mustn't we? >> So, 63/64 limit is a minumum baseline for all compliant >> implementations, i.e., identifiers within 63/64 chars are >> safe for interoperation, but you can still have identifiers >> beyond the limit but with the risk of rejection. > > If you (and others) argument like this, we also have to standardize the > minimum maximum number of identifiers per module, the minimum maximum > string length, the minimum maximum element depth in XML,....... > And at the and, we could standardize something like "the module must be > implementable with 64kB of memory only". > C99 spec: http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf See sections 5.2.4.1 and 6.4.2.1, note 6 to see how the ISO C standard handles the 'minimum maximum' problem. They go into great detail wrt/ the minimum requirements a tool that claims to support C99 must implement. They do this so C programmers that use only the C99 subset of the C language can know exactly what to expect from any C99 compiler. YANG is like C99 and XML is like C in this analogy. IMO, compatibility with SMIv2 and C99 is quite useful to real applications. Andy From lhotka@cesnet.cz Sun Apr 5 11:04:04 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B310D3A6B72 for ; Sun, 5 Apr 2009 11:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzeudP2Re4q1 for ; Sun, 5 Apr 2009 11:04:03 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 83AA43A6B5C for ; Sun, 5 Apr 2009 11:04:03 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 4813DD800BD; Sun, 5 Apr 2009 20:04:56 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49D8B248.9070904@netconfcentral.com> References: <49D87E18.4010604@net.in.tum.de> <1238928795.6399.25.camel@missotis> <49D8B248.9070904@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Sun, 05 Apr 2009 20:04:56 +0200 Message-Id: <1238954696.6399.46.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 18:04:04 -0000 Andy Bierman píše v Ne 05. 04. 2009 v 06:29 -0700: > Ladislav Lhotka wrote: > > Hi, > > > > I fully share Gerhard's view. > > > > So it's OK if I ask the IPFIX WG to > check the ipfix-psamp data model so > all identifiers are 8 chars or less? No, there is no reason to call for any data model changes - as long as the data model complies with the (future) guidelines. But anybody wanting to implement the IPFIX/PSAMP data will have to choose or write an appropriate implementation. For identifier length - which is by far not the only parameter to observe - 8 chars are insufficient but 32 may be enough. > > If my compliant implementation can pick any identifier > length to support, then why can't I pick 8? or 1? You can, but you will be able to use it only for a certain subset of valid YANG models. This is nothing special, every implementation has its limits and won't be able to digest some valid data models (with too long identifiers, too long strings, too many levels of hierarchy, ...) Lada > I want the IPFIX WG to ONLY produce standards that > will work on compliant YANG implementations. > > The identifier string is used on-the-wire quite a bit. > It is used by readers and operators even more. > > > Andy > > > > Interoperability means that any device can talk to any manager, provided > > that the manager implements the device's data model. It is the > > particular data model that determines the identifier length that both > > parties have to support. YANG language specification needn't care about > > this. > > > > Lada > > > > Gerhard Muenz píše v Ne 05. 04. 2009 v 11:47 +0200: > >>> Yes, I agree as I commented before. > >>> > >>> We must admit some implementations have their limits in reality > >>> unless every implementation is able to support infinity, mustn't we? > >>> So, 63/64 limit is a minumum baseline for all compliant > >>> implementations, i.e., identifiers within 63/64 chars are > >>> safe for interoperation, but you can still have identifiers > >>> beyond the limit but with the risk of rejection. > >> If you (and others) argument like this, we also have to standardize the > >> minimum maximum number of identifiers per module, the minimum maximum > >> string length, the minimum maximum element depth in XML,....... > >> And at the and, we could standardize something like "the module must be > >> implementable with 64kB of memory only". > >> > >> To me, it seems arbitrary to start restricting the identifier length > >> while leaving all the other parameters unlimited. If you interpret the > >> lack of a limit as "infinity MUST be supported", then not putting a > >> limit to the number of identifiers also leads to a standard that no > >> real-world implementation can comply with. > >> > >> There will always be situations where a device returns "out of memory". > >> Also, it is not necessary that all YANG-implementations support all > >> modules. An agent can be optimized for the IPFIX-PSAMP module. It does > >> not need to support longer identifiers than those specified in the > >> module. Yet, it must be able to parse and possibly ignore longer > >> identifiers. > >> > >>> the limit constraint MATTERS interoperability. > >> As I understand, it matters because certain prototype implementations do > >> not support longer identifiers. Regardless of a minimum maximum > >> identifier length in the standard, I would not call such implementations > >> non-conform, they just have certain restrictions (or capabilities). > >> > >> Recommending identifier lengths less or equal 64 is a good idea. Yet, > >> I'm still not convinced that a minimum maximum length must be standardized. > >> > >> Cheers, > >> Gerhard > >> > >>> washam > >>> > >>>> ... > >>>>> Unless there is an arbitrary limit that every tool MUST support > >>>>> for identifier length, then no IETF WG can use YANG to > >>>>> produce inter-operable standard data models. That is more than > >>>>> an inconvenience -- it is a show-stopper. > >>>> ... > >>>> > >>>> Calling it an "arbitrary limit" is probably partially to blame for the > >>>> adverse reaction. It is *not* a "limit" in an normal sense. It's a > >>>> "minimum maximum". No tool is forbidden from supporting > >>>> longer things. It also does not take the place of a guideline for > >>>> module developers. It just sets a mimum expectation for what > >>>> tools must be able to support. > >>>> > >>>> Randy > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Sun Apr 5 11:48:12 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 175943A6933 for ; Sun, 5 Apr 2009 11:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkV2Fr7K9PBy for ; Sun, 5 Apr 2009 11:48:11 -0700 (PDT) Received: from n21.bullet.mail.mud.yahoo.com (n21.bullet.mail.mud.yahoo.com [68.142.206.160]) by core3.amsl.com (Postfix) with SMTP id 348EE3A688A for ; Sun, 5 Apr 2009 11:48:11 -0700 (PDT) Received: from [68.142.194.243] by n21.bullet.mail.mud.yahoo.com with NNFMP; 05 Apr 2009 18:49:16 -0000 Received: from [68.142.201.252] by t1.bullet.mud.yahoo.com with NNFMP; 05 Apr 2009 18:49:16 -0000 Received: from [127.0.0.1] by omp413.mail.mud.yahoo.com with NNFMP; 05 Apr 2009 18:49:16 -0000 X-Yahoo-Newman-Id: 229278.97040.bm@omp413.mail.mud.yahoo.com Received: (qmail 7310 invoked from network); 5 Apr 2009 18:49:15 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 5 Apr 2009 18:49:15 -0000 X-YMail-OSG: Sk.klBcVM1mOKp7PaVCt0kea8zaxGxn.WdeO9QMAhkaZkJepin0KNO22Y53nEXhdcgE_A5aX.Nr0CU74llUjBBKAePPeKgxVR2C45me0l0MJ902ThPrEuNKgRsQ_aJsxJKWb03fynRhXyRqS.HfjFnK3EBM6dPz9UvKGpba.p1MkPXnVciSLMsYuxoY3j4dQ3As_cdP_Gu8SpsalGnxUa.OAJbQnE95aqpKEzqk_NyVk9xw62X.VdUU_ogASDDnrs.tcsU8P3aGfP2yM X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D8FD29.3010002@netconfcentral.com> Date: Sun, 05 Apr 2009 11:49:13 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ladislav Lhotka References: <49D87E18.4010604@net.in.tum.de> <1238928795.6399.25.camel@missotis> <49D8B248.9070904@netconfcentral.com> <1238954696.6399.46.camel@missotis> In-Reply-To: <1238954696.6399.46.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 18:48:12 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Ne 05. 04. 2009 v 06:29 -0700: >> Ladislav Lhotka wrote: >>> Hi, >>> >>> I fully share Gerhard's view. >>> >> So it's OK if I ask the IPFIX WG to >> check the ipfix-psamp data model so >> all identifiers are 8 chars or less? > > No, there is no reason to call for any data model changes - as long as > the data model complies with the (future) guidelines. But anybody > wanting to implement the IPFIX/PSAMP data will have to choose or write > an appropriate implementation. For identifier length - which is by far > not the only parameter to observe - 8 chars are insufficient but 32 may > be enough. > >> If my compliant implementation can pick any identifier >> length to support, then why can't I pick 8? or 1? > > You can, but you will be able to use it only for a certain subset of > valid YANG models. This is nothing special, every implementation has its > limits and won't be able to digest some valid data models (with too long > identifiers, too long strings, too many levels of hierarchy, ...) > IMO, this would make the YANG standard much less useful. Among all the other problems with no specified limit is the confusion is causes. You say an implementation that supports 1-char names is complaint. Phil says no. I think another opinion was 'it depends on the memory available'. The current text is quite clear to implementors. Removing it causes a lot of confusion, which is a bad thing wrt/ interoperability. > Lada Andy From muenz@net.in.tum.de Sun Apr 5 12:47:15 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 569853A6B34 for ; Sun, 5 Apr 2009 12:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjVDP4j7MwA2 for ; Sun, 5 Apr 2009 12:47:10 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id DC73A3A6AD3 for ; Sun, 5 Apr 2009 12:47:09 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 9480E47BD3 for ; Sun, 5 Apr 2009 21:48:12 +0200 (CEST) Received: from [131.159.20.248] (vpn-4.net.informatik.tu-muenchen.de [131.159.20.248]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 467225017 for ; Sun, 5 Apr 2009 21:48:12 +0200 (CEST) Message-ID: <49D90B02.6000502@net.in.tum.de> Date: Sun, 05 Apr 2009 21:48:18 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: netmod@ietf.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080100020503030603040901" X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 19:47:15 -0000 This is a cryptographically signed message in MIME format. --------------ms080100020503030603040901 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Andy, Andy Bierman wrote: > So it's OK if I ask the IPFIX WG to > check the ipfix-psamp data model so > all identifiers are 8 chars or less? > > If my compliant implementation can pick any identifier > length to support, then why can't I pick 8? or 1? > I want the IPFIX WG to ONLY produce standards that > will work on compliant YANG implementations. What do you mean by a "compliant YANG implementation"? Maybe you can give a definition? I think that compliance is per YANG module. Vendors will implement specific data models for Netconf that are specified in YANG (e.g., the one of the IPFIX WG). Then, they will advertise their product like: "my router/management system supports the IPFIX configuration data model (RFC XXXX)". They won't say that YANG or whatever language was used in the implementation process. > The identifier string is used on-the-wire quite a bit. > It is used by readers and operators even more. As I've said already, I'm not at all against recommending a resonable identifier length. Gerhard --------------ms080100020503030603040901 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNDA1MTk0ODE4WjAjBgkqhkiG9w0BCQQxFgQU ZB8tdQ1a1vgxg9KBIczPOYQB9nIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBABSpTcbef7FiBQxwLMs4dnxQS1G5RyaVfyn5hJtprGCzdm+T rs1QU95vrCq5sG4/Y+ZQHc4R75znyal+TkoAGFQ3+mEA/tEvrWx3o3L8ibxfUjWbFKFzqJ3T DehhRZPMgonzQNJsqB13kS7B9OxivsbPS5c0dmRF3IAqEl6dg1V3oSgAbjoBhW4V06vQ/MAJ Rw1eyizxq7rG/CqorNV2iMJXKHn2xjxdFHrTNZIudP6cIfHiq9R3MnZ7lL/FJYf4QdoPvnFl AvNRKzWQJG7h2WSmt50YH14favKNLfwGUoNyKZ7t1Gh9NEAklmlVLcN5INQbY1iG2mQrI9qc Lcuak8sAAAAAAAA= --------------ms080100020503030603040901-- From andy@netconfcentral.com Sun Apr 5 12:55:56 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ED113A6ACA for ; Sun, 5 Apr 2009 12:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I55IndZnLgPo for ; Sun, 5 Apr 2009 12:55:51 -0700 (PDT) Received: from n7.bullet.mud.yahoo.com (n7.bullet.mud.yahoo.com [216.252.100.58]) by core3.amsl.com (Postfix) with SMTP id 5B9613A6B6F for ; Sun, 5 Apr 2009 12:55:44 -0700 (PDT) Received: from [68.142.200.226] by n7.bullet.mud.yahoo.com with NNFMP; 05 Apr 2009 19:56:49 -0000 Received: from [68.142.201.240] by t7.bullet.mud.yahoo.com with NNFMP; 05 Apr 2009 19:56:49 -0000 Received: from [127.0.0.1] by omp401.mail.mud.yahoo.com with NNFMP; 05 Apr 2009 19:56:49 -0000 X-Yahoo-Newman-Id: 491315.98266.bm@omp401.mail.mud.yahoo.com Received: (qmail 63339 invoked from network); 5 Apr 2009 19:56:48 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 5 Apr 2009 19:56:48 -0000 X-YMail-OSG: O9VmItEVM1l5F4n5Q4V3VckSEa0ZUNfbjWUw3ZSDfRNgcsjPFuxXJEe_M83wfKhX9dv_j3.KknNRCr3qZz1HR2R86O.2viKWi6MnoRNSXf7e9AeFNFHR_sXjg9UKY2wU6vTvS1Dd5seoZScGmBomziGSeMuelchIU5oCdY82g0ibrXrl3_Cgqd_eg36NE4sG.V.p0kjchT2O3D3m_4n6HC31Y_.nfnFrngbuaKsyFAarqNIqnMZS2oYuAJIVrsR8A4aFyp_VEK4aiyBE X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D90CFE.8030409@netconfcentral.com> Date: Sun, 05 Apr 2009 12:56:46 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Gerhard Muenz References: <49D90B02.6000502@net.in.tum.de> In-Reply-To: <49D90B02.6000502@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 19:55:56 -0000 Gerhard Muenz wrote: > Hi Andy, > > Andy Bierman wrote: >> So it's OK if I ask the IPFIX WG to >> check the ipfix-psamp data model so >> all identifiers are 8 chars or less? >> >> If my compliant implementation can pick any identifier >> length to support, then why can't I pick 8? or 1? >> I want the IPFIX WG to ONLY produce standards that >> will work on compliant YANG implementations. > > What do you mean by a "compliant YANG implementation"? > Maybe you can give a definition? > > I think that compliance is per YANG module. Vendors will implement > specific data models for Netconf that are specified in YANG (e.g., the > one of the IPFIX WG). Then, they will advertise their product like: "my > router/management system supports the IPFIX configuration data model > (RFC XXXX)". They won't say that YANG or whatever language was used in > the implementation process. > >> The identifier string is used on-the-wire quite a bit. >> It is used by readers and operators even more. > > As I've said already, I'm not at all against recommending a resonable > identifier length. > The standard needs to be clear to implementors to promote interoperability. The current sentence is quite clear to implementors. I think a section like C99, 5.2.4.1 is needed for YANG, not just one sentence. An Informational RFC is not part of any standard. > Gerhard Andy From lhotka@cesnet.cz Sun Apr 5 13:01:09 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 379C23A687D for ; Sun, 5 Apr 2009 13:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.955 X-Spam-Level: X-Spam-Status: No, score=-0.955 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJism5YCtqaY for ; Sun, 5 Apr 2009 13:01:03 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C57803A6869 for ; Sun, 5 Apr 2009 13:01:03 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id BABB8D800C0; Sun, 5 Apr 2009 22:02:08 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49D8B485.3050703@netconfcentral.com> References: <49D87E18.4010604@net.in.tum.de> <1238928795.6399.25.camel@missotis> <49D8B485.3050703@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Sun, 05 Apr 2009 22:02:09 +0200 Message-Id: <1238961729.6399.58.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 20:01:09 -0000 Andy Bierman píše v Ne 05. 04. 2009 v 06:39 -0700: > Ladislav Lhotka wrote: > > Hi, > > > > I fully share Gerhard's view. > > > > Interoperability means that any device can talk to any manager, provided > > that the manager implements the device's data model. It is the > > particular data model that determines the identifier length that both > > parties have to support. YANG language specification needn't care about > > this. > > > > If we make this change, > then we also need to remove any other CLRs > in YANG related to saving memory, > starting with reordering list keys. > This is extremely disruptive to ordinary > XML applications that do not know YANG agents are fragile. I wouldn't mind removing this and other CLRs, like forbidding empty type for list keys. > > If a YANG agent can handle infinite length identifiers, > then it should have no problems whatsoever buffering > just 1 element. I can only repeat: nobody wants to force implementations to support identifiers of any length. Lada > > > Lada > > Andy > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Sun Apr 5 13:11:50 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DD953A6B63 for ; Sun, 5 Apr 2009 13:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.96 X-Spam-Level: X-Spam-Status: No, score=-0.96 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3p3oEyENOsWv for ; Sun, 5 Apr 2009 13:11:45 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 0C5B73A6ACA for ; Sun, 5 Apr 2009 13:11:43 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id BBD82D800C0; Sun, 5 Apr 2009 22:12:39 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49D8FD29.3010002@netconfcentral.com> References: <49D87E18.4010604@net.in.tum.de> <1238928795.6399.25.camel@missotis> <49D8B248.9070904@netconfcentral.com> <1238954696.6399.46.camel@missotis> <49D8FD29.3010002@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Sun, 05 Apr 2009 22:12:40 +0200 Message-Id: <1238962360.6399.70.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 20:11:50 -0000 Andy Bierman píše v Ne 05. 04. 2009 v 11:49 -0700: > IMO, this would make the YANG standard much less useful. I don't think it affects YANG in any way. The role of YANG standard is to specify what a valid identifier (and, in general, valid YANG module) is and various memory-related limitations of implementations are irrelevant to it, as long as they operate with valid YANG modules. > Among all the other problems with no specified limit is the > confusion is causes. You say an implementation that supports > 1-char names is complaint. Phil says no. I think another > opinion was 'it depends on the memory available'. The one char limit was an extreme argument. The point I wanted to make was that no implementation will become non-conformant just because it has a fixed limit on identifier length, or doesn't have one, for that matter. Lada > > The current text is quite clear to implementors. > Removing it causes a lot of confusion, which is a bad thing > wrt/ interoperability. > > > Lada > > Andy > > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From muenz@net.in.tum.de Sun Apr 5 13:21:01 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 605DC3A686A for ; Sun, 5 Apr 2009 13:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adKaaeKmQm6O for ; Sun, 5 Apr 2009 13:20:56 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id BB5A53A6869 for ; Sun, 5 Apr 2009 13:20:53 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 57836540; Sun, 5 Apr 2009 22:21:47 +0200 (CEST) Received: from [131.159.20.248] (vpn-4.net.informatik.tu-muenchen.de [131.159.20.248]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id B1B615017; Sun, 5 Apr 2009 22:21:46 +0200 (CEST) Message-ID: <49D912E0.3080308@net.in.tum.de> Date: Sun, 05 Apr 2009 22:21:52 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman References: <49D90B02.6000502@net.in.tum.de> <49D90CFE.8030409@netconfcentral.com> In-Reply-To: <49D90CFE.8030409@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 20:21:01 -0000 Hi Andy, Andy Bierman wrote: > Gerhard Muenz wrote: >> Hi Andy, >> >> Andy Bierman wrote: >>> So it's OK if I ask the IPFIX WG to >>> check the ipfix-psamp data model so >>> all identifiers are 8 chars or less? >>> >>> If my compliant implementation can pick any identifier >>> length to support, then why can't I pick 8? or 1? >>> I want the IPFIX WG to ONLY produce standards that >>> will work on compliant YANG implementations. >> >> What do you mean by a "compliant YANG implementation"? >> Maybe you can give a definition? >> >> I think that compliance is per YANG module. Vendors will implement >> specific data models for Netconf that are specified in YANG (e.g., the >> one of the IPFIX WG). Then, they will advertise their product like: "my >> router/management system supports the IPFIX configuration data model >> (RFC XXXX)". They won't say that YANG or whatever language was used in >> the implementation process. >> >>> The identifier string is used on-the-wire quite a bit. >>> It is used by readers and operators even more. >> >> As I've said already, I'm not at all against recommending a resonable >> identifier length. >> > > The standard needs to be clear to implementors > to promote interoperability. Implementors of what? If you implement a specific YANG module, there's no need for any additional identifier length limitation. It's all in the module spec. Probably you think of implementors of tools that translate YANG into something else, like C99? > The current sentence is > quite clear to implementors. I think a section like > C99, 5.2.4.1 is needed for YANG, not just one sentence. I do not understand the comparison with C99. Must YANG be directly translated into C99? If YANG is compared to any programming language, I would rather choose a current high-level language like Java and Python. There, you do not find such limitations. Gerhard From andy@netconfcentral.com Sun Apr 5 13:24:51 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 126953A68F4 for ; Sun, 5 Apr 2009 13:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFOzYy+ptzj0 for ; Sun, 5 Apr 2009 13:24:45 -0700 (PDT) Received: from n23b.bullet.mail.mud.yahoo.com (n23b.bullet.mail.mud.yahoo.com [68.142.206.142]) by core3.amsl.com (Postfix) with SMTP id 7AD563A6869 for ; Sun, 5 Apr 2009 13:24:45 -0700 (PDT) Received: from [209.191.108.96] by n23.bullet.mail.mud.yahoo.com with NNFMP; 05 Apr 2009 20:25:50 -0000 Received: from [68.142.201.68] by t3.bullet.mud.yahoo.com with NNFMP; 05 Apr 2009 20:25:50 -0000 Received: from [127.0.0.1] by omp420.mail.mud.yahoo.com with NNFMP; 05 Apr 2009 20:25:50 -0000 X-Yahoo-Newman-Id: 696615.68800.bm@omp420.mail.mud.yahoo.com Received: (qmail 8481 invoked from network); 5 Apr 2009 20:25:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 5 Apr 2009 20:25:49 -0000 X-YMail-OSG: S.ApZbAVM1m2WQrz_kdmbeprx8b5EfxZVqPAjt.l7Y9z9KCwGWf1x8aBvWC7EXD4RfkA1ATCNJROJILYeRwIy.bY4kdUZyfeT6faFNoo7HjEzVv.psnRUCOqV3TypJkkl_gxYPq8Rrj8hNmQHZxor63GMvWQGDEiLxTIMiV4vsHBUHTgt5_RhPQDSTCG7XXzDgX60Y.60LG.xtvlDUpdF5.QUQ2u3HUsF9wfLl_aclAJxK8V5Q5aLbMYij5v1PNLZQnwFBsu76MxUTP5 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D913CB.2070207@netconfcentral.com> Date: Sun, 05 Apr 2009 13:25:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ladislav Lhotka References: <49D87E18.4010604@net.in.tum.de> <1238928795.6399.25.camel@missotis> <49D8B485.3050703@netconfcentral.com> <1238961729.6399.58.camel@missotis> In-Reply-To: <1238961729.6399.58.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 20:24:51 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Ne 05. 04. 2009 v 06:39 -0700: >> Ladislav Lhotka wrote: .... > I can only repeat: nobody wants to force implementations to support > identifiers of any length. > I do. I want to force implementations to support certain minimums, like those in the ISO-C spec. I want to insure that all YANG compilers can support a minimum level of complexity just like C compilers. It is unrealistic to think that all implementations will have unlimited resources, or have any consistency across implementations. I cannot cut-and-paste any ISO text, but I will paraphrase it for YANG, using the same values. Again, these are the minimums that an implementation MUST support, and any behavior beyond that is undefined in the standard: 127 levels of definition nesting 63 nesting levels of conditional inclusion (if-feature, when) 63 significant initial characters in an internal identifier 31 significant initial characters in an external identifier 4095 exported identifiers in one module 511 identifiers with block scope declared in 1 block 4095 characters in 1 logical source line 4095 characters in a character string literal (e.g., description, reference) 1023 cases within 1 choice 1023 members within a single container or list 1023 enum/bit constants within a single enumeration or bits data type 63 levels of nested union definitions within a single type-stmt > Lada Andy From mbj@tail-f.com Sun Apr 5 14:26:37 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84BAB3A6B42 for ; Sun, 5 Apr 2009 14:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bdw4C7QT6beV for ; Sun, 5 Apr 2009 14:26:35 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A46553A6B5F for ; Sun, 5 Apr 2009 14:26:35 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 62FB761600E; Sun, 5 Apr 2009 23:27:39 +0200 (CEST) Date: Sun, 05 Apr 2009 23:27:38 +0200 (CEST) Message-Id: <20090405.232738.253944188.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49D913CB.2070207@netconfcentral.com> References: <49D8B485.3050703@netconfcentral.com> <1238961729.6399.58.camel@missotis> <49D913CB.2070207@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 21:26:37 -0000 Hi, Andy Bierman wrote: > I want to force implementations to support certain minimums, ^^^^^^^^^^^^^^^ > like those in the ISO-C spec. Gerhard asked an important question - what do you mean when you say "implementation"? There is a big difference between the NETCONF server (which implements a YANG module) and a generic YANG tool that your 'yangdump' (which validates/translates a YANG module). There is a reason that C99 picked these limits. The identifier limit for example was chosen based on what existing linkers could handle. Using the same argument for YANG identifiers doesn't seem too convincing. Limits were chosen with a target machine of 512K memory in mind. [see 5.2.4.1 and 6.4.2.1 of http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf] I think we would make a huge mistake if we blindly copied these limits into YANG. /martin From andy@netconfcentral.com Sun Apr 5 15:44:40 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F3CC3A6B71 for ; Sun, 5 Apr 2009 15:44:40 -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=[AWL=0.047, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1HD85ict6Po for ; Sun, 5 Apr 2009 15:44:39 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id B08933A6B28 for ; Sun, 5 Apr 2009 15:44:39 -0700 (PDT) Received: (qmail 7090 invoked from network); 5 Apr 2009 22:45:45 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 5 Apr 2009 22:45:44 -0000 X-YMail-OSG: ec8hMB4VM1ksjUGrilgKdhMRWdcmYILvwegkHuoljL6brejQ5YnQ_ty..oyZYogJwSE.YwPzDYKT9ylEEOVpSYZ3GJE1mmwioJ_5_fo8BErUbK9klm6WpghgQbOxWYJwF7FEr8syMTsz8m1dmrGZ8dnbAeT0oixWGcjm7aLRBOwplviZKdJL8817cGEVKHgXqR3YidCjMRV_.AZSSaWf7CDzrqLFzYOZOZSUoaLj7q.LwZ4J_Uk7ywmbjsfDwfd0vbsSNIQ7CYya1d1Ydy2NfHSpJx8QUm1m1_X7D8kLV4PUMP5IBEyyqFaMU6yay4mRbo_TkLrDzDigWg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D93496.6010001@netconfcentral.com> Date: Sun, 05 Apr 2009 15:45:42 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <49D8B485.3050703@netconfcentral.com> <1238961729.6399.58.camel@missotis> <49D913CB.2070207@netconfcentral.com> <20090405.232738.253944188.mbj@tail-f.com> In-Reply-To: <20090405.232738.253944188.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 22:44:40 -0000 Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> I want to force implementations to support certain minimums, > ANY tool that uses a YANG file as input is a YANG implementation ^^^^^^^^^^^^^^^ >> like those in the ISO-C spec. > > Gerhard asked an important question - what do you mean when you say > "implementation"? There is a big difference between the NETCONF > server (which implements a YANG module) and a generic YANG tool that > your 'yangdump' (which validates/translates a YANG module). > > > There is a reason that C99 picked these limits. The identifier > limit for example was chosen based on what existing linkers could > handle. Using the same argument for YANG identifiers doesn't seem too > convincing. > > Limits were chosen with a target machine of 512K memory in mind. > good -- that is about the limit for some embedded NETCONF servers I have in mind. > [see 5.2.4.1 and 6.4.2.1 of > http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf] > > I think we would make a huge mistake if we blindly copied these limits > into YANG. > > Why? It just sets minimum values, and nothing else. Of course your implementation is encouraged to support more. I *never* said we must use the same values for the constants, although I want NETCONF/YANG to be supported on very small embedded servers, so I do not think these values are unreasonable for the *minimum* implementation requirements. The values could be updated. This thread started because Phil insisted all implementations of YANG need to support the *same* limits. This is not actually possible without specification. Having tools fail randomly based on implementation strategy does not make a good standard. We are producing a standard for NETCONF, not some generic language for XML. > > /martin > > Andy From andy@netconfcentral.com Sun Apr 5 17:07:05 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AD203A6846 for ; Sun, 5 Apr 2009 17:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDrRRVUbxjtk for ; Sun, 5 Apr 2009 17:07:04 -0700 (PDT) Received: from n68.bullet.mail.sp1.yahoo.com (n68.bullet.mail.sp1.yahoo.com [98.136.44.44]) by core3.amsl.com (Postfix) with SMTP id 347583A6B71 for ; Sun, 5 Apr 2009 17:07:04 -0700 (PDT) Received: from [216.252.122.219] by n68.bullet.mail.sp1.yahoo.com with NNFMP; 06 Apr 2009 00:08:09 -0000 Received: from [68.142.200.227] by t4.bullet.sp1.yahoo.com with NNFMP; 06 Apr 2009 00:08:09 -0000 Received: from [68.142.201.240] by t8.bullet.mud.yahoo.com with NNFMP; 06 Apr 2009 00:08:09 -0000 Received: from [127.0.0.1] by omp401.mail.mud.yahoo.com with NNFMP; 06 Apr 2009 00:08:09 -0000 X-Yahoo-Newman-Id: 707211.11769.bm@omp401.mail.mud.yahoo.com Received: (qmail 91139 invoked from network); 6 Apr 2009 00:08:09 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 6 Apr 2009 00:08:08 -0000 X-YMail-OSG: oMbHxb4VM1k6hh3IGfx_pdbFNWhF88Q7qZY2.ztychYsdvNnxO5gWMAjEvJMzgJoPH1aqlSV3qI4enfgay3i3yXQRONW609tLHwKaD8rYNrRt9Gcb9l1RV9d0ejnZj2N93KuyU6sGETY4BgRHjBEcuUAs3D4HqqUsWzcV3QueQyfrSKtMXxENfbHlQtS1fRWabyQmbtauzJDNiPuyJ4yqwXqIQqVFnCkXdDpLlb1SZL.etZ2lpGFb8m1TITfbUutmOR3b.OgMlFLKtsnjn7ePcHbafW.9WkjTINFEWCOkUi.JuEK2RPeDxzPM4eJnM.TiMZKK9.fj_KOVA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D947E6.3040607@netconfcentral.com> Date: Sun, 05 Apr 2009 17:08:06 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <49D8B485.3050703@netconfcentral.com> <1238961729.6399.58.camel@missotis> <49D913CB.2070207@netconfcentral.com> <20090405.232738.253944188.mbj@tail-f.com> In-Reply-To: <20090405.232738.253944188.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 00:07:05 -0000 Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> I want to force implementations to support certain minimums, > ^^^^^^^^^^^^^^^ >> like those in the ISO-C spec. > > Gerhard asked an important question - what do you mean when you say > "implementation"? There is a big difference between the NETCONF > server (which implements a YANG module) and a generic YANG tool that > your 'yangdump' (which validates/translates a YANG module). > > > There is a reason that C99 picked these limits. The identifier > limit for example was chosen based on what existing linkers could > handle. Using the same argument for YANG identifiers doesn't seem too > convincing. > The YANG standard must work 1 of 2 ways: - either it is OK for tools for use implementation strategies which impose a hard-limit on certain aspects of the software design - or it is not OK for tools to use implementation strategies that impose any hard limits. If (1), then setting minimum implementation limits is appropriate for better interoperability. If (2), then the standard needs to say that implementations SHOULD NOT restrict any aspect of YANG module contents, such as identifier length, number of objects, nest level, number of must or unique statements, size of description or reference statements, namespace URI, etc. Simply removing the current text increases confusion, so that is a bad option. IMO, leaving the current text is the best option because we have no operational need for long identifiers. In fact, they might even harm interoperability if they are too unreadable. Making rules that promote good YANG use are already being done all over the spec, so singling it out here does not make much sense. > Limits were chosen with a target machine of 512K memory in mind. > > [see 5.2.4.1 and 6.4.2.1 of > http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf] > > I think we would make a huge mistake if we blindly copied these limits > into YANG. > > > > /martin > > Andy From randy_presuhn@mindspring.com Sun Apr 5 20:02:29 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF8BF28C0FD for ; Sun, 5 Apr 2009 20:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.136 X-Spam-Level: X-Spam-Status: No, score=-1.136 tagged_above=-999 required=5 tests=[AWL=-1.137, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fgUJjKudAj2 for ; Sun, 5 Apr 2009 20:02:29 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 2500228C0FA for ; Sun, 5 Apr 2009 20:02:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=iU6qInQZxXUH7+wy6f9MBx1wEK3O3KUXcdqaqO+bZF4d5kjB6bC590e6hGVopJAW; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [69.3.28.157] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lqf7C-0000cY-9o for netmod@ietf.org; Sun, 05 Apr 2009 23:03:14 -0400 Message-ID: <003a01c9b664$7be72320$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <49D90B02.6000502@net.in.tum.de><49D90CFE.8030409@netconfcentral.com> <49D912E0.3080308@net.in.tum.de> Date: Sun, 5 Apr 2009 20:05:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173dac8f7fc009dd9cc0a12e74cd9c28d63350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.157 Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 03:02:30 -0000 Hi - I find it really hard to believe that folks really mean some of the things they've been saying in this thread. As I understand some of the viewpoints, if we in the IETF develop a standard data model for some class of gizmo, we'd have no reason to complain about any tool which cannot process that model because its identifiers are too long, or model elements are too deeply nested, or because it is in any other regard "too complex". In short, model designers will not be able to assume that anything will actually work in off-the-shelf tools. This is insane. The "minimum maximums" from the SNMP SMI were the result of hard- earned experience in implementation and deployment. In the absence of such minimum maximums, vendors *cannot* be relied upon to "do the right thing". The pressures to make short cuts or to over-optimize for specific use cases are just too great, and even rudimentary tool interoperability suffers as a result. Randy From mbj@tail-f.com Mon Apr 6 01:17:49 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86EC53A6BE6 for ; Mon, 6 Apr 2009 01:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RilfmtIoagBc for ; Mon, 6 Apr 2009 01:17:40 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 11E623A6B83 for ; Mon, 6 Apr 2009 01:17:40 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7519161601A; Mon, 6 Apr 2009 10:18:44 +0200 (CEST) Date: Mon, 06 Apr 2009 10:18:44 +0200 (CEST) Message-Id: <20090406.101844.263466351.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <003a01c9b664$7be72320$6801a8c0@oemcomputer> References: <49D90CFE.8030409@netconfcentral.com> <49D912E0.3080308@net.in.tum.de> <003a01c9b664$7be72320$6801a8c0@oemcomputer> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 08:17:49 -0000 "Randy Presuhn" wrote: > Hi - > > I find it really hard to believe that folks really mean some of the things > they've been saying in this thread. As I understand some of the viewpoints, > if we in the IETF develop a standard data model for some class of gizmo, > we'd have no reason to complain about any tool which cannot process > that model because its identifiers are too long, or model elements are too > deeply nested, or because it is in any other regard "too complex". Not even C99 does this. They say that (sec 5.2.4.1 again): The implementation shall be able to translate and execute at least one program that contains at least one instance of every one of the following limits: [...] So just b/c a given program meets all those limits, it is not required that a compliant implementation can "translate and execute" it. IIRC, there are no limits on e.g. the number of scalar variables in a SMIv2 module (I guess there's an implicit upper bound b/c of oid size restrictions, but that's pretty big.) > In short, > model designers will not be able to assume that anything will actually work > in off-the-shelf tools. This is insane. Maybe you are right, but it seems to work fine for programming languages such as Java, for some aspects if SMIv2, and it seems to work for XML in general. /martin From mbj@tail-f.com Mon Apr 6 01:23:52 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93A403A6BCC for ; Mon, 6 Apr 2009 01:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zG84Bgc4EzA for ; Mon, 6 Apr 2009 01:23:51 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7331F3A6B4B for ; Mon, 6 Apr 2009 01:23:51 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id D00BF616017; Mon, 6 Apr 2009 10:24:56 +0200 (CEST) Date: Mon, 06 Apr 2009 10:24:56 +0200 (CEST) Message-Id: <20090406.102456.163596066.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49D93496.6010001@netconfcentral.com> References: <49D913CB.2070207@netconfcentral.com> <20090405.232738.253944188.mbj@tail-f.com> <49D93496.6010001@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 08:23:52 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Hi, > > Andy Bierman wrote: > >> I want to force implementations to support certain minimums, > > > > ANY tool that uses a YANG file as input > is a YANG implementation [...] > > Limits were chosen with a target machine of 512K memory in mind. > > > > good -- that is about the limit for some embedded > NETCONF servers I have in mind. But a NETCONF server is, if I understand your defintion above correctly, not a YANG implementation. > > [see 5.2.4.1 and 6.4.2.1 of > > http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf] > > I think we would make a huge mistake if we blindly copied these limits > > into YANG. > > > > Why? It just sets minimum values, > and nothing else. Of course your implementation > is encouraged to support more. > > I *never* said we must use the same values for the constants, > although I want NETCONF/YANG to be supported on very small > embedded servers, so I do not think these values are > unreasonable for the *minimum* implementation requirements. We share the same goal - I also want *NETCONF* to be supported by small devices. But I don't think these limits help much. A small device which implements just a few data models may very well be able to handle one identifier of length 100. But the same device might not be able to handle a data model with "one instance of every one of the limits". /martin From phil@juniper.net Mon Apr 6 05:30:14 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1BE13A6C4D for ; Mon, 6 Apr 2009 05:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhAc7USNwjw3 for ; Mon, 6 Apr 2009 05:30:13 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id A1CD93A6C0A for ; Mon, 6 Apr 2009 05:30:09 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSdn2E6pqojkRmwCDxKwjF8NUAGjjkVx2@postini.com; Mon, 06 Apr 2009 05:31:19 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Mon, 6 Apr 2009 05:30:55 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 05:30:55 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 05:30:55 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Apr 2009 05:30:54 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n36CUsM71015; Mon, 6 Apr 2009 05:30:54 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n36CNd8S053985; Mon, 6 Apr 2009 12:23:39 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904061223.n36CNd8S053985@idle.juniper.net> To: Andy Bierman In-Reply-To: <49D3CB94.2080508@netconfcentral.com> Date: Mon, 6 Apr 2009 08:23:39 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 Apr 2009 12:30:54.0908 (UTC) FILETIME=[87B6DFC0:01C9B6B3] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] namespace URI length X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 12:30:14 -0000 Andy Bierman writes: >Hi, > >RFC 2396 is silent about URI length (as one would expect). > >RFC 2068, sec. 3.2.1 (HTTP 1.1) says: > > Note: Servers should be cautious about depending on URI lengths > above 255 bytes, because some older client or proxy implementations > may not properly support these lengths. > >Clearly the same issue exists for namespace URI as identifier length, >only worse, because a tool is allowed to accept 1 char URIs and >be considered compliant. YANG writers provide the URI value directly, >and they need to know every compiler will always accept (or reject) >a given length URI. > >IMO, "MUST support 1 to 1024 characters" should be sufficient. Section 3.2.1 of rfc 2068 also says: The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15). This paragraph appears directly above the paragraph you quoted. We can add HTTP to the list of example protocols with an unbounded limit that can be implemented on machines with finite memory. Heck, since NETCONF uses URIs and URIs have no length limit, we can add NETCONF to that list also. Would defining an error code (identifier-too-long) be a reasonable resolution? Thanks, Phil From mbj@tail-f.com Mon Apr 6 05:47:36 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 897013A6C50 for ; Mon, 6 Apr 2009 05:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuAtRoQS6Az8 for ; Mon, 6 Apr 2009 05:47:31 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 18B103A6BD0 for ; Mon, 6 Apr 2009 05:47:31 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 9C43B61601D; Mon, 6 Apr 2009 14:48:35 +0200 (CEST) Date: Mon, 06 Apr 2009 14:48:35 +0200 (CEST) Message-Id: <20090406.144835.47982806.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200904061223.n36CNd8S053985@idle.juniper.net> References: <49D3CB94.2080508@netconfcentral.com> <200904061223.n36CNd8S053985@idle.juniper.net> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] namespace URI length X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 12:47:36 -0000 Phil Shafer wrote: > Would defining an error code (identifier-too-long) be a reasonable > resolution? But this is not a protocol issue. Either your device supports a given data model with its identifiers and URI, or it doesn't. This whole debate has nothing to do with how NETCONF *servers* should behave, but what generic YANG tools (such as 'yangdump', 'pyang', 'smidump') should do. /martin From phil@juniper.net Mon Apr 6 05:58:45 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 002993A6C3E for ; Mon, 6 Apr 2009 05:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNe+XLPoyxp8 for ; Mon, 6 Apr 2009 05:58:39 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id D03B53A6C2E for ; Mon, 6 Apr 2009 05:58:29 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSdn8tf12I7HsS5yAIOl8KB51xOw+qFqz@postini.com; Mon, 06 Apr 2009 05:59:43 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Mon, 6 Apr 2009 05:57:11 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 05:57:11 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 05:57:11 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Apr 2009 05:57:10 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n36Cv4M82527; Mon, 6 Apr 2009 05:57:04 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n36CnlYO054308; Mon, 6 Apr 2009 12:49:49 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904061249.n36CnlYO054308@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090406.144835.47982806.mbj@tail-f.com> Date: Mon, 6 Apr 2009 08:49:47 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 Apr 2009 12:57:10.0300 (UTC) FILETIME=[32B89DC0:01C9B6B7] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] namespace URI length X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 12:58:45 -0000 Martin Bjorklund writes: >Phil Shafer wrote: >> Would defining an error code (identifier-too-long) be a reasonable >> resolution? > >But this is not a protocol issue. Either your device supports a given >data model with its identifiers and URI, or it doesn't. This whole >debate has nothing to do with how NETCONF *servers* should behave, but >what generic YANG tools (such as 'yangdump', 'pyang', 'smidump') >should do. Yup, and such tools are always build tools or clients, so the error wouldn't make much sense. Thanks, Phil From lhotka@cesnet.cz Mon Apr 6 06:05:28 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6353A6C44 for ; Mon, 6 Apr 2009 06:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.71 X-Spam-Level: X-Spam-Status: No, score=0.71 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Rqu3vh1cFYZ for ; Mon, 6 Apr 2009 06:05:27 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 774A43A6C67 for ; Mon, 6 Apr 2009 06:05:27 -0700 (PDT) Received: from [10.8.1.62] (185.197.broadband11.iol.cz [90.178.197.185]) by office2.cesnet.cz (Postfix) with ESMTP id 6B358D800C8 for ; Mon, 6 Apr 2009 15:06:30 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <200904061249.n36CnlYO054308@idle.juniper.net> References: <200904061249.n36CnlYO054308@idle.juniper.net> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 06 Apr 2009 15:06:17 +0200 Message-Id: <1239023177.11579.22.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] namespace URI length X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 13:05:28 -0000 Phil Shafer píše v Po 06. 04. 2009 v 08:49 -0400: > Martin Bjorklund writes: > >Phil Shafer wrote: > >> Would defining an error code (identifier-too-long) be a reasonable > >> resolution? > > > >But this is not a protocol issue. Either your device supports a given > >data model with its identifiers and URI, or it doesn't. This whole > >debate has nothing to do with how NETCONF *servers* should behave, but > >what generic YANG tools (such as 'yangdump', 'pyang', 'smidump') > >should do. > > Yup, and such tools are always build tools or clients, so the error > wouldn't make much sense. Yes, and moreover these tools are run on general computers where the fixed size limits make even less sense. Lada > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Mon Apr 6 07:44:49 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57EAD3A69E7 for ; Mon, 6 Apr 2009 07:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llt0WOGCLPCe for ; Mon, 6 Apr 2009 07:44:48 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 9C6143A67E2 for ; Mon, 6 Apr 2009 07:44:48 -0700 (PDT) Received: (qmail 60651 invoked from network); 6 Apr 2009 14:45:54 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 6 Apr 2009 14:45:54 -0000 X-YMail-OSG: 0Zuw9EUVM1nG0W9KHYJhkE1GG8MeK7Wed1VG_t_X3oafJByKYhjGUn25g6qt7wbzjsqBzPTI2uvs360Zuki2rwu7Rn78JsyBCrIdS7HmBN5HnfcobDIM7zIJwpffvRcMITjqQsC2JZhBNuxqzikpmDNkVCu6msHcBe3_WXUefKD36oIxjA5py2.uzQeseS7hlw_cP7QyeQsYGa0IKMXFtFh_0sYf.spMdqse9w.Z._nNtzjl3IvUYya51GzPZ03h18PKU9MH9quW39NK X-Yahoo-Newman-Property: ymail-3 Message-ID: <49DA15A0.3080000@netconfcentral.com> Date: Mon, 06 Apr 2009 07:45:52 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200904061223.n36CNd8S053985@idle.juniper.net> In-Reply-To: <200904061223.n36CNd8S053985@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] namespace URI length X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 14:44:49 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Hi, >> >> RFC 2396 is silent about URI length (as one would expect). >> >> RFC 2068, sec. 3.2.1 (HTTP 1.1) says: >> >> Note: Servers should be cautious about depending on URI lengths >> above 255 bytes, because some older client or proxy implementations >> may not properly support these lengths. >> >> Clearly the same issue exists for namespace URI as identifier length, >> only worse, because a tool is allowed to accept 1 char URIs and >> be considered compliant. YANG writers provide the URI value directly, >> and they need to know every compiler will always accept (or reject) >> a given length URI. >> >> IMO, "MUST support 1 to 1024 characters" should be sufficient. > > Section 3.2.1 of rfc 2068 also says: > > The HTTP protocol does not place any a priori limit on the length of > a URI. Servers MUST be able to handle the URI of any resource they > serve, and SHOULD be able to handle URIs of unbounded length if they > provide GET-based forms that could generate such URIs. A server > SHOULD return 414 (Request-URI Too Long) status if a URI is longer > than the server can handle (see section 10.4.15). > The very next sentence in RFC 2068: Note: Servers should be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations may not properly support these lengths. But this issue is about YANG the DML, as used by NETCONF. I find the XML arguments to be irrelevant. YANG removes lots of features from XML that are not desirable in NETCONF. Infinite length identifiers are no different the mixed content or XML attributes in this regard. > This paragraph appears directly above the paragraph you quoted. > > We can add HTTP to the list of example protocols with an unbounded > limit that can be implemented on machines with finite memory. > Heck, since NETCONF uses URIs and URIs have no length limit, we > can add NETCONF to that list also. > > Would defining an error code (identifier-too-long) be a reasonable > resolution? > > Thanks, > Phil > > Andy From andy@netconfcentral.com Mon Apr 6 08:12:56 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74A0A28C1C8 for ; Mon, 6 Apr 2009 08:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cvWgmi7BF6j for ; Mon, 6 Apr 2009 08:12:55 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 3578228C1CD for ; Mon, 6 Apr 2009 08:12:53 -0700 (PDT) Received: (qmail 64984 invoked from network); 6 Apr 2009 15:13:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 6 Apr 2009 15:13:58 -0000 X-YMail-OSG: eDgd2EsVM1kLo3aKM0jY2eHKjQaGZiply92J_4mufirv5NCE.8TblUtwt5kzk1b.lJSXNhf4HZSpqB9dBVQUfaabZhE7KzxYC7XM8StM9AlU_91Aw.vWt7JZmYPo3G3dVs9ExFOSAEzi_fU6Caa3y18gHv_AwHxPIgZGotxXbI5yVwh_hdHY3fwPUkQfZjgiKyxN0Xau3qrkPV8DwXQRQwZJ_Xnfyg03e4ZK6o5VTxN8fy1NEZhgyK4dTNXVwMkc4zwEJNZJREDxYKQffnw1dpkdnV1R9THG3U5GOGwBFbFgJ_.MBA_E X-Yahoo-Newman-Property: ymail-3 Message-ID: <49DA1C35.8010705@netconfcentral.com> Date: Mon, 06 Apr 2009 08:13:57 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <49D3CB94.2080508@netconfcentral.com> <200904061223.n36CNd8S053985@idle.juniper.net> <20090406.144835.47982806.mbj@tail-f.com> In-Reply-To: <20090406.144835.47982806.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] namespace URI length X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 15:12:56 -0000 Martin Bjorklund wrote: > Phil Shafer wrote: >> Would defining an error code (identifier-too-long) be a reasonable >> resolution? > > But this is not a protocol issue. Either your device supports a given > data model with its identifiers and URI, or it doesn't. This whole > debate has nothing to do with how NETCONF *servers* should behave, but > what generic YANG tools (such as 'yangdump', 'pyang', 'smidump') > should do. > If the agent consumes YANG/YIN files directly, then IMO it is a YANG application. But in this case, the agent would not be able to return any error except in the logfile during a reboot. IMO, a sentence on translation limits is useful. Except you can't say an implementation MUST NOT run out of memory. So those C99-style minimum maximums are just guidelines anyway, since available memory during an invocation of the tool is unknown. In real code, the tool can just emit a 'resource-denied' error no matter what really happened (e.g., hard limit on foo-stmt reached). There is no way to enforce a "no hard-limits CLR". I understand your point about other YANG statements. Since must-stmt is defined in the ABNF as unbounded, I implemented it as a queue of structs. But only 1 when-stmt is allowed so that is a pointer, not a queue. Whatever the spec says will determine what code is used. If the identifier rule was written differently, I would change the 1 line of code related to identifier length and move on. > > /martin > > Andy From phil@juniper.net Mon Apr 6 08:26:46 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D99B728C1BD for ; Mon, 6 Apr 2009 08:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDWJtf9XRYI8 for ; Mon, 6 Apr 2009 08:26:40 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 8E1DD28C1B7 for ; Mon, 6 Apr 2009 08:26:34 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKSdofbLIoSFZdft+aeCV8IAuita91VQ9E@postini.com; Mon, 06 Apr 2009 08:27:46 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Mon, 6 Apr 2009 08:25:26 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 08:25:26 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 08:25:26 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Apr 2009 08:25:25 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n36FPPM54749; Mon, 6 Apr 2009 08:25:25 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n36FIAXw055372; Mon, 6 Apr 2009 15:18:10 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904061518.n36FIAXw055372@idle.juniper.net> To: Andy Bierman In-Reply-To: <49DA15A0.3080000@netconfcentral.com> Date: Mon, 6 Apr 2009 11:18:09 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 Apr 2009 15:25:25.0504 (UTC) FILETIME=[E8AD0800:01C9B6CB] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] namespace URI length X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 15:26:46 -0000 Andy Bierman writes: >The very next sentence in RFC 2068: > Note: Servers should be cautious about depending on URI lengths > above 255 bytes, because some older client or proxy implementations > may not properly support these lengths. Yes, this is the one you quoted, but you didn't quote the bit about "SHOULD be able to handle URIs of unbounded length". The good news is that YANG and NETCONF need not concern themselves with "older client or proxy implementations", so the "Note" doesn't affect us. >I find the XML arguments to be irrelevant. My point was that URIs in XML are not limited in length so the value of the "xmlns" attribute does not have a length limit. This is true for NETCONF as well; elements in NETCONF are allowd to have monstrously long URIs. Unbounded strings are not new, and there are many other memory-related issues that have already been mentioned on this thread. >YANG removes lots of features from XML that >are not desirable in NETCONF. Infinite length >identifiers are no different the mixed content >or XML attributes in this regard. No, this simply isn't true. We avoid specific features of XML for specific reasons. Mixed content makes data manipulation difficult in languages like XSLT; attributes have namespace issues. There are concrete reasons we avoid them. Lacking such a reason here, why do we need a CLR to limit identifier length? This has become a very repetative debate. Since neither you nor I are adding anything more, would the WG chairs please kindly consider calling for a concensus or finding another way to put this issue to bed? This is too small an issue to eat this much time and space. Thanks, Phil From andy@netconfcentral.com Mon Apr 6 08:38:56 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7919A3A6C79 for ; Mon, 6 Apr 2009 08:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7AO7NFuMFVb for ; Mon, 6 Apr 2009 08:38:49 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id 91F063A6B59 for ; Mon, 6 Apr 2009 08:38:48 -0700 (PDT) Received: (qmail 81812 invoked from network); 6 Apr 2009 15:39:54 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 6 Apr 2009 15:39:54 -0000 X-YMail-OSG: _h8k7ugVM1kV19SEGbX8ixuesqvh27y7AzO6VwaVc_uN3d5ifTzksSQG5rkSKNJ20jxWwINjkEdxi1loLvngF0d3LY8De9tbqTxaOUoyYt6SPLJDCsouALz8mzIxpJ_OM5sGpFJ6jUdmAUIFpvDA5QdtUsknhPUeOiLIxU.q3dq.C3Gby1hFaNE6tNJdsYM4bbfdrvmXoUIwa2129vr7IbC0gw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49DA2248.7010704@netconfcentral.com> Date: Mon, 06 Apr 2009 08:39:52 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200904061518.n36FIAXw055372@idle.juniper.net> In-Reply-To: <200904061518.n36FIAXw055372@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] namespace URI length X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 15:38:56 -0000 Phil Shafer wrote: > Andy Bierman writes: >> The very next sentence in RFC 2068: >> Note: Servers should be cautious about depending on URI lengths >> above 255 bytes, because some older client or proxy implementations >> may not properly support these lengths. > > Yes, this is the one you quoted, but you didn't quote the bit about > "SHOULD be able to handle URIs of unbounded length". The good news > is that YANG and NETCONF need not concern themselves with "older > client or proxy implementations", so the "Note" doesn't affect us. > >> I find the XML arguments to be irrelevant. > > My point was that URIs in XML are not limited in length so the value > of the "xmlns" attribute does not have a length limit. This is > true for NETCONF as well; elements in NETCONF are allowd to have > monstrously long URIs. Unbounded strings are not new, and there > are many other memory-related issues that have already been mentioned > on this thread. > >> YANG removes lots of features from XML that >> are not desirable in NETCONF. Infinite length >> identifiers are no different the mixed content >> or XML attributes in this regard. > > No, this simply isn't true. We avoid specific features of XML for > specific reasons. Mixed content makes data manipulation difficult > in languages like XSLT; attributes have namespace issues. There > are concrete reasons we avoid them. > > Lacking such a reason here, why do we need a CLR to limit identifier > length? > > This has become a very repetative debate. Since neither you nor I > are adding anything more, would the WG chairs please kindly consider > calling for a concensus or finding another way to put this issue > to bed? This is too small an issue to eat this much time and space. > OK, You wore me down (as usual). I don't care anymore. Remove the CLR. I'm going to put a paragraph in the YANG usage guidelines draft about 'SHOULD NOT exceed 64 characters' and why. Since no WG in the history of the IETF has ever even wanted an identifier over 64 chars, this will probably not even get read, let alone cause any problems. > Thanks, > Phil > > Andy From mbj@tail-f.com Mon Apr 6 14:09:23 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFCD73A6CCE for ; Mon, 6 Apr 2009 14:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[AWL=-0.653, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7WxUvqAayV9 for ; Mon, 6 Apr 2009 14:09:23 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 106863A682D for ; Mon, 6 Apr 2009 14:09:22 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 895D5616028 for ; Mon, 6 Apr 2009 23:03:52 +0200 (CEST) Date: Mon, 06 Apr 2009 23:03:52 +0200 (CEST) Message-Id: <20090406.230352.29987150.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] comments on bierman-netmod-yang-usage-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 21:09:24 -0000 Hi, I have some comments on this document. o The Virtual Module concept is a bit unclear, but I believe it will be removed. o section 3.6: Should documents listed in 'reference' statements also be included in (at least) the non-normative reference section? o section 4.4, second bullet: Until a URI is assigned by the IANA, a temporary namespace string SHOULD be selected which is not likely to collide with other YANG namespaces, such as the filename of the Internet Draft containing the YAM. I guess there is a similar rule for assgnments under mib-2 for SMIv2 modules, so maybe this rule should be followed. But I just note that the current I-D YANG modules don't follow this, and I have not seen this being used in XSDs (targetNamespace) in I-Ds. o section 4.5: The description statement MUST be present. It is not clear which description statement you refer to. Typedef? Leaf? o section 4.5: For string data types, if the length of the string is not unbounded in all implementations, then a length statement SHOULD be present. [I don't want to restart the discussion on unbounded strings here!] I think it is obvious that no implementation will support unbounded strings, so I think this rule should be rephrased. My initial suggestion was to: s/is not unbounded/is not required to be unbounded/ but I'm not sure if that is more clear or not. o section 4.6, last bullet. Similar to the previous comment. I don't think max-elements should be used unless it makes sense for the data being modelled. I.e. I think people should be careful not to add "arbitrary" limits... o section 4.6: Do we also want to say that if must/when expressions are present, then their meaning SHOULD be described in the description? o Maybe add a section on naming conventions? We should list our rule that IETF modules use the prefix 'ietf-'. Say that the prefix in IETF modules SHOULD be unique? /martin From cfinss@dial.pipex.com Tue Apr 7 13:03:12 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83CAA3A6B17 for ; Tue, 7 Apr 2009 13:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.074 X-Spam-Level: X-Spam-Status: No, score=0.074 tagged_above=-999 required=5 tests=[AWL=-1.699, BAYES_05=-1.11, RCVD_IN_NJABL_PROXY=1.643, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWF0IB6WzKCk for ; Tue, 7 Apr 2009 13:03:11 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 807913A6A36 for ; Tue, 7 Apr 2009 13:03:11 -0700 (PDT) X-Trace: 91895186/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.34/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.34 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvAEAI9O20k+vBEi/2dsb2JhbACDKjYTijDBAAeDdAY X-IronPort-AV: E=Sophos;i="4.39,339,1235952000"; d="scan'208";a="91895186" X-IP-Direction: IN Received: from 1cust34.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.34]) by smtp.pipex.tiscali.co.uk with SMTP; 07 Apr 2009 21:04:07 +0100 Message-ID: <000201c9b7b3$a71d15e0$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" , "Phil Shafer" References: <200904022057.n32KvifM017904@idle.juniper.net> <49D532F1.7060700@netconfcentral.com> Date: Tue, 7 Apr 2009 20:03:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 20:03:12 -0000 ----- Original Message ----- From: "Andy Bierman" To: "Phil Shafer" Cc: Sent: Thursday, April 02, 2009 11:49 PM Subject: Re: [netmod] identifier length survey > Phil Shafer wrote: > > Andy Bierman writes: > >> Just because XML does not specify a limit does not mean > >> that the NETCONF protocol does not have practical > >> limits imposed from legacy and code generation considerations. > > > > Actually, remembering back to when the RFC 2578 rule > was written, it was done to protect operators, not implementors. > The full test from sec. 3.1, para 3: > > For all descriptors appearing in an information module, the > descriptor shall be unique and mnemonic, and shall not exceed 64 > characters in length. (However, descriptors longer than 32 > characters are not recommended.) This promotes a common language for > humans to use when discussing the information module and also > facilitates simple table mappings for user-interfaces. > > Operators need to be familiar with NETCONF identifiers for > the YANG modules they use. It is even more important than > SNMP, because these YANG identifiers are used in the > instance-identifier data-type. The "max 64" rule > ensures that the YANG readers and network operators (amongst others) > never have to read super-long identifiers in NETCONF/YANG. > That for me is the compelling argument why 64 is plenty big enough. I am more likely to have to read, write, communicate and convey these things and want to be able to do so with the minimum risk of error, so make it long enough that there is no over abbreviation, but not so long that I cannot recognise and remember it in the short term. "dot3OmpEmulationNotBroadcastBitNotOnuLlid" or "gmplsTunnelARHopExplicitReverseLabelPtr" is quite enough. The arguments about tools and capacity seem less relevant to me. Tom Petch > > > Andy > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From andy@netconfcentral.com Tue Apr 7 14:34:44 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 607653A685B for ; Tue, 7 Apr 2009 14:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TD+a3eeY0DD0 for ; Tue, 7 Apr 2009 14:34:43 -0700 (PDT) Received: from n22a.bullet.mail.mud.yahoo.com (n22a.bullet.mail.mud.yahoo.com [68.142.207.188]) by core3.amsl.com (Postfix) with SMTP id 72AE83A692A for ; Tue, 7 Apr 2009 14:34:43 -0700 (PDT) Received: from [68.142.194.243] by n22.bullet.mail.mud.yahoo.com with NNFMP; 07 Apr 2009 21:35:50 -0000 Received: from [68.142.201.254] by t1.bullet.mud.yahoo.com with NNFMP; 07 Apr 2009 21:35:50 -0000 Received: from [127.0.0.1] by omp415.mail.mud.yahoo.com with NNFMP; 07 Apr 2009 21:35:50 -0000 X-Yahoo-Newman-Id: 260485.38765.bm@omp415.mail.mud.yahoo.com Received: (qmail 41741 invoked from network); 7 Apr 2009 21:35:49 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.61 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 7 Apr 2009 21:35:48 -0000 X-YMail-OSG: vhKxukMVM1kBJdPqZVjAvgoq0g99iovgEM84BHa0amO6ybzfOV9KqxzHxnIBlZz75giZRu6CY1sNUD3Cnt1k7Gp9h_DSofy_MkZxmPunZmwrWTPGYegserBtpGNScIVSXcDhLWwHbtecB.PEZml8wnFOYiCJgSFJ7.WTQiFs2_O9LZZ0xNb2AfNbEJGe3KSV3FuF5Vkh6m5QGQsVwreSn3EOh5MXUvHCXW3UdJkFks_4rjO.vWCJooIBlw4oKeaK9ZnKBFWKb6jH3IGg8q5C9.bVL6qBkSh25kqpYnHw9N0wCQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49DBC731.90909@netconfcentral.com> Date: Tue, 07 Apr 2009 14:35:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "tom.petch" References: <200904022057.n32KvifM017904@idle.juniper.net> <49D532F1.7060700@netconfcentral.com> <000201c9b7b3$a71d15e0$0601a8c0@allison> In-Reply-To: <000201c9b7b3$a71d15e0$0601a8c0@allison> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identifier length survey X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 21:34:44 -0000 tom.petch wrote: > ----- Original Message ----- > From: "Andy Bierman" > To: "Phil Shafer" > Cc: > Sent: Thursday, April 02, 2009 11:49 PM > Subject: Re: [netmod] identifier length survey > > >> Phil Shafer wrote: >>> Andy Bierman writes: >>>> Just because XML does not specify a limit does not mean >>>> that the NETCONF protocol does not have practical >>>> limits imposed from legacy and code generation considerations. >> Actually, remembering back to when the RFC 2578 rule >> was written, it was done to protect operators, not implementors. >> The full test from sec. 3.1, para 3: >> >> For all descriptors appearing in an information module, the >> descriptor shall be unique and mnemonic, and shall not exceed 64 >> characters in length. (However, descriptors longer than 32 >> characters are not recommended.) This promotes a common language for >> humans to use when discussing the information module and also >> facilitates simple table mappings for user-interfaces. >> >> Operators need to be familiar with NETCONF identifiers for >> the YANG modules they use. It is even more important than >> SNMP, because these YANG identifiers are used in the >> instance-identifier data-type. The "max 64" rule >> ensures that the YANG readers and network operators (amongst others) >> never have to read super-long identifiers in NETCONF/YANG. >> > > That for me is the compelling argument why 64 is plenty big enough. > The reason I changed my opinion to "don't care" is that is really is no big deal in the code. That argument is a wash. For any detail, we can probably find 2 vendors that think it should be implemented 1 way and 2 more that think it should be implemented another way. It's just code. It takes 1/1000 as much time to change it, than it does to argue about it. > I am more likely to have to read, write, communicate and convey these > things and want to be able to do so with the minimum risk of error, so make it > long enough that there is no over abbreviation, but not so long that > I cannot recognise and remember it in the short term. > > "dot3OmpEmulationNotBroadcastBitNotOnuLlid" > or > "gmplsTunnelARHopExplicitReverseLabelPtr" > is quite enough. > Yes, and therefore Phil is right about the self-regulating aspect of the CLR, not to mention the real CLR that will be in the YANG Usage Guidelines. WG members will object to long identifiers because they are unreadable, not because some YANG vendor might not like to implement their code this way or that way. > The arguments about tools and capacity seem less relevant to > me. > > Tom Petch > Andy From mbj@tail-f.com Wed Apr 8 04:02:45 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12E643A6B20 for ; Wed, 8 Apr 2009 04:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcqRx4PYMaT5 for ; Wed, 8 Apr 2009 04:02:44 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id BECE83A6ADE for ; Wed, 8 Apr 2009 04:01:57 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1B3A876C54F; Wed, 8 Apr 2009 13:03:04 +0200 (CEST) Date: Wed, 08 Apr 2009 13:03:03 +0200 (CEST) Message-Id: <20090408.130303.112175402.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49D78349.4010404@netconfcentral.com> References: <49D78349.4010404@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-04: when-stmt and rpc/input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 11:02:45 -0000 Hi, Andy Bierman wrote: > Hi, > > The section on the rpc input statement is not clear enough. > > I don't know what para 2 means: > > If a container in the input tree has a "presence" statement, the > container need not be present in a NETCONF RPC invocation. > > An NP container does not have to be present unless it has > 1 or more mandatory descendants. I see what you mean. I suggest we simply remove this sentence. > The when-stmt is not mentioned at all. > IMO, the agent should ignore when-stmt for rpc/input. Section 7.19.5 The when Statement specifies how the when statement is used in rpc input/output. I believe it was the consensus to allow when in rpcs (see the mail thread called "Proposed consensus mail on yang-00172"), so I'd rather fix the text in the RPC section instead. I propose this text in section 7.13.2 (and similar in 7.13.3): If any node has a "when" statement which would evaluate to false, then this node MUST NOT be present in the input tree. /martin From reid@snmp.com Wed Apr 8 13:59:30 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 473463A687D for ; Wed, 8 Apr 2009 13:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7qLtBr8CIhu for ; Wed, 8 Apr 2009 13:59:29 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 5E61A3A686A for ; Wed, 8 Apr 2009 13:59:29 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA14536 for ; Wed, 8 Apr 2009 17:00:36 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id RAA09621 for ; Wed, 8 Apr 2009 17:00:35 -0400 (EDT) Message-Id: <200904082100.RAA09621@adminfs.snmp.com> To: netmod@ietf.org From: David Reid In-reply-to: Your message of Wed, 01 Apr 2009 15:30:28 -0400. <200904011930.PAA07624@adminfs.snmp.com> Date: Wed, 08 Apr 2009 17:00:35 -0400 Sender: reid@snmp.com Subject: Re: [netmod] question about unions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 08 Apr 2009 20:59:30 -0000 > If I have the following union: > > leaf foo { > type union { > type int32; > type string; > } > } Is it possible in the above example to send the string '010'? Since '010' will be treated as the integer 10, I'm assuming that there is no way to pass '010' as a string in union like this. Is that right? I'm actually interested in a union like this: leaf fum { type union { type binary; type string; } } I think this example has the same type of problem since some strings are also legal binary encodings. -David Reid From spakes@snmp.com Wed Apr 8 14:14:24 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3F228C19A for ; Wed, 8 Apr 2009 14:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmWP5Y7rTmhn for ; Wed, 8 Apr 2009 14:14:23 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 55A4028C1F4 for ; Wed, 8 Apr 2009 14:14:23 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA15952; Wed, 8 Apr 2009 17:15:29 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id RAA09731; Wed, 8 Apr 2009 17:15:29 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Wed, 8 Apr 2009 17:15:26 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: netmod@ietf.org In-Reply-To: <200904032122.RAA02614@adminfs.snmp.com> Message-ID: References: <200904032122.RAA02614@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [netmod] SMIv2 to YANG mapping: OBJECT-IDENTITY X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 21:14:24 -0000 It hasn't been that long ago that the working group added identityref to the Yang spec. While others were working on identityref, I was trying to figure out how to map conformance statements from the SNMP world to the Yang world. As a result of that work, I began to believe that Yang really needed to have a more generic ref type, but other duties as assigned took my attention away from the matter. Now, as I read the posts about mapping SNMP's OBJECT-IDENTITY/ OBJECT IDENTIFIER to Yang's identity/identityref, I have the same thought that I did before about the need for a more generic ref type. We started out with a keyref, which was too restrictive. Andy proposed the leafref in July, 2008. The leafref was too restrictive to handle OBJECT-IDENTITY mapping, so identityref was added. What I propose is that we drop identityref and leafref and replace them with a generic 'ref' that can point to: - leafs - identities - lists (and other constructs) - modules - groupings - containers - notifications Under this proposal, a MIB object of type OBJECT IDENTIFIER would always be converted to a leaf having a type that is the generic ref type. If the working group were to choose to adopt this proposal, I don't see any reason why Yang would need to define the built-in object-identifier and object-identifier-128 types. Regards, David Spakes On Fri, 3 Apr 2009, David Reid wrote: > > On Wed, Apr 01, 2009 at 08:10:36PM +0200, David Reid wrote: > > > > > > o Need to add support for the translation of OBJECT-IDENTITY macro > > > > invocations to YANG identity statements. > > > > > > The biggest problem I'm having with OBJECT-IDENTITY is knowing when to map > > > a SYNTAX clause of a MIB object with a SYNTAX of OBJECT IDENTIFIER to > > > a YANG identityref. > > > > There is likely no good answer since the SMIv2 does not distinguish > > how OBJECT IDENTIFIERs are used. > > I was afraid of that. I can't come up with a good answer. Here is a > possibility: use a yang extension to carry the SMIv2 OID information > from the SMIv2 OBJECT-IDENTITY to the YANG identity and then just convert > the SMIv2 OBJECT IDENTIFIER SYNTAX to a YANG object-identifier type in > all cases. On Tue, 8 Jul 2008 netmod@ietf.org wrote: > I have some concerns about the keyref builtin data type. > > 8.8. The keyref Built-in Type > ------------------------------ > > The keyref type is used to reference a particular list entry in the > data tree. Its value is constrained to be the same as the key of an > existing list entry. ... > It is also too restrictive to limit a keyref to a leaf used as a key. > A new list can be created with key leafs which happen to already be > defined as non-key leafs in other data structure (does not have to > be in a list). Perhaps a separate 'leafref' would be better for this > purpose. IMO, this is also needed to define notification content > properly. ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From mbj@tail-f.com Wed Apr 8 14:56:29 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DE413A6EA3 for ; Wed, 8 Apr 2009 14:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0yLu5QJVxSJ for ; Wed, 8 Apr 2009 14:56:28 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B7AFC3A6B36 for ; Wed, 8 Apr 2009 14:56:28 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id E63D0616005; Wed, 8 Apr 2009 23:57:34 +0200 (CEST) Date: Wed, 08 Apr 2009 23:57:34 +0200 (CEST) Message-Id: <20090408.235734.237591776.mbj@tail-f.com> To: spakes@snmp.com From: Martin Bjorklund In-Reply-To: References: <200904032122.RAA02614@adminfs.snmp.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] SMIv2 to YANG mapping: OBJECT-IDENTITY X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 21:56:29 -0000 Hi David, David Spakes wrote: > What I propose is that we drop identityref and leafref and replace them > with a generic 'ref' that can point to: > > - leafs > - identities > - lists (and other constructs) > - modules > - groupings > - containers > - notifications > > Under this proposal, a MIB object of type OBJECT IDENTIFIER would always > be converted to a leaf having a type that is the generic ref type. I must admit I don't quite understand how this would work. Maybe you could examplify your proposal by showing how a leaf/leafref, identity/identityref and OID would be done with the current syntax, and with your proposal? /martin From j.schoenwaelder@jacobs-university.de Wed Apr 8 15:36:10 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0B103A6A8C for ; Wed, 8 Apr 2009 15:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtkSttN1EKhg for ; Wed, 8 Apr 2009 15:36:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 97C5928B56A for ; Wed, 8 Apr 2009 15:36:01 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A05AAC0019; Thu, 9 Apr 2009 00:37: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 iKnaxBbr1znq; Thu, 9 Apr 2009 00:37:08 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BFF98C0017; Thu, 9 Apr 2009 00:37:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 80A31A6B42E; Thu, 9 Apr 2009 00:36:50 +0200 (CEST) Date: Thu, 9 Apr 2009 00:36:50 +0200 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20090408223650.GA23576@elstar.local> Mail-Followup-To: David Spakes , "netmod@ietf.org" References: <200904032122.RAA02614@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] SMIv2 to YANG mapping: OBJECT-IDENTITY X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2009 22:36:11 -0000 On Wed, Apr 08, 2009 at 11:15:26PM +0200, David Spakes wrote: > Under this proposal, a MIB object of type OBJECT IDENTIFIER would always > be converted to a leaf having a type that is the generic ref type. > If the working group were to choose to adopt this proposal, I don't see > any reason why Yang would need to define the built-in object-identifier > and object-identifier-128 types. An SMIv2 object of type OBJECT IDENTIFIER can hold arbitrary OID values; restricting this to something that is defined somewhere won't work. Please also note that there are other protocols using OIDs and hence these types will be useful even if there is a way to eliminate OIDs from translated SMIv2 modules (which I doubt will be possible). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Washam.Fan@huaweisymantec.com Wed Apr 8 23:47:26 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E32E93A67EE for ; Wed, 8 Apr 2009 23:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9Wx5PS9kgdp for ; Wed, 8 Apr 2009 23:47:26 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id E37633A6BEA for ; Wed, 8 Apr 2009 23:47:25 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHT00BNSMWQAI10@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Thu, 09 Apr 2009 14:48:28 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHT000H6MWOMJ00@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Thu, 09 Apr 2009 14:48:26 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 09 Apr 2009 14:48:24 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Thu, 09 Apr 2009 14:48:24 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090408.235734.237591776.mbj@tail-f.com> References: <200904032122.RAA02614@adminfs.snmp.com> <20090408.235734.237591776.mbj@tail-f.com> Cc: netmod@ietf.org Subject: [netmod] sec 9.9.6, yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 06:47:27 -0000 Hi, current interface definition: list interface { key "name"; leaf name { type string; } leaf ifIndex { type uint32; } list address { key "ip"; leaf ip { type yang:ip-address; } } } And corresponding default-address definition is: container default-address { leaf ifname { type leafref { path "../../interface/name"; } } leaf address { type leafref { path "../../interface[name = current()/../ifname]" + "/address/ip"; } } } If I changed the nested keys to ones placing in parallel: list interface { key "name" "ip"; leaf name { type string; } leaf ifIndex { type uint32; } leaf ip { type yang:ip-address; } } Is the corresponding default-address defined as: container default-address { leaf ifname { type leafref { path "../../interface/name"; } } leaf address { type leafref { path "../../interface[name = current()/../ifname]" + "/ip"; } } } or container default-address { leaf ifname { type leafref { path "../../interface/name"; } } leaf address { type leafref { path "../../interface/ip"; } } } Predicates are not used in the latter case, but I do not think it is clear in current text that predicates MUST be used when refering a list entry if the list has multiplex keys. PS: line 5, para1, sec 9.10.2: s/defined the module/defined in the module/ washam From Washam.Fan@huaweisymantec.com Thu Apr 9 00:01:30 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 697693A6BF0 for ; Thu, 9 Apr 2009 00:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.291 X-Spam-Level: X-Spam-Status: No, score=-1.291 tagged_above=-999 required=5 tests=[AWL=-0.796, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xH6fc8BCnkDo for ; Thu, 9 Apr 2009 00:01:29 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 18B753A6EAE for ; Thu, 9 Apr 2009 00:00:41 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHT003F0NILS120@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Thu, 09 Apr 2009 15:01:35 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHT000I7NIJMJ00@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Thu, 09 Apr 2009 15:01:33 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 09 Apr 2009 15:01:31 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Thu, 09 Apr 2009 15:01:31 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090408.235734.237591776.mbj@tail-f.com> References: <200904032122.RAA02614@adminfs.snmp.com> <20090408.235734.237591776.mbj@tail-f.com> Cc: netmod@ietf.org Subject: [netmod] sec 7.8.3.1, yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 07:01:30 -0000 Hi, given server: list server { key "name"; unique "ip port"; leaf name { type string; } leaf ip { type inet:ip-address; } leaf port { type inet:port-number; } } The following configuration is valid: smtp 192.0.2.1 25 http 192.0.2.1 ftp 192.0.2.1 If I changed the server definition to: list server { key "name"; unique "ip port"; leaf name { type string; } leaf ip { type inet:ip-address; } leaf port { default 22; <- set default type inet:port-number; } } then, the same configuration should be invalid, right? PS: the title, sec 7.8.3 s/lists's/list's/ washam From mbj@tail-f.com Thu Apr 9 06:10:28 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0038D3A6881 for ; Thu, 9 Apr 2009 06:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.281 X-Spam-Level: X-Spam-Status: No, score=0.281 tagged_above=-999 required=5 tests=[AWL=-2.140, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MANGLED_NAIL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3NTAERmxO5p for ; Thu, 9 Apr 2009 06:10:24 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id F25003A6A6E for ; Thu, 9 Apr 2009 06:10:22 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id E2C74616005 for ; Thu, 9 Apr 2009 15:11:28 +0200 (CEST) Date: Thu, 09 Apr 2009 15:11:28 +0200 (CEST) Message-Id: <20090409.151128.236670770.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_Apr__9_15_11_28_2009_379)--" Content-Transfer-Encoding: 7bit Subject: [netmod] YANG draft -05 changes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 13:10:28 -0000 ----Next_Part(Thu_Apr__9_15_11_28_2009_379)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, As discussed in S.F., here is a diff with changes between 04 and 05-to-be. Please check that my edits are correct! There are two open issues: o identifier length. It seems we do have consensus to remove the length restriction, so unless anyone else has any comments, I will make that change in -05. o the text about schema monitoring (5.6.5). Should we move this into the monitoring draft? I think it would be better to move it out of this draft. When these issues are resolved, I will post 05 which I think is ready for WGLC. /martin ----Next_Part(Thu_Apr__9_15_11_28_2009_379)-- Content-Type: Text/Html; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-netmod-yang-05-from-4.wdiff.html" wdiff draft-ietf-netmod-yang-04.txt draft-ietf-netmod-yang-05.txt 
1.  Introduction

   Today, the NETCONF protocol [RFC4741] lacks a standardized way to
   create data models.  Instead, vendors are forced to use proprietary
   solutions.  In order for NETCONF to be a interoperable protocol,
   models must be defined in a vendor-neutral way.  YANG provides the
   language and rules for defining such models for use with NETCONF.

   YANG is a data modeling language used to model configuration and
   state data manipulated by the NETCONF protocol, NETCONF remote
   procedure calls, and NETCONF notifications.  YANG models the
   operations and content layers of NETCONF (see the NETCONF protocol
   [RFC4741], section 1.1).

   This document describes the syntax and semantics of the YANG
   language, how the data model defined in a YANG module is represented
   in XML, and how NETCONF operations are used to manipulate the data.

[skipping...]

4.2.4.  Built-in Types

   YANG has a set of built-in types, similar to those of many
   programming languages, but with some differences due to special
   requirements from the management domain.  The following table
   summarizes the built-in types discussed in Section 9:

   +---------------------+-------------+-------------------------------+
   | Name                | Type        | Description                   |
   +---------------------+-------------+-------------------------------+
   | binary              | Text        | Any binary data               |
   | bits                | Text/Number | A set of bits or flags        |
   | boolean             | Text        | "true" or "false"             |
   | decimal64           | Number      | 64-bit signed decimal number  |
   | empty               | Empty       | A leaf that does not have any |
   |                     |             | value                         |
   | enumeration         | Text/Number | Enumerated strings with       |
   |                     |             | associated numeric values     |
   | float32             | Number      | 32-bit IEEE floating point    |
   |                     |             | real number                   |
   | float64             | Number      | 64-bit IEEE floating point    |
   |                     |             | real number                   |
   | identityref         | Text        | A reference to an abstract    |
   |                     |             | identity                      |
   | instance-identifier | Text        | References a data tree node   |
   | int8                | Number      | 8-bit signed integer          |
   | int16               | Number      | 16-bit signed integer         |
   | int32               | Number      | 32-bit signed integer         |
   | int64               | Number      | 64-bit signed integer         |
   | leafref             | Text/Number | A reference to a leaf         |
   |                     |             | instance                      |
   | string              | Text        | Human readable string         |
   | uint8               | Number      | 8-bit unsigned integer        |
   | uint16              | Number      | 16-bit unsigned integer       |
   | uint32              | Number      | 32-bit unsigned integer       |
   | uint64              | Number      | 64-bit unsigned integer       |
   | union               | Text/Number | Choice of member types        |
   +---------------------+-------------+-------------------------------+

   The "type" statement is covered in Section 9.

[skipping...]

5.3.  XML Namespaces

   All YANG definitions are specified within a module that is bound to a
   particular XML Namespace [XML-NAMES], which is a globally unique URI
   [RFC3986].  A NETCONF client or server uses the namespace during XML
   encoding of data.

   Namespaces for standard modules published in RFC streams MUST be assigned by IANA.
   IANA, see Section 14.

   Namespaces for private modules are assigned by the organization
   owning the module without a central registry.  It is RECOMMENDED to
   choose namespaces that will have a low probability of colliding with
   standard or other enterprise modules, e.g. by using the enterprise or
   organization name in the namespace.

   The "namespace" statement is covered in Section 7.1.3.

5.3.1.  YANG XML Namespace

   YANG defines its own XML namespace for NETCONF <edit-config>
   operations.  This namespace is "urn:ietf:params:xml:ns:yang:1" [XXX
   IANA]. "urn:ietf:params:xml:ns:yang:1".

[skipping...]

7.1.  The module Statement

   The "module" statement defines the module's name, and groups all
   statements which belong to the module together.  The "module"
   statement's argument is the name of the module, followed by a block
   of substatements that hold detailed module information.  The module
   name follows the rules for identifiers in Section 6.2.

   Standard module names

   Names of modules published in RFC streams MUST be assigned by IANA. IANA,
   see Section 14.

[skipping...]

7.2.  The submodule Statement

   While the primary unit in YANG is a module, a YANG module can itself
   be constructed out of several submodules.  Submodules allows a module
   designer to split a complex model into several pieces where all the
   submodules contribute to a single namespace, which is defined by the
   module that includes the submodules.

   The "submodule" statement is used to give the submodule a name, and
   to group all statements which belong to the submodule together.

   The "submodule" statement, which MUST be present at most once, takes
   as an argument an identifier which is the name of the submodule,
   followed by a block of substatements that hold detailed submodule
   information.

   Standard submodule names

   Names of submodules published in RFC streams MUST be assigned by IANA.
   IANA, see Section 14.

[skipping...]

7.5.7.  XML Encoding Rules

   A container node is encoded as an XML element.  The element's name is
   the container's identifier, and its XML namespace is the module's XML
   namespace.

   The container's child nodes are encoded as subelements to the
   container element, element.  If the container defines RPC input or output
   parameters, the subelements are encoded in the same order as they are
   defined within the container statement.  Otherwise, the subelements
   are encoded in any order.

   A NETCONF server that replies to a <get> or <get-config> request MAY
   choose not to send a container element if the container node does not
   have the "presence" statement and no child nodes exist.  Thus, a
   client that receives an <rpc-reply> for a <get> or <get-config>
   request, must be prepared to handle the case that a container node
   without a presence statement is not present in the XML.

[skipping...]

7.8.5.  XML Encoding Rules

   A list is encoded as a series of XML elements, one for each entry in
   the list.  Each element's name is the list's identifier, and its XML
   namespace is the module's XML namespace.

   The list's key nodes are encoded as subelements to the list's
   identifier element, in the same order as they are defined within the
   key statement.

   The rest of the list's child nodes are encoded as subelements to the
   list element, after the keys, keys.  If the list defines RPC input or
   output parameters, the subelements are encoded in the same order as
   they are defined within the list statement.  Otherwise, the
   subelements are encoded in any order.

[skipping...]

7.9.2.  The choice's case Statement

   The "case" statement is used to define branches of the choice.  It
   takes as an argument an identifier, followed by a block of
   substatements that holds detailed case information.

   The identifier is used to identify the case node in the schema tree.
   A case node does not exist in the data tree.

   Within a "case" statement, the "anyxml", "container", "leaf", "list",
   "leaf-list", "uses", and "augment" "uses" statements can be used to define child nodes
   to the case node.  The identifiers of all these child nodes MUST be
   unique within all cases in a choice.  For example, the following is
   illegal:

     choice interface-type {     // This example is illegal YANG
         case a {
             leaf ethernet { ... }
         }
         case b {
             container ethernet { ...}
         }
     }

[skipping...]

7.13.2.  The input Statement

   The "input" statement, which is optional, is used to define input
   parameters to the RPC method.  It does not take an argument.  The
   substatements to "input" defines nodes under the RPC's input node.

   If a container in the input tree has a "presence" statement, the
   container need not be present in a NETCONF RPC invocation.

   If a leaf in the input tree has a "mandatory" statement with the
   value "true", the leaf MUST be present in a NETCONF RPC invocation.

   If a leaf in the input tree has a default value, the NETCONF server
   MUST internally use this default if the leaf is not present in a
   NETCONF RPC invocation.

   If a "config" statement is present for any node in the input tree, it
   is ignored.

   If any node has a "when" statement which would evaluate to false,
   then this node MUST NOT be present in the input tree.

7.13.2.1.  The input's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | container    | 7.5     | 0..n        |
                 | grouping     | 7.11    | 0..n        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | typedef      | 7.3     | 0..n        |
                 | uses         | 7.12    | 0..n        |
                 +--------------+---------+-------------+

7.13.3.  The output Statement

   The "output" statement, which is optional, is used to define output
   parameters to the RPC method.  It does not take an argument.  The
   substatements to "output" defines nodes under the RPC's output node.

   If a container in the output tree has a "presence" statement, the
   container need not be present in a NETCONF RPC reply

   If a leaf in the output tree has a "mandatory" statement with the
   value "true", the leaf MUST be present in a NETCONF RPC reply.

   If a leaf in the output tree has a default value, the NETCONF client
   MUST internally use this default if the leaf is not present in a
   NETCONF RPC reply.

   If a "config" statement is present for any node in the output tree,
   it is ignored.

   If any node has a "when" statement which would evaluate to false,
   then this node MUST NOT be present in the output tree.

[skipping...]

7.14.2.  XML Encoding Rules

   A notification node is encoded as a child XML element to the
   <notification> element defined in NETCONF Event Notifications
   [RFC5277].  The element's name is the notification's identifier, and
   its XML namespace is the module's XML namespace.

   The notifications's child nodes are encoded as subelements to the
   notification node's XML element, in the same order as they are
   defined within the notification statement.

[skipping...]

7.15.  The augment Statement

   The "augment" statement allows a module or submodule to add to the
   schema tree defined in another module an external module, or submodule, the current module and
   its submodules, and to add to the nodes from a grouping in a "uses"
   statement.  The argument is a string which identifies a node in the
   schema tree.  This node is called the augment's target node.  The
   target node MUST be either a container, list, choice, case, input,
   output, or notification node.  It is augmented with the nodes defined
   in the substatements that follow the "augment" statement.

   The argument string is a schema node identifier.  The syntax is
   formally defined by the rule "augment-arg" in Section 12.  If the
   "augment" statement is on the top-level in a module or submodule, the
   absolute form (defined by the rule "absolute-schema-nodeid" in
   Section 12) of a schema node identifier MUST be used.  If the
   "augment" statement is in a "uses" statement, the descendant form
   (defined by the rule "descendant-schema-nodeid" in Section 12) MUST
   be used.

   The syntax for a schema node identifier is a subset of the XPath
   syntax.  It is an absolute or relative XPath location path in
   abbreviated syntax, where axes and predicates are not permitted.

   If the target node is a container, list, case, input, output, or
   notification node, the "container", "leaf", "list", "leaf-list",
   "uses", and "choice" statements can be used within the "augment"
   statement.

   If the target node is a choice node, the "case" statement can be used
   within the "augment" statement.

   If the target node is in another module, then nodes added by the
   augmentation MUST NOT be mandatory nodes (see Section 3.1).

   The augment statement MUST NOT add multiple nodes with the same name
   from the same module to the target node.

7.15.1.  The augment's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | case         | 7.9.2   | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | container    | 7.5     | 0..n        |
                 | description  | 7.19.3  | 0..1        |
                 | if-feature   | 7.18.2  | 0..n        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | uses         | 7.12    | 0..n        |
                 | when         | 7.19.5  | 0..1        |
                 +--------------+---------+-------------+

7.15.2.  XML Encoding Rules

   All data nodes defined in the "augment" statement are defined as XML
   elements in the XML namespace of the module where the "augment" is
   specified.

   When a node is augmented, the augmented augmenting child nodes are encoded after
   all normal child nodes.  If the node is augmented more than once, the
   blocks of augmented child nodes are sorted (in alphanumeric order)
   according as
   subelements to their namespace URI and name of the first child node augmented node, in
   each block. any order.

[skipping...]

7.19.5.  The when Statement

   The "when" statement makes its parent data definition statement
   conditional.  The node defined by the parent data definition
   statement is only valid when the condition specified by the "when"
   statement is satisfied.  The statement's argument is an XPath
   expression, which is used to formally specify this condition.  If the
   XPath expression conceptually evaluates to "true" for a particular
   instance, then the node defined by the parent data definition
   statement is valid, otherwise it is not.

   See Section 8.3.2 for additional information.

   The XPath expression is conceptually evaluated in the following
   context:

   o  If the "when" statement is a child of an "augment" statement, then
      the context node is the augment's target node in the data tree, if
      the target node is a data node.  Otherwise, the context node is
      the closest ancestor node to the target node which is also a data
      node.

   o  If the "when" statement is a child of a "choice" or "case"
      statement, then the context node is the closest ancestor node to
      the "choice" or "case" node which is also a data node.

   o  If the "when" statement is a child of any other data definition
      statement, the context node is the data definition's node in the
      data tree.

   o  The accessible tree is made up of all nodes in the data tree, and
      all leafs with default values.

   o  The set of namespace declarations is the set of all "import"
      statements' prefix and namespace pairs, and the "prefix"
      statement's prefix for the "namespace" statement's URI.

   o  Elements without a namespace refer to nodes in the current module.

   o  The function library is the core function library defined in
      [XPATH], and a function "current()" which returns a node set with
      the initial context node.

   The accessible data tree depends on the context node:

   o  If the context node represents configuration, the tree is the data
      in one of the datastores <startup/>, <running/>, or <candidate/>.
      The XPath root node has all top-level configuration data nodes in
      all modules as children.

   o  If the context node represents state data, the tree is all state
      data on the device, and the <running/> datastore.  The XPath root
      node has all top-level data nodes in all modules as children.

   o  If the context node represents notification content, the tree is
      the notification XML instance document.  The XPath root node has
      the element representing the notification being defined as the
      only child.

   o  If the context node represents RPC input parameters, the tree is
      the RPC XML instance document.  The XPath root node has the
      element representing the RPC method being defined as the only
      child.

   o  If the context node represents RPC output parameters, the tree is
      the RPC reply instance document.  The XPath root node has the
      elements representing the RPC output parameters as children.

   The result of the XPath expression is converted to a boolean value
   using the standard XPath rules.

   The XPath expression MUST NOT include any references to the context
   node or any descendants of the context node.

   Note that the XPath expression is conceptually evaluated.  This means
   that an implementation does not have to use an XPath evaluator on the
   device.  The augment can very well be implemented with specially
   written code.

[skipping...]

8.3.1.  Payload Parsing

   When content arrives in RPC payloads, it MUST be well-formed and
   valid XML,
   following the hierarchy and content rules defined by the set of
   models the device implements.

[skipping...]

9.2.4.  The range Statement

   The "range" statement, which is an optional substatement to the
   "type" statement, takes as an argument a range expression string.  It
   is used to restrict integer and floating point decimal built-in types, or types
   derived from those.

[skipping...]

9.3.  The Floating Point decimal64 Built-in Types Type

   The floating point built-in types are float32 and float64.  They
   represent floating point values decimal64 type represents a subset of single and double precision the real numbers, which can
   be represented by decimal numerals.  The value space of decimal64 is
   the set of numbers that can be obtained by multiplying a 64 bit
   signed integer by a negative power of ten, i.e. expressible as
   defined in [IEEE.754].  Special values are positive
   "i\&#A0;x\&#A0;10^\&#8209;n" where i is an integer64 and negative
   infinity, n is an
   integer between 1 and not-a-number. 18, inclusively.

9.3.1.  Lexicographic Representation

   A floating point decimal64 value is lexicographically represented as consisting
   of an optional
   sign ("+" or "-"), followed by a sequence of decimal mantissa followed, optionally, by the character "E" or
   "e", digits,
   optionally followed by an integer exponent.  The special values positive
   and negative infinity and not-a-number have lexical representations
   INF, -INF a period ('.') as a decmial indicator and NaN, respectively. a
   sequence of decimal digits.  If no sign is specified, "+" is assumed.

9.3.2.  Canonical Form

   The minimal value accepted for canonical form of a
   float positive decimal64 does not include the sign
   "+".  The decimal point is -INF, required.  Leading and trailing zeros are
   prohibited, subject to the rule that there MUST be at least one digit
   before and after the maximal decimal point.  The value accepted for a float zero is INF.

9.3.2.  Canonical Form

   [Editor's Note: TBD] represented as
   "0.0".

9.3.3.  Restrictions

   All floating point types

   A decmial64 type can be restricted with the "range" statement
   (Section 9.2.4).

9.3.4.  Usage Example

     type float32 {
         range "1..4.5 | 10 | 20..INF";
     }  The fraction-digits Statement

   The "fraction-digits" statement, which is equivalent a substatement to the
   "type" statement, MUST be present if the type float32 {
         range "1..4.5 | 10 is "decimal64".  It
   takes as an argument an integer between 1 and 18, inclusively.  It
   controls the size of the minimum difference between values of a
   decimal64 type, by restricting the value space to numbers that are
   expressible as i x 10^-n where n is the fraction-digits argument.

9.3.5.  Usage Example

     type decimal64 {
         fraction-digits 2;
         range "1 .. 3.14 | 10 | 20..max";
     }

[skipping...]

9.12.  The union Built-in Type

   The union built-in type represents a value that corresponds to one of
   its member types.

   When the type is "union", the "type" statement (Section 7.4) MUST be
   present.  It is used to repeatedly specify each member type of the
   union.  It takes as an argument a string which is the name of a
   member type.

   A member type can be of any built-in or derived type, except it MUST
   NOT be one of the built-in types "empty" or "leafref".

   When a string representing a union data type is validated, the string
   is validated against each member type, in the order they are
   specified in the type statement, until a match is found.

[skipping...]

11.1.  Formal YIN Definition

   There is a one-to-one correspondence between YANG keywords and YIN
   elements.  The local name of a YIN element is identical to the
   corresponding YANG keyword.  This means in particular that the
   document element (root) of a YIN document is always <module> or
   <submodule>.

   YIN elements corresponding to the core YANG keywords belong to the
   namespace whose associated URI is
   "urn:ietf:params:xml:ns:yang:yin:1".  [XXX IANA].

   YIN elements corresponding to extension keywords belong to the
   namespace of the YANG module where the extension keyword is declared
   via the "extension" statement.

[skipping...]

             Mapping of arguments of the core YANG statements.

            +------------------+---------------+-------------+
            | keyword          | argument name | yin-element |
            +------------------+---------------+-------------+
            | anyxml           | name          | false       |
            | argument         | name          | false       |
            | augment          | target-node   | false       |
            | base             | name          | false       |
            | belongs-to       | module        | false       |
            | bit              | name          | false       |
            | case             | name          | false       |
            | choice           | name          | false       |
            | config           | value         | false       |
            | contact          | info          | true        |
            | container        | name          | false       |
            | default          | value         | false       |
            | description      | text          | true        |
            | deviate          | value         | false       |
            | deviation        | target-node   | false       |
            | enum             | name          | false       |
            | error-app-tag    | value         | false       |
            | error-message    | value         | true        |
            | extension        | name          | false       |
            | feature          | name          | false       |
            | fraction-digits  | value         | false       |
            | grouping         | name          | false       |
            | identity         | name          | false       |
            | if-feature       | name          | false       |
            | import           | module        | false       |
            | include          | module        | false       |
            | input            | <no argument> | n/a         |
            | key              | value         | false       |
            | leaf             | name          | false       |
            | leaf-list        | name          | false       |
            | length           | value         | false       |
            | list             | name          | false       |
            | mandatory        | value         | false       |
            | max-elements     | value         | false       |
            | min-elements     | value         | false       |
            | module           | name          | false       |
            | must             | condition     | false       |
            | namespace        | uri           | false       |
            | notification     | name          | false       |
            | ordered-by       | value         | false       |
            | organization     | info          | true        |
            | output           | <no argument> | n/a         |
            | path             | value         | false       |
            | pattern          | value         | false       |
            | position         | value         | false       |
            | prefix           | value         | false       |
            | presence         | value         | false       |
            | range            | value         | false       |
            | reference        | info          | false       |
            | refine           | target-node   | false       |
            | require-instance | value         | false       |
            | revision         | date          | false       |
            | revision-date    | date          | false       |
            | rpc              | name          | false       |
            | status           | value         | false       |
            | submodule        | name          | false       |
            | type             | name          | false       |
            | typedef          | name          | false       |
            | unique           | tag           | false       |
            | units            | name          | false       |
            | uses             | name          | false       |
            | value            | value         | false       |
            | when             | condition     | false       |
            | yang-version     | value         | false       |
            | yin-element      | value         | false       |
            +------------------+---------------+-------------+

                                  Table 1

[skipping...]

12.  YANG ABNF Grammar

   In YANG, almost all statements are unordered.  The ABNF grammar
   [RFC5234] defines the canonical order.  To improve module
   readability, it is RECOMMENDED that clauses be entered in this order.

   Within the ABNF grammar, unordered statements are marked with
   comments.

   This grammar assumes that the scanner replaces YANG comments with a
   single space character.

   module-stmt         = optsep module-keyword sep identifier-arg-str
                         optsep
                         "{" stmtsep
                             module-header-stmts
                             linkage-stmts
                             meta-stmts
                             revision-stmts
                             body-stmts
                         "}" optsep

   submodule-stmt      = optsep submodule-keyword sep identifier-arg-str
                         optsep
                         "{" stmtsep
                             submodule-header-stmts
                             linkage-stmts
                             meta-stmts
                             revision-stmts
                             body-stmts
                         "}" optsep

   module-header-stmts = ;; these stmts can appear in any order
                         [yang-version-stmt stmtsep]
                          namespace-stmt stmtsep
                          prefix-stmt stmtsep

   submodule-header-stmts =
                         ;; these stmts can appear in any order
                         [yang-version-stmt stmtsep]
                          belongs-to-stmt stmtsep

   meta-stmts          = ;; these stmts can appear in any order
                         [organization-stmt stmtsep]
                         [contact-stmt stmtsep]
                         [description-stmt stmtsep]
                         [reference-stmt stmtsep]
   linkage-stmts       = ;; these stmts can appear in any order
                         *(import-stmt stmtsep)
                         *(include-stmt stmtsep)

   revision-stmts      = *(revision-stmt stmtsep)

   body-stmts          = *((extension-stmt /
                            feature-stmt /
                            identity-stmt /
                            typedef-stmt /
                            grouping-stmt /
                            data-def-stmt /
                            augment-stmt /
                            rpc-stmt /
                            notification-stmt /
                            deviation-stmt) stmtsep)

   data-def-stmt       = container-stmt /
                         leaf-stmt /
                         leaf-list-stmt /
                         list-stmt /
                         choice-stmt /
                         anyxml-stmt /
                         uses-stmt

   case-data-def-stmt  = container-stmt /
                         leaf-stmt /
                         leaf-list-stmt /
                         list-stmt /
                         anyxml-stmt /
                         uses-stmt

   yang-version-stmt   = yang-version-keyword sep yang-version-arg-str
                         optsep stmtend

   yang-version-arg-str = < a string which matches the rule
                           yang-version-arg >

   yang-version-arg    = "1"

   import-stmt         = import-keyword sep identifier-arg-str optsep
                         "{" stmtsep
                             prefix-stmt stmtsep
                             [revision-date-stmt stmtsep]
                         "}"

   include-stmt        = include-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              [revision-date-stmt stmtsep]
                          "}")

   namespace-stmt      = namespace-keyword sep uri-str optsep stmtend

   uri-str             = < a string which matches the rule
                           URI in RFC 3986 >

   prefix-stmt         = prefix-keyword sep prefix-arg-str
                         optsep stmtend

   belongs-to-stmt     = belongs-to-keyword sep identifier-arg-str
                         optsep
                         "{" stmtsep
                             prefix-stmt stmtsep
                         "}"

   organization-stmt   = organization-keyword sep string
                         optsep stmtend

   contact-stmt        = contact-keyword sep string optsep stmtend

   description-stmt    = description-keyword sep string optsep
                         stmtend

   reference-stmt      = reference-keyword sep string optsep stmtend

   units-stmt          = units-keyword sep string optsep stmtend

   revision-stmt       = revision-keyword sep revision-date optsep
                         (";" /
                          "{" stmtsep
                              [description-stmt stmtsep]
                          "}")

   revision-date       =  date-arg-str

   revision-date-stmt = revision-date-keyword sep revision-date stmtend

   extension-stmt      = extension-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [argument-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                          "}")

   argument-stmt       = argument-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              [yin-element-stmt stmtsep]
                          "}")

   yin-element-stmt    = yin-element-keyword sep yin-element-arg-str
                         stmtend

   yin-element-arg-str = < a string which matches the rule
                           yin-element-arg >

   yin-element-arg     = true-keyword / false-keyword

   identity-stmt       = identity-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [base-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                          "}")

   base-stmt           = base-keyword sep identifier-ref-arg-str
                         optsep stmtend

   feature-stmt        = feature-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              *(if-feature-stmt stmtsep)
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                          "}")

   if-feature-stmt     = if-feature-keyword sep identifier-ref-arg-str
                         optsep stmtend

   typedef-stmt        = typedef-keyword sep identifier-arg-str optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             type-stmt stmtsep
                             [units-stmt stmtsep]
                             [default-stmt stmtsep]
                             [status-stmt stmtsep]
                             [description-stmt stmtsep]
                             [reference-stmt stmtsep]
                          "}"

   type-stmt           = type-keyword sep identifier-ref-arg-str optsep
                         (";" /
                          "{" stmtsep
                              type-body-stmts
                          "}")

   type-body-stmts     = numerical-restrictions /
                         decimal64-specification /
                         string-restrictions /
                         enum-specification /
                         leafref-specification /
                         identityref-specification /
                         instance-identifier-specification /
                         bits-specification /
                         union-specification

   numerical-restrictions = range-stmt stmtsep

   range-stmt          = range-keyword sep range-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [error-message-stmt stmtsep]
                              [error-app-tag-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                           "}")

   decimal64-specification = fraction-digits-stmt

   fraction-digits-stmt = fraction-digits-keyword sep
                          fraction-digits-arg-str stmtend

   fraction-digits-arg-str = < a string which matches the rule
                              fraction-digits-arg >

   fraction-digits-arg = ("1" ["2" / "3" / "4" / "5" / "6" / "7" / "8"])
                         / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"

   string-restrictions = ;; these stmts can appear in any order
                         [length-stmt stmtsep]
                         *(pattern-stmt stmtsep)
   length-stmt         = length-keyword sep length-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [error-message-stmt stmtsep]
                              [error-app-tag-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                           "}")

   pattern-stmt        = pattern-keyword sep string optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [error-message-stmt stmtsep]
                              [error-app-tag-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                           "}")

   default-stmt        = default-keyword sep string stmtend

   enum-specification  = 1*(enum-stmt stmtsep)

   enum-stmt           = enum-keyword sep string optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [value-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                           "}")

   leafref-specification =
                         ;; these stmts can appear in any order
                         path-stmt stmtsep
                         [require-instance-stmt stmtsep]

   path-stmt           = path-keyword sep path-arg-str stmtend

   require-instance-stmt = require-instance-keyword sep
                            require-instance-arg-str stmtend

   require-instance-arg-str = < a string which matches the rule
                              require-instance-arg >

   require-instance-arg = true-keyword / false-keyword
   instance-identifier-specification =
                         [require-instance-stmt stmtsep]

   identityref-specification =
                         base-stmt stmtsep

   union-specification = 1*(type-stmt stmtsep)

   bits-specification  = 1*(bit-stmt stmtsep)

   bit-stmt            = bit-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [position-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                            "}"
                          "}")

   position-stmt       = position-keyword sep
                         position-value-arg-str stmtend

   position-value-arg-str = < a string which matches the rule
                              position-value-arg >

   position-value-arg  = non-negative-decimal-value non-negative-integer-value

   status-stmt         = status-keyword sep status-arg-str stmtend

   status-arg-str      = < a string which matches the rule
                           status-arg >

   status-arg          = current-keyword /
                         obsolete-keyword /
                         deprecated-keyword

   config-stmt         = config-keyword sep
                         config-arg-str stmtend

   config-arg-str      = < a string which matches the rule
                           config-arg >

   config-arg          = true-keyword / false-keyword

   mandatory-stmt      = mandatory-keyword sep
                         mandatory-arg-str stmtend
   mandatory-arg-str   = < a string which matches the rule
                           mandatory-arg >

   mandatory-arg       = true-keyword / false-keyword

   presence-stmt       = presence-keyword sep string stmtend

   ordered-by-stmt     = ordered-by-keyword sep
                         ordered-by-arg-str stmtend

   ordered-by-arg-str  = < a string which matches the rule
                           ordered-by-arg >

   ordered-by-arg      = user-keyword / system-keyword

   must-stmt           = must-keyword sep string optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [error-message-stmt stmtsep]
                              [error-app-tag-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                           "}")

   error-message-stmt  = error-message-keyword sep string stmtend

   error-app-tag-stmt  = error-app-tag-keyword sep string stmtend

   min-elements-stmt   = min-elements-keyword sep
                         min-value-arg-str stmtend;

   min-value-arg-str   = < a string which matches the rule
                           min-value-arg >

   min-value-arg       = non-negative-decimal-value non-negative-integer-value

   max-elements-stmt   = max-elements-keyword sep
                         max-value-arg-str stmtend;

   max-value-arg-str   = < a string which matches the rule
                           max-value-arg >

   max-value-arg       = unbounded-keyword /
                         positive-decimal-value
                         positive-integer-value

   value-stmt          = value-keyword sep decimal-value integer-value stmtend
   grouping-stmt       = grouping-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                              *((typedef-stmt /
                                 grouping-stmt) stmtsep)
                              *(data-def-stmt stmtsep)
                          "}")

   container-stmt      = container-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [when-stmt stmtsep]
                              *(if-feature-stmt stmtsep)
                              *(must-stmt stmtsep)
                              [presence-stmt stmtsep]
                              [config-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                              *((typedef-stmt /
                                 grouping-stmt) stmtsep)
                              *(data-def-stmt stmtsep)
                          "}")

   leaf-stmt           = leaf-keyword sep identifier-arg-str optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             [when-stmt stmtsep]
                             *(if-feature-stmt stmtsep)
                             type-stmt stmtsep
                             [units-stmt stmtsep]
                             *(must-stmt stmtsep)
                             [default-stmt stmtsep]
                             [config-stmt stmtsep]
                             [mandatory-stmt stmtsep]
                             [status-stmt stmtsep]
                             [description-stmt stmtsep]
                             [reference-stmt stmtsep]
                          "}"

   leaf-list-stmt      = leaf-list-keyword sep identifier-arg-str optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             [when-stmt stmtsep]
                             *(if-feature-stmt stmtsep)
                             type-stmt stmtsep
                             [units-stmt stmtsep]
                             *(must-stmt stmtsep)
                             [config-stmt stmtsep]
                             [min-elements-stmt stmtsep]
                             [max-elements-stmt stmtsep]
                             [ordered-by-stmt stmtsep]
                             [status-stmt stmtsep]
                             [description-stmt stmtsep]
                             [reference-stmt stmtsep]
                          "}"

   list-stmt           = list-keyword sep identifier-arg-str optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             [when-stmt stmtsep]
                             *(if-feature-stmt stmtsep)
                             *(must-stmt stmtsep)
                             [key-stmt stmtsep]
                             *(unique-stmt stmtsep)
                             [config-stmt stmtsep]
                             [min-elements-stmt stmtsep]
                             [max-elements-stmt stmtsep]
                             [ordered-by-stmt stmtsep]
                             [status-stmt stmtsep]
                             [description-stmt stmtsep]
                             [reference-stmt stmtsep]
                             *((typedef-stmt /
                                grouping-stmt) stmtsep)
                             1*(data-def-stmt stmtsep)
                          "}"

   key-stmt            = key-keyword sep key-arg-str stmtend

   key-arg-str         = < a string which matches the rule
                           key-arg >

   key-arg             = node-identifier *(sep node-identifier)

   unique-stmt         = unique-keyword sep unique-arg-str stmtend

   unique-arg-str      = < a string which matches the rule
                           unique-arg >

   unique-arg          = descendant-schema-nodeid
                         *(sep descendant-schema-nodeid)
   choice-stmt         = choice-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [when-stmt stmtsep]
                              *(if-feature-stmt stmtsep)
                              [default-stmt stmtsep]
                              [config-stmt stmtsep]
                              [mandatory-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                              *((short-case-stmt / case-stmt) stmtsep)
                          "}")

   short-case-stmt     = container-stmt /
                         leaf-stmt /
                         leaf-list-stmt /
                         list-stmt /
                         anyxml-stmt

   case-stmt           = case-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [when-stmt stmtsep]
                              *(if-feature-stmt stmtsep)
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                              *(case-data-def-stmt stmtsep)
                          "}")

   anyxml-stmt         = anyxml-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [when-stmt stmtsep]
                              *(if-feature-stmt stmtsep)
                              *(must-stmt stmtsep)
                              [config-stmt stmtsep]
                              [mandatory-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                           "}")

   uses-stmt           = uses-keyword sep identifier-ref-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [when-stmt stmtsep]
                              *(if-feature-stmt stmtsep)
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                              *(refine-stmt stmtsep)
                              *(uses-augment-stmt stmtsep)
                          "}")

   refine-stmt         = refine-keyword sep refine-arg-str optsep
                         (";" /
                          "{" stmtsep
                              (refine-container-stmts /
                               refine-leaf-stmts /
                               refine-leaf-list-stmts /
                               refine-list-stmts /
                               refine-choice-stmts /
                               refine-case-stmts /
                               refine-anyxml-stmts)
                          "}")

   refine-arg-str      = < a string which matches the rule
                           refine-arg >

   refine-arg          = descendant-schema-nodeid

   refine-container-stmts =
                         ;; these stmts can appear in any order
                         *(must-stmt stmtsep)
                         [presence-stmt stmtsep]
                         [config-stmt stmtsep]
                         [description-stmt stmtsep]
                         [reference-stmt stmtsep]

   refine-leaf-stmts   = ;; these stmts can appear in any order
                         *(must-stmt stmtsep)
                         [default-stmt stmtsep]
                         [config-stmt stmtsep]
                         [mandatory-stmt stmtsep]
                         [description-stmt stmtsep]
                         [reference-stmt stmtsep]

   refine-leaf-list-stmts =
                         ;; these stmts can appear in any order
                         *(must-stmt stmtsep)
                         [config-stmt stmtsep]
                         [min-elements-stmt stmtsep]
                         [max-elements-stmt stmtsep]
                         [description-stmt stmtsep]
                         [reference-stmt stmtsep]

   refine-list-stmts   = ;; these stmts can appear in any order
                         *(must-stmt stmtsep)
                         [config-stmt stmtsep]
                         [min-elements-stmt stmtsep]
                         [max-elements-stmt stmtsep]
                         [description-stmt stmtsep]
                         [reference-stmt stmtsep]

   refine-choice-stmts = ;; these stmts can appear in any order
                         [default-stmt stmtsep]
                         [config-stmt stmtsep]
                         [mandatory-stmt stmtsep]
                         [description-stmt stmtsep]
                         [reference-stmt stmtsep]

   refine-case-stmts   = ;; these stmts can appear in any order
                         [description-stmt stmtsep]
                         [reference-stmt stmtsep]

   refine-anyxml-stmts = ;; these stmts can appear in any order
                         [config-stmt stmtsep]
                         [mandatory-stmt stmtsep]
                         [description-stmt stmtsep]
                         [reference-stmt stmtsep]

   uses-augment-stmt   = augment-keyword sep uses-augment-arg-str optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             [when-stmt stmtsep]
                             *(if-feature-stmt stmtsep)
                             [status-stmt stmtsep]
                             [description-stmt stmtsep]
                             [reference-stmt stmtsep]
                             1*((data-def-stmt stmtsep) /
                                (case-stmt stmtsep))
                          "}"

   uses-augment-arg-str = < a string which matches the rule
                            uses-augment-arg >

   uses-augment-arg    = descendant-schema-nodeid
   augment-stmt        = augment-keyword sep augment-arg-str optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             [when-stmt stmtsep]
                             *(if-feature-stmt stmtsep)
                             [status-stmt stmtsep]
                             [description-stmt stmtsep]
                             [reference-stmt stmtsep]
                             1*((data-def-stmt stmtsep) /
                                (case-stmt stmtsep))
                          "}"

   augment-arg-str     = < a string which matches the rule
                           augment-arg >

   augment-arg         = absolute-schema-nodeid schema-nodeid

   unknown-statement   = prefix ":" identifier [sep string] optsep
                         (";" / "{" *unknown-statement "}")

   when-stmt           = when-keyword sep string stmtend

   rpc-stmt            = rpc-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              *(if-feature-stmt stmtsep)
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                              *((typedef-stmt /
                                 grouping-stmt) stmtsep)
                              [input-stmt stmtsep]
                              [output-stmt stmtsep]
                          "}")

   input-stmt          = input-keyword optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             *((typedef-stmt /
                                grouping-stmt) stmtsep)
                             1*(data-def-stmt stmtsep)
                         "}"

   output-stmt         = output-keyword optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             *((typedef-stmt /
                                grouping-stmt) stmtsep)
                             1*(data-def-stmt stmtsep)
                         "}"

   notification-stmt   = notification-keyword sep
                         identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              *(if-feature-stmt stmtsep)
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                              *((typedef-stmt /
                                 grouping-stmt) stmtsep)
                              *(data-def-stmt stmtsep)
                          "}")

   deviation-stmt      = deviation-keyword sep
                         deviation-arg-str optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             [description-stmt stmtsep]
                             [reference-stmt stmtsep]
                             (deviate-not-supported-stmt /
                               1*(deviate-add-stmt /
                                  deviate-replace-stmt /
                                  deviate-delete-stmt))
                         "}"

   deviation-arg-str   = < a string which matches the rule
                           deviation-arg >

   deviation-arg       = absolute-schema-nodeid

   deviate-not-supported-stmt =
                         deviate-keyword sep
                         not-supported-keyword optsep
                         (";" /
                          "{" stmtsep
                          "}")

   deviate-add-stmt    = deviate-keyword sep add-keyword optsep
                         (";" /
                          "{" stmtsep
                              [units-stmt stmtsep]
                              *(must-stmt stmtsep)
                              *(unique-stmt stmtsep)
                              [default-stmt stmtsep]
                              [config-stmt stmtsep]
                              [mandatory-stmt stmtsep]
                              [min-elements-stmt stmtsep]
                              [max-elements-stmt stmtsep]
                          "}")

   deviate-delete-stmt = deviate-keyword sep delete-keyword optsep
                         (";" /
                          "{" stmtsep
                              [units-stmt stmtsep]
                              *(must-stmt stmtsep)
                              *(unique-stmt stmtsep)
                              [default-stmt stmtsep]
                          "}")

   deviate-replace-stmt = deviate-keyword sep replace-keyword optsep
                         (";" /
                          "{" stmtsep
                              [type-stmt stmtsep]
                              [units-stmt stmtsep]
                              [default-stmt stmtsep]
                              [config-stmt stmtsep]
                              [mandatory-stmt stmtsep]
                              [min-elements-stmt stmtsep]
                              [max-elements-stmt stmtsep]
                          "}")

   ;; Ranges

   range-arg-str       = < a string which matches the rule
                           range-arg >

   range-arg           = range-part *(optsep "|" optsep range-part)

   range-part          = range-boundary
                         [optsep ".." optsep range-boundary]

   range-boundary      = neginf-keyword / posinf-keyword / min-keyword / max-keyword /
                         decimal-value
                         integer-value / float-value decimal-value

   ;; Lengths

   length-arg-str      = < a string which matches the rule
                           length-arg >

   length-arg          = length-part *(optsep "|" optsep length-part)
   length-part         = length-boundary
                         [optsep ".." optsep length-boundary]

   length-boundary     = min-keyword / max-keyword /
                         non-negative-decimal-value
                         non-negative-integer-value

   ;; Date

   date-arg-str        = < a string which matches the rule
                           date-arg >

   date-arg            = 4DIGIT "-" 2DIGIT "-" 2DIGIT

   ;; Schema Node Identifiers

   schema-nodeid       = absolute-schema-nodeid /
                         relative-schema-nodeid
                         descendant-schema-nodeid

   absolute-schema-nodeid = 1*("/" node-identifier)

   relative-schema-nodeid =
                         descendant-schema-nodeid /
                         (("." / "..") "/"
                         *relative-schema-nodeid)

   descendant-schema-nodeid =
                         node-identifier
                         absolute-schema-nodeid

   node-identifier     = [prefix ":"] identifier

   ;; Instance Identifiers

   instance-identifier = 1*("/" (node-identifier *predicate))

   predicate           = "[" *WSP (predicate-expr / pos) *WSP "]"

   predicate-expr      = (node-identifier / ".") *WSP "=" *WSP
                         ((DQUOTE string DQUOTE) /
                          (SQUOTE string SQUOTE))

   pos                 = non-negative-decimal-value) non-negative-integer-value

   ;; leafref path

   path-arg-str        = < a string which matches the rule
                           path-arg >

   path-arg            = absolute-path / relative-path

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

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

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

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

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

   rel-path-keyexpr    = 1*(".." *WSP "/" *WSP)
                         *(node-identifier *WSP "/" *WSP)
                         node-identifier

   ;;; Keywords, using abnfgen's syntax for case-sensitive strings

   ;; statment keywords
   anyxml-keyword      = 'anyxml'
   argument-keyword    = 'argument'
   augment-keyword     = 'augment'
   base-keyword        = 'base'
   belongs-to-keyword  = 'belongs-to'
   bit-keyword         = 'bit'
   case-keyword        = 'case'
   choice-keyword      = 'choice'
   config-keyword      = 'config'
   contact-keyword     = 'contact'
   container-keyword   = 'container'
   default-keyword     = 'default'
   description-keyword = 'description'
   enum-keyword        = 'enum'
   error-app-tag-keyword = 'error-app-tag'
   error-message-keyword = 'error-message'
   extension-keyword   = 'extension'
   deviation-keyword   = 'deviation'
   deviate-keyword     = 'deviate'
   feature-keyword     = 'feature'
   fraction-digits-keyword = 'fraction-digits'
   grouping-keyword    = 'grouping'
   identity-keyword    = 'identity'
   if-feature-keyword  = 'if-feature'
   import-keyword      = 'import'
   include-keyword     = 'include'
   input-keyword       = 'input'
   key-keyword         = 'key'
   leaf-keyword        = 'leaf'
   leaf-list-keyword   = 'leaf-list'
   length-keyword      = 'length'
   list-keyword        = 'list'
   mandatory-keyword   = 'mandatory'
   max-elements-keyword = 'max-elements'
   min-elements-keyword = 'min-elements'
   module-keyword      = 'module'
   must-keyword        = 'must'
   namespace-keyword   = 'namespace'
   notification-keyword= 'notification'
   ordered-by-keyword  = 'ordered-by'
   organization-keyword= 'organization'
   output-keyword      = 'output'
   path-keyword        = 'path'
   pattern-keyword     = 'pattern'
   position-keyword    = 'position'
   prefix-keyword      = 'prefix'
   presence-keyword    = 'presence'
   range-keyword       = 'range'
   reference-keyword   = 'reference'
   refine-keyword      = 'refine'
   require-instance-keyword = 'require-instance'
   revision-keyword    = 'revision'
   revision-date-keyword = 'revision-date'
   rpc-keyword         = 'rpc'
   status-keyword      = 'status'
   submodule-keyword   = 'submodule'
   type-keyword        = 'type'
   typedef-keyword     = 'typedef'
   unique-keyword      = 'unique'
   units-keyword       = 'units'
   uses-keyword        = 'uses'
   value-keyword       = 'value'
   when-keyword        = 'when'
   yang-version-keyword= 'yang-version'
   yin-element-keyword = 'yin-element'

   ;; other keywords

   add-keyword         = 'add'
   current-keyword     = 'current'
   delete-keyword      = 'delete'
   deprecated-keyword  = 'deprecated'
   false-keyword       = 'false'
   max-keyword         = 'max'
   min-keyword         = 'min'
   nan-keyword         = 'NaN'
   neginf-keyword      = '-INF'
   not-supported-keyword = 'not-supported'
   obsolete-keyword    = 'obsolete'
   posinf-keyword      = 'INF'
   replace-keyword     = 'replace'
   system-keyword      = 'system'
   true-keyword        = 'true'
   unbounded-keyword   = 'unbounded'
   user-keyword        = 'user'

   current-function-invocation = current-keyword *WSP "(" *WSP ")"

   ;; Basic Rules

   prefix-arg-str      = < a string which matches the rule
                           prefix-arg >

   prefix-arg          = prefix

   prefix              = identifier

   identifier-arg-str  = < a string which matches the rule
                           identifier-arg >

   identifier-arg      = identifier

   identifier          = (ALPHA / "_")
                         *(ALPHA / DIGIT / "_" / "-" / ".")

   identifier-ref-arg-str = < a string which matches the rule
                           identifier-ref-arg >

   identifier-ref-arg  = [prefix ":"] identifier

   string              = < an unquoted string as returned by
                           the scanner >

   decimal-value

   integer-value       = ("-" non-negative-decimal-value) non-negative-integer-value)  /
                          non-negative-decimal-value

   non-negative-decimal-value
                          non-negative-integer-value

   non-negative-integer-value = "0" / positive-decimal-value

   positive-decimal-value positive-integer-value

   positive-integer-value = (non-zero-digit *DIGIT)

   zero-decimal-value

   zero-integer-value  = 1*DIGIT

   stmtend             = ";" / "{" *unknown-statement "}"

   sep                 = 1*(WSP / line-break)
                         ; unconditional separator

   optsep              = *(WSP / line-break)
   stmtsep             = *(WSP / line-break / unknown-statement)

   line-break          = CRLF / LF

   non-zero-digit      = %x31-39

   float-value         = neginf-keyword /
                         posinf-keyword /
                         nan-keyword /

   decimal-value "." zero-decimal-value
                            *1("E" ("+"/"-") zero-decimal-value)       = integer-value ("." zero-integer-value)

   SQUOTE              = %x27
                         ; ' (Single Quote)

   ;;
   ;; RFC 4234 core rules.
   ;;

   ALPHA               = %x41-5A / %x61-7A
                         ; A-Z / a-z

   CR                  = %x0D
                         ; carriage return

   CRLF                = CR LF
                         ; Internet standard newline

   DIGIT               = %x30-39
                         ; 0-9

   DQUOTE              = %x22
                         ; " (Double Quote)

   HEXDIG              = DIGIT /
                         %x61 / %x62 / %x63 / %x64 / %x65 / %x66
                         ; only lower-case a..f

   HTAB                = %x09
                         ; horizontal tab

   LF                  = %x0A
                         ; linefeed

   SP                  = %x20
                         ; space

   VCHAR               = %x21-7E
                         ; visible (printing) characters

   WSP                 = SP / HTAB
                         ; white space

13.  Error Responses for YANG Related Errors

   A number of NETCONF error responses are defined for error cases
   related to the data-model handling.  If the relevant YANG statement
   has an "error-app-tag" substatement, that overrides the default value
   specified below.

13.1.  Error Message for Data that Violates a unique Statement:

   If a NETCONF operation would result in configuration data where a
   unique constraint is invalidated, the following error is returned:

     Tag:            operation-failed
     Error-app-tag:  data-not-unique
     Error-info:     <non-unique>: Contains an instance identifier which
                     points to a leaf which invalidates the unique
                     constraint. This element is present once for each
                     leaf invalidating the unique constraint.

                     The <non-unique> element is in the YANG
                     namespace ("urn:ietf:params:xml:ns:yang:1"
                     [XXX IANA]). ("urn:ietf:params:xml:ns:yang:1").


[skipping...]

13.6.  Error Message for Data that Violates a mandatory choice
       statement:

   If a NETCONF operation would result in configuration data where no
   nodes exists in a mandatory choice, the following error is returned:

     Tag:            data-missing
     Error-app-tag:  missing-choice
     Error-path:     Path to the element with the missing choice.
     Error-info:     <missing-choice>: Contains the name of the missing
                     mandatory choice.

                     The <missing-choice> element is in the YANG
                     namespace ("urn:ietf:params:xml:ns:yang:1"
                     [XXX IANA]). ("urn:ietf:params:xml:ns:yang:1").

[skipping...]

14.  IANA Considerations

   +-------------------------------------------------------------------+
   | Open Question                                                     |
   +-------------------------------------------------------------------+
   | Write this section properly. We need

   This document defines a registry for (sub)module   |
   | names YANG module and submodule names.
   The name of the registry is "YANG Module Names".

   The registry shall record for each entry:

   o  the name of the module namespaces.                                      |
   +-------------------------------------------------------------------+ or submodule

   o  for modules, the assigned XML namespace

   o  for submodules, the name of the module it belongs to

   o  a reference to the (sub)module's documentation (the RFC number)

   For allocation, RFC publication is required as per RFC 5226
   [RFC5226].  All registered YANG module names must comply with the
   rules for identifiers stated in Section 6.2.  There are no initial
   assignments.

   The module name prefix 'ietf-' is reserved for IETF stream documents
   while the module name prefix 'irtf-' is reserved for IRTF stream
   documents.  Modules published in other RFC streams must have a
   similar suitable prefix.  The prefix 'iana-' is reserved for modules
   maintained by IANA.

   This document registers two URIs for the YANG and YIN XML namespace namespaces
   in the IETF XML registry [RFC3688].  Following the format in RFC
   3688, the following registration is requested.

     URI: urn:ietf:params:xml:ns:yang:yin:1
     URI: urn:ietf:params:xml:ns:yang:1

     Registrant Contact: The IESG.

     XML: N/A, the requested URIs are XML namespaces.

[skipping...]

17.  Acknowledgements

   The authors wish to thank the following individuals, who all provided
   helpful comments on various versions of this document: Mehmet Ersue,
   Joel Halpern, Leif Johansson, Ladislav Lhotka, Gerhard Muenz, Tom
   Petch, Randy Preshun, David Reid, Bert Wijnen.

18.  References

17.1.

18.1.  Normative References

   [IEEE.754]
              Institute of Electrical and Electronics Engineers,
              "Standard for Binary Floating-Point Arithmetic",
              IEEE Standard 754, August 1985.

   [ISO.10646]
              International Organization for Standardization,
              "Information Technology - Universal Multiple-octet coded
              Character Set (UCS) - Part 1: Architecture and Basic
              Multilingual Plane", ISO Standard 10646-1, May 1993.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006.

   [RFC4741]  Enns, R., "NETCONF Configuration Protocol", RFC 4741,
              December 2006.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5277]  Chisholm, S. and H. Trevino, "NETCONF Event
              Notifications", RFC 5277, July 2008.

   [XML-NAMES]
              Tobin, R., Bray, T., Hollander, D., and A. Layman,
              "Namespaces in XML 1.0 (Second Edition)", World Wide Web
              Consortium Recommendation REC-xml-names-20060816,
              August 2006,
              <http://www.w3.org/TR/2006/REC-xml-names-20060816>.

   [XPATH]    Clark, J. and S. DeRose, "XML Path Language (XPath)
              Version 1.0", World Wide Web Consortium
              Recommendation REC-xpath-19991116, November 1999,
              <http://www.w3.org/TR/1999/REC-xpath-19991116>.

   [XSD-TYPES]
              Biron, P V. and A. Malhotra, "XML Schema Part 2: Datatypes
              Second Edition", W3C REC REC-xmlschema-2-20041028,
              October 2004.

   [XSLT]     Clark, J., "XSL Transformations (XSLT) Version 1.0", World
              Wide Web Consortium Recommendation REC-xslt-19991116,
              November 1999,
              <http://www.w3.org/TR/1999/REC-xslt-19991116>.

17.2.

18.2.  Non-Normative References

   [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Structure of Management Information
              Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

   [RFC2579]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Textual Conventions for SMIv2",
              STD 58, RFC 2579, April 1999.

   [RFC3780]  Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation
              Structure of Management Information", RFC 3780, May 2004.

Appendix A.  ChangeLog

A.1.  Version -05

   o  Replaced the data types "float32" and "float64" with "decimal64".

   o  Specified that the elements in the XML encoding of configuration
      data can occur in any order.

   o  Clarified that "augement" cannot add multiple nodes with the same
      name.

   o  Clarified what "when" means in RPC input / output.

   o  Wrote the IANA Considerations section.

A.2.  Version -04

   o  Using "revision-date" substatement to "import" and "include".

   o  Corrected grammar and text for instance-identifier.

   o  Fixed bugs in some examples.

   o  Rewrote the YIN description to use a declarative style.

   o  Added two error codes in Section 13.

   o  Clarified that YANG uses the same XPath data model as XSLT.

   o  Specified which errors are generated in Section 8.3.1.

   o  Corrected grammar for key-arg; now allowing optional prefix on
      each leaf identifier.

   o  Clarified that "unique" constraints only check instances with
      values for all referenced leafs.

   o  Clarified how mandatory and min-elements constraints are enforced.

   o  Editorial fixes.

A.2.

A.3.  Version -03

   o  Added import by revision (yang-00413)

   o  Changed type "keyref" to "leafref", and added the statement
      "require-instance" (yang-01253)
   o  Clarified that data sent from the server must be in the canonical
      form.

   o  Clarified when and how constraints in the models are enforced.

   o  Many editorial fixes

   o  Added more strict grammar for the "deviate" statement.

A.3.

A.4.  Version -02

   o  Added module update rules. (yang-00000)

   o  Added "refine" statement as a substatement to "uses". (yang-00088)

   o  Allow "augment" on top-level and in "uses" only. (yang-00088)

   o  Allow "when" on all data defintion statements. (yang-00088)

   o  Added section "Constraints" and clarified when constraints are
      enforced. (yang-00172)

   o  Added "feature" and "if-feature" statements. (yang-00750)

   o  Added "prefix" as a substatement to "belongs-to". (yang-00755)

   o  Added section on Conformance. (yang-01281)

   o  Added "deviation" statement. (yang-01281)

   o  Added "identity" statement and "identityref" type. (yang-01339)

   o  Aligned grammar for "enum" with text.

A.4.

A.5.  Version -01

   o  Removed "Appendix A.  Derived YANG Types".

   o  Removed "Appendix C.  XML Schema Considerations".

   o  Removed "Appendix F.  Why We Need a New Modeling Language".

   o  Moved "Appendix B.  YIN" to its own section.

   o  Moved "Appendix D.  YANG ABNF Grammar" to its own section.

   o  Moved "Appendix E.  Error Responses for YANG Related Errors" into
      its own section.

   o  The "input" and "output" nodes are now implicitly created by the
      "rpc" statement, in order for augmentation of these nodes to work
      correctly.

   o  Allow "config" in "choice".

   o  Added reference to XPath 1.0.

   o  Using an XPath function "current()" instead of the variable
      "$this".

   o  Clarified that a "must" expression in a configuration node must
      not reference non-configuration nodes.

   o  Added XML encoding rules and usage examples for rpc and
      notification.

   o  Removed requirement that refinements are specified in the same
      order as in the original grouping's definition.

   o  Fixed whitespace issues in the ABNF grammar.

   o  Added the term "mandatory node", and refer to it in the
      description of augment (see Section 7.15), and choice (see
      Section 7.9.3).

   o  Added support for multiple "pattern" statements in "type".

   o  Several clarifications and fixed typos.

A.5.

A.6.  Version -00

   Changes from draft-bjorklund-netconf-yang-02.txt

   o  Fixed bug in grammar for bit-stmt

   o  Fixed bugs in example XPath expressions

   o  Added keyword 'presence' to the YIN mapping table

Author's Address

   Martin Bjorklund (editor)
   Tail-f Systems

   Email: mbj@tail-f.com
----Next_Part(Thu_Apr__9_15_11_28_2009_379)---- From phil@juniper.net Thu Apr 9 07:11:05 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A2E23A6C65 for ; Thu, 9 Apr 2009 07:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YbM8bAJRPjk for ; Thu, 9 Apr 2009 07:11:04 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id AC35B3A6B86 for ; Thu, 9 Apr 2009 07:10:40 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSd4CISYnfjjGmEOOo5M8knElHSsOyxLj@postini.com; Thu, 09 Apr 2009 07:11:50 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 9 Apr 2009 07:07:18 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Apr 2009 07:07:18 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Apr 2009 07:07:18 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 07:07:17 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n39E7GM94890; Thu, 9 Apr 2009 07:07:16 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n39Dxt0U098557; Thu, 9 Apr 2009 13:59:58 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904091359.n39Dxt0U098557@idle.juniper.net> To: WashamFan In-Reply-To: Date: Thu, 9 Apr 2009 09:59:55 -0400 From: Phil Shafer X-OriginalArrivalTime: 09 Apr 2009 14:07:17.0317 (UTC) FILETIME=[7D89B750:01C9B91C] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] sec 7.8.3.1, yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 14:11:05 -0000 WashamFan writes: > > http > 192.0.2.1 > > > > ftp > 192.0.2.1 > >then, the same configuration should be invalid, right? This config should be invalid both with and without the default. A missing leaf should be considered as part of uniqueness. Thanks, Phil From andy@netconfcentral.com Thu Apr 9 07:26:57 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0305F3A6C72 for ; Thu, 9 Apr 2009 07:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WlDQEVbbOlQ for ; Thu, 9 Apr 2009 07:26:56 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id 0F3D13A6C76 for ; Thu, 9 Apr 2009 07:25:43 -0700 (PDT) Received: (qmail 92033 invoked from network); 9 Apr 2009 14:26:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.61 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 9 Apr 2009 14:26:50 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49DE05A8.7060607@netconfcentral.com> Date: Thu, 09 Apr 2009 07:26:48 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200904091359.n39Dxt0U098557@idle.juniper.net> In-Reply-To: <200904091359.n39Dxt0U098557@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] sec 7.8.3.1, yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 14:26:57 -0000 Phil Shafer wrote: > WashamFan writes: >> >> http >> 192.0.2.1 >> >> >> >> ftp >> 192.0.2.1 >> >> then, the same configuration should be invalid, right? > > This config should be invalid both with and without > the default. A missing leaf should be considered > as part of uniqueness. > I don't think they are. Incomplete tuples are skipped. In this case, the default-stmt adds the leaf, but if it didn't, the rows without a complete unique tuple get skipped in the test. > Thanks, > Phil Andy From mbj@tail-f.com Thu Apr 9 09:10:24 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 048093A6CC1 for ; Thu, 9 Apr 2009 09:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5BZjzhJk-ZR for ; Thu, 9 Apr 2009 09:10:23 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A1C743A6C65 for ; Thu, 9 Apr 2009 09:10:22 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5BDBD616004; Thu, 9 Apr 2009 18:11:29 +0200 (CEST) Date: Thu, 09 Apr 2009 18:11:29 +0200 (CEST) Message-Id: <20090409.181129.50668639.mbj@tail-f.com> To: Washam.Fan@huaweisymantec.com From: Martin Bjorklund In-Reply-To: References: <20090408.235734.237591776.mbj@tail-f.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] sec 9.9.6, yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 16:10:24 -0000 Hi, WashamFan wrote: > Hi, > > current interface definition: > > list interface { > key "name"; > leaf name { > type string; > } > leaf ifIndex { > type uint32; > } > list address { > key "ip"; > leaf ip { > type yang:ip-address; > } > } > } > > And corresponding default-address definition is: > > container default-address { > leaf ifname { > type leafref { > path "../../interface/name"; > } > } > leaf address { > type leafref { > path "../../interface[name = current()/../ifname]" > + "/address/ip"; > } > } > } > > If I changed the nested keys to ones placing in parallel: > > list interface { > key "name" "ip"; ^^^^^^^^^^^ This should be "name ip". > leaf name { > type string; > } > leaf ifIndex { > type uint32; > } > leaf ip { > type yang:ip-address; > } > } > > Is the corresponding default-address defined as: > > container default-address { > leaf ifname { > type leafref { > path "../../interface/name"; > } > } > leaf address { > type leafref { > path "../../interface[name = current()/../ifname]" > + "/ip"; > } > } > } > > or > > container default-address { > leaf ifname { > type leafref { > path "../../interface/name"; > } > } > leaf address { > type leafref { > path "../../interface/ip"; > } > } > } Both are valid, but they mean different things. The first one is the one you're probably looking for. It makes sure you give values for one list entry instance. The second one has to unrelated leafrefs, each one points to one or many instances. For example, suppose the db is: eth0 # 1.a 10.0.0.1 # 1.b eth0 # 2.a 10.0.0.2 # 2.b eth1 # 3.a 10.0.0.2 # 3.b eth0 # X
10.0.0.2
# Y With your first alternative, the XPath expression for 'ifname' evaluates to a nodeset with 1.a and 2.a, and the the XPath expression for 'address' evaluates to a nodeset with 2.b. With your second alternative, the XPath expression for 'ifname' evaluates to a nodeset with 1.a and 2.a, and the the XPath expression for 'address' evaluates to a nodeset with 2.b and 3.b. > PS: > line 5, para1, sec 9.10.2: > s/defined the module/defined in the module/ Thanks, fixed. /martin From mbj@tail-f.com Thu Apr 9 09:11:59 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B13F3A6902 for ; Thu, 9 Apr 2009 09:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYFCJmUsGji9 for ; Thu, 9 Apr 2009 09:11:58 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 89CC73A6EB6 for ; Thu, 9 Apr 2009 09:11:06 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 41AFD616004; Thu, 9 Apr 2009 18:12:14 +0200 (CEST) Date: Thu, 09 Apr 2009 18:12:14 +0200 (CEST) Message-Id: <20090409.181214.06551488.mbj@tail-f.com> To: Washam.Fan@huaweisymantec.com From: Martin Bjorklund In-Reply-To: References: <20090408.235734.237591776.mbj@tail-f.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] sec 7.8.3.1, yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 16:11:59 -0000 WashamFan wrote: > Hi, > > given server: > > list server { > key "name"; > unique "ip port"; > leaf name { > type string; > } > leaf ip { > type inet:ip-address; > } > leaf port { > type inet:port-number; > } > } > > The following configuration is valid: > > > smtp > 192.0.2.1 > 25 > > > > http > 192.0.2.1 > > > > ftp > 192.0.2.1 > > > If I changed the server definition to: > > list server { > key "name"; > unique "ip port"; > leaf name { > type string; > } > leaf ip { > type inet:ip-address; > } > leaf port { > default 22; <- set default > type inet:port-number; > } > } > > then, the same configuration should be invalid, right? Yes, see Andy's reply. > PS: > the title, sec 7.8.3 > s/lists's/list's/ Thanks, fixed. /martin From mbj@tail-f.com Thu Apr 9 09:14:38 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B838C3A6BAF for ; Thu, 9 Apr 2009 09:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.993 X-Spam-Level: X-Spam-Status: No, score=-0.993 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDPubv1CskKN for ; Thu, 9 Apr 2009 09:14:38 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EBA1D3A6A75 for ; Thu, 9 Apr 2009 09:14:37 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A51DF616004 for ; Thu, 9 Apr 2009 18:15:45 +0200 (CEST) Date: Thu, 09 Apr 2009 18:15:45 +0200 (CEST) Message-Id: <20090409.181545.261418950.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20090409.151128.236670770.mbj@tail-f.com> References: <20090409.151128.236670770.mbj@tail-f.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [netmod] YANG draft -05 changes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 16:14:38 -0000 Martin Bjorklund wrote: > Hi, > > As discussed in S.F., here is a diff with changes between 04 and > 05-to-be. Please check that my edits are correct! No, one edit is not correct. The description of decimal64 contains some weird characters. Here's the description for decimal64: The decimal64 type represents a subset of the real numbers, which can be represented by decimal numerals. The value space of decimal64 is the set of numbers that can be obtained by multiplying a 64 bit signed integer by a negative power of ten, i.e. expressible as "i x 10^-n" where i is an integer64 and n is an integer between 1 and 18, inclusively. /martin From andy@netconfcentral.com Thu Apr 9 09:29:55 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 168173A6A19 for ; Thu, 9 Apr 2009 09:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6rYSmVtV2NR for ; Thu, 9 Apr 2009 09:29:54 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 64ABD3A68DE for ; Thu, 9 Apr 2009 09:29:54 -0700 (PDT) Received: (qmail 57813 invoked from network); 9 Apr 2009 16:31:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.61 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 9 Apr 2009 16:31:01 -0000 X-YMail-OSG: Jaagfp4VM1kcuhT3_fPQ7LraxDPztImF3DPWCwFWp872DCmHAP_q41zAOdcwKrVrt5wzD5.iGh_RZyz.mlVSZhg9yb2.L6BdzfccgI1S4FOW6_K2P8b9ckOlg337xrVDCO.FGJ_cZTjTx04owI21Rd.9OKyla.hLN4ptvUSOlVCeVmbd7tScnHMw9nYaF5Don65rVk3vg9joYaIay4Yp9c2JJoQjUrEnHubN2O8EPORnHF_vd_SaF51aacWxyQKJ2jeS_27hZWjRNwloEF8NHCdZVhJHTsHzNZ_f9Eh6Gplz.CqKSapvgwa6WWwlzyiHcl_.tZzRu7k- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49DE22C4.7050203@netconfcentral.com> Date: Thu, 09 Apr 2009 09:31:00 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <49D78349.4010404@netconfcentral.com> <20090408.130303.112175402.mbj@tail-f.com> In-Reply-To: <20090408.130303.112175402.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-04: when-stmt and rpc/input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 16:29:55 -0000 Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Hi, >> >> The section on the rpc input statement is not clear enough. >> >> I don't know what para 2 means: >> >> If a container in the input tree has a "presence" statement, the >> container need not be present in a NETCONF RPC invocation. >> >> An NP container does not have to be present unless it has >> 1 or more mandatory descendants. > > I see what you mean. I suggest we simply remove this sentence. > yes >> The when-stmt is not mentioned at all. >> IMO, the agent should ignore when-stmt for rpc/input. > > Section 7.19.5 The when Statement specifies how the when statement is > used in rpc input/output. I believe it was the consensus to allow > when in rpcs (see the mail thread called "Proposed consensus mail on > yang-00172"), so I'd rather fix the text in the RPC section instead. > > I propose this text in section 7.13.2 (and similar in 7.13.3): > > If any node has a "when" statement which would evaluate to > false, then this node MUST NOT be present in the input tree. > This is different than the 'silently delete all false when-stmt nodes' procedure used on the database target(s). I think returning an 'unknown-element' error is confusing, but so is deleting/ignoring false when-stmt nodes. I'm a bit unclear on the use-cases for when-stmt in rpc/input. I can see if-feature quite easily, but not when-stmt. Does anyone have any use-cases for this, or are we just adding complexity every opportunity we get? > > > /martin > > Andy From spakes@snmp.com Thu Apr 9 13:41:36 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AAFB3A691C for ; Thu, 9 Apr 2009 13:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-blL+0HPs-U for ; Thu, 9 Apr 2009 13:41:34 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 72DC13A6CA4 for ; Thu, 9 Apr 2009 13:41:34 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id QAA02434; Thu, 9 Apr 2009 16:42:41 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id QAA21123; Thu, 9 Apr 2009 16:42:41 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Thu, 9 Apr 2009 16:42:40 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Martin Bjorklund In-Reply-To: <20090408.235734.237591776.mbj@tail-f.com> Message-ID: References: <200904032122.RAA02614@adminfs.snmp.com> <20090408.235734.237591776.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] SMIv2 to YANG mapping: OBJECT-IDENTITY X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 20:41:36 -0000 On Wed, 8 Apr 2009, Martin Bjorklund wrote: > Hi David, > > David Spakes wrote: > > What I propose is that we drop identityref and leafref and replace them > > with a generic 'ref' that can point to: > > > > - leafs > > - identities > > - lists (and other constructs) > > - modules > > - groupings > > - containers > > - notifications > > > > Under this proposal, a MIB object of type OBJECT IDENTIFIER would always > > be converted to a leaf having a type that is the generic ref type. > > I must admit I don't quite understand how this would work. Maybe you > could examplify your proposal by showing how a leaf/leafref, > identity/identityref and OID would be done with the current syntax, > and with your proposal? > > > /martin > A MIB object of type OBJECT IDENTIFIER contains information about the [MIB] schema implemented by the [SNMP] agent. It's value is a path to a position in the MIB tree. A leaf having a type that is the proposed generic ref type contains information about the [Yang] schema implemented by the [Netconf] agent. It's value should also be a path to a position in the Yang module. Below I have provided three examples. 1. Example 1 shows the YANG representation of the object definition for sysObjectID from RFC 3418 followed by the NETCONF XML Encoding in which the value of the object is taken from draft-ietf-netmod-yang-03 page 18. YANG Example: leaf sysObjectID { type ref; config false; description "The vendor's authoritative identification of the network management subsystem contained in the entity. This value is allocated within the SMI enterprises subtree (1.3.6.1.4.1) and provides an easy and unambiguous means for determining `what kind of box' is being managed. For example, if vendor `Flintstones, Inc.' was assigned the subtree 1.3.6.1.4.1.424242, it could assign the identifier 1.3.6.1.4.1.424242.1.1 to its `Fred Router'."; } NETCONF XML Encoding (to refer to the module): acme-system NETCONF XML Encoding (to refer to a container in the module): acme:/system 2. Example 2 shows the YANG representation of exerpts from RFC 4293, where the leaf ipAddressPrefix points to a row in the ipAddressPrefixTable. In the original MIB document, the object is defined to be of type "RowPointer" with semantics described in RFC 2579. YANG Example: container ipAddressPrefixTable { list ipAddressPrefixEntry { key "ipAddressPrefixIfIndex, ipAddressPrefixType, ipAddressPrefixPrefix, ipAddressPrefixLength"; description "An entry in the ipAddressPrefixTable."; leaf ipAddressPrefixIfIndex { type if-mib:InterfaceIndex; config false; description "The index value that uniquely identifies the interface on which this prefix is configured. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex."; } leaf ipAddressPrefixType { type inet-address-mib:InetAddressType; config false; description "The address type of ipAddressPrefix."; } leaf ipAddressPrefixPrefix { type inet:host; config false; description "The address prefix. The address type of this object is specified in ipAddressPrefixType. The length of this object is the standard length for objects of that type (4 or 16 bytes). Any bits after ipAddressPrefixLength must be zero. Implementors need to be aware that, if the size of ipAddressPrefixPrefix exceeds 114 octets, then OIDS of instances of columns in this row will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3."; } leaf ipAddressPrefixLength { type inet-address-mib:InetAddressPrefixLength; config false; description "The prefix length associated with this prefix. The value 0 has no special meaning for this object. It simply refers to address '::/0'."; } leaf ipAddressPrefixOrigin { type ip-mib:IpAddressPrefixOriginTC; config false; description "The origin of this prefix."; } /* ... detail omitted here ... */ } } container ipAddressTable { list ipAddressEntry { key "ipAddressAddrType, ipAddressAddr"; description "An address mapping for a particular interface."; /* ... detail omitted here ... */ leaf ipAddressPrefix { type ref; config false; description "A pointer to the row in the prefix table to which this address belongs. May be { 0 0 } if there is no such row."; } /* ... detail omitted here ... */ } } NETCONF XML Encoding: "../../../ipAddressPrefixTable/ipAddressPrefixEntry/ipAddressPrefixOrigin","1","ipv4","192.168.1.0","24" For the NETCONF client to correctly interpret the value of ipAddressPrefix, it may need to issue a query to the device. In this case, the position is an instance of the columnar leaf object ipAddressPrefixOrigin. The instance is: ipAddressPrefixIfIndex = 1 ipAddressPrefixType = ipv4 ipAddressPrefixPrefix = 192.168.1.0 ipAddressPrefixLength = 24 3. Example 3 shows the YANG representation of exerpts from RFC 2790, where the leaf hrStorageType points to any of several identities defined in the hrStoragetypes container in the HOST-RESOURCES-TYPES module. YANG Example: module HOST-RESOURCES-TYPES { namespace "urn:ietf:params:xml:ns:yang:smiv2:HOST-RESOURCES-TYPES"; prefix "host-resources-types"; container hrStorageTypes { identity hrStorageOther { description "The storage type identifier used when no other defined type is appropriate."; } identity hrStorageRam { description "The storage type identifier used for RAM."; } /* ... detail omitted here ... */ } } module HOST-RESOURCES-MIB { namespace "urn:ietf:params:xml:ns:yang:smiv2:HOST-RESOURCES-MIB"; prefix "host-resources-mib"; /* ... detail omitted here ... */ container hrStorage { container hrStorageTypes { } leaf hrMemorySize { type host-resources-mib:KBytes; config false; description "The amount of physical read-write main memory, typically RAM, contained by the host."; } container hrStorageTable { list hrStorageEntry { key "hrStorageIndex"; description "A (conceptual) entry for one logical storage area on the host. As an example, an instance of the hrStorageType object might be named hrStorageType.3"; leaf hrStorageIndex { type int32 { range "1..2147483647"; } config false; description "A unique value for each logical storage area contained by the host."; } leaf hrStorageType { type ref; config false; description "The type of storage represented by this entry."; } /* ... detail omitted here ... */ } } } } NETCONF XML Encoding: host-resources-types:/hrStorageTypes/hrStorageRam Regards, David ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From spakes@snmp.com Thu Apr 9 13:44:28 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B36DB3A6954 for ; Thu, 9 Apr 2009 13:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIaQobA8yML7 for ; Thu, 9 Apr 2009 13:44:27 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 5B0033A68D2 for ; Thu, 9 Apr 2009 13:44:27 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id QAA02714; Thu, 9 Apr 2009 16:45:33 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id QAA21151; Thu, 9 Apr 2009 16:45:30 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Thu, 9 Apr 2009 16:45:30 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20090408223650.GA23576@elstar.local> Message-ID: References: <200904032122.RAA02614@adminfs.snmp.com> <20090408223650.GA23576@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "netmod@ietf.org" Subject: Re: [netmod] SMIv2 to YANG mapping: OBJECT-IDENTITY X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 20:44:28 -0000 Juergen, I would not argue against keeping the object-identifier and object-identifier-128 as built-in types in YANG for other purposes. Regards, David On Thu, 9 Apr 2009, Juergen Schoenwaelder wrote: > On Wed, Apr 08, 2009 at 11:15:26PM +0200, David Spakes wrote: > > > Under this proposal, a MIB object of type OBJECT IDENTIFIER would always > > be converted to a leaf having a type that is the generic ref type. > > > If the working group were to choose to adopt this proposal, I don't see > > any reason why Yang would need to define the built-in object-identifier > > and object-identifier-128 types. > > An SMIv2 object of type OBJECT IDENTIFIER can hold arbitrary OID > values; restricting this to something that is defined somewhere won't > work. Please also note that there are other protocols using OIDs and > hence these types will be useful even if there is a way to eliminate > OIDs from translated SMIv2 modules (which I doubt will be possible). > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From j.schoenwaelder@jacobs-university.de Thu Apr 9 14:37:02 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B594A3A691C for ; Thu, 9 Apr 2009 14:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEWYaHwMwWaM for ; Thu, 9 Apr 2009 14:37:01 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 924B63A67E4 for ; Thu, 9 Apr 2009 14:37:01 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 563EEC0023; Thu, 9 Apr 2009 23:38:09 +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 ldg2uFp9yccC; Thu, 9 Apr 2009 23:38:08 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1E15CC0004; Thu, 9 Apr 2009 23:38:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F094DA6EEBF; Thu, 9 Apr 2009 23:37:50 +0200 (CEST) Date: Thu, 9 Apr 2009 23:37:50 +0200 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20090409213750.GA26670@elstar.local> Mail-Followup-To: David Spakes , Martin Bjorklund , "netmod@ietf.org" References: <200904032122.RAA02614@adminfs.snmp.com> <20090408.235734.237591776.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] SMIv2 to YANG mapping: OBJECT-IDENTITY X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 09 Apr 2009 21:37:02 -0000 On Thu, Apr 09, 2009 at 10:42:40PM +0200, David Spakes wrote: > A MIB object of type OBJECT IDENTIFIER contains information about the > [MIB] schema implemented by the [SNMP] agent. It's value is a path > to a position in the MIB tree. The value of an OBJECT IDENTIFIER is well an OBJECT IDENTIFIER value. The value can be anything and it does not have to be defined in any MIB module. Turning all OBJECT IDENTIFIERs into a new YANG ref type which requires to introduce new syntatic constructs to refer to arbitrary elements in a data tree won't solve the ambiguity mentioned above. Here is an example: The vacmViewTreeFamilySubtree object of the SNMP-VIEW-BASED-ACM-MIB carried an OBJECT IDENTIFIER value that is combined with a bitmask to identifier to identify a family of view subtrees. There are two things worth to note here: a) The vacmViewTreeFamilySubtree can be any OID - it does not have to point to anything ever defined in the SMIv2 because subidentifier can be masked (and as a consequence these masked subidentifier can be arbitrary without changing the semantics). b) A mask is applied to the vacmViewTreeFamilySubtree OID. If you translate the OID to a ref, how to you then apply a bitmask to the ref value with a completely different syntax? [ examples deleted ] I believe YANG has the mechanisms in place to write proper YANG models for all these examples that actually express more clearly what is being referenced. Automated translations from SMIv2 to "natural" YANG is difficult (or requires additional annotations), but this is mainly a shortcoming of the SMIv2. But note that automated translations to "workable" YANG is possible - but this will expose SMIv2 concepts such as OIDs in the YANG data models generated by a translator. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Washam.Fan@huaweisymantec.com Thu Apr 9 22:39:32 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2C773A6938 for ; Thu, 9 Apr 2009 22:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.238 X-Spam-Level: X-Spam-Status: No, score=-1.238 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jloGis5xvfhi for ; Thu, 9 Apr 2009 22:39:32 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id D06A53A6810 for ; Thu, 9 Apr 2009 22:39:31 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHV00CIJEFDAP20@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Fri, 10 Apr 2009 13:40:27 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHV00GBREFAAS00@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Fri, 10 Apr 2009 13:40:24 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Fri, 10 Apr 2009 13:40:22 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Fri, 10 Apr 2009 13:40:22 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090409.181214.06551488.mbj@tail-f.com> References: <20090408.235734.237591776.mbj@tail-f.com> <20090409.181214.06551488.mbj@tail-f.com> Cc: netmod@ietf.org Subject: [netmod] sec 7.6.4, yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 05:39:32 -0000 Hi, para2 says: If "mandatory" is "true", the behavior of the constraint depends on the type of the leaf's closest ancestor node in the schema tree which is not a presence container (see Section 7.5.1): ^^^^^^^^^^^^^ [ two bullets omitted ] Could we just say "a container" instead? Imagine that a mandatory leaf L is under a non-presence container C, then bullet 2 applies: L's existence depends on C's existence, since C is the closest ancestor which is not a presence container. but, ITOH, C's existence depends on L's existence in return, since C is a container without presence. Does that make sense? washam From andy@netconfcentral.com Fri Apr 10 17:55:34 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 270E63A69C3 for ; Fri, 10 Apr 2009 17:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CHWnWc64U-b for ; Fri, 10 Apr 2009 17:55:33 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id 479143A692F for ; Fri, 10 Apr 2009 17:55:33 -0700 (PDT) Received: (qmail 55919 invoked from network); 11 Apr 2009 00:56:42 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.61 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 11 Apr 2009 00:56:41 -0000 X-YMail-OSG: 4XZVMwQVM1n3Vk9cposEpWj7FxtyzfJf7Ai5tNNtzPjLlNES8ephj0cYDK6TMbt7.gzUB4va9ighLMsj_2Kl1OFpIrnRVfjb6eKml6uzmdfrgZouHgngmr00lgU3ZRlrmEpuE7xThWD1IOWkkzl_jITPEBEQTF_6sR__O5jciZ.JH5MYXtx3wfbv4xPBnD_0rxmWAItnr7Ug5kMgv4ysx03ZTl41y3NXlwbOVivxcU5ff10_fHuyJOpmqEEHnaPTSLvfg4SC6JNU7g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49DFEAC7.4050708@netconfcentral.com> Date: Fri, 10 Apr 2009 17:56:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <20090406.230352.29987150.mbj@tail-f.com> In-Reply-To: <20090406.230352.29987150.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] comments on bierman-netmod-yang-usage-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 00:55:34 -0000 Martin Bjorklund wrote: > Hi, > > I have some comments on this document. > > o The Virtual Module concept is a bit unclear, but I believe it will > be removed. > yes it will be removed. The idea was to prevent the republication of an RPC just to an an 'include-stmt' for a new submodule. But this will not work. For many reasons, a statically published RFC is needed every time a module is changed. > o section 3.6: > > Should documents listed in 'reference' statements also be included > in (at least) the non-normative reference section? > hmmm... usually only the imports are normative references. I guess some text about the reference clause(s) needs to be mentioned as well. > o section 4.4, second bullet: > > Until a URI is assigned by the IANA, a temporary namespace string > SHOULD be selected which is not likely to collide with other YANG > namespaces, such as the filename of the Internet Draft containing > the YAM. > > I guess there is a similar rule for assgnments under mib-2 for SMIv2 > modules, so maybe this rule should be followed. But I just note > that the current I-D YANG modules don't follow this, and I have not > seen this being used in XSDs (targetNamespace) in I-Ds. > This is controversial. The practice for MIBs is to intentionally publish I-D MIBs so they do not compile. Instead they crash with an invalid module assignment OID. IMO, this is really overboard. Instead, a well-known formula (e.g., I-D draft name) for a temporary namespace URI seems more useful. In reality, since this field is just a 'string', any value including '' will be accepted by a tool, but using random strings in NETCONF namespace URIs may cause problems, especially ''. My formula works fine for NETCONF. E.g., if the agent advertises 'draft-ietf-netconf-with-defaults-01' as the namespace URI, then it is absolutely clear what is in the implementation, and early interoperability testing is not suppressed by IETF policy. > o section 4.5: > > The description statement MUST be present. > > It is not clear which description statement you refer to. Typedef? > Leaf? > typedef. I will make it clear. for object definitions, it is not as clear. For example, a bits or enumeration object SHOULD use individual description-stmt in the enum/bit statements, so maybe the main description has nothing to say. Balazs also mentioned obvious, well-known objects, like 'name' ("The name of the foo entry.") Description clauses are meant to add additional information beyond the most obvious. Usually in a standard data model, there is *something* that needs to be mentioned about every object. > o section 4.5: > > For string data types, if the length of the string is not > unbounded in all implementations, then a length statement SHOULD > be present. > > [I don't want to restart the discussion on unbounded strings here!] > > I think it is obvious that no implementation will support unbounded > strings, so I think this rule should be rephrased. My initial > suggestion was to: > s/is not unbounded/is not required to be unbounded/ > but I'm not sure if that is more clear or not. > OK - I will make this edit. The reason many standard MIB objects have length limits, even descriptive ones (SnmpAdminString is 0..255 octets (!)) is that every implementation MUST support this limit. Unbounded mandatory-to-implement strings rarely get approved by WGs. > o section 4.6, last bullet. > > Similar to the previous comment. I don't think max-elements should > be used unless it makes sense for the data being modelled. I.e. I > think people should be careful not to add "arbitrary" limits... > I will say that min and max should be used when there are design limits, not implementation limits, to consider. > o section 4.6: > > Do we also want to say that if must/when expressions are present, > then their meaning SHOULD be described in the description? > yes > o Maybe add a section on naming conventions? We should list our rule > that IETF modules use the prefix 'ietf-'. Say that the prefix in > IETF modules SHOULD be unique? > yes -- I was going to add a section on module naming. I am hesitant to say anything about camelCase or anything else style-related (SMIv2 forces people to look up the plural form of every counter name they want to define). I will say that naming conventions SHOULD remain consistent within the same module. > > /martin Andy From mbj@tail-f.com Mon Apr 13 23:19:56 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5637F28C113 for ; Mon, 13 Apr 2009 23:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_26=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7Pw1RU2DJ4E for ; Mon, 13 Apr 2009 23:19:55 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 936FB28B56A for ; Mon, 13 Apr 2009 23:19:55 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7980B76C52F; Tue, 14 Apr 2009 08:21:06 +0200 (CEST) Date: Tue, 14 Apr 2009 08:21:06 +0200 (CEST) Message-Id: <20090414.082106.135745430.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49DFEAC7.4050708@netconfcentral.com> References: <20090406.230352.29987150.mbj@tail-f.com> <49DFEAC7.4050708@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] comments on bierman-netmod-yang-usage-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 06:19:56 -0000 Andy Bierman wrote: > > o section 4.4, second bullet: > > Until a URI is assigned by the IANA, a temporary namespace string > > SHOULD be selected which is not likely to collide with other YANG > > namespaces, such as the filename of the Internet Draft containing > > the YAM. > > I guess there is a similar rule for assgnments under mib-2 for SMIv2 > > modules, so maybe this rule should be followed. But I just note > > that the current I-D YANG modules don't follow this, and I have not > > seen this being used in XSDs (targetNamespace) in I-Ds. > > > > This is controversial. > The practice for MIBs is to intentionally publish I-D MIBs > so they do not compile. Instead they crash with an invalid > module assignment OID. > > IMO, this is really overboard. > Instead, a well-known formula (e.g., I-D draft name) > for a temporary namespace URI seems more useful. In reality, > since this field is just a 'string', any value including '' > will be accepted by a tool, but using random strings in NETCONF > namespace URIs may cause problems, especially ''. The namespace value is not a string, it is a URI. The element in the XSD in 4741 is an xs:anyURI. My tool gives an error if you don't have a prooper URI as namespace. /martin From andy@netconfcentral.com Tue Apr 14 00:27:06 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41C3E3A6A3F for ; Tue, 14 Apr 2009 00:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_26=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYhHOg50TOJk for ; Tue, 14 Apr 2009 00:27:05 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 942693A692D for ; Tue, 14 Apr 2009 00:27:05 -0700 (PDT) Received: (qmail 23865 invoked from network); 14 Apr 2009 07:28:17 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.236 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 14 Apr 2009 07:28:16 -0000 X-YMail-OSG: gEHfKSoVM1nd_jBOZBYE58CY4uyt2lGhZci2XH46zgWCH5v2IxGjjwZ7RCjWkR6qV4KJQ4aBMdRd2emZbKZ6XW8s0kf7odqow2FhE0wKVYPLA24GFXwu3C0c8OKarUA7.bI3G7GnTDoq8tkldLgzvfwomfJ_3r3p.jyPFqq4gQCbBiU6PNpus7CrVMRv9QwdulQSWKJJAe1LoMtWtsBAVEZOrkm97iGU1j.WhcsymR3GiTojTzVIXN03bc4Vxbj1gnwz5jqLa_NXymFmEt_QdcFkuZWl_ign1ZEIP5_MV9GgzfyxwVzr3yTWM4sUbRZLRB7UlTW0LpjWog-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E43B0F.2070505@netconfcentral.com> Date: Tue, 14 Apr 2009 00:28:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <20090406.230352.29987150.mbj@tail-f.com> <49DFEAC7.4050708@netconfcentral.com> <20090414.082106.135745430.mbj@tail-f.com> In-Reply-To: <20090414.082106.135745430.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] comments on bierman-netmod-yang-usage-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 07:27:06 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >>> o section 4.4, second bullet: >>> Until a URI is assigned by the IANA, a temporary namespace string >>> SHOULD be selected which is not likely to collide with other YANG >>> namespaces, such as the filename of the Internet Draft containing >>> the YAM. >>> I guess there is a similar rule for assgnments under mib-2 for SMIv2 >>> modules, so maybe this rule should be followed. But I just note >>> that the current I-D YANG modules don't follow this, and I have not >>> seen this being used in XSDs (targetNamespace) in I-Ds. >>> >> This is controversial. >> The practice for MIBs is to intentionally publish I-D MIBs >> so they do not compile. Instead they crash with an invalid >> module assignment OID. >> >> IMO, this is really overboard. >> Instead, a well-known formula (e.g., I-D draft name) >> for a temporary namespace URI seems more useful. In reality, >> since this field is just a 'string', any value including '' >> will be accepted by a tool, but using random strings in NETCONF >> namespace URIs may cause problems, especially ''. > > The namespace value is not a string, it is a URI. The > element in the XSD in 4741 is an xs:anyURI. > > My tool gives an error if you don't have a prooper URI as namespace. > So what value should we use for the IANA-assigned URI field in I-Ds, obviously before IANA has assigned any value? It would not be hard to invent a new schema, like 'temp-ns': temp-ns://draft-foo-bar-who-cares-00 Or just 'file': file://draft-foo-bar-who-cares-00.txt That would be a proper URI and your tool will be happy again. > > > /martin > > Andy From mbj@tail-f.com Tue Apr 14 01:46:45 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0FE13A6ADA for ; Tue, 14 Apr 2009 01:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kql+RNy59HVj for ; Tue, 14 Apr 2009 01:46:45 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3A42A3A6C7F for ; Tue, 14 Apr 2009 01:45:37 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 5663361600B; Tue, 14 Apr 2009 10:46:48 +0200 (CEST) Date: Tue, 14 Apr 2009 10:46:48 +0200 (CEST) Message-Id: <20090414.104648.214752743.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <200904082100.RAA09621@adminfs.snmp.com> References: <200904011930.PAA07624@adminfs.snmp.com> <200904082100.RAA09621@adminfs.snmp.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] question about unions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 08:46:45 -0000 David Reid wrote: > > If I have the following union: > > > > leaf foo { > > type union { > > type int32; > > type string; > > } > > } > > Is it possible in the above example to send the string '010'? > Since '010' will be treated as the integer 10, I'm assuming that > there is no way to pass '010' as a string in union like this. > Is that right? Yes, that is right. /martin From mbj@tail-f.com Tue Apr 14 02:05:27 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE5483A6A8D for ; Tue, 14 Apr 2009 02:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTFVhPMp1xgM for ; Tue, 14 Apr 2009 02:05:27 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id BAF7128C0FC for ; Tue, 14 Apr 2009 02:05:26 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C3D0661600B; Tue, 14 Apr 2009 11:06:37 +0200 (CEST) Date: Tue, 14 Apr 2009 11:06:37 +0200 (CEST) Message-Id: <20090414.110637.168506945.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49DE22C4.7050203@netconfcentral.com> References: <49D78349.4010404@netconfcentral.com> <20090408.130303.112175402.mbj@tail-f.com> <49DE22C4.7050203@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-04: when-stmt and rpc/input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 09:05:27 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Hi, > > Andy Bierman wrote: > >> Hi, > >> > >> The section on the rpc input statement is not clear enough. > >> > >> I don't know what para 2 means: > >> > >> If a container in the input tree has a "presence" statement, the > >> container need not be present in a NETCONF RPC invocation. > >> > >> An NP container does not have to be present unless it has > >> 1 or more mandatory descendants. > > I see what you mean. I suggest we simply remove this sentence. > > > > yes > > >> The when-stmt is not mentioned at all. > >> IMO, the agent should ignore when-stmt for rpc/input. > > Section 7.19.5 The when Statement specifies how the when statement is > > used in rpc input/output. I believe it was the consensus to allow > > when in rpcs (see the mail thread called "Proposed consensus mail on > > yang-00172"), so I'd rather fix the text in the RPC section instead. > > I propose this text in section 7.13.2 (and similar in 7.13.3): > > If any node has a "when" statement which would evaluate to > > false, then this node MUST NOT be present in the input tree. > > > > This is different than the 'silently delete all false when-stmt nodes' > procedure used on the database target(s). But it is consistent with this, from the Payload Parsing section: - If data for a node tagged with "when" is present, and the "when" condition evaluates to "false", the server MUST reply with an 'unknown-element' error-tag in the rpc-error. > I'm a bit unclear on the use-cases for when-stmt in rpc/input. > I can see if-feature quite easily, but not when-stmt. > Does anyone have any use-cases for this, or are we just > adding complexity every opportunity we get? I think we want to avoid having too many special cases for these statements - if the semantics of a particular statement combination is clear then it is allowed. There are some cases where the semantics are unclear, and where we thus do not allow it, e.g. for 'ordered-by' we have: This statement is ignored if the list represents state data, RPC output parameters, or notification content. /martin From mbj@tail-f.com Tue Apr 14 03:19:55 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE07E3A69A2 for ; Tue, 14 Apr 2009 03:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2e2nKV2G8qc for ; Tue, 14 Apr 2009 03:19:54 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4A7DE3A677C for ; Tue, 14 Apr 2009 03:19:54 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id BB75661600B; Tue, 14 Apr 2009 12:21:04 +0200 (CEST) Date: Tue, 14 Apr 2009 12:21:04 +0200 (CEST) Message-Id: <20090414.122104.145214368.mbj@tail-f.com> To: Washam.Fan@huaweisymantec.com From: Martin Bjorklund In-Reply-To: References: <20090409.181214.06551488.mbj@tail-f.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] sec 7.6.4, yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 10:19:56 -0000 WashamFan wrote: > Hi, > > para2 says: > > If "mandatory" is "true", the behavior of the constraint depends on > the type of the leaf's closest ancestor node in the schema tree which > is not a presence container (see Section 7.5.1): > ^^^^^^^^^^^^^ > [ two bullets omitted ] > > Could we just say "a container" instead? It should be "a non-presence container". The idea is that non-presence containers are ignored. Now fixed, thanks. /martin From andy@netconfcentral.com Tue Apr 14 07:07:58 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E66E03A6DFC for ; Tue, 14 Apr 2009 07:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwWck2GLsAA8 for ; Tue, 14 Apr 2009 07:07:58 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 3936B3A6E02 for ; Tue, 14 Apr 2009 07:07:58 -0700 (PDT) Received: (qmail 40662 invoked from network); 14 Apr 2009 14:09:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.236 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 14 Apr 2009 14:09:09 -0000 X-YMail-OSG: DU4QfowVM1nFZzMLtMToRwWrb0o9ePbf8zBSv1ONzZ23wRVOAAzsTwsIgDBo35diBTb122Ds5LPCnMDbJviMdbFSUO9S9sHHO8QTZL4NPnJLu_W4rNMpcY.otCgCBY_CPmxK92IYJbfW9.eKFOgIEF5xuM7xsz1NbFMD1xRbw4wES2fGO0Y1.9JpytH4xoQpE.cV_HtNlGgA5VScdxfVjYzNMBYQ3YyGzybqSd6oBE.VLft9luGYCSUvG.EGyW20pk6jNgD1DazsntM9Hp6Km8mAtfy93J6wBbTMCynohmdInIAvg3LOen5k4bVKY8vZ1RJehbNkWneBZA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E49904.5010107@netconfcentral.com> Date: Tue, 14 Apr 2009 07:09:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <49D78349.4010404@netconfcentral.com> <20090408.130303.112175402.mbj@tail-f.com> <49DE22C4.7050203@netconfcentral.com> <20090414.110637.168506945.mbj@tail-f.com> In-Reply-To: <20090414.110637.168506945.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-04: when-stmt and rpc/input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 14:07:59 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Hi, >>> Andy Bierman wrote: >>>> Hi, >>>> >>>> The section on the rpc input statement is not clear enough. >>>> >>>> I don't know what para 2 means: >>>> >>>> If a container in the input tree has a "presence" statement, the >>>> container need not be present in a NETCONF RPC invocation. >>>> >>>> An NP container does not have to be present unless it has >>>> 1 or more mandatory descendants. >>> I see what you mean. I suggest we simply remove this sentence. >>> >> yes >> >>>> The when-stmt is not mentioned at all. >>>> IMO, the agent should ignore when-stmt for rpc/input. >>> Section 7.19.5 The when Statement specifies how the when statement is >>> used in rpc input/output. I believe it was the consensus to allow >>> when in rpcs (see the mail thread called "Proposed consensus mail on >>> yang-00172"), so I'd rather fix the text in the RPC section instead. >>> I propose this text in section 7.13.2 (and similar in 7.13.3): >>> If any node has a "when" statement which would evaluate to >>> false, then this node MUST NOT be present in the input tree. >>> >> This is different than the 'silently delete all false when-stmt nodes' >> procedure used on the database target(s). > > But it is consistent with this, from the Payload Parsing section: > > - If data for a node tagged with "when" is present, and the "when" > condition evaluates to "false", the server MUST reply with an > 'unknown-element' error-tag in the rpc-error. > I strongly disagree with this text. The false node stuff applies (like must-stmt) to valid configurations. The false when-stmt test does not apply to the candidate config. That test only applies to the running config. The candidate is allowed to be invalid. >> I'm a bit unclear on the use-cases for when-stmt in rpc/input. >> I can see if-feature quite easily, but not when-stmt. >> Does anyone have any use-cases for this, or are we just >> adding complexity every opportunity we get? > > I think we want to avoid having too many special cases for these > statements - if the semantics of a particular statement combination is > clear then it is allowed. There are some cases where the semantics > are unclear, and where we thus do not allow it, e.g. for 'ordered-by' > we have: > I guess you can't think of a single use-case either. > This statement is ignored if the list represents state data, RPC > output parameters, or notification content. > > > /martin > > Andy From mbj@tail-f.com Tue Apr 14 11:52:47 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1A533A68A8 for ; Tue, 14 Apr 2009 11:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5nQWm-F-XMX for ; Tue, 14 Apr 2009 11:52:47 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id AD07B3A659C for ; Tue, 14 Apr 2009 11:52:46 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 208A6616005; Tue, 14 Apr 2009 20:53:57 +0200 (CEST) Date: Tue, 14 Apr 2009 20:53:56 +0200 (CEST) Message-Id: <20090414.205356.224174286.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49E49904.5010107@netconfcentral.com> References: <49DE22C4.7050203@netconfcentral.com> <20090414.110637.168506945.mbj@tail-f.com> <49E49904.5010107@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-04: when-stmt and rpc/input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 18:52:47 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >>> Hi, > >>> Andy Bierman wrote: > >>>> Hi, > >>>> > >>>> The section on the rpc input statement is not clear enough. > >>>> > >>>> I don't know what para 2 means: > >>>> > >>>> If a container in the input tree has a "presence" statement, the > >>>> container need not be present in a NETCONF RPC invocation. > >>>> > >>>> An NP container does not have to be present unless it has > >>>> 1 or more mandatory descendants. > >>> I see what you mean. I suggest we simply remove this sentence. > >>> > >> yes > >> > >>>> The when-stmt is not mentioned at all. > >>>> IMO, the agent should ignore when-stmt for rpc/input. > >>> Section 7.19.5 The when Statement specifies how the when statement is > >>> used in rpc input/output. I believe it was the consensus to allow > >>> when in rpcs (see the mail thread called "Proposed consensus mail on > >>> yang-00172"), so I'd rather fix the text in the RPC section instead. > >>> I propose this text in section 7.13.2 (and similar in 7.13.3): > >>> If any node has a "when" statement which would evaluate to > >>> false, then this node MUST NOT be present in the input tree. > >>> > >> This is different than the 'silently delete all false when-stmt nodes' > >> procedure used on the database target(s). > > But it is consistent with this, from the Payload Parsing section: > > - If data for a node tagged with "when" is present, and the "when" > > condition evaluates to "false", the server MUST reply with an > > 'unknown-element' error-tag in the rpc-error. > > > > I strongly disagree with this text. > The false node stuff applies (like must-stmt) to valid configurations. > The false when-stmt test does not apply to the candidate config. > That test only applies to the running config. > The candidate is allowed to be invalid. But that's not how "when" works. The difference between "when" and "must" is how the constraint is enforced. "when" can be viewed as a generalization of "choice"; they share the same processing model and behavior. > >> I'm a bit unclear on the use-cases for when-stmt in rpc/input. > >> I can see if-feature quite easily, but not when-stmt. > >> Does anyone have any use-cases for this, or are we just > >> adding complexity every opportunity we get? > > I think we want to avoid having too many special cases for these > > statements - if the semantics of a particular statement combination is > > clear then it is allowed. There are some cases where the semantics > > are unclear, and where we thus do not allow it, e.g. for 'ordered-by' > > we have: > > > > I guess you can't think of a single use-case either. Any discriminated union, such as: input { leaf ip-version { type inet:ip-version; } container ipv4-params { when "../ip-version = 'ipv4'"; ... } container ipv6-params { when "../ip-version = 'ipv6'"; ... } ... } Or any case where "when" is used in a grouping which is used in "rpc". /martin From andy@netconfcentral.com Tue Apr 14 12:16:11 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4685A3A6E31 for ; Tue, 14 Apr 2009 12:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofkTNrs6qUMf for ; Tue, 14 Apr 2009 12:16:10 -0700 (PDT) Received: from n24.bullet.mail.mud.yahoo.com (n24.bullet.mail.mud.yahoo.com [68.142.206.163]) by core3.amsl.com (Postfix) with SMTP id 3BDDA3A6E16 for ; Tue, 14 Apr 2009 12:16:10 -0700 (PDT) Received: from [68.142.200.226] by n24.bullet.mail.mud.yahoo.com with NNFMP; 14 Apr 2009 19:17:22 -0000 Received: from [68.142.201.247] by t7.bullet.mud.yahoo.com with NNFMP; 14 Apr 2009 19:17:21 -0000 Received: from [127.0.0.1] by omp408.mail.mud.yahoo.com with NNFMP; 14 Apr 2009 19:17:21 -0000 X-Yahoo-Newman-Id: 964609.70062.bm@omp408.mail.mud.yahoo.com Received: (qmail 32704 invoked from network); 14 Apr 2009 19:17:21 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.236 with plain) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 14 Apr 2009 19:17:20 -0000 X-YMail-OSG: Fg_ltUUVM1k2tDGNEOnAQbOjJPGkOuGzzTXDvDEGQ5Db4wHLr9V0eNwUR2ksIVRec_3OJGDJCpXzY_9jSP9EQJxJtL.m5LGGSbPrWB7dFc.ExFZ.17L21IhospgyRcT2j2TAFvb_LPkCSHpV0Vm3Uf.F0bjnOy64DA8n60y_VvUU3xItLqwar6e42KwKlKswdkAgDT4UaS.AsbNzLDWX0PJZc7F8rCjQh5_CUeVti0doN3vw353QtRvoAQNGRSshSNW42aNMePshJ3tke8klsaI_K5wIBUxBfnSq.7C4ZT54gqXoaZnL65Eg4f.U3KWkQnijzi37o9e_nw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E4E13F.2080802@netconfcentral.com> Date: Tue, 14 Apr 2009 12:17:19 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <49DE22C4.7050203@netconfcentral.com> <20090414.110637.168506945.mbj@tail-f.com> <49E49904.5010107@netconfcentral.com> <20090414.205356.224174286.mbj@tail-f.com> In-Reply-To: <20090414.205356.224174286.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-04: when-stmt and rpc/input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 19:16:11 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Martin Bjorklund wrote: >>>>> Hi, >>>>> Andy Bierman wrote: >>>>>> Hi, >>>>>> >>>>>> The section on the rpc input statement is not clear enough. >>>>>> >>>>>> I don't know what para 2 means: >>>>>> >>>>>> If a container in the input tree has a "presence" statement, the >>>>>> container need not be present in a NETCONF RPC invocation. >>>>>> >>>>>> An NP container does not have to be present unless it has >>>>>> 1 or more mandatory descendants. >>>>> I see what you mean. I suggest we simply remove this sentence. >>>>> >>>> yes >>>> >>>>>> The when-stmt is not mentioned at all. >>>>>> IMO, the agent should ignore when-stmt for rpc/input. >>>>> Section 7.19.5 The when Statement specifies how the when statement is >>>>> used in rpc input/output. I believe it was the consensus to allow >>>>> when in rpcs (see the mail thread called "Proposed consensus mail on >>>>> yang-00172"), so I'd rather fix the text in the RPC section instead. >>>>> I propose this text in section 7.13.2 (and similar in 7.13.3): >>>>> If any node has a "when" statement which would evaluate to >>>>> false, then this node MUST NOT be present in the input tree. >>>>> >>>> This is different than the 'silently delete all false when-stmt nodes' >>>> procedure used on the database target(s). >>> But it is consistent with this, from the Payload Parsing section: >>> - If data for a node tagged with "when" is present, and the "when" >>> condition evaluates to "false", the server MUST reply with an >>> 'unknown-element' error-tag in the rpc-error. >>> >> I strongly disagree with this text. >> The false node stuff applies (like must-stmt) to valid configurations. >> The false when-stmt test does not apply to the candidate config. >> That test only applies to the running config. >> The candidate is allowed to be invalid. > > But that's not how "when" works. The difference between "when" and > "must" is how the constraint is enforced. "when" can be viewed as a > generalization of "choice"; they share the same processing model and > behavior. > >>>> I'm a bit unclear on the use-cases for when-stmt in rpc/input. >>>> I can see if-feature quite easily, but not when-stmt. >>>> Does anyone have any use-cases for this, or are we just >>>> adding complexity every opportunity we get? >>> I think we want to avoid having too many special cases for these >>> statements - if the semantics of a particular statement combination is >>> clear then it is allowed. There are some cases where the semantics >>> are unclear, and where we thus do not allow it, e.g. for 'ordered-by' >>> we have: >>> >> I guess you can't think of a single use-case either. > > Any discriminated union, such as: > > input { > leaf ip-version { > type inet:ip-version; > } > container ipv4-params { > when "../ip-version = 'ipv4'"; > ... > } > container ipv6-params { > when "../ip-version = 'ipv6'"; > ... > } > ... > } > > Or any case where "when" is used in a grouping which is used in "rpc". > The difference between when-stmt and choice-stmt is that a choice is well-constrained and contained. The when-stmt is arbitrary XPath. Silently deleting all the false nodes in the scratch-pad database seems harder to use to me, but it doesn't matter that much. The astonishment train left the station already anyway. ;-) I would prefer a real discriminated choice, if that is important enough to have. > > /martin > > > Andy From j.schoenwaelder@jacobs-university.de Wed Apr 15 02:36:15 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 377233A6AE1 for ; Wed, 15 Apr 2009 02:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4ZfU+M6lM1H for ; Wed, 15 Apr 2009 02:36:14 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D3A493A685E for ; Wed, 15 Apr 2009 02:36:10 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 44FFAC004B; Wed, 15 Apr 2009 11:37:22 +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 lE9o3BZqY-Nv; Wed, 15 Apr 2009 11:37:21 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB118C0049; Wed, 15 Apr 2009 11:37:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1D94DA98B18; Wed, 15 Apr 2009 11:37:03 +0200 (CEST) Date: Wed, 15 Apr 2009 11:37:02 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20090415093702.GC4045@elstar.local> Mail-Followup-To: netmod@ietf.org, Seiichi Kawamura References: <49D17E45.7010907@mesh.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D17E45.7010907@mesh.ad.jp> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: [netmod] ipv6 address representation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 15 Apr 2009 09:36:15 -0000 On Tue, Mar 31, 2009 at 04:21:57AM +0200, Seiichi Kawamura wrote: > From what I've experienced, the "preferred way" noted in RFC4291 > sec 2.2 item 1 is rarely used. BTW, I'm a network > operator at an ISP/Data Center. I like to followup on this and nail down what should be in the -03 version of the yang types document. The proposal on the table is to go back to what we had in an earlier version of the document as the canonical format for IPv6 addresses: The :: substitution must be applied to the longest sequence of all-zero 16-bit chunks in an IPv6 address. If there is a tie, the first sequence of all-zero 16-bit chunks is replaced by ::. Single all-zero 16-bit chunks are not compressed. The normalized format uses lower-case characters and leading zeros are not allowed. This is inline with [1] and with a large fraction of inet_ntop() implementations. While the proposed format is not the preferred format spelled out in RFC 4291, it seems to be the most widely deployed format. Furthermore, operators have given reasons why this is their preferred format [1]. I personally believe we should adapt the :: compressed format as the canonical format for IPv6 addresses (and prefixes). But before I make the edits, I like to see more support for this change from the WG. So please tell us "I prefer the proposed compressed format" or "I prefer the uncompressed format". /js [1] draft-kawamura-ipv6-text-representation-00.txt -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Apr 15 03:12:48 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 972FD3A6B18 for ; Wed, 15 Apr 2009 03:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KqW4qJJVxPV for ; Wed, 15 Apr 2009 03:12:48 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id CF7E13A6917 for ; Wed, 15 Apr 2009 03:12:47 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7F6D3616004; Wed, 15 Apr 2009 12:13:58 +0200 (CEST) Date: Wed, 15 Apr 2009 12:13:58 +0200 (CEST) Message-Id: <20090415.121358.170140203.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090415093702.GC4045@elstar.local> References: <49D17E45.7010907@mesh.ad.jp> <20090415093702.GC4045@elstar.local> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ipv6 address representation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 10:12:48 -0000 Hi, Juergen Schoenwaelder wrote: > I personally believe we should adapt the :: compressed format as the > canonical format for IPv6 addresses (and prefixes). But before I make > the edits, I like to see more support for this change from the WG. So > please tell us "I prefer the proposed compressed format" or "I prefer > the uncompressed format". I prefer the proposed compressed format. /martin From lhotka@cesnet.cz Wed Apr 15 03:57:18 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D97203A6AC3 for ; Wed, 15 Apr 2009 03:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmUTA44MI8GV for ; Wed, 15 Apr 2009 03:57:18 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 125B63A67E7 for ; Wed, 15 Apr 2009 03:57:18 -0700 (PDT) Received: from [195.113.228.38] (nomad.w2lan.cesnet.cz [195.113.228.38]) by office2.cesnet.cz (Postfix) with ESMTP id 6DBBCD800BD for ; Wed, 15 Apr 2009 12:58:29 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20090415.121358.170140203.mbj@tail-f.com> References: <49D17E45.7010907@mesh.ad.jp> <20090415093702.GC4045@elstar.local> <20090415.121358.170140203.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 15 Apr 2009 12:58:28 +0200 Message-Id: <1239793108.6249.4.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] ipv6 address representation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 10:57:18 -0000 Martin Bjorklund píše v St 15. 04. 2009 v 12:13 +0200: > Hi, > > Juergen Schoenwaelder wrote: > > I personally believe we should adapt the :: compressed format as the > > canonical format for IPv6 addresses (and prefixes). But before I make > > the edits, I like to see more support for this change from the WG. So > > please tell us "I prefer the proposed compressed format" or "I prefer > > the uncompressed format". > > I prefer the proposed compressed format. Me too. Lada > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Wed Apr 15 09:33:05 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0819F3A6839 for ; Wed, 15 Apr 2009 09:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sedd32aaWJG for ; Wed, 15 Apr 2009 09:33:04 -0700 (PDT) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id 3668F3A6835 for ; Wed, 15 Apr 2009 09:33:04 -0700 (PDT) Received: from [68.142.200.227] by n17.bullet.mail.mud.yahoo.com with NNFMP; 15 Apr 2009 16:34:16 -0000 Received: from [68.142.201.72] by t8.bullet.mud.yahoo.com with NNFMP; 15 Apr 2009 16:34:16 -0000 Received: from [127.0.0.1] by omp424.mail.mud.yahoo.com with NNFMP; 15 Apr 2009 16:34:16 -0000 X-Yahoo-Newman-Id: 574629.6202.bm@omp424.mail.mud.yahoo.com Received: (qmail 93837 invoked from network); 15 Apr 2009 16:34:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.236 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 15 Apr 2009 16:34:15 -0000 X-YMail-OSG: X3SsK3YVM1nj6CS5mRQHDnHy5sO.31bAip2Hu8zGJwK7LosDqB8Fs6T357TtDRcwdFSSJGToEsAVxn8mspgEoWWvZF.FCDFQZvWUj1TYGQ65TQlr5i9vAJ2Sj.Gar9_pUIFbGvsV5IXNSyP9iie0YORwhJcWlwH7zpSdZuFT56ZUReP0GfPMXq0OzImd8sxqoKhVZFYW6XTphn_9_Wun172l7gVba3YWz3zI6pNnMFukInlSAzRcwlIMbdtlxlroT2INDGEsjGVRCBKT X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E60C84.1030108@netconfcentral.com> Date: Wed, 15 Apr 2009 09:34:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <49DE22C4.7050203@netconfcentral.com> <20090414.110637.168506945.mbj@tail-f.com> <49E49904.5010107@netconfcentral.com> <20090414.205356.224174286.mbj@tail-f.com> In-Reply-To: <20090414.205356.224174286.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-04: when-stmt and rpc/input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 16:33:05 -0000 Martin Bjorklund wrote: ..... > But that's not how "when" works. The difference between "when" and > "must" is how the constraint is enforced. "when" can be viewed as a > generalization of "choice"; they share the same processing model and > behavior. > >... Then I think some error handling procedures (new error-app-tag?) are needed to deal with problems with 'silent-delete'. If an operation would result in the deletion of nodes that are partial-locked or the session is not authorized to delete, then the MUST fail with some error-tag. It will confuse the manager to get back values for nodes that are completely unrelated to the actual target of the edit (especially access-denied). An actual notification is going to be needed as well, for this thing to move out of the sandbox. > /martin > > Andy From mbj@tail-f.com Wed Apr 15 12:28:07 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E44693A6C46 for ; Wed, 15 Apr 2009 12:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rf+4HKs-01Ns for ; Wed, 15 Apr 2009 12:28:07 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 26AE23A6B07 for ; Wed, 15 Apr 2009 12:28:06 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id EF7D861600C; Wed, 15 Apr 2009 21:29:17 +0200 (CEST) Date: Wed, 15 Apr 2009 21:29:17 +0200 (CEST) Message-Id: <20090415.212917.153297679.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49E60C84.1030108@netconfcentral.com> References: <49E49904.5010107@netconfcentral.com> <20090414.205356.224174286.mbj@tail-f.com> <49E60C84.1030108@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang-04: when-stmt and rpc/input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 19:28:08 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > ..... > > But that's not how "when" works. The difference between "when" and > > "must" is how the constraint is enforced. "when" can be viewed as a > > generalization of "choice"; they share the same processing model and > > behavior. >... > > > Then I think some error handling procedures (new error-app-tag?) > are needed to deal with problems with 'silent-delete'. > If an operation would result in the deletion > of nodes that are partial-locked or the session is not authorized > to delete, then the MUST fail with some error-tag. > It will confuse the manager to get back values > for nodes that are completely unrelated to the actual target > of the edit (especially access-denied). There are some kinds of errors where the error-path will refer to an object which is not in the PDU. 'when' and 'must' are two examples. For 'access-denied', you will get the same behaviour if you have access to one case but not another in a choice. Also, I think I have seen recommendations to not include error-path in 'access-denied' errors, for security reasons? /martin From david.kessens@nsn.com Wed Apr 15 21:17:09 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C95E3A6CB9 for ; Wed, 15 Apr 2009 21:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5Q4EyYv4LR6 for ; Wed, 15 Apr 2009 21:17:08 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 3D6163A6C5E for ; Wed, 15 Apr 2009 21:17:08 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3G4IC06013054; Thu, 16 Apr 2009 07:18:14 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 07:18:14 +0300 Received: from localhost.localdomain ([10.241.58.140]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 07:18:13 +0300 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.3/8.14.3) with ESMTP id n3G4IwYj006199; Wed, 15 Apr 2009 21:18:58 -0700 Received: (from david@localhost) by localhost.localdomain (8.14.3/8.14.3/Submit) id n3G4Iv8s006197; Wed, 15 Apr 2009 21:18:57 -0700 Date: Wed, 15 Apr 2009 21:18:57 -0700 From: David Kessens To: netmod@ietf.org, Seiichi Kawamura Message-ID: <20090416041857.GL4589@nsn.com> References: <49D17E45.7010907@mesh.ad.jp> <20090415093702.GC4045@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090415093702.GC4045@elstar.local> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 16 Apr 2009 04:18:14.0164 (UTC) FILETIME=[5C44CD40:01C9BE4A] X-Nokia-AV: Clean Subject: Re: [netmod] ipv6 address representation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 04:17:09 -0000 Juergen, On Wed, Apr 15, 2009 at 11:37:02AM +0200, Juergen Schoenwaelder wrote: > > The :: substitution must be applied to the longest sequence of > all-zero 16-bit chunks in an IPv6 address. If there is a tie, the > first sequence of all-zero 16-bit chunks is replaced by ::. Single > all-zero 16-bit chunks are not compressed. The normalized format > uses lower-case characters and leading zeros are not allowed. not speaking as one of the working group chairpeople: I think this should be fine. Personally, I would compress a single '0' as well and I usually use capitals for the hex characters (like in rfc4291). It would probably be good if some operators would respond with their preferences. David Kessens --- From david.partain@ericsson.com Wed Apr 15 23:29:15 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBDA03A67B4 for ; Wed, 15 Apr 2009 23:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.481 X-Spam-Level: X-Spam-Status: No, score=-4.481 tagged_above=-999 required=5 tests=[AWL=-0.398, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsLv2jg06tFv for ; Wed, 15 Apr 2009 23:29:12 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1B1923A6982 for ; Wed, 15 Apr 2009 23:29:12 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9451B20BD3 for ; Thu, 16 Apr 2009 08:30:23 +0200 (CEST) X-AuditID: c1b4fb3c-ab7ccbb00000238f-17-49e6d07fcbf7 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4DF2220A7F for ; Thu, 16 Apr 2009 08:30:23 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 08:30:23 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 08:30:22 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Thu, 16 Apr 2009 08:30:22 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200904160830.22633.david.partain@ericsson.com> X-OriginalArrivalTime: 16 Apr 2009 06:30:22.0770 (UTC) FILETIME=[D2161120:01C9BE5C] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Prelimary Meeting Minutes from IETF 74 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 06:29:15 -0000 Hi, Please find the preliminary meeting minutes below for both sessions. Pleas= e=20 send me any corrections. Cheers, David +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ IETF 74, NETMOD WG Monday, March 23, 2009 17:40-19:40 David Kessens, David Partain About 25 attendees WG status and Agenda Bashing (David Partain) The working group will have two sessions so there will be lots of time to address any issues and to make good progress. Drafts are available for all work items, but not quite following the proposed time line. The NETMOD architecture draft is rather late so that one needs to get special attention. Notes: Phil Shafer, Alan Luchuk, David Reid, and Balazs Lengyel Jabber: Will Ivancic =2D------------------------------------------------------------ NETMOD architecture document discussion: Phil Shafer David Kessens: Who read architecture? 15 hands. Ca. 1/2 the attendees have read the draft. Phil Shafer: Comments mainly to remove stuff. Is this good enough? Andy Bierman: Happy with the document. I am missing a NETCONF architecture, but for current scope fine. It doesn't say things that are out of scope. No unreasonable assumptions. Balazs Lengyel: It is in good condition. Mehmet Ersue: looks good. General consensus is that the new document is much improved. General consensus is that the new doc is ready for last call, after minor edits. Balazs Lengyel, David Partain, and Dan Romascanu have comments on the draft. Several people asked for a NETCONF architecture document also. David Harrington would like to petition the NETCONF WG for such a document. ?? (sorry, missed the name): I am interested in writing NETCONF architecture. This is fine for NETMOD, but would like something with a wider scope. David Harrington: NETCONF WG should write NETCONF architecture. Dan Romascanu: NETCONF architecture should be done in the NETCONF working group. NETMOD architecture is needed to show why YANG is needed and how YANG should work together the other components. We can start discussions for a bigger document in NETCONF WG. David Partain: How many people who read it think it is OK to go to WG last call. Most of them. (13?) =2D--------------------------------------------------------------- Common YANG Data Types document discussion: Martin Bj=F6rklund for J=FCrgen Sch=F6nw=E4lder (who was on jabber) How many have read the document: about 10 Summary of changes was presented. =2D-------------------------- Discussion of XPATH type and versioning Ladislav Lhotka suggested xpath1, matter a preference; suspects there will not be more than 2 versions for quite a long time. Wes Hardaker suggested xpath1.0 because it is easier to extract and compare numerically. Ladislav Lhotka: There won't be any XPath 1.1 so there is need for xpath1.0. David Harrington: How does XPath define version number Martin Bj=F6rklund: 1.0 David Harrington suggested following an existing standard numbering scheme Consensus: Show of hands 6/4 for Xpath1.0 -------------------------------------------------------------- Canonical form of an XPATH expression? Proposal: Don't define a canonical form. Some concern about whether the lack of a canonical form will result in interoperability issues. Several people did not think it would be a problem. Phil Shafer: When is this needed? What does canonical mean for xpath? Rewriting axis? Martin Bj=F6rklund: namespaces. Martin Bj=F6rklund: Filtering, keys in the database - problem is with prefixes, dependent on context. Andy Bierman: no axis in our uses of xpath (?). No win in canonicalization. The reason to canonicalize it is the agent needs to resolve the namespaces in the context of the config. David Harrington: If we don't have a canonical form, what about interoperability? Can't depend on the agent and manager coming from the same vendor. Could define crappy little rules that everyone should follow. David Harrington: XPath might be used for access control. If we don't have a canonical format will access control work? Ladislav Lhotka: It is not an interoperability problem. The XPath spec guarantees interoperability. Martin Bj=F6rklund: Filtering keys, might not work? Andy Bierman: What about whitespace normalisation, tokens, self or descendant? Phil Shafer: is there a real use case? Martin Bj=F6rklund: It is used mostly in protocol RPCs not in configuration datastore. In the PDU context. Andy Bierman: NETCONF monitoring uses it. This is no different than string identifiers. The problem is not worse than a simple string. Phil Shafer: Namespace mappings should be explicit, not contained in the context. David Partain: we have a use case, since it's in documents that are already written. Martin Bj=F6rklund: could be generated differently on each . In theory you could generate different prefixes for every call. Ladislav Lhotka: Prefixes are not stable, they should not be used. Martin: Yes, but this datatype is better than nothing. Balazs Lengyel: could we specify/suggest prefixes that aren't 100% but will help in many cases? We need to explicitly say the prefix mappings (the prefix strings themselves) may changed. Ladislav Lhotka: the prefix means nothing, just represents the URI string. Against prescribing a fixed prefix. Wes Hardaker: make two different datatypes, one for string and one where canonicalization matters. Datatypes are cheap. David Harrington: can xpath expressions be interpreted differently? Martin Bj=F6rklund: nope Ladislav Lhotka: discussion is moot because the xpath datatype is derived from string so there's no difference between xpath and string. David Partain: An engine can do something smart if it knows it is an XPath. Andy Bierman: Disagrees. It helped in implementation. The type is needed because trying to guess if it's xpath is expensive. Andy Bierman: The context and prefixes are a problem, and so canonical form is not needed/possible. Wes Hardaker: WG should not define canonical XPath, but if there is a definition use it. Most of the time we don't care for the exact match. A search for 'canonical xpath' yields multiple matches. Proposed looking for a canonical XPATH definition, and reuse if possible, otherwise we cannot solve the problem. David Partain: Anyone for working on a canonical form? None. Consensus in the room: Look for an existing canonical XPATH definition and reuse it if such exists. Otherwise, we do nothing. Put the canonical form (if found) in a separate data type. -------------------------------------------------------------- IPv6 Address Pattern? Which pattern should be used? Do we need a pattern at all? Ladislav Lhotka/J=FCrgen Sch=F6nw=E4lder came up with a pattern that seems to work. Ladislav Lhotka: new revision works in Ladislav Lhotka and J=FCrgen Sch=F6nw=E4lder tests; others should test it also. -------------------------------------------------------------- Do we have to support all IPv6 address writing styles, or can we just use the canonical IPv6 address format? (Slide 5) Ladislav Lhotka: If we allow it for IP address we should allow it here. Ladislav Lhotka referred to an RFC standard. David Harrington: how does it affect interoperability? Martin Bj=F6rklund: should have the same rules for addresses and prefixes. Ladislav Lhotka: allow both David Kessens as contributor: suggested a single format makes for simpler, more interoperable code. Martin: We are not inventing it here. Phil Shafer: Should be just as flexible for prefixes as for addresses. People use the shorthand, so we should support them. J=FCrgen Sch=F6nwalder: would like the flexibility. Hands for supporting all: 8 against: 1 Rough consensus: Support all IPv6 writing styles. -------------------------------------------------------------- DNS expert advice is needed so we get the restrictions on the DNS label right and future proof. People already discussing this. Once the DNS experts have had their say, J=FCrgen will propose the relevant change. -------------------------------------------------------------- URI expert advice is needed to answer the question if it is safe to use the regular expression from RFC 3986. Currently the uri type is defined as a string with restrictions in the description clause only David Partain will ask for expert review from apps area. (Editor note: This process is underway.) J=FCrgen Sch=F6nw=E4lder: question is whether the regular expression in Appendix B of RFC 3986 can be used? Ladislav Lhotka: Using it in his code, and it seems to work. -------------------------------------------------------------- IEEE Port List (slide 8) Suggestion to add a port list type (J=FCrgen Sch=F6nw=E4lder) Suggestion to use a comma separated list of port ranges: e.g. 1-5,8,10-22. Ranges may not overlap and may not be consecutive. Andy Bierman: do not add type right now Martin Bj=F6rklund: also do not add too much stuff Dan Romascanu: did not see a reason to add David Harrington remembers textual conventions for SMI to use standard formats. Suggested defining a type consistent with other definitions, such as IEEE or SNMP to promote standardization. David Harrington: came from TC; don't know where it came from; people were defining VLAN lists and came up with multiple alternatives. J=FCrgen Sch=F6nw=E4lder: TC is in the qbridge MIB but the TC uses a binary stream, each bit representing a port. David Harrington: a great deal of work was done; we should be consistent with that work; don't recall the bit stream stuff, but we can always add it later. David Partain: doesn't mind adding it as long as there is not extensive debate. Phil Shafer: This opens a lot of other issues, integer ranges, number of ranges. David Harrington: remembers a lot of effort and interoperability problems due to the lack of something defined for SNMP. Lobbied for adding this to YANG, but could come later. Dan Romascanu: discussion of bridge MIBs. Suggested defining later in YANG bridge modules. Dan Romascanu: some confusion, because this is trying to mirror work in bridge MIB but that MIB uses these as an index for tables. More general concern: we are trying to sync with ietf MIBs but IEEE has extended those. This should be postponed to bridge YANG basic module. I see bridge as an early customer for YANG, but we can do more work then. J=FCrgen Sch=F6nw=E4lder: Phil's questions are easy to address. Qbridge MIB. no definition, should be deferred, can define using port list TCs David Partain: consensus: defer until needed -------------------------------------------------------------- Add Other VLAN types (Slide 9) J=FCrgen Sch=F6nw=E4lder: defer David Partain: consensus: defer until needed -------------------------------------------------------------- Other comments/questions Phil Shafer: do not leave room until all open issues resolved, not all issues resolved. David Partain: two issues are open for expert review: 1. URI (uri datatype) (editor: underway) 2. DNS (domain-name datatype) (editor: underway) Also XPath canonicalization standards; if we find one we like, we'll define a new type "xpath-canonicalized" ((editor: discussion already on mailing list) Balazs Lengyel: customers want a port number of 0, meaning "wildcard". Change explanation of port type, or define a new type? Phil Shafer: isn't this a perfect use for unions? J=FCrgen Sch=F6nw=E4lder: port number 0 is not valid, a union might be a good solution. YANG draft: Martin Bj=F6rklund How many people have read -04: 10 Summary of changes since draft 02 -------------------------------------------------------------- Order of XML elements Currently the draft specifies that all XML elements are encoded in the same order as specified in the YANG model Proposal: remove this restriction, and specify that XML elements can encoded in any order. This maps nicely nicely in RelaxNG. Andy Bierman: in NETMOD only, or in also in NETCONF? NETCONF keeps the same ordering. Martin Bj=F6rklund: perhaps only for application or layer 4. David Reid: why make the change? Martin Bj=F6rklund: allow any order unless there is a good reason for the order to be specified David Harrington: why allow any way? Why not require a specified order? How will it affect interoperability. Andy Bierman: it's harder to enforce the order than to ignore it. Martin Bj=F6rklund: single agent, multiple NETMOD modules, each has top level, why require forced order? J=FCrgen Sch=F6nw=E4lder: most XML servers do not enforce an order, why should NETMOD? Phil Shafer: RPC input? Martin Bj=F6rklund: Andy Bierman pointed out that it only matters at the "content" layer, not the "operation" layer. David Partain: consensus. do not enforce order (10 for, 0 against) -------------------------------------------------------------- Float vs. decimal A number of problems with the floating point datatypes have been identified on the mailing list. Specifically, how are they handled by XPath, and the canonical type. Proposal: Replace the float types with a (fixed point) decimal type. Examples/alternatives shown on slide David Partain: Should we have floats or this other alternative (or both)? Wes Hardaker: If not needed now, why define it now? Integer operations are always faster. Jeff Case liked doing things this way. But datatypes are cheap, so adding it now may be cheap. But if there are no use cases, we could delay it. Andy Bierman: supports having integer type only, did not see a need for floating point. David Partain: question: omit float for now? David Reid: Drop both? 1 for, 8 against. David Partain: consensus. Use decimal64 (10 to 0) Martin Bj=F6rklund - what should canonical form be? David Harrington: is the proposed canonical form standard Xpath? David Partain: vote : consensus (9 to 0): must be one digit on both sides of the decimal point. David Harrington: Is the 3.0 standard XSD/XPath Martin Bj=F6rklund: 3.0 is standard -------------------------------------------------------------- Other open issues? Andy Bierman: canonical version XML applies to Xpath (comment on Xpath discussion). David Reid: list with "foo", augmented with "foo" is clearly illegal. But if augmented with something from another module, this is in a separate module, and so is OK. Martin Bj=F6rklund proposed a rule which is fine. Andy Bierman: My code up to date with draft 04. Ladislav Lhotka: reserve "augment" to augmenting other modules Martin Bj=F6rklund: discussion with use cases. Submodules can augment submodules. Useful for distributed software development. Balazs Lengyel: We have use cases for submodules augmenting other submodules. We need the modularity without the namespaces. Ladislav Lhotka: another comment about augmenting David Reid: why wouldn't you want to augment something in the same module? Ladislav Lhotka: there are simpler ways, can't imagine a use case; becomes unreadable. Martin Bj=F6rklund: submodules are to allow distributed authorship. Ladislav Lhotka: limit augments to something from another module. Balazs Lengyel: we put parts into different submodules and use augment to connect them. Andy Bierman: I sympathize with Ladislav, on the complexity side, but limiting augment didn't change the complexity. David Partain: vote: rough consensus: keep as is +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ IETF 74, NETMOD WG Wednesday, March 25, 2009, 0900 - 1130 Agenda Reviewed =2D----------------------------------------------------------------- YANG Types (revisited) J=FCrgen Sch=F6nw=E4lder suggestion: Remove IEEE types from the documents, doesn't make sense to standardize a small set of types. Dan Romascanu: agrees with J=FCrgen Balazs Lengyel: The MAC address is needed immediately Dan Romascanu: move mac address to another document? Consensus: (unanimous) move mac address to different document and stop working on ieee-types.yang for now. =2D----------------------------------------------------------------- Mapping YANG to DSDL: Ladislav Lhotka Notes on recent publications 00 in Feb, 01 on mar 8, many changes David Partain: How many people have read the draft? note taker missed the count; David Partain: 5-6 Presentation on the draft (see slides) Open Issues: 1) if-feature Martin Bj=F6rklund: Question: couldn't the features be supplied as arguments as an alternative way of doing this? Ladislav Lhotka: put as annocation to the conceptual tree schema. Martin Bj=F6rklund: I thought that would be simplier, it wouldn't generate nodes for features not available. Ladislav Lhotka: it could be done also. Martin Bj=F6rklund: In the first step you specify modules a device implements and you know which features a device implements. David Partain: are you trying to create something that is useful across multiple systems? Ladislav Lhotka: Features will be fixed; same set of input modules that are transformed via the schema. David Partain: input is at second stage rather than the first. 2) deviations Martin Bj=F6rklund: I agree with Ladislav. David Partain: anyone else have opinions? (no response) David Partain: consensus is then called as being what Martin Bj=F6rklund and Ladislav want. Andy Bierman: has questions about naming, but will send mail. 3) instance-identifier type Ladislav Lhotka: options: EXSLT or XPATH 2.0, proposes EXSLT Martin Bj=F6rklund: in xpath you can define your own functions, can you do that in EXSLT? Ladislav Lhotka: yes you can, but it only makes sense if the validator supports the functions. I have to check the EXSLT specification but it is also supported by the libxml tools. 4) Other targets for validation Ladislav Lhotka: certain document types can be validated; are there other types to be validated for the DSDL schemas? Martin Bj=F6rklund: I think edit-config is a missing one in the list and possibly copy-config; copy config is difficult because there is no standard way of what the copy-config would be so unless we define one. It will be hard to define a schema for it. Ladislav Lhotka: discusses biggest thing to validate is output from get-reply. Phil Shafer: when you say data store I think configuration data. Ladislav Lhotka: get-config means config data, get means all. David Partain: anyone else want something other than edit-config/copy-config? (silence) Ladislav Lhotka: change in order of elements in data from Monday's meeting needs to be added to draft. Next version of draft will be complete and resolved all open issues. Martin Bj=F6rklund: require-instance and instance identifier missing. David Partain: you're writing and implementing at the same time; excellent! Your plan is getting a new rev during April? Ladislav Lhotka: yes David Partain: plenty of time for people to read by Stockholm. Perhaps we can even do a last-call about then. Andy Bierman: how are you doing naming? you're putting module name as a type name or element name. Is that really needed? Ladislav Lhotka: yes. multiple reasons talked about (including "you can have clashes between different modules") Andy Bierman: is that why there is a top container and a container for notifications? Why all the extra containers? do you just like that better? Ladislav Lhotka: It's just easy to translate between schemas and is easier to implement in the tool. Andy Bierman: what about local typedefs embedded inside lists, etc. Ladislav Lhotka: these types defs have both the module name and the name of the container nodes. Andy Bierman: keep registry of names used and then add a new one (like a .1) to deal with conflicts Ladislav Lhotka: that could be used too. =2D----------------------------------------------------------------- netmod-usage-guidelines: Andy Bierman Documents guidelines for writing YANG modules intended for IETF usage. Proposing writing a YANG usage guidelines to improve quality of YANG documents, and result in quicker passage of YANG modules. To avoid issues at "Last Call". David Partain: How many have read it? 7-8 Minor issues: the language is not constrained in places it may be helpful for tool support (e.g., identifier length). Andy Bierman: Options: 1) do nothing 2) published as a BCP Dan Romascanu: what "Last Call" issues are you thinking about when dealing with issues raised? Andy Bierman: there are lots of things (stated examples) Dan Romascanu: I'm very much in favor of this document. Suggest start by doing as Informational. Come back after 1-2 years of operational experience and revise it as a BCP. Andy Bierman: my approach was to include guidelines that had strong consensus. Dan Romascanu: we may get to the point to revise them because we may learn things down the road, certainly. Andy Bierman: we have experience to draw on from SMIv2 that will make some of these back by experience now. Phil Shafer: is the 63 chars really an issue? Should that be solved in YANG, or is it ietf specific? Andy Bierman: you run the risk that the YANG module won't be accepted by the tools. YANG says that 63 must be accepted, which means more can be dropped. Phil Shafer: but what about vendor module. Let's fix in the YANG module. Andy Bierman: I want a fixed length identifier. Phil Shafer: I'd rather fix it in YANG. Andy Bierman: my fix is that it must be 63 chars or less. Martin Bj=F6rklund: is your proposal to add to the main doc? Andy Bierman: I don't have a problem with YANG docs; I want this to deal with interop with the IETF documents not globally. Phil Shafer: does there need to be a bound? Andy Bierman: yes, so tools can be written that will work. Phil Shafer: what's the issue? Andy Bierman: buffering and memory. Wes Hardaker: tries to clarify discussion and agrees with Andy. Language should not be constrained, but should IETF have more tight restrictions within IETF for all tool writers. Phil Shafer: would this be something willing to do in an extension (eg: strict: true). Andy Bierman: I would rather not; I'd rather have a set that defines what the lower bound is. Phil Shafer: What about adding a YANG extension to add restrictions? David Partain: first step is to decide if we're going to have the rules, standardize the rules. Sharon Chisholm: (on jabber) I'm voting not to bake into YANG a length restriction and I don't like Phil's suggestion. Whether we do an IETF-module practice of shorter length that we can change in 5 years is different. I don't mind that. The extension just seemed to complicated than we needed. Andy Bierman: to my knowledge the 63 char limit is SMIv2 isn't a problem. David Partain: how many think we should work on this document? *count:* many hands for yes, none for no. David Partain: How do we do this? recharter? Andy Bierman: what is the IESG going to do with a 50 page YANG document? Skip it? Create a yang-doctors group? Dan Romascanu: probably create a experts group Dan Romascanu: To issue of recharter: I'm not sure you need to recharter, especially if you go for Informational. David Partain: should this be a WG document straight away: *count:* many hands for yes, none for no We'll talk to Dan Romascanu about how to do it (informational vs ...) Andy will continue editing; anyone else can offer to help. Martin Bj=F6rklund: There is a section called YANG registry section, do you want to keep that? Andy Bierman: no, I'm going to drop it. The top level module needs a RFC number for each revision. Martin Bj=F6rklund: does the top need to be published in an RFC or can it be IANA contained? Andy Bierman: no, conformance is tied to an RFC number not to a dynamic IANA registry. =2D----------------------------------------------------------------- netconf-module-00 (Editor's note: This discussion was started in a previous NETCONF WG meeting, but was continued with the consent of both NETCONF WG chairs.) David Partain: Do we want to consider talking about YANG NETCONF module? Andy ran out of time yesterday, can we consider discussing it now? NETCONF Chairs: Yes, that's fine. David Partain: last slide of NETCONF agenda. (http://www.ietf.org/proceedings/09mar/slides/netconf-6.pdf) Andy Bierman: surprised to see consensus for normative YANG going forward. Phil Shafer: I was suggesting adding an extension that says "this element supports these two attributes" and that's the meaning of this extension statement. YANG:this-container-supports-these-two-attributes:true Andy Bierman: I only want to support it for RPC elements and not in the data at all. So that would be acceptable to me. David Partain: 3 options: use XSD, use YANG with attributes (change YANG to support XML attributes), use YANG with an extension for 2 specific attributes. Bert Wijnen: would there be a 4th option to remove it from the base spec? Andy Bierman: you're the code chair, it might open the box of other non-compatible changes. I've got a ton of them. Bert Wijnen: how seriously would it get existing implementations in trouble? Martin Bj=F6rklund: I'd rather not change it because it would affect existing implementations. Balazs Lengyel: we have a statement that any other elements can be added to an attribute. Andy Bierman: the proposal is this would only be used for Balazs Lengyel: But we keep the XSD for the RPC layer? Andy Bierman: that needs to be looked at, what happens to the XSD? Mehmet Ersue: I think we need to keep the attributes in NETCONF and we can not skip them. David Partain: what are the options we're taking to the mailing list? Ladislav Lhotka: I think the schema can't be used by any tools. It will claim a number of things are valid that aren't (gives examples). Some of the problems can't be solved in XSD. (RelaxNG is better) Martin Bj=F6rklund: if we do YANG, we have a standard mapping to DSDL so we get DSDL as well. Ladislav Lhotka: yes of course. Long explanation followed by I don't think it's appropriate to use YANG for David Partain: unless we have an extension for the relevant attributes. Martin Bj=F6rklund: it is appropriate to use for operations layer. Ladislav Lhotka: I see it as a natural way of using NETCONF modeling language for definition for NETCONF base module. that's better than introducing a third modeling language. Andy Bierman: if we don't have a YANG module, we can't augment it with YANG. [stuff missed] David Partain: someone needs to write down what the options are and send to list. Bert Wijnen: Yes that's what we want; Andy will do it. If we want to use it for RPC layer and not operations layer then make that clear. Make clear that we will not do YANG for RPC layer. Andy Bierman summary: if RPC element is in YANG module then all elements are mirrored back. For the agent it's not used at all. Having a particular attribute called msgid in the PDU is a CLR. Martin Bj=F6rklund: I really think we should not do the RPC layer in the YANG module. Andy Bierman: You're right. I do that with an extension. it'll be removed in the next version and add an extension for the filter-element-thing. Phil Shafer: what's left in the XSD? barely anything? (yep) David Partain: do we want to do choices now? Phil Shafer: YANG will have all the guts. XSD or RelaxNG will just have an element that will contain everything. can we just write it as text? The XSD is so small and has no value. Martin Bj=F6rklund: it's easy to write and has a small value, so do it. Ladislav Lhotka: XSD is generic but RelaxNG can be much more helpful. Sharon Chisholm (jabber): considering this is a normative update, then keeping this as an XSD will help us determine what has changed. Phil Shafer: one of the things that has changed has is that we have YANG. Martin Bj=F6rklund: we're not doing it for the fun of it, we're doing it because the original XSD has problems. Phil Shafer: one of the problems with XSD is that we didn't know what it did. I have an issue with RelaxNG as well, I couldn't tell if it was right or not? Bert Wijnen: should we consider RelaxNG as a 4th or 5th option? Only two hands. Mehmet Ersue: we should think of future NETCONF modules that are trying to augment. Phil Shafer: which means that YANG has to own it. David Partain: how many think YANG has to be normative, or how many thing XSD has to be normative: YANG: 10 XSD: 1 Andy Bierman: we need to think in a new way. We need to understand that people pull these documents out of documents and use them in applications in new ways. Phil Shafer: will the YANG module be part of 4741bis? Andy Bierman and Martin Bj=F6rklund: yes =2D----------------------------------------------------------------- Plans after this IETF? David Partain: Are we ready for WG last call on YANG/YANG data types? Seems things are stable and believe we'll do a WG last call. Martin Bj=F6rklund will publish a -05 in the next few weeks. J=FCrgen Sch=F6nw=E4lder will publish types documents as well. Usage guidelines will be added as a WG document. David Partain: do people use XSD produced from YANG? Two tools do that, should we have a document that defines that? Andy Bierman: Martin Bj=F6rklund and I have been converging on a similar solution. David Partain: is there a chance of people actually writing that down? Andy Bierman: if we have enough people to work on it, it would be valuable. I can't do it myself (there is a lot to write down). Ladislav Lhotka: also option of using auto-translation of RelaxNG to XSD, which would save cycles for this work. It would be valuable for customers that want to do validation. David Partain: the mapping isn't standardized but there are tools that are industry standardized. Ladislav Lhotka: there are WWW tools that use RelaxNG Martin Bj=F6rklund: I'd prefer that as well. Andy Bierman: the use case would be xmlspy that would construct the PDU contents based on the schema? but xmlspy already uses RelaxNG, so... Martin Bj=F6rklund: most people that want to do validation don't care which they have. The DSDL schema is much more precise than the XSD. David Partain: so we don't need to do this (audience fails to say otherwise). =2D----------------------------------------------------------------- Open Microphone: SMIv2 to YANG David Reid: previous agenda had it on it. can we talk about it? David Partain: yes, but J=FCrgen Sch=F6nw=E4lder isn't here. Andy Bierman: I read the draft and really support it as at least an informational RFC. David Partain: how many have read it? *Count: 8-people* David Partain: how many think we should consider publishing it and work on it *Count: 10-people yes, 0-no* David Partain: anything for today? David Reid: there are a number of issues, maybe the mailing list would be better? David Reid: one particular topic of interest: In mapping a MIB table, he translates the entry to a list and drops the table (the "extra" container). What I do is translate the list and put the list in a container. Andy Bierman: we should keep the "extra" container due to least astonishment. David Reid: I don't know of reasons beyond that, but there could be more. Ladislav Lhotka: I think list items should always be in a container and not loose. David Partain: David Reid, please send comments to the list. David Reid: what I do is similar so there aren't huge issues. =46loats revisited David Perkins: wants floats discussed Wes Hardaker: tries to summarize why David Perkins wants floats (+/- inf and NaN). Andy Bierman: doesn't like +/- inf and would rather return an error anyway. David Partain: bring it up on the list at this point after the minutes are posted. Meeting concluded =2D----------------------------------------------------- From david.partain@ericsson.com Thu Apr 16 07:18:54 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F06923A6F30 for ; Thu, 16 Apr 2009 07:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.524 X-Spam-Level: X-Spam-Status: No, score=-5.524 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0l-yMD4i6ha for ; Thu, 16 Apr 2009 07:18:54 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 2A5033A6D0D for ; Thu, 16 Apr 2009 07:18:54 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 79CF523374 for ; Thu, 16 Apr 2009 16:19:38 +0200 (CEST) X-AuditID: c1b4fb3e-ac01fbb0000024d5-4a-49e733b929e2 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5850E23C14 for ; Thu, 16 Apr 2009 15:33:45 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 15:33:44 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 15:33:44 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Thu, 16 Apr 2009 15:33:43 +0200 User-Agent: KMail/1.9.10 References: <49D17E45.7010907@mesh.ad.jp> <20090415093702.GC4045@elstar.local> <20090415.121358.170140203.mbj@tail-f.com> In-Reply-To: <20090415.121358.170140203.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904161533.44043.david.partain@ericsson.com> X-OriginalArrivalTime: 16 Apr 2009 13:33:44.0310 (UTC) FILETIME=[F6957960:01C9BE97] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] ipv6 address representation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 14:18:55 -0000 On Wednesday 15 April 2009 12.13.58 Martin Bjorklund wrote: > Hi, > > Juergen Schoenwaelder wrote: > > I personally believe we should adapt the :: compressed format as the > > canonical format for IPv6 addresses (and prefixes). But before I make > > the edits, I like to see more support for this change from the WG. So > > please tell us "I prefer the proposed compressed format" or "I prefer > > the uncompressed format". > > I prefer the proposed compressed format. As non-chair... +1 David From david.partain@ericsson.com Thu Apr 16 23:41:23 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2663A695C for ; Thu, 16 Apr 2009 23:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.59 X-Spam-Level: X-Spam-Status: No, score=-5.59 tagged_above=-999 required=5 tests=[AWL=0.659, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJBWyBGU4o8P for ; Thu, 16 Apr 2009 23:41:22 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id B1E543A67F3 for ; Thu, 16 Apr 2009 23:41:22 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BF67222051 for ; Fri, 17 Apr 2009 08:42:33 +0200 (CEST) X-AuditID: c1b4fb3e-ae824bb0000024d5-6b-49e8228adc64 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AF9BD21290 for ; Fri, 17 Apr 2009 08:32:42 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 08:31:08 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 08:31:08 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Fri, 17 Apr 2009 08:31:08 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200904170831.08159.david.partain@ericsson.com> X-OriginalArrivalTime: 17 Apr 2009 06:31:08.0092 (UTC) FILETIME=[178367C0:01C9BF26] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Consensus call (YANG types) - drop ieee-types.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 06:41:23 -0000 Hi, J=FCrgen Sch=F6nw=E4lder suggested that we remove IEEE types from the documents since it doesn't make sense to standardize only a small set of types. At the recent IETF, rough consensus was reached to move MAC address to different document and stop working on ieee-types.yang for now. If you disagree with this consensus, speak now or forever hold your peace. D^2 From david.partain@ericsson.com Thu Apr 16 23:41:38 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47D8B3A695C for ; Thu, 16 Apr 2009 23:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.645 X-Spam-Level: X-Spam-Status: No, score=-5.645 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m88po7koy65q for ; Thu, 16 Apr 2009 23:41:37 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 6F0743A67F3 for ; Thu, 16 Apr 2009 23:41:37 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0FD4C21109 for ; Fri, 17 Apr 2009 08:42:49 +0200 (CEST) X-AuditID: c1b4fb3e-ac01fbb0000024d5-b4-49e8229e3c60 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2DECC21473 for ; Fri, 17 Apr 2009 08:33:02 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 08:32:31 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 08:32:31 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Fri, 17 Apr 2009 08:32:31 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904170832.31438.david.partain@ericsson.com> X-OriginalArrivalTime: 17 Apr 2009 06:32:31.0230 (UTC) FILETIME=[491141E0:01C9BF26] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Consensus call (YANG types) - Canonical XPath X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 06:41:38 -0000 Do we need a definition of canonical XPath? At the recent IETF, rough consensus was reached to look for an existing canonical XPATH definition and reuse it if such exists. Otherwise, we do nothing. Put the canonical form (if found) in a separate data type. If you disagree with this consensus, speak now or forever hold your peace. D^2 From david.partain@ericsson.com Thu Apr 16 23:42:12 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB0783A6884 for ; Thu, 16 Apr 2009 23:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.692 X-Spam-Level: X-Spam-Status: No, score=-5.692 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtTbWjrf4X2z for ; Thu, 16 Apr 2009 23:42:12 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 1FB2D3A67F3 for ; Thu, 16 Apr 2009 23:42:12 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C4EA0210EF for ; Fri, 17 Apr 2009 08:43:21 +0200 (CEST) X-AuditID: c1b4fb3e-ac820bb0000024d5-17-49e822f2a262 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 51510212CA for ; Fri, 17 Apr 2009 08:34:26 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 08:33:46 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 08:33:45 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Fri, 17 Apr 2009 08:33:45 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904170833.45560.david.partain@ericsson.com> X-OriginalArrivalTime: 17 Apr 2009 06:33:45.0945 (UTC) FILETIME=[7599DC90:01C9BF26] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Consensus call (YANG types) - Add VLAN types? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 06:42:13 -0000 Hi, It has been suggested to add more VLAN related typedefs, but no concrete suggestions has been made so far. At the recent IETF, rough consensus was reached NOT to add any such types at this time. If you disagree with this consensus, speak now or forever hold your peace. D^2 From david.partain@ericsson.com Thu Apr 16 23:48:46 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163ED3A67F8 for ; Thu, 16 Apr 2009 23:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.731 X-Spam-Level: X-Spam-Status: No, score=-5.731 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5ogbFp8BORG for ; Thu, 16 Apr 2009 23:48:45 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 038683A67D1 for ; Thu, 16 Apr 2009 23:48:44 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CCE5B22477 for ; Fri, 17 Apr 2009 08:49:04 +0200 (CEST) X-AuditID: c1b4fb3e-ac820bb0000024d5-ad-49e823e0bfd9 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 54A5621A60 for ; Fri, 17 Apr 2009 08:38:24 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 08:36:43 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 08:36:43 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Fri, 17 Apr 2009 08:36:43 +0200 User-Agent: KMail/1.9.10 References: <49D17E45.7010907@mesh.ad.jp> <20090415093702.GC4045@elstar.local> In-Reply-To: <20090415093702.GC4045@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904170836.43233.david.partain@ericsson.com> X-OriginalArrivalTime: 17 Apr 2009 06:36:43.0146 (UTC) FILETIME=[DF3896A0:01C9BF26] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] ipv6 address representation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 06:48:46 -0000 On Wednesday 15 April 2009 11.37.02 Juergen Schoenwaelder wrote: > On Tue, Mar 31, 2009 at 04:21:57AM +0200, Seiichi Kawamura wrote: > > From what I've experienced, the "preferred way" noted in RFC4291 > > sec 2.2 item 1 is rarely used. BTW, I'm a network > > operator at an ISP/Data Center. > > I like to followup on this and nail down what should be in the -03 > version of the yang types document. The proposal on the table is to go > back to what we had in an earlier version of the document as the > canonical format for IPv6 addresses: > > The :: substitution must be applied to the longest sequence of > all-zero 16-bit chunks in an IPv6 address. If there is a tie, the > first sequence of all-zero 16-bit chunks is replaced by ::. Single > all-zero 16-bit chunks are not compressed. The normalized format > uses lower-case characters and leading zeros are not allowed. > > This is inline with [1] and with a large fraction of inet_ntop() > implementations. While the proposed format is not the preferred format > spelled out in RFC 4291, it seems to be the most widely deployed > format. Furthermore, operators have given reasons why this is their > preferred format [1]. > > I personally believe we should adapt the :: compressed format as the > canonical format for IPv6 addresses (and prefixes). But before I make > the edits, I like to see more support for this change from the WG. So > please tell us "I prefer the proposed compressed format" or "I prefer > the uncompressed format". > > /js > > [1] draft-kawamura-ipv6-text-representation-00.txt Hi all, So far, no one has said "I prefer the uncompressed format" as far as I can see. Unless someone hollers fast, I personally think we have consensus. Cheers, David From david.partain@ericsson.com Fri Apr 17 00:03:59 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BCAC3A6941 for ; Fri, 17 Apr 2009 00:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.766 X-Spam-Level: X-Spam-Status: No, score=-5.766 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WXH4F+-UWPk for ; Fri, 17 Apr 2009 00:03:58 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 7CA7E3A67F3 for ; Fri, 17 Apr 2009 00:03:58 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8F6E1214C1 for ; Fri, 17 Apr 2009 08:42:35 +0200 (CEST) X-AuditID: c1b4fb3e-ac820bb0000024d5-77-49e8228c4453 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EB84A212A0 for ; Fri, 17 Apr 2009 08:32:44 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 08:31:53 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 08:31:53 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Fri, 17 Apr 2009 08:31:53 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904170831.54057.david.partain@ericsson.com> X-OriginalArrivalTime: 17 Apr 2009 06:31:53.0887 (UTC) FILETIME=[32CF2AF0:01C9BF26] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 07:03:59 -0000 Hi all, Should the 'xpath' datatype be renamed to 'xpath1', 'xpath1-0' or 'xpath1.0' to accommodate definitions of other XPath versions in the future? At the recent IETF, rough consensus was reached to rename the type xpath1.0. If you disagree with this consensus, speak now or forever hold your peace. D^2 From david.partain@ericsson.com Fri Apr 17 00:06:07 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0B193A68AA for ; Fri, 17 Apr 2009 00:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.796 X-Spam-Level: X-Spam-Status: No, score=-5.796 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcTzyBfdroEO for ; Fri, 17 Apr 2009 00:06:07 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D43613A6884 for ; Fri, 17 Apr 2009 00:06:06 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A88E62155C for ; Fri, 17 Apr 2009 08:43:24 +0200 (CEST) X-AuditID: c1b4fb3e-ac820bb0000024d5-1e-49e822f46195 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7DB58222B4 for ; Fri, 17 Apr 2009 08:34:28 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 08:33:08 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 08:33:08 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Fri, 17 Apr 2009 08:33:08 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904170833.08391.david.partain@ericsson.com> X-OriginalArrivalTime: 17 Apr 2009 06:33:08.0182 (UTC) FILETIME=[5F17AF60:01C9BF26] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Consensus call (YANG types) - Add port type X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 07:06:07 -0000 Hi, Suggestion to add a port list type. Use a comma separated list of port ranges: e.g. 1-5,8,10-22. Ranges may not overlap and may not be consecutive. At the recent IETF, rough consensus was reached NOT to add this type at this time. If you disagree with this consensus, speak now or forever hold your peace. D^2 From lhotka@cesnet.cz Fri Apr 17 00:46:32 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8FC33A6821 for ; Fri, 17 Apr 2009 00:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.226 X-Spam-Level: X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_05=-1.11, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEQqPixkl7RA for ; Fri, 17 Apr 2009 00:46:32 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 045CF3A6809 for ; Fri, 17 Apr 2009 00:46:32 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 9ADA5D800BD for ; Fri, 17 Apr 2009 09:47:38 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <200904170832.31438.david.partain@ericsson.com> References: <200904170832.31438.david.partain@ericsson.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 17 Apr 2009 09:47:37 +0200 Message-Id: <1239954457.6454.6.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] Consensus call (YANG types) - Canonical XPath X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 07:46:33 -0000 David Partain píše v Pá 17. 04. 2009 v 08:32 +0200: > Do we need a definition of canonical XPath? > > At the recent IETF, rough consensus was reached to look for an > existing canonical XPATH definition and reuse it if such exists. > Otherwise, we do nothing. Put the canonical form (if found) in a > separate data type. There is no such thing, at least not in the sense we need - see Martin's message from 24 March. Lada > > If you disagree with this consensus, speak now or forever hold > your peace. > > D^2 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From david.partain@ericsson.com Fri Apr 17 01:49:45 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5AE028C141 for ; Fri, 17 Apr 2009 01:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.823 X-Spam-Level: X-Spam-Status: No, score=-5.823 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkYEpAf2m5Cq for ; Fri, 17 Apr 2009 01:49:45 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 08C4128C0F6 for ; Fri, 17 Apr 2009 01:49:44 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 758D223074 for ; Fri, 17 Apr 2009 10:50:56 +0200 (CEST) X-AuditID: c1b4fb3e-af826bb0000024d5-c0-49e8379dfd35 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C1468211C3 for ; Fri, 17 Apr 2009 10:02:37 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 10:02:36 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 10:02:36 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Fri, 17 Apr 2009 10:02:35 +0200 User-Agent: KMail/1.9.10 References: <200904170832.31438.david.partain@ericsson.com> <1239954457.6454.6.camel@missotis> In-Reply-To: <1239954457.6454.6.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200904171002.36062.david.partain@ericsson.com> X-OriginalArrivalTime: 17 Apr 2009 08:02:36.0473 (UTC) FILETIME=[DED7E290:01C9BF32] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] Consensus call (YANG types) - Canonical XPath X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 08:49:45 -0000 On Friday 17 April 2009 09.47.37 Ladislav Lhotka wrote: > David Partain p=C3=AD=C5=A1e v P=C3=A1 17. 04. 2009 v 08:32 +0200: > > Do we need a definition of canonical XPath? > > > > At the recent IETF, rough consensus was reached to look for an > > existing canonical XPATH definition and reuse it if such exists. > > Otherwise, we do nothing. Put the canonical form (if found) in a > > separate data type. > > There is no such thing, at least not in the sense we need - see Martin's > message from 24 March. Hi, Yep, I know. For those who need to look at it, see: http://www.ietf.org/mail-archive/web/netmod/current/msg02289.html This call simply reflects the need to confirm consensus on the mailing=20 list :-) Cheers, David From phil@juniper.net Fri Apr 17 06:48:10 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F0EA3A6837 for ; Fri, 17 Apr 2009 06:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylnUiJLW1Ao8 for ; Fri, 17 Apr 2009 06:48:09 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id CADEA3A6941 for ; Fri, 17 Apr 2009 06:48:09 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSeiI4/xIFfp/2MGQjlQbOk7LKdjGot/M@postini.com; Fri, 17 Apr 2009 06:49:23 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Fri, 17 Apr 2009 06:47:59 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 06:47:59 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 06:47:59 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 06:47:58 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n3HDlvM90819; Fri, 17 Apr 2009 06:47:57 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n3HDeVB8089915; Fri, 17 Apr 2009 13:40:32 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904171340.n3HDeVB8089915@idle.juniper.net> To: David Partain In-Reply-To: <200904170831.54057.david.partain@ericsson.com> Date: Fri, 17 Apr 2009 09:40:31 -0400 From: Phil Shafer X-OriginalArrivalTime: 17 Apr 2009 13:47:58.0093 (UTC) FILETIME=[1DE42BD0:01C9BF63] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 13:48:10 -0000 David Partain writes: >At the recent IETF, rough consensus was reached to rename the >type xpath1.0. I am not hung up on this, but it sure seems odd that this is the only place we call out the "1.0"-ness of our xpaths. We use xpath-1.0 for all sorts of YANG constructs. Would we be better served by calling this "xpath" and adding "2.0" suffix when and if we ever move to 2.0? We'll need "must2.0" and "when2.0", etc, at the time also. Thanks, Phil From andy@netconfcentral.com Fri Apr 17 08:16:48 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1429C3A6DDA for ; Fri, 17 Apr 2009 08:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaCW2+EalR2T for ; Fri, 17 Apr 2009 08:16:47 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 707B93A6DFD for ; Fri, 17 Apr 2009 08:16:47 -0700 (PDT) Received: (qmail 1193 invoked from network); 17 Apr 2009 15:18:01 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.236 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 17 Apr 2009 15:18:00 -0000 X-YMail-OSG: 2hjK7hgVM1kgEyuD.8svwjKufwVpLWoYEc2u8Wxv8QX1zK0FxEoRtpTmG0.hDCVzEmKjcTmTgA7sCrxKpfJYvahGJDTCZ72a4vJJWGg8T1r9ouAGjr_GiTppJ6XsLM5gSSKuamsYADIMyeFgQVR_EXVNbm7lZz1DEocn2N4UpZP6xOrY6ABgs2iGIelBjxwka4u.0VYmMi0w0ofCjunnGDz0zh6WyN8AlY8EcTk21bDAcmDKi7bbu.GmVPLz4bQ6_IvsspTF6lEJcKlf X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E89DA6.30106@netconfcentral.com> Date: Fri, 17 Apr 2009 08:17:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200904171340.n3HDeVB8089915@idle.juniper.net> In-Reply-To: <200904171340.n3HDeVB8089915@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 15:16:48 -0000 Phil Shafer wrote: > David Partain writes: >> At the recent IETF, rough consensus was reached to rename the >> type xpath1.0. > > I am not hung up on this, but it sure seems odd that this is > the only place we call out the "1.0"-ness of our xpaths. We > use xpath-1.0 for all sorts of YANG constructs. Would we > be better served by calling this "xpath" and adding "2.0" > suffix when and if we ever move to 2.0? We'll need "must2.0" > and "when2.0", etc, at the time also. > I agree. I also prefer not to encourage use of the '.' char in identifiers. > Thanks, > Phil Andy From j.schoenwaelder@jacobs-university.de Fri Apr 17 08:26:18 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A29D28C0D8 for ; Fri, 17 Apr 2009 08:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SQt4N9Ao6Yg for ; Fri, 17 Apr 2009 08:26:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 566A33A6EAA for ; Fri, 17 Apr 2009 08:26:17 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A4991C018D; Fri, 17 Apr 2009 17:27:30 +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 UrMZtUyupTsB; Fri, 17 Apr 2009 17:27:29 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 34895C0181; Fri, 17 Apr 2009 17:27:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3ABEFAABA49; Fri, 17 Apr 2009 17:27:10 +0200 (CEST) Date: Fri, 17 Apr 2009 17:27:10 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090417152710.GB18345@elstar.local> Mail-Followup-To: Phil Shafer , David Partain , "netmod@ietf.org" References: <200904170831.54057.david.partain@ericsson.com> <200904171340.n3HDeVB8089915@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904171340.n3HDeVB8089915@idle.juniper.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 17 Apr 2009 15:26:18 -0000 On Fri, Apr 17, 2009 at 03:40:31PM +0200, Phil Shafer wrote: > David Partain writes: > >At the recent IETF, rough consensus was reached to rename the > >type xpath1.0. > > I am not hung up on this, but it sure seems odd that this is > the only place we call out the "1.0"-ness of our xpaths. We > use xpath-1.0 for all sorts of YANG constructs. Would we > be better served by calling this "xpath" and adding "2.0" > suffix when and if we ever move to 2.0? We'll need "must2.0" > and "when2.0", etc, at the time also. One thing to keep in mind is that YANG data models will be written for non-NETCONF things and the need for an xpath 2.0 type might arise even if NETCONF never ever uses xpath 2.0 itself. I am not opposing to call the typedef just xpath (like Andy I dislike the dots in identifiers) - I just have a problem with the argument you are bringing up. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Fri Apr 17 08:51:17 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A6CD3A6D6D for ; Fri, 17 Apr 2009 08:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.962 X-Spam-Level: X-Spam-Status: No, score=-0.962 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSroY-B2eoSM for ; Fri, 17 Apr 2009 08:51:16 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B665E3A6CFA for ; Fri, 17 Apr 2009 08:51:16 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 0D147D800BD for ; Fri, 17 Apr 2009 17:52:30 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20090417152710.GB18345@elstar.local> References: <200904170831.54057.david.partain@ericsson.com> <200904171340.n3HDeVB8089915@idle.juniper.net> <20090417152710.GB18345@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 17 Apr 2009 17:52:30 +0200 Message-Id: <1239983550.6454.52.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 15:51:17 -0000 Juergen Schoenwaelder píše v Pá 17. 04. 2009 v 17:27 +0200: > On Fri, Apr 17, 2009 at 03:40:31PM +0200, Phil Shafer wrote: > > David Partain writes: > > >At the recent IETF, rough consensus was reached to rename the > > >type xpath1.0. > > > > I am not hung up on this, but it sure seems odd that this is > > the only place we call out the "1.0"-ness of our xpaths. We > > use xpath-1.0 for all sorts of YANG constructs. Would we > > be better served by calling this "xpath" and adding "2.0" > > suffix when and if we ever move to 2.0? We'll need "must2.0" > > and "when2.0", etc, at the time also. > > One thing to keep in mind is that YANG data models will be written for > non-NETCONF things and the need for an xpath 2.0 type might arise even > if NETCONF never ever uses xpath 2.0 itself. An option would be to use "xpath" for the type name and specify version in "version" substatement, for example leaf foo { type xpath { version 2.0; } } Lada > > I am not opposing to call the typedef just xpath (like Andy I dislike > the dots in identifiers) - I just have a problem with the argument you > are bringing up. ;-) > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Fri Apr 17 08:55:34 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 269963A69FF for ; Fri, 17 Apr 2009 08:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFI9HDxu76OI for ; Fri, 17 Apr 2009 08:55:33 -0700 (PDT) Received: from n66.bullet.mail.sp1.yahoo.com (n66.bullet.mail.sp1.yahoo.com [98.136.44.50]) by core3.amsl.com (Postfix) with SMTP id 7276B3A6DDA for ; Fri, 17 Apr 2009 08:55:33 -0700 (PDT) Received: from [216.252.122.216] by n66.bullet.mail.sp1.yahoo.com with NNFMP; 17 Apr 2009 15:56:47 -0000 Received: from [68.142.194.243] by t1.bullet.sp1.yahoo.com with NNFMP; 17 Apr 2009 15:56:47 -0000 Received: from [68.142.201.253] by t1.bullet.mud.yahoo.com with NNFMP; 17 Apr 2009 15:56:47 -0000 Received: from [127.0.0.1] by omp414.mail.mud.yahoo.com with NNFMP; 17 Apr 2009 15:56:47 -0000 X-Yahoo-Newman-Id: 214406.28222.bm@omp414.mail.mud.yahoo.com Received: (qmail 80837 invoked from network); 17 Apr 2009 15:56:46 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.236 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 17 Apr 2009 15:56:46 -0000 X-YMail-OSG: CXVqZDgVM1ln_2IMRBuwdOlUTCkx0TEtQei0A_FUi8ZIuevncAhArT.EA9PfuprfOzpxT3ocLhSJ4eFyeEEoC90fz8HsoOAT9RFLQNGYZBlOAKpwBiDH6EsLlYZZlD5zb9bSDVgu.yRQFjNdyX0PUwY3dQSVSPAfuzxfKorcFhFukyYda_b_5V2uBCugV1z.66GNyYEaf09z3AyRGTDhHlfN7M_TrbNhfGCceAz2VzW5DisIe03FDGA7tgzM9EB5aNJeubaEtX2Z.OIa X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E8A6BD.6040409@netconfcentral.com> Date: Fri, 17 Apr 2009 08:56:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer , David Partain , "netmod@ietf.org" References: <200904170831.54057.david.partain@ericsson.com> <200904171340.n3HDeVB8089915@idle.juniper.net> <20090417152710.GB18345@elstar.local> In-Reply-To: <20090417152710.GB18345@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 15:55:34 -0000 Juergen Schoenwaelder wrote: > On Fri, Apr 17, 2009 at 03:40:31PM +0200, Phil Shafer wrote: >> David Partain writes: >>> At the recent IETF, rough consensus was reached to rename the >>> type xpath1.0. >> I am not hung up on this, but it sure seems odd that this is >> the only place we call out the "1.0"-ness of our xpaths. We >> use xpath-1.0 for all sorts of YANG constructs. Would we >> be better served by calling this "xpath" and adding "2.0" >> suffix when and if we ever move to 2.0? We'll need "must2.0" >> and "when2.0", etc, at the time also. > > One thing to keep in mind is that YANG data models will be written for > non-NETCONF things and the need for an xpath 2.0 type might arise even > if NETCONF never ever uses xpath 2.0 itself. > > I am not opposing to call the typedef just xpath (like Andy I dislike > the dots in identifiers) - I just have a problem with the argument you > are bringing up. ;-) > The main issue is the one Phil raised. We aren't versioning all the little pieces of YANG 1.0. If YANG needs to be written for non-NETCONF things then we should read about it in the NETMOD arch draft. If we ever add an :xpath2 capability to NETCONF, then an xpath2 data type can be added at the same time. > /js > Andy From j.schoenwaelder@jacobs-university.de Fri Apr 17 09:26:11 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 649A53A6962 for ; Fri, 17 Apr 2009 09:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMyXDhTsIZNr for ; Fri, 17 Apr 2009 09:26:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 672E83A6DCF for ; Fri, 17 Apr 2009 09:26:10 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8DA00C01D2; Fri, 17 Apr 2009 18:27:23 +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 NPMHBZYir0pq; Fri, 17 Apr 2009 18:27:22 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F571C01D1; Fri, 17 Apr 2009 18:27:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 98C73AABAFF; Fri, 17 Apr 2009 18:27:04 +0200 (CEST) Date: Fri, 17 Apr 2009 18:27:04 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090417162704.GC18345@elstar.local> Mail-Followup-To: Ladislav Lhotka , "netmod@ietf.org" References: <200904170831.54057.david.partain@ericsson.com> <200904171340.n3HDeVB8089915@idle.juniper.net> <20090417152710.GB18345@elstar.local> <1239983550.6454.52.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1239983550.6454.52.camel@missotis> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 17 Apr 2009 16:26:11 -0000 On Fri, Apr 17, 2009 at 05:52:30PM +0200, Ladislav Lhotka wrote: > An option would be to use "xpath" for the type name and specify version > in "version" substatement, for example > > leaf foo { > type xpath { > version 2.0; > } > } Are you serious? Adding another complexity dimension to our already versioned includes?? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Apr 17 09:32:55 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23D1C3A6A60 for ; Fri, 17 Apr 2009 09:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRGvmwzlbriK for ; Fri, 17 Apr 2009 09:32:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EB25E3A6962 for ; Fri, 17 Apr 2009 09:32:53 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 616C8C01DA; Fri, 17 Apr 2009 18:34:07 +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 a3oGdR8uYd9O; Fri, 17 Apr 2009 18:34:06 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB9ADC01D8; Fri, 17 Apr 2009 18:34:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 84879AABB46; Fri, 17 Apr 2009 18:33:46 +0200 (CEST) Date: Fri, 17 Apr 2009 18:33:46 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090417163346.GD18345@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , David Partain , "netmod@ietf.org" References: <200904170831.54057.david.partain@ericsson.com> <200904171340.n3HDeVB8089915@idle.juniper.net> <20090417152710.GB18345@elstar.local> <49E8A6BD.6040409@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49E8A6BD.6040409@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 17 Apr 2009 16:32:55 -0000 On Fri, Apr 17, 2009 at 05:56:45PM +0200, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Fri, Apr 17, 2009 at 03:40:31PM +0200, Phil Shafer wrote: > >> David Partain writes: > >>> At the recent IETF, rough consensus was reached to rename the > >>> type xpath1.0. > >> I am not hung up on this, but it sure seems odd that this is > >> the only place we call out the "1.0"-ness of our xpaths. We > >> use xpath-1.0 for all sorts of YANG constructs. Would we > >> be better served by calling this "xpath" and adding "2.0" > >> suffix when and if we ever move to 2.0? We'll need "must2.0" > >> and "when2.0", etc, at the time also. > > > > One thing to keep in mind is that YANG data models will be written for > > non-NETCONF things and the need for an xpath 2.0 type might arise even > > if NETCONF never ever uses xpath 2.0 itself. > > > > I am not opposing to call the typedef just xpath (like Andy I dislike > > the dots in identifiers) - I just have a problem with the argument you > > are bringing up. ;-) > > The main issue is the one Phil raised. > We aren't versioning all the little pieces of YANG 1.0. If we do IPv8, we do not need to change NETCONF nor YANG but we do need an IPv8 data type. My point is that the versioning of data type definitions is independent of the versioning of NETCONF or YANG. With xpath, we already know for sure that there are two versions out there and that is why I asked to consider this when I wrote the xpath typedef. > If YANG needs to be written for non-NETCONF things then > we should read about it in the NETMOD arch draft. I was talking about YANG data models to configure protocols (e.g. a potential future version of EPP) that use xpath 2.0. I believe such a data model is in scope of YANG and does not require text in the NETMOD arch draft. Anyway, I am fine with xpath as well. I just think Phil's argument was not quite convincing. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From david.kessens@nsn.com Fri Apr 17 14:14:06 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FCC03A6F65 for ; Fri, 17 Apr 2009 14:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LTAg012rx3C for ; Fri, 17 Apr 2009 14:14:05 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id A4C143A6844 for ; Fri, 17 Apr 2009 14:14:04 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3HLEWQG020374 for ; Fri, 17 Apr 2009 16:15:19 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 18 Apr 2009 00:14:51 +0300 Received: from localhost.localdomain ([10.241.58.204]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 18 Apr 2009 00:14:49 +0300 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.3/8.14.3) with ESMTP id n3HLEk73012360 for ; Fri, 17 Apr 2009 14:14:46 -0700 Received: (from david@localhost) by localhost.localdomain (8.14.3/8.14.3/Submit) id n3HLEjR4012358 for netmod@ietf.org; Fri, 17 Apr 2009 14:14:45 -0700 Date: Fri, 17 Apr 2009 14:14:45 -0700 From: David Kessens To: netmod@ietf.org Message-ID: <20090417211445.GU4589@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 17 Apr 2009 21:14:50.0631 (UTC) FILETIME=[8B68C970:01C9BFA1] X-Nokia-AV: Clean Subject: [netmod] Proposed solution to "identifier length" discussion X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 21:14:06 -0000 It seems the working group is quite divided on the issue of identifier length. At the same time, there is no question that postponing a decision would not help anything so we believe that we are better served making a decision now. When we analyzed the opinions it seems that a significant majority of the people can actually live with the current text as long as 63 gets changed to 64 and that many would like to have an explicit recommendation in the usage guidelines to not use anything more than 64 for IETF modules. We realize that this will not make everybody happy as some people would like to have no limits while others might feel that the limits we propose now are still not specified as tightly as possible. On the other hand, this solutions encourages to use identifiers that are at least somewhat human(=operator)-friendly while interoperation for IETF modules is ensured. We would like to hear whether you can live with this proposal in the interest of moving forward or that you still feel that we need to continue this debate. David Kessens & David Partain --- From lhotka@cesnet.cz Fri Apr 17 14:29:46 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3183A6E07 for ; Fri, 17 Apr 2009 14:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.967 X-Spam-Level: X-Spam-Status: No, score=-0.967 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdJbWgswaQCf for ; Fri, 17 Apr 2009 14:29:46 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 190843A6A10 for ; Fri, 17 Apr 2009 14:29:46 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 407E7D800BD; Fri, 17 Apr 2009 23:30:59 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090417162704.GC18345@elstar.local> References: <200904170831.54057.david.partain@ericsson.com> <200904171340.n3HDeVB8089915@idle.juniper.net> <20090417152710.GB18345@elstar.local> <1239983550.6454.52.camel@missotis> <20090417162704.GC18345@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 17 Apr 2009 23:31:00 +0200 Message-Id: <1240003860.6454.56.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 21:29:47 -0000 Juergen Schoenwaelder píše v Pá 17. 04. 2009 v 18:27 +0200: > On Fri, Apr 17, 2009 at 05:52:30PM +0200, Ladislav Lhotka wrote: > > > An option would be to use "xpath" for the type name and specify version > > in "version" substatement, for example > > > > leaf foo { > > type xpath { > > version 2.0; > > } > > } > > Are you serious? Adding another complexity dimension to our already > versioned includes?? Yes, if you are serious about leaving space for XPath 2.0. Why is it less complex to introduce two separate datatypes? In 99 % cases, users will just use "type xpath;". Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Fri Apr 17 14:44:55 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C57B28C1B7 for ; Fri, 17 Apr 2009 14:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.352 X-Spam-Level: X-Spam-Status: No, score=-1.352 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uygsra3A27JK for ; Fri, 17 Apr 2009 14:44:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0FE9728C1A7 for ; Fri, 17 Apr 2009 14:44:54 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 54C1AC033C; Fri, 17 Apr 2009 23:46:07 +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 t96PX9HEZeYh; Fri, 17 Apr 2009 23:46:06 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E912C0337; Fri, 17 Apr 2009 23:46:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9ED79AABF46; Fri, 17 Apr 2009 23:45:48 +0200 (CEST) Date: Fri, 17 Apr 2009 23:45:48 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090417214548.GA18794@elstar.local> Mail-Followup-To: Ladislav Lhotka , "netmod@ietf.org" References: <200904170831.54057.david.partain@ericsson.com> <200904171340.n3HDeVB8089915@idle.juniper.net> <20090417152710.GB18345@elstar.local> <1239983550.6454.52.camel@missotis> <20090417162704.GC18345@elstar.local> <1240003860.6454.56.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1240003860.6454.56.camel@missotis> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 17 Apr 2009 21:44:55 -0000 On Fri, Apr 17, 2009 at 11:31:00PM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder p????e v P?? 17. 04. 2009 v 18:27 +0200: > > On Fri, Apr 17, 2009 at 05:52:30PM +0200, Ladislav Lhotka wrote: > > > > > An option would be to use "xpath" for the type name and specify version > > > in "version" substatement, for example > > > > > > leaf foo { > > > type xpath { > > > version 2.0; > > > } > > > } > > > > Are you serious? Adding another complexity dimension to our already > > versioned includes?? > > Yes, if you are serious about leaving space for XPath 2.0. Why is it > less complex to introduce two separate datatypes? Its less complex because I can do this with YANG today and I do not need yet another language feature. We are not here to build the most beautiful and most complex language. At least I am not. > In 99 % cases, users will just use "type xpath;". And this is actually the big argument in favour of the name xpath-1.0 - the type name tells you what you get and makes people think whether they actually want what they get. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Fri Apr 17 14:46:53 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26E2B3A6A4E for ; Fri, 17 Apr 2009 14:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.334 X-Spam-Level: X-Spam-Status: No, score=-2.334 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SrhE+AbPNrg for ; Fri, 17 Apr 2009 14:46:52 -0700 (PDT) Received: from n13a.bullet.mail.mud.yahoo.com (n13a.bullet.mail.mud.yahoo.com [68.142.207.51]) by core3.amsl.com (Postfix) with SMTP id D2CD63A6FBC for ; Fri, 17 Apr 2009 14:46:15 -0700 (PDT) Received: from [68.142.200.225] by n13.bullet.mail.mud.yahoo.com with NNFMP; 17 Apr 2009 21:47:29 -0000 Received: from [68.142.201.245] by t6.bullet.mud.yahoo.com with NNFMP; 17 Apr 2009 21:47:29 -0000 Received: from [127.0.0.1] by omp406.mail.mud.yahoo.com with NNFMP; 17 Apr 2009 21:47:29 -0000 X-Yahoo-Newman-Id: 507598.73581.bm@omp406.mail.mud.yahoo.com Received: (qmail 46232 invoked from network); 17 Apr 2009 21:47:29 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.236 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 17 Apr 2009 21:47:28 -0000 X-YMail-OSG: DKENcFwVM1kyxhrBSzUEth3Y.NP8w8tt_C.hkGeF5uwezBaDE0ORtQJIKFenZveD3uxVJk50IrHJ8_u4Mt5J0Ba9p5FOdlYX6v7IaXVO2lIPQf9d6nbBOaXz4Avy9rE7qXyHNn8tdzrC28NKC7u6ZIRFWCzOaDmwxkl7I0IDjRu3EU9yWdUjzFFqM5d7n13CpYvWpcZce31e2J1L5O9EMZAA4AVwBfmSnSelHPC649cVPuOtUDF1nQTO7LCLur8BKSQimE.eK5JqEmOd X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E8F8EE.7070609@netconfcentral.com> Date: Fri, 17 Apr 2009 14:47:26 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ladislav Lhotka References: <200904170831.54057.david.partain@ericsson.com> <200904171340.n3HDeVB8089915@idle.juniper.net> <20090417152710.GB18345@elstar.local> <1239983550.6454.52.camel@missotis> <20090417162704.GC18345@elstar.local> <1240003860.6454.56.camel@missotis> In-Reply-To: <1240003860.6454.56.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 21:46:53 -0000 Ladislav Lhotka wrote: > Juergen Schoenwaelder píše v Pá 17. 04. 2009 v 18:27 +0200: >> On Fri, Apr 17, 2009 at 05:52:30PM +0200, Ladislav Lhotka wrote: >> >>> An option would be to use "xpath" for the type name and specify version >>> in "version" substatement, for example >>> >>> leaf foo { >>> type xpath { >>> version 2.0; >>> } >>> } >> Are you serious? Adding another complexity dimension to our already >> versioned includes?? > > Yes, if you are serious about leaving space for XPath 2.0. Why is it > less complex to introduce two separate datatypes? In 99 % cases, users > will just use "type xpath;". > I agree with Juergen. This is way too much flexibility and complexity. In standards, it is good to remove these things whenever possible, not add them. Since this 'xpath' data type is nothing but a derived string and nothing special at all in YANG, there is nothing preventing any WG or vendor from making their own 'xpath2', 'myxpath', or whatever. Sorry for over-reacting, but I really dislike it when IETF WGs back into architectural or protocol decisions via some second or third order problem. If XPath 2.0 needs to be supported, and needs to be available as a data type for all protocols that use YANG, then that decision should be made first. Then decide how to do it. Since standard NETCONF cannot support this data type at all, and no other protocols are planning to use YANG, there seems little reason to add it now. > Lada > >> /js >> Andy From andy@netconfcentral.com Fri Apr 17 14:52:03 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A20813A6AF1 for ; Fri, 17 Apr 2009 14:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tw2Low5BcxUZ for ; Fri, 17 Apr 2009 14:52:03 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id F2EC83A6A4E for ; Fri, 17 Apr 2009 14:52:02 -0700 (PDT) Received: (qmail 86163 invoked from network); 17 Apr 2009 21:53:17 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.236 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 17 Apr 2009 21:53:16 -0000 X-YMail-OSG: a6Hn1mwVM1mOIj2ohsarkRIY0K3giXmzU6RbHWWqI2IY0RuazulOn9Ayv2jxuEL_yJy0cUmMwoHggBHqYSqDxvAxMamDvz7MUjomDtS5urAYdBU3.3zeNUnbHQqU_vYlBmZY8IBaVc8Hf7tQ9MqHv6QlhiEhR.OTfZ2U6M564JHvg.jqx7jadUlM1OGhZLk5HOCn_7IDNyQmrUaNXKkh2BsdM7F3VF8SYu9LYMRPdKe6HZOZw_u1_JMEINExkW_gqHzrZwXEi9fEfg9_wPsOc_s5S7fX2Y3BHoKl36AocA6sNgz9v6dO X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E8FA4A.9090201@netconfcentral.com> Date: Fri, 17 Apr 2009 14:53:14 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ladislav Lhotka , "netmod@ietf.org" References: <200904170831.54057.david.partain@ericsson.com> <200904171340.n3HDeVB8089915@idle.juniper.net> <20090417152710.GB18345@elstar.local> <1239983550.6454.52.camel@missotis> <20090417162704.GC18345@elstar.local> <1240003860.6454.56.camel@missotis> <20090417214548.GA18794@elstar.local> In-Reply-To: <20090417214548.GA18794@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 21:52:03 -0000 Juergen Schoenwaelder wrote: > On Fri, Apr 17, 2009 at 11:31:00PM +0200, Ladislav Lhotka wrote: >> Juergen Schoenwaelder p????e v P?? 17. 04. 2009 v 18:27 +0200: >>> On Fri, Apr 17, 2009 at 05:52:30PM +0200, Ladislav Lhotka wrote: >>> >>>> An option would be to use "xpath" for the type name and specify version >>>> in "version" substatement, for example >>>> >>>> leaf foo { >>>> type xpath { >>>> version 2.0; >>>> } >>>> } >>> Are you serious? Adding another complexity dimension to our already >>> versioned includes?? >> Yes, if you are serious about leaving space for XPath 2.0. Why is it >> less complex to introduce two separate datatypes? > > Its less complex because I can do this with YANG today and I do not > need yet another language feature. We are not here to build the most > beautiful and most complex language. At least I am not. > >> In 99 % cases, users will just use "type xpath;". > > And this is actually the big argument in favour of the name xpath-1.0 > - the type name tells you what you get and makes people think whether > they actually want what they get. > good point. is this 'xpath' really XPath 1.0 or is it the 'special' YANG XPath 1.0 plus the current() function from XPath 2.0? Because I implemented YANG XPath 1.0, so I want to know if I need a special data type for that, or if this one covers it. > /js > Andy From j.schoenwaelder@jacobs-university.de Sat Apr 18 01:28:39 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 418B73A6A06 for ; Sat, 18 Apr 2009 01:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXcTea-hFzq8 for ; Sat, 18 Apr 2009 01:28:38 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E48763A67AA for ; Sat, 18 Apr 2009 01:28:37 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A4A4EC0608; Sat, 18 Apr 2009 10:29:51 +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 agtSxQqESCpP; Sat, 18 Apr 2009 10:29:50 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D571C0607; Sat, 18 Apr 2009 10:29:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 29E67AAC3B1; Sat, 18 Apr 2009 10:29:31 +0200 (CEST) Date: Sat, 18 Apr 2009 10:29:31 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090418082931.GA19244@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , "netmod@ietf.org" References: <200904170831.54057.david.partain@ericsson.com> <200904171340.n3HDeVB8089915@idle.juniper.net> <20090417152710.GB18345@elstar.local> <1239983550.6454.52.camel@missotis> <20090417162704.GC18345@elstar.local> <1240003860.6454.56.camel@missotis> <20090417214548.GA18794@elstar.local> <49E8FA4A.9090201@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49E8FA4A.9090201@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 08:28:39 -0000 On Fri, Apr 17, 2009 at 11:53:14PM +0200, Andy Bierman wrote: > > > > And this is actually the big argument in favour of the name xpath-1.0 > > - the type name tells you what you get and makes people think whether > > they actually want what they get. > > > > good point. > is this 'xpath' really XPath 1.0 or is it the 'special' YANG XPath 1.0 > plus the current() function from XPath 2.0? > > Because I implemented YANG XPath 1.0, so I want to know if I need > a special data type for that, or if this one covers it. Very good point. Right now, the definition says: typedef xpath { type string; description "This type represents an XPATH 1.0 expression."; reference "W3C REC-xpath-19991116: XML Path Language (XPath) Version 1.0"; } So this is right now pretty much XPATH 1.0 (but I would have to read the XPATH specs to figure out whether custom functions like current() can be dealt with in XPATH 1.0). It seems we likely already have three xpath versions to deal with. The question is to what extend we have to distinguish them by having different typedefs. Another possible alternative could be that we write down in the description clause of the xpath typedef that this type represents any xpath expression and that objects using the type must specify which xpath version is meant or people create a derived type for that: module netconf { import yang-types { prefix yang; } typedef xpath-netconf { type yang:xpath; description "This is xpath 1.0 with the netconf extensions..."; } // ... } This way we have a common xpath type and we can add commonly used subtypes (xpath-1.0, xpath-2.0, xpath-yang, ...) once we know we need them. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Sat Apr 18 05:03:28 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C98D3A6A43 for ; Sat, 18 Apr 2009 05:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbU865oDURh6 for ; Sat, 18 Apr 2009 05:03:27 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id EF1A03A680A for ; Sat, 18 Apr 2009 05:03:27 -0700 (PDT) Received: (qmail 95996 invoked from network); 18 Apr 2009 12:04:42 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.236 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 18 Apr 2009 12:04:41 -0000 X-YMail-OSG: vDgvNoMVM1mAIw53EJ6HEY08U_EWJ1mjIOuqyid6BTxA6ceiam2TOS5Gzl9GwcPCDz8ZpFTraUSgTtFSTqPx4By0V0AUnbz.QQD.7Nq7lpRMrQ7yEJsXJPWSus6tUVYRlPrRAMCf01Fqpe9YjhsWwV3KzeWTGN0aqYsYFuFR81Q5pfBktnsOYdZd5nt7e2mwH3gFwvz.Z2toVgpGfVrT7jGBevBs9zkTGAQeeqazRUjt0fAHjSZTFbd0qu.1zZtQk35HMkEE5YdwI1UA X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E9C1D7.3000406@netconfcentral.com> Date: Sat, 18 Apr 2009 05:04:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman , Ladislav Lhotka , "netmod@ietf.org" References: <200904170831.54057.david.partain@ericsson.com> <200904171340.n3HDeVB8089915@idle.juniper.net> <20090417152710.GB18345@elstar.local> <1239983550.6454.52.camel@missotis> <20090417162704.GC18345@elstar.local> <1240003860.6454.56.camel@missotis> <20090417214548.GA18794@elstar.local> <49E8FA4A.9090201@netconfcentral.com> <20090418082931.GA19244@elstar.local> In-Reply-To: <20090418082931.GA19244@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 12:03:28 -0000 Juergen Schoenwaelder wrote: > On Fri, Apr 17, 2009 at 11:53:14PM +0200, Andy Bierman wrote: >>> And this is actually the big argument in favour of the name xpath-1.0 >>> - the type name tells you what you get and makes people think whether >>> they actually want what they get. >>> >> good point. >> is this 'xpath' really XPath 1.0 or is it the 'special' YANG XPath 1.0 >> plus the current() function from XPath 2.0? >> >> Because I implemented YANG XPath 1.0, so I want to know if I need >> a special data type for that, or if this one covers it. > > Very good point. Right now, the definition says: > > typedef xpath { > type string; > description > "This type represents an XPATH 1.0 expression."; > reference > "W3C REC-xpath-19991116: XML Path Language (XPath) Version 1.0"; > } > > So this is right now pretty much XPATH 1.0 (but I would have to read > the XPATH specs to figure out whether custom functions like current() > can be dealt with in XPATH 1.0). It seems we likely already have three > xpath versions to deal with. The question is to what extend we have to > distinguish them by having different typedefs. > > Another possible alternative could be that we write down in the > description clause of the xpath typedef that this type represents any > xpath expression and that objects using the type must specify which > xpath version is meant or people create a derived type for that: > > module netconf { > > import yang-types { prefix yang; } > > typedef xpath-netconf { > type yang:xpath; > description > "This is xpath 1.0 with the netconf extensions..."; > } > > // ... > > } > > This way we have a common xpath type and we can add commonly used > subtypes (xpath-1.0, xpath-2.0, xpath-yang, ...) once we know we need > them. > It's the ... part that worries me. Can't we start out in YANG 1.0 with 1 xpath data type? Don't we want everybody to implement YANG XPath? If they do more than the YANG standard requires, then NETCONF capabilities could be used to tell them apart. (Unless we want implementations to support xpath1 for /foo, xpath2 for /bar, xpath-fred for /foobar, xpath-barney for /fubar...) Andy > /js > From j.schoenwaelder@jacobs-university.de Sun Apr 19 14:53:48 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7A103A6963 for ; Sun, 19 Apr 2009 14:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.164 X-Spam-Level: X-Spam-Status: No, score=-1.164 tagged_above=-999 required=5 tests=[AWL=-0.774, BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbZQAjPbnIPL for ; Sun, 19 Apr 2009 14:53:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 985E53A67D8 for ; Sun, 19 Apr 2009 14:53:46 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 120EEC0FF9; Sun, 19 Apr 2009 23:55:01 +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 tU0M72Jl5MEz; Sun, 19 Apr 2009 23:54:59 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 375EDC0FF8; Sun, 19 Apr 2009 23:54:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 22BFDAACF64; Sun, 19 Apr 2009 23:54:41 +0200 (CEST) Date: Sun, 19 Apr 2009 23:54:40 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090419215440.GA19817@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , "netmod@ietf.org" References: <200904170831.54057.david.partain@ericsson.com> <200904171340.n3HDeVB8089915@idle.juniper.net> <20090417152710.GB18345@elstar.local> <1239983550.6454.52.camel@missotis> <20090417162704.GC18345@elstar.local> <1240003860.6454.56.camel@missotis> <20090417214548.GA18794@elstar.local> <49E8FA4A.9090201@netconfcentral.com> <20090418082931.GA19244@elstar.local> <49E9C1D7.3000406@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49E9C1D7.3000406@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 21:53:48 -0000 On Sat, Apr 18, 2009 at 02:04:39PM +0200, Andy Bierman wrote: > Can't we start out in YANG 1.0 with 1 xpath data type? > Don't we want everybody to implement YANG XPath? > If they do more than the YANG standard requires, > then NETCONF capabilities could be used to tell them apart. > (Unless we want implementations to support xpath1 for /foo, > xpath2 for /bar, xpath-fred for /foobar, xpath-barney for /fubar...) You seem to confuse NETCONF, YANG, and the data models defined in YANG and manipulated using NETCONF. We will likely see variants of XPath in _data models_ of other protocols that are to be managed using NETCONF and YANG. (XCON for example uses a restricted suset of XPath 1.0). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Sun Apr 19 16:00:29 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB5A13A6881 for ; Sun, 19 Apr 2009 16:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDV4dTerdvrn for ; Sun, 19 Apr 2009 16:00:29 -0700 (PDT) Received: from n15a.bullet.mail.mud.yahoo.com (n15a.bullet.mail.mud.yahoo.com [68.142.207.125]) by core3.amsl.com (Postfix) with SMTP id D92783A6405 for ; Sun, 19 Apr 2009 16:00:28 -0700 (PDT) Received: from [68.142.200.225] by n15.bullet.mail.mud.yahoo.com with NNFMP; 19 Apr 2009 23:01:44 -0000 Received: from [68.142.201.244] by t6.bullet.mud.yahoo.com with NNFMP; 19 Apr 2009 23:01:44 -0000 Received: from [127.0.0.1] by omp405.mail.mud.yahoo.com with NNFMP; 19 Apr 2009 23:01:44 -0000 X-Yahoo-Newman-Id: 23873.95089.bm@omp405.mail.mud.yahoo.com Received: (qmail 23381 invoked from network); 19 Apr 2009 23:01:43 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.138.188 with plain) by smtp108.sbc.mail.sp1.yahoo.com with SMTP; 19 Apr 2009 23:01:42 -0000 X-YMail-OSG: drhEvugVM1ngOGQ8Q0A_Vpoym4X6elr8fPj3bVGuyC9cgqv0Q.BqoXIAadOBTkUlvgHIOhsWepMi3eEB3VTKmYSg7QP2Ae2c1wBcsq9kTxQgE7hBgieoPLKmTV3L7uIfPc7ub3OWmWIVSqpC1ceWt6YbQISL2gdXYeah30k8Gur8yexLnP_KAWsQSjTRejA9EARHJ2lHecMmt01ZOehtAmypmQEoUjMdEtyIvGRxuLNItKoSzt7PW6b2iRQ5icfnIXqt5IcyhxWQl__u X-Yahoo-Newman-Property: ymail-3 Message-ID: <49EBAD56.1060801@netconfcentral.com> Date: Sun, 19 Apr 2009 16:01:42 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman , Ladislav Lhotka , "netmod@ietf.org" References: <200904170831.54057.david.partain@ericsson.com> <200904171340.n3HDeVB8089915@idle.juniper.net> <20090417152710.GB18345@elstar.local> <1239983550.6454.52.camel@missotis> <20090417162704.GC18345@elstar.local> <1240003860.6454.56.camel@missotis> <20090417214548.GA18794@elstar.local> <49E8FA4A.9090201@netconfcentral.com> <20090418082931.GA19244@elstar.local> <49E9C1D7.3000406@netconfcentral.com> <20090419215440.GA19817@elstar.local> In-Reply-To: <20090419215440.GA19817@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 23:00:29 -0000 Juergen Schoenwaelder wrote: > On Sat, Apr 18, 2009 at 02:04:39PM +0200, Andy Bierman wrote: > >> Can't we start out in YANG 1.0 with 1 xpath data type? >> Don't we want everybody to implement YANG XPath? >> If they do more than the YANG standard requires, >> then NETCONF capabilities could be used to tell them apart. >> (Unless we want implementations to support xpath1 for /foo, >> xpath2 for /bar, xpath-fred for /foobar, xpath-barney for /fubar...) > > You seem to confuse NETCONF, YANG, and the data models defined in YANG > and manipulated using NETCONF. We will likely see variants of XPath in > _data models_ of other protocols that are to be managed using NETCONF > and YANG. (XCON for example uses a restricted suset of XPath 1.0). > Not really. I don't see why I would have a leaf in the 'fred-XPath' expression language if I didn't have some support for that XPath dialect somewhere in the tool. I don't care if there are 3 types (xpath1, xpath2, xpath-yang) all derived from the common 'xpath' typedef. I don't think many NETCONF agents support XPath 1.0 properly, so it's a really minor issue to think about XPath 2.0 at all here. But perhaps it is being used outside of NETCONF -- I don't know. > /js > Andy From lhotka@cesnet.cz Sun Apr 19 23:08:11 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DB893A687B for ; Sun, 19 Apr 2009 23:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.073 X-Spam-Level: X-Spam-Status: No, score=0.073 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_05=-1.11, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gp6IgJoUea4I for ; Sun, 19 Apr 2009 23:08:10 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3ACFC3A6BC0 for ; Sun, 19 Apr 2009 23:08:10 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 5421ED800C0; Mon, 20 Apr 2009 08:09:25 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090417214548.GA18794@elstar.local> References: <200904170831.54057.david.partain@ericsson.com> <200904171340.n3HDeVB8089915@idle.juniper.net> <20090417152710.GB18345@elstar.local> <1239983550.6454.52.camel@missotis> <20090417162704.GC18345@elstar.local> <1240003860.6454.56.camel@missotis> <20090417214548.GA18794@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 20 Apr 2009 08:09:24 +0200 Message-Id: <1240207764.6390.19.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 06:08:11 -0000 Juergen Schoenwaelder píše v Pá 17. 04. 2009 v 23:45 +0200: > On Fri, Apr 17, 2009 at 11:31:00PM +0200, Ladislav Lhotka wrote: > > Juergen Schoenwaelder p????e v P?? 17. 04. 2009 v 18:27 +0200: > > > On Fri, Apr 17, 2009 at 05:52:30PM +0200, Ladislav Lhotka wrote: > > > > > > > An option would be to use "xpath" for the type name and specify version > > > > in "version" substatement, for example > > > > > > > > leaf foo { > > > > type xpath { > > > > version 2.0; > > > > } > > > > } > > > > > > Are you serious? Adding another complexity dimension to our already > > > versioned includes?? > > > > Yes, if you are serious about leaving space for XPath 2.0. Why is it > > less complex to introduce two separate datatypes? > > Its less complex because I can do this with YANG today and I do not > need yet another language feature. We are not here to build the most > beautiful and most complex language. At least I am not. I think ANY use of XPath expressions in configuration data is a big complication in the first place, even instance-identifier. I would certainly prefer the way how cross-references are normally dealt with in XML, i.e., via xml:id labels. Lada > > > In 99 % cases, users will just use "type xpath;". > > And this is actually the big argument in favour of the name xpath-1.0 > - the type name tells you what you get and makes people think whether > they actually want what they get. > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Sun Apr 19 23:28:07 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01BD23A6BBD for ; Sun, 19 Apr 2009 23:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oz20zRnLQ8FM for ; Sun, 19 Apr 2009 23:28:06 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 46DDD3A6A36 for ; Sun, 19 Apr 2009 23:28:06 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 8E0BA61600A; Mon, 20 Apr 2009 08:29:20 +0200 (CEST) Date: Mon, 20 Apr 2009 08:29:20 +0200 (CEST) Message-Id: <20090420.082920.96492697.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1240207764.6390.19.camel@missotis> References: <1240003860.6454.56.camel@missotis> <20090417214548.GA18794@elstar.local> <1240207764.6390.19.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 06:28:07 -0000 Ladislav Lhotka wrote: > I think ANY use of XPath expressions in configuration data is a big > complication in the first place, even instance-identifier. This type is already used in some YANG modules defining rpc operations. Also, there are at least two proprietary access control modules for NETCONF that I know of that use a restricted form of XPath (or instance-identifier). These are configuration data models. So I think we need to keep this data type, and we need to solve the naming issue. I (still) think the name should be xpath-1.0, and the lexical space should be all syntactically valid XPath 1.0 expressions. This includes any "extra" functions, and it includes variables. Just like with XPath in general, when this type is used, the description clause will have to specify which functions and variables are valid. If/when an XPath 2.0 type is needed, we can add it. Note that not all XPath 1.0 expressions are syntactically valid XPath 2.0. /martin From j.schoenwaelder@jacobs-university.de Sun Apr 19 23:33:24 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9263A6800 for ; Sun, 19 Apr 2009 23:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.043 X-Spam-Level: X-Spam-Status: No, score=-1.043 tagged_above=-999 required=5 tests=[AWL=-0.883, BAYES_05=-1.11, HELO_EQ_DE=0.35, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BM5-zLC1BYcG for ; Sun, 19 Apr 2009 23:33:23 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9AE7E3A69B5 for ; Sun, 19 Apr 2009 23:33:23 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 74066C000F; Mon, 20 Apr 2009 08:34:38 +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 dKdLgJTNwj0p; Mon, 20 Apr 2009 08:34:37 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3E3A4C000A; Mon, 20 Apr 2009 08:34:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 60FA1AB4F99; Mon, 20 Apr 2009 08:34:18 +0200 (CEST) Date: Mon, 20 Apr 2009 08:34:18 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090420063418.GA10045@elstar.local> Mail-Followup-To: Ladislav Lhotka , "netmod@ietf.org" References: <200904170831.54057.david.partain@ericsson.com> <200904171340.n3HDeVB8089915@idle.juniper.net> <20090417152710.GB18345@elstar.local> <1239983550.6454.52.camel@missotis> <20090417162704.GC18345@elstar.local> <1240003860.6454.56.camel@missotis> <20090417214548.GA18794@elstar.local> <1240207764.6390.19.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1240207764.6390.19.camel@missotis> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 20 Apr 2009 06:33:25 -0000 On Mon, Apr 20, 2009 at 08:09:24AM +0200, Ladislav Lhotka wrote: > > Its less complex because I can do this with YANG today and I do not > > need yet another language feature. We are not here to build the most > > beautiful and most complex language. At least I am not. > > I think ANY use of XPath expressions in configuration data is a big > complication in the first place, even instance-identifier. I would > certainly prefer the way how cross-references are normally dealt with in > XML, i.e., via xml:id labels. I am trying to come up with common typedefs that are broadly applicable - I thought this was the goal of the common data types document. I prefer to leave the decision to the designers of protocols we are going to manage with NETCONF/YANG whether they want to use XPath or not, which version/subset/superset of XPath, and for which purpose. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From root@core3.amsl.com Sun Apr 19 23:45:01 2009 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 43E843A69FD; Sun, 19 Apr 2009 23:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090420064501.43E843A69FD@core3.amsl.com> Date: Sun, 19 Apr 2009 23:45:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-05.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 06:45:01 -0000 --NextPart 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 : YANG - A data modeling language for NETCONF Author(s) : M. Bjorklund Filename : draft-ietf-netmod-yang-05.txt Pages : 174 Date : 2009-04-19 YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-yang-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-19233410.I-D@ietf.org> --NextPart-- From lhotka@cesnet.cz Mon Apr 20 00:24:24 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0625B3A6A31 for ; Mon, 20 Apr 2009 00:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.215 X-Spam-Level: X-Spam-Status: No, score=-0.215 tagged_above=-999 required=5 tests=[AWL=-0.454, BAYES_05=-1.11, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4AtWV32TWPO for ; Mon, 20 Apr 2009 00:24:23 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3C3F33A6978 for ; Mon, 20 Apr 2009 00:24:23 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 59106D800BD; Mon, 20 Apr 2009 09:25:38 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090420.082920.96492697.mbj@tail-f.com> References: <1240003860.6454.56.camel@missotis> <20090417214548.GA18794@elstar.local> <1240207764.6390.19.camel@missotis> <20090420.082920.96492697.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 20 Apr 2009 09:25:38 +0200 Message-Id: <1240212338.6390.46.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 07:24:24 -0000 Martin Bjorklund píše v Po 20. 04. 2009 v 08:29 +0200: > Ladislav Lhotka wrote: > > I think ANY use of XPath expressions in configuration data is a big > > complication in the first place, even instance-identifier. > > This type is already used in some YANG modules defining rpc > operations. Yes, XPath is needed in RPC operations, but IMO not in configuration data. So how about having "xpath" as a (properly defined) built-in type instead of less general "instance-identifier", but restrict it only for use in RPC definitions? The same "xpath" type then could be used with :xpath capability in NETCONF. > > Also, there are at least two proprietary access control modules for > NETCONF that I know of that use a restricted form of XPath (or > instance-identifier). These are configuration data models. This is not surprising given the SNMP/MIB/SMI heritage. My question is whether the use of XPath is really necessary there or whether the same effect could be possibly achieved via ID and IDREF. Lada > > So I think we need to keep this data type, and we need to solve the > naming issue. > > I (still) think the name should be xpath-1.0, and the lexical space > should be all syntactically valid XPath 1.0 expressions. This > includes any "extra" functions, and it includes variables. Just like > with XPath in general, when this type is used, the description clause > will have to specify which functions and variables are valid. > > If/when an XPath 2.0 type is needed, we can add it. Note that not all > XPath 1.0 expressions are syntactically valid XPath 2.0. > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Apr 20 00:37:44 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E990B3A6912 for ; Mon, 20 Apr 2009 00:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5++Q9D6XMn4C for ; Mon, 20 Apr 2009 00:37:44 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C62E43A67F0 for ; Mon, 20 Apr 2009 00:37:43 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 242E0C0021; Mon, 20 Apr 2009 09:38:59 +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 wYd73mSjgz4r; Mon, 20 Apr 2009 09:38:58 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C4B7C0020; Mon, 20 Apr 2009 09:38:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 52214AB50E8; Mon, 20 Apr 2009 09:38:39 +0200 (CEST) Date: Mon, 20 Apr 2009 09:38:39 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090420073839.GA10099@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" References: <1240003860.6454.56.camel@missotis> <20090417214548.GA18794@elstar.local> <1240207764.6390.19.camel@missotis> <20090420.082920.96492697.mbj@tail-f.com> <1240212338.6390.46.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1240212338.6390.46.camel@missotis> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 20 Apr 2009 07:37:45 -0000 On Mon, Apr 20, 2009 at 09:25:38AM +0200, Ladislav Lhotka wrote: > Yes, XPath is needed in RPC operations, but IMO not in configuration > data. So how about having "xpath" as a (properly defined) built-in type > instead of less general "instance-identifier", but restrict it only for > use in RPC definitions? The same "xpath" type then could be used > with :xpath capability in NETCONF. Xpath as a built-in type that can only be used in RPC definitions (a true CLR) because there will never ever be an xpath expression in any of data models to be written in the next 10-20 years??? I think we are not discussing built-in types at the moment. > > Also, there are at least two proprietary access control modules for > > NETCONF that I know of that use a restricted form of XPath (or > > instance-identifier). These are configuration data models. > > This is not surprising given the SNMP/MIB/SMI heritage. My question is > whether the use of XPath is really necessary there or whether the same > effect could be possibly achieved via ID and IDREF. It does not matter whether you like or dislike usage of XPath in data models - there is already some evidence that people will use XPath in data models and inventing CLRs to prevent people from doing that is not going to be very successful. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Mon Apr 20 00:59:52 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76EF53A6809 for ; Mon, 20 Apr 2009 00:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.057 X-Spam-Level: X-Spam-Status: No, score=-1.057 tagged_above=-999 required=5 tests=[AWL=-0.870, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMeQ+-YHjpmN for ; Mon, 20 Apr 2009 00:59:51 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id BB7963A687A for ; Mon, 20 Apr 2009 00:59:51 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 5F64D61600A for ; Mon, 20 Apr 2009 10:01:05 +0200 (CEST) Date: Mon, 20 Apr 2009 10:01:05 +0200 (CEST) Message-Id: <20090420.100105.51169129.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20090420064501.43E843A69FD@core3.amsl.com> References: <20090420064501.43E843A69FD@core3.amsl.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [netmod] I-D Action:draft-ietf-netmod-yang-05.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 07:59:52 -0000 Hi, I have now published -05 with the edits agreed upon. I believe this document now is ready for WGLC. /martin From lhotka@cesnet.cz Mon Apr 20 01:05:10 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37A8F3A6925 for ; Mon, 20 Apr 2009 01:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.952 X-Spam-Level: X-Spam-Status: No, score=-0.952 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKtwhvExrNzz for ; Mon, 20 Apr 2009 01:05:09 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2F4633A687A for ; Mon, 20 Apr 2009 01:05:09 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A3154D800C5; Mon, 20 Apr 2009 10:06:24 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090420073839.GA10099@elstar.local> References: <1240003860.6454.56.camel@missotis> <20090417214548.GA18794@elstar.local> <1240207764.6390.19.camel@missotis> <20090420.082920.96492697.mbj@tail-f.com> <1240212338.6390.46.camel@missotis> <20090420073839.GA10099@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 20 Apr 2009 10:06:24 +0200 Message-Id: <1240214784.6390.65.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 08:05:10 -0000 Juergen Schoenwaelder píše v Po 20. 04. 2009 v 09:38 +0200: > On Mon, Apr 20, 2009 at 09:25:38AM +0200, Ladislav Lhotka wrote: > > > Yes, XPath is needed in RPC operations, but IMO not in configuration > > data. So how about having "xpath" as a (properly defined) built-in type > > instead of less general "instance-identifier", but restrict it only for > > use in RPC definitions? The same "xpath" type then could be used > > with :xpath capability in NETCONF. > > Xpath as a built-in type that can only be used in RPC definitions (a > true CLR) because there will never ever be an xpath expression in any > of data models to be written in the next 10-20 years??? XSD datatype library doesn't define any XPath-like type either. > > I think we are not discussing built-in types at the moment. > > > > Also, there are at least two proprietary access control modules for > > > NETCONF that I know of that use a restricted form of XPath (or > > > instance-identifier). These are configuration data models. > > > > This is not surprising given the SNMP/MIB/SMI heritage. My question is > > whether the use of XPath is really necessary there or whether the same > > effect could be possibly achieved via ID and IDREF. > > It does not matter whether you like or dislike usage of XPath in data > models - there is already some evidence that people will use XPath in > data models and inventing CLRs to prevent people from doing that is > not going to be very successful. The problems of XPath have been already extensively discussed here - apart from the version and subset issue it is also the variability of the root node. XPath as a general datatype is just a kind of rope that already has a loop at its end. Nothing prevents module designers from defining their "xpath" type as an alias to string, if then want to, but then it's their business to define what it really means. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Apr 20 01:46:50 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 638893A69CD for ; Mon, 20 Apr 2009 01:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pD9wZvK7881n for ; Mon, 20 Apr 2009 01:46:49 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 33D033A692D for ; Mon, 20 Apr 2009 01:46:48 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0186CC0007; Mon, 20 Apr 2009 10:48:00 +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 DyaYJTAJwsey; Mon, 20 Apr 2009 10:47:58 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C47CBC0006; Mon, 20 Apr 2009 10:47:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A0800AB525A; Mon, 20 Apr 2009 10:47:39 +0200 (CEST) Date: Mon, 20 Apr 2009 10:47:39 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090420084739.GA10149@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" References: <1240003860.6454.56.camel@missotis> <20090417214548.GA18794@elstar.local> <1240207764.6390.19.camel@missotis> <20090420.082920.96492697.mbj@tail-f.com> <1240212338.6390.46.camel@missotis> <20090420073839.GA10099@elstar.local> <1240214784.6390.65.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1240214784.6390.65.camel@missotis> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 20 Apr 2009 08:46:50 -0000 On Mon, Apr 20, 2009 at 10:06:24AM +0200, Ladislav Lhotka wrote: > Nothing prevents module designers from defining their "xpath" type > as an alias to string, if then want to, but then it's their business > to define what it really means. This is exactly what happened and instead of having to deal with N different "xpath" types, the WG wanted to have a common definition in yang-types.yang and this is what we are discussing. The room's consensus at the last IETF meeting was to name the xpath typedef (which happens to stand for XPath 1.0) to xpath-1.0. The purpose of this thread was supposed to verify this consensus position. - Martin still seems to support to the call the typedef xpath-1.0 and I am fine with this as well (especially is the type allows for custom functions like current()). - Phil suggested to just use xpath (which implicitely stands for xpath 1.0) and to add version numbers once we add more xpath definitions. It did not sound he objects against xpath-1.0 though (please correct me if I got this wrong). - Lada posted several proposals ranging from adding version statements to typedefs over an xpath built-in type to don't use xpath at all. - Andy wrote several messages and I am not sure where exactly he stands in this discussion. It will help if others can comment as well and to have Andy and Lada clarify their positions so that we can put this to bed and move on. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Mon Apr 20 02:27:18 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63CC03A6A79 for ; Mon, 20 Apr 2009 02:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.957 X-Spam-Level: X-Spam-Status: No, score=-0.957 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29j4Qx1YFUNV for ; Mon, 20 Apr 2009 02:27:17 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 886E13A68F6 for ; Mon, 20 Apr 2009 02:27:17 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 8C2E4D800C8; Mon, 20 Apr 2009 11:28:32 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090420084739.GA10149@elstar.local> References: <1240003860.6454.56.camel@missotis> <20090417214548.GA18794@elstar.local> <1240207764.6390.19.camel@missotis> <20090420.082920.96492697.mbj@tail-f.com> <1240212338.6390.46.camel@missotis> <20090420073839.GA10099@elstar.local> <1240214784.6390.65.camel@missotis> <20090420084739.GA10149@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 20 Apr 2009 11:28:32 +0200 Message-Id: <1240219712.6390.85.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 09:27:18 -0000 Juergen Schoenwaelder píše v Po 20. 04. 2009 v 10:47 +0200: > On Mon, Apr 20, 2009 at 10:06:24AM +0200, Ladislav Lhotka wrote: > > > Nothing prevents module designers from defining their "xpath" type > > as an alias to string, if then want to, but then it's their business > > to define what it really means. > > This is exactly what happened and instead of having to deal with N > different "xpath" types, the WG wanted to have a common definition in > yang-types.yang and this is what we are discussing. So if this "xpath" type is used within rpc output specification, is its root node the top-level element inside the rpc reply or in the configuration database? My point is that "xpath" (with version or without) is a weasel data type that can lead to interoperability problems. > > - Lada posted several proposals ranging from adding version statements > to typedefs over an xpath built-in type to don't use xpath at all. My position is: 1. Do not to define any "xpath" type in yang-types. 2. However, if there is evidence that such a type is needed (perhaps in RPCs), I'd prefer to define it properly and carefully as a built-in type. Lada > > - Andy wrote several messages and I am not sure where exactly he > stands in this discussion. > > It will help if others can comment as well and to have Andy and Lada > clarify their positions so that we can put this to bed and move on. > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Mon Apr 20 02:38:42 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4758D3A6A42 for ; Mon, 20 Apr 2009 02:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZI6dTq3dQ7wK for ; Mon, 20 Apr 2009 02:38:41 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id A3F9F3A6A39 for ; Mon, 20 Apr 2009 02:38:41 -0700 (PDT) Received: (qmail 97054 invoked from network); 20 Apr 2009 09:39:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.138.188 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 20 Apr 2009 09:39:57 -0000 X-YMail-OSG: 4ccBuQgVM1m_xtPOTSV0mLLvelmGkYPSAjAhoKmJwjPLSe0hy201RJyLJuSyEC_gi4S8VtuukI53XxtJNBXC6r_D9MtqeHGBGKqDrWJn2jIn8QlpmbqYewlbUtczrJdlf9qoj3VydSgxbevAxp9b6pDN4VF9XdFmpkMif0qrPUUqfFC9hozOTy106eZMy15Ex56aw8H1RtC_jmxHBPyzBnKHSBosuKP4l9YQSYJsiy8PVp2.0CMVyFIjEGRMZXphuNNY0yck7Zxom4rc5UXbuTDWJmEQJoNvapWk85wEUfy98jj9oEY7 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49EC42EC.4090102@netconfcentral.com> Date: Mon, 20 Apr 2009 02:39:56 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" References: <1240003860.6454.56.camel@missotis> <20090417214548.GA18794@elstar.local> <1240207764.6390.19.camel@missotis> <20090420.082920.96492697.mbj@tail-f.com> <1240212338.6390.46.camel@missotis> <20090420073839.GA10099@elstar.local> <1240214784.6390.65.camel@missotis> <20090420084739.GA10149@elstar.local> In-Reply-To: <20090420084739.GA10149@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 09:38:42 -0000 Juergen Schoenwaelder wrote: > On Mon, Apr 20, 2009 at 10:06:24AM +0200, Ladislav Lhotka wrote: > >> Nothing prevents module designers from defining their "xpath" type >> as an alias to string, if then want to, but then it's their business >> to define what it really means. > > This is exactly what happened and instead of having to deal with N > different "xpath" types, the WG wanted to have a common definition in > yang-types.yang and this is what we are discussing. > > The room's consensus at the last IETF meeting was to name the xpath > typedef (which happens to stand for XPath 1.0) to xpath-1.0. The > purpose of this thread was supposed to verify this consensus position. > > - Martin still seems to support to the call the typedef xpath-1.0 and > I am fine with this as well (especially is the type allows for > custom functions like current()). > > - Phil suggested to just use xpath (which implicitely stands for xpath > 1.0) and to add version numbers once we add more xpath definitions. > It did not sound he objects against xpath-1.0 though (please correct > me if I got this wrong). > > - Lada posted several proposals ranging from adding version statements > to typedefs over an xpath built-in type to don't use xpath at all. > > - Andy wrote several messages and I am not sure where exactly he > stands in this discussion. > > It will help if others can comment as well and to have Andy and Lada > clarify their positions so that we can put this to bed and move on. > I don't think there is agreement on the original charter motivation for this data type. This is just a user-defined derived type for a string. It is not a built-in type. Anybody can define as many xpath variants as they want. I will still use my ncx:xpath extension no matter what the WG does. All I need is a tag indicating that XML prefixes are in the content. All the rest is just noise. > /js > Andy From j.schoenwaelder@jacobs-university.de Mon Apr 20 02:46:06 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 982E63A684B for ; Mon, 20 Apr 2009 02:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYSrhp32RbJQ for ; Mon, 20 Apr 2009 02:46:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8182B3A6B90 for ; Mon, 20 Apr 2009 02:45:53 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 06B1DC000A; Mon, 20 Apr 2009 11:47:09 +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 5+8Q6uEKHrQ8; Mon, 20 Apr 2009 11:47:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 52BFFC0004; Mon, 20 Apr 2009 11:47:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A6D46AB53DB; Mon, 20 Apr 2009 11:46:47 +0200 (CEST) Date: Mon, 20 Apr 2009 11:46:47 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090420094647.GA10349@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" References: <1240003860.6454.56.camel@missotis> <20090417214548.GA18794@elstar.local> <1240207764.6390.19.camel@missotis> <20090420.082920.96492697.mbj@tail-f.com> <1240212338.6390.46.camel@missotis> <20090420073839.GA10099@elstar.local> <1240214784.6390.65.camel@missotis> <20090420084739.GA10149@elstar.local> <49EC42EC.4090102@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49EC42EC.4090102@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netmod@ietf.org" Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 20 Apr 2009 09:46:06 -0000 On Mon, Apr 20, 2009 at 11:39:56AM +0200, Andy Bierman wrote: > I don't think there is agreement on the original > charter motivation for this data type. This is just > a user-defined derived type for a string. > It is not a built-in type. Anybody can > define as many xpath variants as they want. This is what the charter says: 6. A standard type library for use by YANG (proposed standard) Are you saying we should not have a common data type library?? > I will still use my ncx:xpath extension no matter what > the WG does. All I need is a tag indicating that > XML prefixes are in the content. All the rest is > just noise. So your position is "I do not care of what will be in yang-types.yang"? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Mon Apr 20 03:10:23 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B98228C11E for ; Mon, 20 Apr 2009 03:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dC8MPNFyJFV6 for ; Mon, 20 Apr 2009 03:10:22 -0700 (PDT) Received: from n13.bullet.mail.mud.yahoo.com (n13.bullet.mail.mud.yahoo.com [68.142.206.40]) by core3.amsl.com (Postfix) with SMTP id 888CF3A6D21 for ; Mon, 20 Apr 2009 03:10:22 -0700 (PDT) Received: from [68.142.194.243] by n13.bullet.mail.mud.yahoo.com with NNFMP; 20 Apr 2009 10:11:37 -0000 Received: from [68.142.201.253] by t1.bullet.mud.yahoo.com with NNFMP; 20 Apr 2009 10:11:37 -0000 Received: from [127.0.0.1] by omp414.mail.mud.yahoo.com with NNFMP; 20 Apr 2009 10:11:37 -0000 X-Yahoo-Newman-Id: 376006.93787.bm@omp414.mail.mud.yahoo.com Received: (qmail 4696 invoked from network); 20 Apr 2009 10:11:36 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.138.188 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 20 Apr 2009 10:11:36 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49EC4A57.9070407@netconfcentral.com> Date: Mon, 20 Apr 2009 03:11:35 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman , Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" References: <1240003860.6454.56.camel@missotis> <20090417214548.GA18794@elstar.local> <1240207764.6390.19.camel@missotis> <20090420.082920.96492697.mbj@tail-f.com> <1240212338.6390.46.camel@missotis> <20090420073839.GA10099@elstar.local> <1240214784.6390.65.camel@missotis> <20090420084739.GA10149@elstar.local> <49EC42EC.4090102@netconfcentral.com> <20090420094647.GA10349@elstar.local> In-Reply-To: <20090420094647.GA10349@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 10:10:23 -0000 Juergen Schoenwaelder wrote: > On Mon, Apr 20, 2009 at 11:39:56AM +0200, Andy Bierman wrote: > >> I don't think there is agreement on the original >> charter motivation for this data type. This is just >> a user-defined derived type for a string. >> It is not a built-in type. Anybody can >> define as many xpath variants as they want. > > This is what the charter says: > > 6. A standard type library for use by YANG (proposed standard) > > Are you saying we should not have a common data type library?? > >> I will still use my ncx:xpath extension no matter what >> the WG does. All I need is a tag indicating that >> XML prefixes are in the content. All the rest is >> just noise. > > So your position is "I do not care of what will be in > yang-types.yang"? > I do not think this RFC needs more than one xpath data type. > /js > Andy From david.partain@ericsson.com Mon Apr 20 04:17:13 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEE293A69F2 for ; Mon, 20 Apr 2009 04:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eX-GgAoINBJ1 for ; Mon, 20 Apr 2009 04:17:13 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 477003A6FEB for ; Mon, 20 Apr 2009 04:17:04 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DB1702033D for ; Mon, 20 Apr 2009 13:18:18 +0200 (CEST) X-AuditID: c1b4fb3e-ae78abb000005486-6d-49ec59fa46e5 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CAEBC20332 for ; Mon, 20 Apr 2009 13:18:18 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 13:18:18 +0200 Received: from selic023.ki.sw.ericsson.se ([147.214.32.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 13:18:18 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Mon, 20 Apr 2009 13:18:21 +0200 User-Agent: KMail/1.9.10 References: <200904160830.22633.david.partain@ericsson.com> In-Reply-To: <200904160830.22633.david.partain@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904201318.21085.david.partain@ericsson.com> X-OriginalArrivalTime: 20 Apr 2009 11:18:18.0316 (UTC) FILETIME=[B4C430C0:01C9C1A9] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] Prelimary Meeting Minutes from IETF 74 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 11:17:14 -0000 On Thursday 16 April 2009 08.30.22 David Partain wrote: > Hi, > > Please find the preliminary meeting minutes below for both sessions. > Please send me any corrections. Greetings, As I've received no comments, I assume that these minutes are accurate according to the collective wisdom of this working group. Cheers, David From randy_presuhn@mindspring.com Mon Apr 20 14:11:51 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D752528C194 for ; Mon, 20 Apr 2009 14:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.173 X-Spam-Level: X-Spam-Status: No, score=-1.173 tagged_above=-999 required=5 tests=[AWL=-0.988, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFA4u1D5Fsmm for ; Mon, 20 Apr 2009 14:11:51 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 169823A6873 for ; Mon, 20 Apr 2009 14:11:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ppPiW2sd7whQckHe5leKqE8o810gsl9aEbTT6m2x+roDcnjZAXVZl0Kxkp+WTHPF; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.206.70] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lw0nT-0007Oj-Qb for netmod@ietf.org; Mon, 20 Apr 2009 17:13:00 -0400 Message-ID: <008701c9c1fd$1caf31a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <1240003860.6454.56.camel@missotis><20090417214548.GA18794@elstar.local><1240207764.6390.19.camel@missotis><20090420.082920.96492697.mbj@tail-f.com> <1240212338.6390.46.camel@missotis> Date: Mon, 20 Apr 2009 14:15:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69683a5a88004836ae867aaec92cdf939739350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.206.70 Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 21:11:51 -0000 Hi - > From: "Ladislav Lhotka" > To: "Martin Bjorklund" > Cc: > Sent: Monday, April 20, 2009 12:25 AM > Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype ... > Yes, XPath is needed in RPC operations, but IMO not in configuration > data. So how about having "xpath" as a (properly defined) built-in type > instead of less general "instance-identifier", but restrict it only for > use in RPC definitions? The same "xpath" type then could be used > with :xpath capability in NETCONF. ... What are the chances that access control policies will have XPath expressions as part of their configuration data? Randy From lhotka@cesnet.cz Tue Apr 21 07:45:30 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFBB03A6BC5 for ; Tue, 21 Apr 2009 07:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.961 X-Spam-Level: X-Spam-Status: No, score=-0.961 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqCy6lV6+aLh for ; Tue, 21 Apr 2009 07:45:30 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 267AF3A6A67 for ; Tue, 21 Apr 2009 07:45:30 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 12996D800C5 for ; Tue, 21 Apr 2009 16:46:46 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <008701c9c1fd$1caf31a0$6801a8c0@oemcomputer> References: <1240003860.6454.56.camel@missotis> <20090417214548.GA18794@elstar.local><1240207764.6390.19.camel@missotis> <20090420.082920.96492697.mbj@tail-f.com> <1240212338.6390.46.camel@missotis> <008701c9c1fd$1caf31a0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Tue, 21 Apr 2009 16:46:45 +0200 Message-Id: <1240325205.8801.20.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 14:45:31 -0000 Randy Presuhn píše v Po 20. 04. 2009 v 14:15 -0700: > Hi - > > > From: "Ladislav Lhotka" > > To: "Martin Bjorklund" > > Cc: > > Sent: Monday, April 20, 2009 12:25 AM > > Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype > ... > > Yes, XPath is needed in RPC operations, but IMO not in configuration > > data. So how about having "xpath" as a (properly defined) built-in type > > instead of less general "instance-identifier", but restrict it only for > > use in RPC definitions? The same "xpath" type then could be used > > with :xpath capability in NETCONF. > ... > > What are the chances that access control policies will have XPath > expressions as part of their configuration data? Is there any proposal about how such policies can be implemented? Presumably it's not going to be part of YANG modules(?), so XPath might be useful. Lada > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From cfinss@dial.pipex.com Tue Apr 21 10:46:48 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32A853A69F1 for ; Tue, 21 Apr 2009 10:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=0.523, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWpRNndDFRfs for ; Tue, 21 Apr 2009 10:46:47 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id E662F3A6E44 for ; Tue, 21 Apr 2009 10:46:46 -0700 (PDT) X-Trace: 205742832/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.215/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.215 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYEACek7Uk+vBPX/2dsb2JhbACDJ0uKOMZ3B4NzBg X-IronPort-AV: E=Sophos;i="4.40,225,1238972400"; d="scan'208";a="205742832" X-IP-Direction: IN Received: from 1cust215.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.215]) by smtp.pipex.tiscali.co.uk with SMTP; 21 Apr 2009 18:47:58 +0100 Message-ID: <002001c9c2a0$ea5a1d60$0601a8c0@allison> From: "tom.petch" To: "David Partain" , References: <200904170832.31438.david.partain@ericsson.com><1239954457.6454.6.camel@missotis> <200904171002.36062.david.partain@ericsson.com> Date: Tue, 21 Apr 2009 18:35:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [netmod] Consensus call (YANG types) - Canonical XPath X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 17:46:48 -0000 ----- Original Message ----- From: "David Partain" To: Sent: Friday, April 17, 2009 10:02 AM Subject: Re: [netmod] Consensus call (YANG types) - Canonical XPath > On Friday 17 April 2009 09.47.37 Ladislav Lhotka wrote: > > David Partain píše v Pá 17. 04. 2009 v 08:32 +0200: > > > Do we need a definition of canonical XPath? > > > > > > At the recent IETF, rough consensus was reached to look for an > > > existing canonical XPATH definition and reuse it if such exists. > > > Otherwise, we do nothing. Put the canonical form (if found) in a > > > separate data type. > > > > There is no such thing, at least not in the sense we need - see Martin's > > message from 24 March. > > Hi, > > Yep, I know. For those who need to look at it, see: > > http://www.ietf.org/mail-archive/web/netmod/current/msg02289.html > On the other hand, XPath 1.0 s.3.6 says "Therefore, XPath expressions may return unexpected results unless both the characters in the XPath expression and in the XML document have been normalized into a canonical form. See [Character Model]." which suggests to me that XPath 1.0 has a canonical form. But reading the Provisional Meeting Minutes on this topic leaves me struggling as to what the discussion is about. I don't doubt that the minutes record what was said but am unclear what is meant, that is, I am missing the link with the datatype, seeing rather the issue as where Martin is quoted as saying "Martin Björklund: Filtering keys, might not work?" which sounds like the concern and then "David Harrington: can xpath expressions be interpreted differently? Martin Björklund: nope" which seems contradicted by the quote above. Tom Petch > This call simply reflects the need to confirm consensus on the mailing > list :-) > > Cheers, > > David From phil@juniper.net Tue Apr 21 11:18:31 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EF3528C311 for ; Tue, 21 Apr 2009 11:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTkrLgiQ+n9i for ; Tue, 21 Apr 2009 11:18:30 -0700 (PDT) Received: from chip3og57.obsmtp.com (chip3og57.obsmtp.com [64.18.14.179]) by core3.amsl.com (Postfix) with ESMTP id 149EF28C2C8 for ; Tue, 21 Apr 2009 11:16:02 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob57.postini.com ([64.18.6.12]) with SMTP ID DSNKSe4NrpK3ItpwPBG8em0/krAatCJ+p1Gu@postini.com; Tue, 21 Apr 2009 11:17:21 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 21 Apr 2009 11:03:56 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 11:03:56 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 11:03:56 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Apr 2009 11:03:55 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n3LI3tM02635; Tue, 21 Apr 2009 11:03:55 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n3LHuOuH086242; Tue, 21 Apr 2009 17:56:25 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904211756.n3LHuOuH086242@idle.juniper.net> To: "tom.petch" In-Reply-To: <002001c9c2a0$ea5a1d60$0601a8c0@allison> Date: Tue, 21 Apr 2009 13:56:24 -0400 From: Phil Shafer X-OriginalArrivalTime: 21 Apr 2009 18:03:55.0596 (UTC) FILETIME=[895428C0:01C9C2AB] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Consensus call (YANG types) - Canonical XPath X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 18:18:31 -0000 "tom.petch" writes: >On the other hand, XPath 1.0 s.3.6 says >... >which suggests to me that XPath 1.0 has a canonical form. The full section says: NOTE: It is possible in Unicode for there to be two strings that should be treated as identical even though they consist of the distinct sequences of Unicode abstract characters. For example, some accented characters may be represented in either a precomposed or decomposed form. Therefore, XPath expressions may return unexpected results unless both the characters in the XPath expression and in the XML document have been normalized into a canonical form. See [Character Model]. I read this as the _characters_ have a canonical form, not the expressions. This means that testing for equality, etc should have both sides to have the same representation, or that the sw behind the operators grok the differing representations. I guess the really annoying thing is that the xpath spec leaves open the possibility that one might _not_ normalize the characters and this means xpath expresions are _allowed_ to return unexpected results. This seems like a mistake to not return normalization and prevent unexpected results, but I didn't read the full discussion. Thanks, Phil From mbj@tail-f.com Tue Apr 21 11:53:42 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58ACA28C129 for ; Tue, 21 Apr 2009 11:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-f8h7TA4wEc for ; Tue, 21 Apr 2009 11:53:41 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7EA4D28C128 for ; Tue, 21 Apr 2009 11:53:41 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 25AB6616001; Tue, 21 Apr 2009 20:54:57 +0200 (CEST) Date: Tue, 21 Apr 2009 20:54:56 +0200 (CEST) Message-Id: <20090421.205456.243420518.mbj@tail-f.com> To: cfinss@dial.pipex.com From: Martin Bjorklund In-Reply-To: <002001c9c2a0$ea5a1d60$0601a8c0@allison> References: <1239954457.6454.6.camel@missotis> <200904171002.36062.david.partain@ericsson.com> <002001c9c2a0$ea5a1d60$0601a8c0@allison> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netmod@ietf.org Subject: Re: [netmod] Consensus call (YANG types) - Canonical XPath X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 18:53:42 -0000 Hi, "tom.petch" wrote: > But reading the Provisional Meeting Minutes on this topic leaves me > struggling > as to what the discussion is about. I don't doubt that the minutes > record what > was said but am unclear what is meant, that is, I am missing the link= > with the > datatype, seeing rather the issue as where Martin is quoted as saying= > = > "Martin Bj=F6rklund: Filtering keys, might not work?" > = > which sounds like the concern and then What I meant was that if an XPath expression is used in the data store, it might be difficult to filter (subtree, xpath) on its value. For example if the value stored is "/child::interface" and the filter string is "/interface" will the filter match? There is also the problem with prefixes, the XPath strings "/if:interface" and "/x:interface" may mean the same thing if the prefixes "if" and "x" are bound to the same URI. And the problem exists without filtering; if an XPath expression is used as key in a list, and I try to do an edit-config "delete" of the list entry with key value "/child::interface", will the entry "/interface" be deleted? > "David Harrington: can xpath expressions be interpreted differently? > = > Martin Bj=F6rklund: nope" > = > which seems contradicted by the quote above. I think the question was about when the expressions were executed. There are many string representations of one XPath expression, but all will evaluate to the same result. /martin From lhotka@cesnet.cz Wed Apr 22 23:14:59 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 438C028C685 for ; Wed, 22 Apr 2009 23:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.966 X-Spam-Level: X-Spam-Status: No, score=-0.966 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRoVy74o+zey for ; Wed, 22 Apr 2009 23:14:58 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7278828C679 for ; Wed, 22 Apr 2009 23:14:58 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id E1AEBD800BD for ; Thu, 23 Apr 2009 08:16:14 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain Organization: CESNET Date: Thu, 23 Apr 2009 08:16:14 +0200 Message-Id: <1240467374.6392.4.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Subject: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 06:14:59 -0000 Hi, when substituting defaults with the following module, should the default case "foo" be inserted if no case is present in the configuration? module test { namespace "http://example.com/test"; prefix test; choice foobar { default foo; container foo { presence "foo"; } container bar { presence "bar"; } } } Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Apr 23 03:42:06 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7F6B3A7248 for ; Thu, 23 Apr 2009 03:42:06 -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=[AWL=0.077, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWW78ZtQ9Bhv for ; Thu, 23 Apr 2009 03:42:06 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 55A863A7209 for ; Thu, 23 Apr 2009 03:40:42 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id AEEA6616019; Thu, 23 Apr 2009 12:41:58 +0200 (CEST) Date: Thu, 23 Apr 2009 12:41:58 +0200 (CEST) Message-Id: <20090423.124158.90458521.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1240467374.6392.4.camel@missotis> References: <1240467374.6392.4.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 10:42:06 -0000 Ladislav Lhotka wrote: > Hi, > > when substituting defaults with the following module, should the default > case "foo" be inserted if no case is present in the configuration? > > module test { > namespace "http://example.com/test"; > prefix test; > choice foobar { > default foo; > container foo { > presence "foo"; > } > container bar { > presence "bar"; > } > } > } I'm not sure I understand what you mean with "substituting defaults", but 7.9.3 says: The default case is only important when considering the default values of nodes under the cases. The default values for nodes under the default case are used if none of the nodes under any of the cases are present. This means that if no case is present in your configuration, nothing special happens, since there are no default values under the default case. Maybe our tools should give a warning about this... /martin From lhotka@cesnet.cz Thu Apr 23 04:14:32 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C83043A6814 for ; Thu, 23 Apr 2009 04:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.97 X-Spam-Level: X-Spam-Status: No, score=-0.97 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3slrmfx03Ipa for ; Thu, 23 Apr 2009 04:14:32 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id EEBBD3A67EC for ; Thu, 23 Apr 2009 04:14:31 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 59DAFD800BD; Thu, 23 Apr 2009 13:15:43 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090423.124158.90458521.mbj@tail-f.com> References: <1240467374.6392.4.camel@missotis> <20090423.124158.90458521.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 23 Apr 2009 13:15:43 +0200 Message-Id: <1240485343.16930.19.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 11:14:32 -0000 Martin Bjorklund píše v Čt 23. 04. 2009 v 12:41 +0200: > Ladislav Lhotka wrote: > > Hi, > > > > when substituting defaults with the following module, should the default > > case "foo" be inserted if no case is present in the configuration? > > > > module test { > > namespace "http://example.com/test"; > > prefix test; > > choice foobar { > > default foo; > > container foo { > > presence "foo"; > > } > > container bar { > > presence "bar"; > > } > > } > > } > > I'm not sure I understand what you mean with "substituting defaults", By this I mean the transformation of a configuration with suppressed defaults to one with expressed defaults. I am trying to figure out how the choice's default statement should be mapped to DSRL. > but 7.9.3 says: > > The default case is only important when considering the default > values of nodes under the cases. The default values for nodes under > the default case are used if none of the nodes under any of the cases > are present. Does "under" mean children or descendants here? For example, what will happen if container foo in my example contained this leaf: leaf greeting { type string; default "Hello"; } Lada > > This means that if no case is present in your configuration, nothing > special happens, since there are no default values under the default > case. Maybe our tools should give a warning about this... > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Apr 23 04:24:17 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FF8028C188 for ; Thu, 23 Apr 2009 04:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.226 X-Spam-Level: X-Spam-Status: No, score=-1.226 tagged_above=-999 required=5 tests=[AWL=-0.669, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSV0Y60NMj-W for ; Thu, 23 Apr 2009 04:24:16 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6AE9228C174 for ; Thu, 23 Apr 2009 04:24:16 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id EF21A61600E; Thu, 23 Apr 2009 13:25:33 +0200 (CEST) Date: Thu, 23 Apr 2009 13:25:33 +0200 (CEST) Message-Id: <20090423.132533.89817704.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1240485343.16930.19.camel@missotis> References: <1240467374.6392.4.camel@missotis> <20090423.124158.90458521.mbj@tail-f.com> <1240485343.16930.19.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 11:24:17 -0000 Ladislav Lhotka wrote: > > but 7.9.3 says: > > > > The default case is only important when considering the default > > values of nodes under the cases. The default values for nodes under > > the default case are used if none of the nodes under any of the cases > > are present. > > Does "under" mean children or descendants here? > For example, what will > happen if container foo in my example contained this leaf: > > leaf greeting { type string; default "Hello"; } Nothing, since the foo container is a presence container. If you remove the presence statement, then greeting would have its default value if no case was present. /martin From lhotka@cesnet.cz Thu Apr 23 05:22:50 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BADE3A69CB for ; Thu, 23 Apr 2009 05:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.045 X-Spam-Level: X-Spam-Status: No, score=-0.045 tagged_above=-999 required=5 tests=[AWL=-0.654, BAYES_20=-0.74, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTfjWlwiUAXJ for ; Thu, 23 Apr 2009 05:22:49 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 481523A69B5 for ; Thu, 23 Apr 2009 05:22:49 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id B260BD800BD; Thu, 23 Apr 2009 14:24:06 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090423.132533.89817704.mbj@tail-f.com> References: <1240467374.6392.4.camel@missotis> <20090423.124158.90458521.mbj@tail-f.com> <1240485343.16930.19.camel@missotis> <20090423.132533.89817704.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 23 Apr 2009 14:24:07 +0200 Message-Id: <1240489447.16930.35.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 12:22:50 -0000 Martin Bjorklund píše v Čt 23. 04. 2009 v 13:25 +0200: > Ladislav Lhotka wrote: > > > but 7.9.3 says: > > > > > > The default case is only important when considering the default > > > values of nodes under the cases. The default values for nodes under > > > the default case are used if none of the nodes under any of the cases > > > are present. > > > > Does "under" mean children or descendants here? > > For example, what will > > happen if container foo in my example contained this leaf: > > > > leaf greeting { type string; default "Hello"; } > > Nothing, since the foo container is a presence container. If you > remove the presence statement, then greeting would have its default > value if no case was present. OK, so "under" means descendants, but then I think the cited paragraph from 7.9.3 is a bit vague. One can understand the choice's default statement as a way for selecting one case by default. This would IMO make a perfect sense: choice protocol { default ssh; container ssh { presence "secure shell"; ... } container rsh { presence "remote shell"; ... } } Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Thu Apr 23 12:43:20 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76CE03A7293 for ; Thu, 23 Apr 2009 12:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4v7QQcZn3qJ9 for ; Thu, 23 Apr 2009 12:43:19 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 7C13628C6FB for ; Thu, 23 Apr 2009 12:41:04 -0700 (PDT) Received: (qmail 9840 invoked from network); 23 Apr 2009 19:42:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.97.151 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 23 Apr 2009 19:42:22 -0000 X-YMail-OSG: DQzVrc8VM1nG0HUlZmlUwNqSC86ukZoVUvHWGzsCZpdPBSldsRnK52MrIlY34ym8gGbTvOPDmXVF2879M8ul261Y5NdWXz1KQOBzxP7D5n8YeDWs9YqwFa8lNhRfzcqrudaeTfdSIOMUUrxDJDOF8vqdOOmQfojPTGkzXVYSa6ZMXcJnfawRLpssEqVP4rIsQHmIffyTbuUKXhoWZkWSvadZwcd_3OItzRYmPBNLT2Dt3CdXOb99WHrRyC3JlxRLi8wB2paQME2mD1PiznjYUFApJ5dUeqtiLbCEv2ngo5QFsAGXO99XU.a1YjZfo4Z1meKwrCGAKj8welmmgUXhj68- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49F0C49B.5070509@netconfcentral.com> Date: Thu, 23 Apr 2009 12:42:19 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <1240467374.6392.4.camel@missotis> <20090423.124158.90458521.mbj@tail-f.com> In-Reply-To: <20090423.124158.90458521.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 19:43:20 -0000 Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Hi, >> >> when substituting defaults with the following module, should the default >> case "foo" be inserted if no case is present in the configuration? >> >> module test { >> namespace "http://example.com/test"; >> prefix test; >> choice foobar { >> default foo; >> container foo { >> presence "foo"; >> } >> container bar { >> presence "bar"; >> } >> } >> } > > I'm not sure I understand what you mean with "substituting defaults", > but 7.9.3 says: > > The default case is only important when considering the default > values of nodes under the cases. The default values for nodes under > the default case are used if none of the nodes under any of the cases > are present. > > This means that if no case is present in your configuration, nothing > special happens, since there are no default values under the default > case. Maybe our tools should give a warning about this... > I'm not sure I interpreted/implemented this correctly. I probably create because it is a P container. Clearly, if 'foo' was an NP-container, it would not be added as the default unless it had child nodes that had defaults. Lists and leaf-lists do not get entries created by default. That is also clear. But why not presence containers? By definition, an empty P container has meaning, so this sort of construct is valid: choice dhcp-or-static { default dhcp; container dhcp { presence "empty container means default DHCP parms are in effect."; ... optional leafs ... } container static { leaf address { type inet:ip-address; mandatory true; } leaf subnetmask { type inet:ip-address; mandatory true; } leaf gateway { type inet:ip-address; mandatory true; } } } This is a valid config node: > > /martin Andy From Washam.Fan@huaweisymantec.com Thu Apr 23 19:43:08 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A17F28C715 for ; Thu, 23 Apr 2009 19:43:08 -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=[AWL=0.701, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2P5NM+5CLMd for ; Thu, 23 Apr 2009 19:43:07 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id C7A7E28C720 for ; Thu, 23 Apr 2009 19:41:56 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KIL002T03JXGL50@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Fri, 24 Apr 2009 10:43:11 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KIL0091K3JVDV00@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Fri, 24 Apr 2009 10:43:09 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Fri, 24 Apr 2009 10:43:07 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Fri, 24 Apr 2009 10:43:07 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <49F0C49B.5070509@netconfcentral.com> References: <1240467374.6392.4.camel@missotis> <20090423.124158.90458521.mbj@tail-f.com> <49F0C49B.5070509@netconfcentral.com> Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 02:43:08 -0000 > Martin Bjorklund wrote: > > Ladislav Lhotka wrote: > >> Hi, > >> > >> when substituting defaults with the following module, should the default > >> case "foo" be inserted if no case is present in the configuration? > >> > >> module test { > >> namespace "http://example.com/test"; > >> prefix test; > >> choice foobar { > >> default foo; > >> container foo { > >> presence "foo"; > >> } > >> container bar { > >> presence "bar"; > >> } > >> } > >> } > > > > I'm not sure I understand what you mean with "substituting defaults", > > but 7.9.3 says: > > > > The default case is only important when considering the default > > values of nodes under the cases. The default values for nodes under > > the default case are used if none of the nodes under any of the > cases > > are present. > > > > This means that if no case is present in your configuration, nothing > > special happens, since there are no default values under the default > > case. Maybe our tools should give a warning about this... > > > > I'm not sure I interpreted/implemented this correctly. > I probably create because it is a P container. > > Clearly, if 'foo' was an NP-container, it would not > be added as the default unless it had child nodes > that had defaults. > > Lists and leaf-lists do not get entries created by default. > That is also clear. > > But why not presence containers? > > By definition, an empty P container has meaning, > so this sort of construct is valid: > > choice dhcp-or-static { > default dhcp; > > container dhcp { > presence > "empty container means default DHCP parms are in effect."; > ... optional leafs ... > } > container static { > leaf address { type inet:ip-address; mandatory true; } > leaf subnetmask { type inet:ip-address; mandatory true; } > leaf gateway { type inet:ip-address; mandatory true; } > } > } > > This is a valid config node: > > > I also prefer presence container is added as the default if it is stated as the default in its ancestor choice. washam > > > > > > /martin > > Andy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From kawamucho@mesh.ad.jp Thu Apr 23 19:55:30 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EE763A6D52 for ; Thu, 23 Apr 2009 19:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.795 X-Spam-Level: X-Spam-Status: No, score=0.795 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpfJ2rwXkwEi for ; Thu, 23 Apr 2009 19:55:29 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by core3.amsl.com (Postfix) with ESMTP id 85AC03A67F4 for ; Thu, 23 Apr 2009 19:55:29 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.161]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id n3O2ukUn003215 for ; Fri, 24 Apr 2009 11:56:46 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id n3O2ukd12695 for netmod@ietf.org; Fri, 24 Apr 2009 11:56:46 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id n3O2ukKT024963 for ; Fri, 24 Apr 2009 11:56:46 +0900 (JST) Received: from bsac29088.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id n3O2uk7c027308 for ; Fri, 24 Apr 2009 11:56:46 +0900 Received: from mail.sys.biglobe.nec.co.jp (bgsx5626.sys.biglobe.nec.co.jp [10.18.151.10]) by bsac29088.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id n3O2ukjg028182 for ; Fri, 24 Apr 2009 11:56:46 +0900 Received: from [127.0.0.1] (bdonet119.sys.biglobe.nec.co.jp [10.19.136.119]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id n3O2uk5R031277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 24 Apr 2009 11:56:46 +0900 Message-ID: <49F12A6C.7020606@mesh.ad.jp> Date: Fri, 24 Apr 2009 11:56:44 +0900 From: Seiichi Kawamura User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: netmod@ietf.org References: <49D17E45.7010907@mesh.ad.jp> <20090415093702.GC4045@elstar.local> <200904170836.43233.david.partain@ericsson.com> In-Reply-To: <200904170836.43233.david.partain@ericsson.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] ipv6 address representation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 02:55:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> [1] draft-kawamura-ipv6-text-representation-00.txt FYI the draft is now -01.txt Lots of editorial cleanups. The core of it has not chaged. There is also a thread on v6ops about this. Thanks for all your comments! Regards Seiichi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) iD8DBQFJ8SpscrhTYfxyMkIRAvv1AJ4yJ0nNye+xtVR6UirqKQa4XdWSYQCghizA tw/mvZcionxN5NwAG7BtMkw= =TEbx -----END PGP SIGNATURE----- From lhotka@cesnet.cz Fri Apr 24 02:42:47 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1C1F3A72D7 for ; Fri, 24 Apr 2009 02:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTpKNeR91XuY for ; Fri, 24 Apr 2009 02:42:46 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3364A3A6AE2 for ; Fri, 24 Apr 2009 02:41:59 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 96838D800BD; Fri, 24 Apr 2009 11:43:17 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49F0C49B.5070509@netconfcentral.com> References: <1240467374.6392.4.camel@missotis> <20090423.124158.90458521.mbj@tail-f.com> <49F0C49B.5070509@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 24 Apr 2009 11:43:17 +0200 Message-Id: <1240566197.6505.31.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 09:42:47 -0000 Andy Bierman píše v Čt 23. 04. 2009 v 12:42 -0700: > Clearly, if 'foo' was an NP-container, it would not > be added as the default unless it had child nodes > that had defaults. > > Lists and leaf-lists do not get entries created by default. > That is also clear. > > But why not presence containers? > > By definition, an empty P container has meaning, > so this sort of construct is valid: Yes, this is the same as my ssh/rsh example and seems very natural, but it is much less clear in this case: choice dhcp-or-static { default dhcp; case dhcp { leaf someleaf { type string; default "Hi!"; } container dhcp { presence "..."; ... } ... } I'd tend not to insert the P container by default here, but from the point of view of the P container it is pretty much the same situation as in your example. Lada > > choice dhcp-or-static { > default dhcp; > > container dhcp { > presence > "empty container means default DHCP parms are in effect."; > ... optional leafs ... > } > container static { > leaf address { type inet:ip-address; mandatory true; } > leaf subnetmask { type inet:ip-address; mandatory true; } > leaf gateway { type inet:ip-address; mandatory true; } > } > } > > This is a valid config node: > > > > > > > > > > /martin > > Andy > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Fri Apr 24 03:27:51 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1EB13A68AD for ; Fri, 24 Apr 2009 03:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uo4Do0vYpCBf for ; Fri, 24 Apr 2009 03:27:51 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id F20253A688F for ; Fri, 24 Apr 2009 03:27:50 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5A353616001; Fri, 24 Apr 2009 12:29:08 +0200 (CEST) Date: Fri, 24 Apr 2009 12:29:07 +0200 (CEST) Message-Id: <20090424.122907.159423503.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49F0C49B.5070509@netconfcentral.com> References: <1240467374.6392.4.camel@missotis> <20090423.124158.90458521.mbj@tail-f.com> <49F0C49B.5070509@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 10:27:51 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > I'm not sure I understand what you mean with "substituting defaults", > > but 7.9.3 says: > > The default case is only important when considering the default > > values of nodes under the cases. The default values for nodes under > > the default case are used if none of the nodes under any of the cases > > are present. > > This means that if no case is present in your configuration, nothing > > special happens, since there are no default values under the default > > case. Maybe our tools should give a warning about this... > > > > I'm not sure I interpreted/implemented this correctly. > I probably create because it is a P container. > > Clearly, if 'foo' was an NP-container, it would not > be added as the default unless it had child nodes > that had defaults. > > Lists and leaf-lists do not get entries created by default. > That is also clear. > > But why not presence containers? We want this to work with all flavors of :with-defaults. In some systems defaults are actually not stored in the data store. If a leaf does not exist in the data store, its default value is used. If a P container doesn't exist, with your suggestion above, the application would treat it as if it existed. But this means that there is no difference to the application if it exists or not! Another way to understand this is that default values are not sent unless with-defaults is "true" in the request. So if a P container would exist by default, it would not be sent if with-defaults is false. How can you differentiate this with the case that the P container is explicitly removed? In both cases it is not there. /martin From lhotka@cesnet.cz Fri Apr 24 03:52:41 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D9263A6ED8 for ; Fri, 24 Apr 2009 03:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.969 X-Spam-Level: X-Spam-Status: No, score=-0.969 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HE3N19vARegM for ; Fri, 24 Apr 2009 03:52:40 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A43473A6836 for ; Fri, 24 Apr 2009 03:50:52 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A78E8D800BD; Fri, 24 Apr 2009 12:52:06 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090424.122907.159423503.mbj@tail-f.com> References: <1240467374.6392.4.camel@missotis> <20090423.124158.90458521.mbj@tail-f.com> <49F0C49B.5070509@netconfcentral.com> <20090424.122907.159423503.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 24 Apr 2009 12:52:06 +0200 Message-Id: <1240570326.6505.43.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 10:52:41 -0000 Martin Bjorklund píše v Pá 24. 04. 2009 v 12:29 +0200: > We want this to work with all flavors of :with-defaults. In some The fact that we don't have a clear model for dealing with defaults leads to ambiguous formulations like in 7.9.3: "The default values for nodes under the default case are used ...". What does this actually mean? Apparently they are used only in some cases. > systems defaults are actually not stored in the data store. If a leaf > does not exist in the data store, its default value is used. If a P > container doesn't exist, with your suggestion above, the application > would treat it as if it existed. But this means that there is no > difference to the application if it exists or not! > > Another way to understand this is that default values are not sent > unless with-defaults is "true" in the request. So if a P container > would exist by default, it would not be sent if with-defaults is > false. How can you differentiate this with the case that the P > container is explicitly removed? In both cases it is not there. The default statement in effect means that there is no way to suppress all cases of the choice, so either one is specified explicitly or the default one is assumed. This is no different from normal (leaf) defaults: either an explicit value is specified or the default assumed. Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Fri Apr 24 04:15:20 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E806A3A68FD for ; Fri, 24 Apr 2009 04:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oREPjeDWMV0S for ; Fri, 24 Apr 2009 04:15:20 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id 20E713A68AF for ; Fri, 24 Apr 2009 04:15:20 -0700 (PDT) Received: (qmail 31085 invoked from network); 24 Apr 2009 11:16:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.97.151 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 24 Apr 2009 11:16:38 -0000 X-YMail-OSG: m4YMSsgVM1mXRNtJUCW5BkJqIu27eRV1JeAR0Am7Qg4S6jrZ20F5fgDeg_8pRv2bzSpJZDrP5RIa_GpB0qTbwUqZFTeGEYApTHa2iTHdw.oxWx5LCk9vbzNw3aOxyJ5npAk9oVMfuo0.2skit4KbR.xpLCpF5o2RxyxWEjijKD4fbGh1dQkJeMcEHEifNMoIYgntCg2LvmNxA7r17da4cpQaMWuokSoFCs30S1zVqu65cwcL34_lS7N5AG5VIMBV3Ib3FdWJQxmzjeRfBBnFo3v1uTahYvbaqVZNmEOlUvrg2b5MKperJdDxtGOCmX9_KrDqbRJ25lTE X-Yahoo-Newman-Property: ymail-3 Message-ID: <49F19F93.7080608@netconfcentral.com> Date: Fri, 24 Apr 2009 04:16:35 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <1240467374.6392.4.camel@missotis> <20090423.124158.90458521.mbj@tail-f.com> <49F0C49B.5070509@netconfcentral.com> <20090424.122907.159423503.mbj@tail-f.com> In-Reply-To: <20090424.122907.159423503.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 11:15:21 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> I'm not sure I understand what you mean with "substituting defaults", >>> but 7.9.3 says: >>> The default case is only important when considering the default >>> values of nodes under the cases. The default values for nodes under >>> the default case are used if none of the nodes under any of the cases >>> are present. >>> This means that if no case is present in your configuration, nothing >>> special happens, since there are no default values under the default >>> case. Maybe our tools should give a warning about this... >>> >> I'm not sure I interpreted/implemented this correctly. >> I probably create because it is a P container. >> >> Clearly, if 'foo' was an NP-container, it would not >> be added as the default unless it had child nodes >> that had defaults. >> >> Lists and leaf-lists do not get entries created by default. >> That is also clear. >> >> But why not presence containers? > > We want this to work with all flavors of :with-defaults. In some > systems defaults are actually not stored in the data store. If a leaf > does not exist in the data store, its default value is used. If a P > container doesn't exist, with your suggestion above, the application > would treat it as if it existed. But this means that there is no > difference to the application if it exists or not! > > Another way to understand this is that default values are not sent > unless with-defaults is "true" in the request. So if a P container > would exist by default, it would not be sent if with-defaults is > false. How can you differentiate this with the case that the P > container is explicitly removed? In both cases it is not there. > I don't agree with this logic at all. The data modeler can decide if the default case makes sense or not. It makes no difference whether the default case is a leaf or a P container. In my perfectly valid use case, there are semantics associated with the agent-selected default of 'plain DCHP'. If the node was a leaf of type 'empty' then everything is fine. A P container is no different, if none of the optional leafs are filled in. The service is still running, and the config is clear and complete. I really dislike P and NP containers. I get comments all the time how strange it is to make such a complicated mess out of a simple container. > > /martin > > Andy From prvs=alexd=358002e3c@redback.com Fri Apr 24 14:54:32 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939963A6922 for ; Fri, 24 Apr 2009 14:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrAqejm27Ynw for ; Fri, 24 Apr 2009 14:54:31 -0700 (PDT) Received: from mgate-2.redback.com (mgate-2.redback.com [209.82.119.199]) by core3.amsl.com (Postfix) with ESMTP id C83D63A683D for ; Fri, 24 Apr 2009 14:54:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,244,1239001200"; d="scan'208";a="15765" Received: from unknown (HELO mailhost.van.redback.com) ([155.53.172.64]) by mgate-2.redback.com with ESMTP; 24 Apr 2009 14:55:50 -0700 Received: from [127.0.0.1] (unknown [155.53.189.235]) by mailhost.van.redback.com (Postfix) with ESMTP id A49D158C21 for ; Fri, 24 Apr 2009 14:55:50 -0700 (PDT) Message-ID: <49F23566.4020602@redback.com> Date: Fri, 24 Apr 2009 14:55:50 -0700 From: Alex Dickinson User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: netmod@ietf.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] Leaf node ambiguity in container elements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 21:54:32 -0000 Hello, Suppose I define the following container: container aaa { leaf bar { description: "Some configuration parameter" mandatory: false; type: string; } leaf bar { description: "Some other configuration parameter, but distinct from the first" mandatory: false; type: int; } } Now given the following XML instance document: 123 It is ambiguous as to which bar leaf node definition that the element represents. Are there any constraints present in the YANG spec that prevents the initial container from being formed? Cheers, Alex Dickinson From andy@netconfcentral.com Fri Apr 24 18:12:39 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B0123A6AA8 for ; Fri, 24 Apr 2009 18:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovzpXQuRFh-g for ; Fri, 24 Apr 2009 18:12:38 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 7A3313A6A60 for ; Fri, 24 Apr 2009 18:12:38 -0700 (PDT) Received: (qmail 2163 invoked from network); 25 Apr 2009 01:13:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.97.151 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 25 Apr 2009 01:13:57 -0000 X-YMail-OSG: iIe2M8oVM1nApd9Z8RkGMSrYD0za1GILi9pCts7Oi395HS60ro2TSttmRGuXblNJTj52EMii42V5lXS5Aj_kKUKq.Re2yC58jntXn3vuv0wh2iU9nzLIXc7KJTYtHSPynTguGxgtB5e_dC5rOSeOigyTUP.rwqyRI68GnKVCStcLGct53VB1K6pfwxh4fPF2f.ssM2h8Ms0WaUxlmLPvewZgNvlFGAE7FCh81rz2UqcIX7T.baeq8sbRidF0mifKO.3YKm_VuLplBK2wt5vxOkVxZlI6W3x9DP1dNKDN6AOXF844mb1ZrMlIwWe6Y3qhHDm8khWLSSAtsPwt0ao- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49F263D1.8000704@netconfcentral.com> Date: Fri, 24 Apr 2009 18:13:53 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Alex Dickinson References: <49F23566.4020602@redback.com> In-Reply-To: <49F23566.4020602@redback.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Leaf node ambiguity in container elements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 01:12:39 -0000 Alex Dickinson wrote: > Hello, > > Suppose I define the following container: > > container aaa { > > leaf bar { > description: "Some configuration parameter" > mandatory: false; > type: string; > } > > leaf bar { > description: > "Some other configuration parameter, but distinct from > the first" > mandatory: false; > type: int; > } > } > This is invalid YANG. Section 6.2.1, bullet 7: o All leafs, leaf-lists, lists, containers, choices, rpcs, and notifications defined within a parent node or at the top-level of the module or its submodules share the same identifier namespace. This namespace is scoped to the parent node or module, unless the parent node is a case node. In that case, the namespace is scoped to the parent node of the case node's parent choice node. Andy > > Now given the following XML instance document: > > > 123 > > > It is ambiguous as to which bar leaf node definition that the > element represents. > > Are there any constraints present in the YANG spec that prevents the > initial container from being formed? > > Cheers, > Alex Dickinson > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > From dromasca@avaya.com Sun Apr 26 08:22:38 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C57A33A6F0A; Sun, 26 Apr 2009 08:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0d6-cprLXYG; Sun, 26 Apr 2009 08:22:38 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 561783A6B39; Sun, 26 Apr 2009 08:22:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,248,1238990400"; d="scan'208";a="144126903" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Apr 2009 11:23:54 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 26 Apr 2009 11:23:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 26 Apr 2009 17:23:34 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The NGO List - EOL? Thread-Index: AcnGgva03edne+kIQ1WDbI5buW0BNw== From: "Romascanu, Dan (Dan)" To: , Cc: ngo@ietf.org Subject: [netmod] The NGO List - EOL? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 15:22:38 -0000 Is there any reason to keep the NGO (NETCONF Goes On) list alive? No useful traffic seems to have been sent to that list for the last calendar year.=20 Dan From andy@netconfcentral.com Sun Apr 26 09:00:21 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F1DE3A6DC2 for ; Sun, 26 Apr 2009 09:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.518 X-Spam-Level: X-Spam-Status: No, score=-0.518 tagged_above=-999 required=5 tests=[AWL=-1.453, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpoRiwC3dXd7 for ; Sun, 26 Apr 2009 09:00:21 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 36C8D3A6CAF for ; Sun, 26 Apr 2009 09:00:21 -0700 (PDT) Received: (qmail 80052 invoked from network); 26 Apr 2009 15:55:01 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.97.151 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 26 Apr 2009 15:55:01 -0000 X-YMail-OSG: 6lMLvdEVM1lI6JbdXx.TX5YDohMnXsrVtz572OWnKh8akfIIpjmTIRt2vM3ZNA7m_hxzH3L4pNUvD953NQj_bXGAi5axkKYc8gCHETbp_yy0MmCD4Riv2h1no592_3aKO1u6dMkKr0T8AgwUbqIm69yhJsTDH7j7dbVqaOur8Z8EyOSyd.9jKDe.oxhxpnGymUMaeUPVno2fiKDWiLAxzts1TQbKruQ23UXtQtr7QtEs.IO_WMdvxf_9dQG4VvAeR43cTeZKj7xVkE_tZURGWNhY3V7bA.tYdiWHSvhfieiRMAVim5OvL1hrNDFb9IwfzBGK4cb.blThR.oltv0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49F483D2.10904@netconfcentral.com> Date: Sun, 26 Apr 2009 08:54:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NETCONF , NETMOD Working Group References: <49E4BA9C.7080307@netconfcentral.com> In-Reply-To: <49E4BA9C.7080307@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] [Netconf] ietf-netconf.yang (2) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 16:00:21 -0000 Andy Bierman wrote: > Hi, > > Here is the updated version based on Martin's comments. > I did not get any comments on the YANG module or the total lack of support for NETCONF capabilities. There is a disconnect between how the NETMOD WG views the data modeling world and how standard NETCONF data models already in place are using capabilities. The claim is that capabilities are not needed in YANG because they are for the protocol layer, and features are for the content layer. This assertion has proven to be false in 2 of the first 4 YANG standard data models. The result is that any YANG file that tries to describe capability-based constructs is really describing a superset of all possible versions -- just like XSD, and just as worthless. A schema that works for all possible implementations but doesn't work for any specific implementation is not that useful to real CM work. I suggest that the NETCONF and NETMOD WGs think about this problem some more. Andy > IMO, the total lack of support in YANG for NETCONF capabilities > is a mistake. It leaves a big hole in the tool automation chain, > for a very basic feature of the NETCONF architecture. It forces > simple boolean logic into description statements, where it must > be read by every single implementor, the English text understood > correctly, and then manually implemented correctly. > > This is not just some corner-case, because this module happens > to be netconf.yang. The ietf-partial-lock data model is designed > to utilize the :xpath capability, and is only defined in description > statements. The ietf-netconf-state data model contains > sections which are only relevant if :notifications is supported, > or if :partial-lock is supported. Again, only defined in > description statements. > > So, out of the 4 very first 'content layer' standard data models, > (not counting netconf.yang) half of them need an 'if-capability' > statement. That seems like a pretty solid use-case to me. > > > > Andy > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From phil@juniper.net Sun Apr 26 20:09:22 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EB743A69BC for ; Sun, 26 Apr 2009 20:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.294 X-Spam-Level: X-Spam-Status: No, score=-6.294 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rn+yX0lh7kRL for ; Sun, 26 Apr 2009 20:09:21 -0700 (PDT) Received: from chip3og60.obsmtp.com (chip3og60.obsmtp.com [64.18.14.185]) by core3.amsl.com (Postfix) with ESMTP id 9A1743A6A90 for ; Sun, 26 Apr 2009 20:09:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob60.postini.com ([64.18.6.12]) with SMTP ID DSNKSfUiK6Vh2B3Ug65MaUZQlwRPXCHzenlr@postini.com; Sun, 26 Apr 2009 20:10:42 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Sun, 26 Apr 2009 20:04:35 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 26 Apr 2009 20:04:35 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 26 Apr 2009 20:04:35 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 26 Apr 2009 20:04:34 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n3R34XM27899; Sun, 26 Apr 2009 20:04:34 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n3R2uwTn033056; Mon, 27 Apr 2009 02:56:58 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904270256.n3R2uwTn033056@idle.juniper.net> To: Andy Bierman In-Reply-To: <49F483D2.10904@netconfcentral.com> Date: Sun, 26 Apr 2009 22:56:58 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Apr 2009 03:04:34.0402 (UTC) FILETIME=[E46DE420:01C9C6E4] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] [Netconf] ietf-netconf.yang (2) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 03:09:22 -0000 [moving to a single mailing list (netmod); bcc'ing netconf] Andy Bierman writes: >I did not get any comments on the YANG module >or the total lack of support for NETCONF capabilities. You've mentioned this issue several times and I believe it's been addressed, most recently by Martin, but by others before and during the interim. My quick summary would be: (1) If we'd had features during the initial netconf work, we would have used them. (2) YANG can handle multiple capabilities using multiple modules. (3) Early YANG users wanted something less heavy/ more light-weight for their models. The disliked using capabilities for this. (4) We made features, which give a simple extension mechanism for modelers to mark portions of the model as only applying when a feature is present. (5) This approach was approved at the interim and subsequently on the mailing list. If you want to use capabilities to model these bits instead of features, I think that is a valid choice. Other modelers may find features more suitable. I believe this is a closed issue. Thanks, Phil From andy@netconfcentral.com Sun Apr 26 20:27:35 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 234063A6939 for ; Sun, 26 Apr 2009 20:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGJcyGa-DssU for ; Sun, 26 Apr 2009 20:27:34 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id 68CC03A67F4 for ; Sun, 26 Apr 2009 20:27:34 -0700 (PDT) Received: (qmail 18117 invoked from network); 27 Apr 2009 03:28:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.97.151 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 27 Apr 2009 03:28:54 -0000 X-YMail-OSG: bBJV6B4VM1kbPeBEoYKNytpM3I02NEphF11WxJxvgkobshtWodZJdVTILlKw7qmCZ.GNY3wM3t4k0bso4fkMHwWLCafN8kivv3pTCzE1U90MYvXvJnhfeDnwPKeUjAmG08WhAl5YbrRIClBhS4MaUFx5DQUjGJ0mdcXlEk09FvAsJaKBjAl_qtxfyDRelM6V.gUoIJ_kCM0GEbmlL8OKT3X01cGsyV59Woit5q4r6ZkAEA.bThVT98.eQgwrWAza2SUmINxCSru04I9NSfRJxo0ZtfgzkIhr04nUdqVYF1f7yQ28y28- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49F52674.3060904@netconfcentral.com> Date: Sun, 26 Apr 2009 20:28:52 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200904270256.n3R2uwTn033056@idle.juniper.net> In-Reply-To: <200904270256.n3R2uwTn033056@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] [Netconf] ietf-netconf.yang (2) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 03:27:35 -0000 Phil Shafer wrote: > [moving to a single mailing list (netmod); bcc'ing netconf] > > Andy Bierman writes: >> I did not get any comments on the YANG module >> or the total lack of support for NETCONF capabilities. > > You've mentioned this issue several times and I believe > it's been addressed, most recently by Martin, but by > others before and during the interim. > > My quick summary would be: > (1) If we'd had features during the initial netconf > work, we would have used them. > (2) YANG can handle multiple capabilities using multiple > modules. > (3) Early YANG users wanted something less heavy/ more > light-weight for their models. The disliked using > capabilities for this. > (4) We made features, which give a simple extension > mechanism for modelers to mark portions of the model > as only applying when a feature is present. > (5) This approach was approved at the interim and > subsequently on the mailing list. > > If you want to use capabilities to model these bits instead of > features, I think that is a valid choice. Other modelers may find > features more suitable. > > I believe this is a closed issue. > I believe this is an ignored issue. Modelers obviously want to use NETCONF capabilities to partition content layer constructs, otherwise they would not have designed partial-lock and netconf-state data models that way. > Thanks, > Phil > > Andy From phil@juniper.net Sun Apr 26 20:41:52 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 242313A69A7 for ; Sun, 26 Apr 2009 20:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrpIM9XaTTg2 for ; Sun, 26 Apr 2009 20:41:51 -0700 (PDT) Received: from chip3og63.obsmtp.com (chip3og63.obsmtp.com [64.18.14.203]) by core3.amsl.com (Postfix) with ESMTP id 54BF63A69AA for ; Sun, 26 Apr 2009 20:41:42 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob63.postini.com ([64.18.6.12]) with SMTP ID DSNKSfUpxhISsBky6N22ArxW1O3yN0zCywe5@postini.com; Sun, 26 Apr 2009 20:43:12 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Sun, 26 Apr 2009 20:37:37 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 26 Apr 2009 20:37:37 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 26 Apr 2009 20:37:37 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 26 Apr 2009 20:37:36 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n3R3bZM42189; Sun, 26 Apr 2009 20:37:35 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n3R3U00P033716; Mon, 27 Apr 2009 03:30:00 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904270330.n3R3U00P033716@idle.juniper.net> To: Andy Bierman In-Reply-To: <49F52674.3060904@netconfcentral.com> Date: Sun, 26 Apr 2009 23:30:00 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Apr 2009 03:37:36.0288 (UTC) FILETIME=[81B9B200:01C9C6E9] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] [Netconf] ietf-netconf.yang (2) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 03:41:52 -0000 Andy Bierman writes: >Modelers obviously want to use NETCONF capabilities >to partition content layer constructs, otherwise >they would not have designed partial-lock and netconf-state >data models that way. These drafts predate features and don't contain normative YANG modules. Should these drafts be held until YANG is complete? Thanks, Phil From andy@netconfcentral.com Sun Apr 26 21:00:31 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 992443A6A2B for ; Sun, 26 Apr 2009 21:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.312 X-Spam-Level: X-Spam-Status: No, score=-1.312 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aw-lis8fOB-d for ; Sun, 26 Apr 2009 21:00:31 -0700 (PDT) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 048EF3A696A for ; Sun, 26 Apr 2009 21:00:31 -0700 (PDT) Received: (qmail 1448 invoked from network); 27 Apr 2009 04:01:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.97.151 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 27 Apr 2009 04:01:51 -0000 X-YMail-OSG: pP1bQHgVM1n6Ri0d6A4mVRYZ6DY6BKICCrUUbIuWZx6MVPhYuLWcqn9b5KM65Pdbv4XYtDsUElq8yuDSYzIYJMiaCVTmYktAAlXhZge2dYJm_7ske61ZYmyP3vAOm4zsjMfp659PAenyTnunQXi_ddX0.TOYHg5zSCOJ84WlySMKmaeJ9hO8qais7kc7Km3xUiq_asb_seDm56OiuOvojQ.HG.Uz7tEAX101gCCkdA7fPdr4OpMZoY7dq3nC8m4kq127Ep57Am7mFto- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49F52E2D.7090107@netconfcentral.com> Date: Sun, 26 Apr 2009 21:01:49 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200904270330.n3R3U00P033716@idle.juniper.net> In-Reply-To: <200904270330.n3R3U00P033716@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] [Netconf] ietf-netconf.yang (2) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 04:00:31 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Modelers obviously want to use NETCONF capabilities >> to partition content layer constructs, otherwise >> they would not have designed partial-lock and netconf-state >> data models that way. > > These drafts predate features and don't contain normative YANG > modules. Should these drafts be held until YANG is complete? > Yes. These data models should use YANG if-feature instead of capabilities and description clauses. The partial-lock draft doesn't actually work for all but a small number of use-cases. The monitoring draft is mostly redundant data already returned in PDUs. The get-schema RPC operation is really useful, though. We need a clean 'YANG MIB' for NETCONF. We should not rush out these particular drafts, ignoring YANG features. > Thanks, > Phil Andy From mbj@tail-f.com Mon Apr 27 07:57:56 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1E023A6834 for ; Mon, 27 Apr 2009 07:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVDqw+MaFrUD for ; Mon, 27 Apr 2009 07:57:56 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B774D3A68AF for ; Mon, 27 Apr 2009 07:57:55 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 0221C616005; Mon, 27 Apr 2009 16:53:23 +0200 (CEST) Date: Mon, 27 Apr 2009 16:53:23 +0200 (CEST) Message-Id: <20090427.165323.11937488.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49F19F93.7080608@netconfcentral.com> References: <49F0C49B.5070509@netconfcentral.com> <20090424.122907.159423503.mbj@tail-f.com> <49F19F93.7080608@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 14:57:56 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >>> I'm not sure I understand what you mean with "substituting defaults", > >>> but 7.9.3 says: > >>> The default case is only important when considering the default > >>> values of nodes under the cases. The default values for nodes under > >>> the default case are used if none of the nodes under any of the cases > >>> are present. > >>> This means that if no case is present in your configuration, nothing > >>> special happens, since there are no default values under the default > >>> case. Maybe our tools should give a warning about this... > >>> > >> I'm not sure I interpreted/implemented this correctly. > >> I probably create because it is a P container. > >> > >> Clearly, if 'foo' was an NP-container, it would not > >> be added as the default unless it had child nodes > >> that had defaults. > >> > >> Lists and leaf-lists do not get entries created by default. > >> That is also clear. > >> > >> But why not presence containers? > > We want this to work with all flavors of :with-defaults. In some > > systems defaults are actually not stored in the data store. If a leaf > > does not exist in the data store, its default value is used. If a P > > container doesn't exist, with your suggestion above, the application > > would treat it as if it existed. But this means that there is no > > difference to the application if it exists or not! Another way to understand > > this is that default values are not sent > > unless with-defaults is "true" in the request. So if a P container > > would exist by default, it would not be sent if with-defaults is > > false. How can you differentiate this with the case that the P > > container is explicitly removed? In both cases it is not there. > > > > I don't agree with this logic at all. > > The data modeler can decide if the default case makes sense > or not. It makes no difference whether the default case > is a leaf or a P container. In my perfectly valid use case, > there are semantics associated with the agent-selected default > of 'plain DCHP'. If the node was a leaf of type 'empty' > then everything is fine. No, that not how choice defaults work. If I understand you correctly, you mean that with this model: list foo { key name; leaf name { type string; } choice bar { default "tcp"; case tcp { leaf tcp { type empty; } } case udp { leaf tcp { type empty; } } } } If I create: t1 Then /foo/tcp gets automatically created by the agent? And you suggest that the same happens if 'tcp' is a P container? But the same does not happen if 'tcp' is a leaf of type boolean? After my create in the example above, suppose I do: t1 Is 'tcp' deleted or not? /martin From andy@netconfcentral.com Mon Apr 27 08:47:09 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E9473A68AF for ; Mon, 27 Apr 2009 08:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.089 X-Spam-Level: X-Spam-Status: No, score=-1.089 tagged_above=-999 required=5 tests=[AWL=-0.683, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aqpo5o8UVGKW for ; Mon, 27 Apr 2009 08:47:08 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 4DC163A6BC5 for ; Mon, 27 Apr 2009 08:47:08 -0700 (PDT) Received: (qmail 98342 invoked from network); 27 Apr 2009 15:48:23 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.97.151 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 27 Apr 2009 15:48:22 -0000 X-YMail-OSG: V50VEPMVM1kAyPgQmbea4u7wuAvNmtGme7CzegVSILCcW_7FHC6h84RIO2lJUqMvwIkte1idG8YT6B7Kme4DoqehE7xVweQDenPkbb9qytLP5Cv2aMQgiIeMj6T7jtb36m7KDEvtOCiqbZBqW.BtVNa5BfPkFIyDUhXSxgaggnDJ34M94Dei0amFn9HImlTUB6RsPaeMKgD7NeHkyDLNmm.5qwqDi4yT.FaUihJq0h6qnvMnLx8NL2LUoUZBnAfFfpKainUbJDi2LSLUAsMzhHYQgvYcmgLvIUvANveDBfTmnNlHOAYcMLFVfww7_a5oHTXcljPwx11PpW3D8LozZ4eYFbZX6VW61zP6m93BmU8zyEwh X-Yahoo-Newman-Property: ymail-3 Message-ID: <49F5D3C5.3020904@netconfcentral.com> Date: Mon, 27 Apr 2009 08:48:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <49F0C49B.5070509@netconfcentral.com> <20090424.122907.159423503.mbj@tail-f.com> <49F19F93.7080608@netconfcentral.com> <20090427.165323.11937488.mbj@tail-f.com> In-Reply-To: <20090427.165323.11937488.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 15:47:09 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Martin Bjorklund wrote: >>>>> I'm not sure I understand what you mean with "substituting defaults", >>>>> but 7.9.3 says: >>>>> The default case is only important when considering the default >>>>> values of nodes under the cases. The default values for nodes under >>>>> the default case are used if none of the nodes under any of the cases >>>>> are present. >>>>> This means that if no case is present in your configuration, nothing >>>>> special happens, since there are no default values under the default >>>>> case. Maybe our tools should give a warning about this... >>>>> >>>> I'm not sure I interpreted/implemented this correctly. >>>> I probably create because it is a P container. >>>> >>>> Clearly, if 'foo' was an NP-container, it would not >>>> be added as the default unless it had child nodes >>>> that had defaults. >>>> >>>> Lists and leaf-lists do not get entries created by default. >>>> That is also clear. >>>> >>>> But why not presence containers? >>> We want this to work with all flavors of :with-defaults. In some >>> systems defaults are actually not stored in the data store. If a leaf >>> does not exist in the data store, its default value is used. If a P >>> container doesn't exist, with your suggestion above, the application >>> would treat it as if it existed. But this means that there is no >>> difference to the application if it exists or not! Another way to understand >>> this is that default values are not sent >>> unless with-defaults is "true" in the request. So if a P container >>> would exist by default, it would not be sent if with-defaults is >>> false. How can you differentiate this with the case that the P >>> container is explicitly removed? In both cases it is not there. >>> >> I don't agree with this logic at all. >> >> The data modeler can decide if the default case makes sense >> or not. It makes no difference whether the default case >> is a leaf or a P container. In my perfectly valid use case, >> there are semantics associated with the agent-selected default >> of 'plain DCHP'. If the node was a leaf of type 'empty' >> then everything is fine. > > No, that not how choice defaults work. If I understand you correctly, > you mean that with this model: > > list foo { > key name; > leaf name { type string; } > > choice bar { > default "tcp"; > case tcp { > leaf tcp { type empty; } > } > case udp { > leaf tcp { type empty; } > } > } > } > > If I create: > > > t1 > > > Then /foo/tcp gets automatically created by the agent? > > And you suggest that the same happens if 'tcp' is a P container? > > But the same does not happen if 'tcp' is a leaf of type boolean? > > > After my create in the example above, suppose I do: > > > t1 > > > > Is 'tcp' deleted or not? > no -- just the same as any other time you try to delete the default case. choice dhcp-or-static { default dhcp; container dhcp { presence "empty container means default DHCP parms are in effect."; leaf getDnsFromDhcp { description "If true, then the agent will use the DHCP provided DNS servers. Otherwise any pre-configured DNS servers will be used instead."; type boolean; default true; } } container static { leaf address { type inet:ip-address; mandatory true; } leaf subnetmask { type inet:ip-address; mandatory true; } leaf gateway { type inet:ip-address; mandatory true; } } } This data model works fine wrt/ default case. It does not make sense to simply delete /dhcp or its leaf. The agent will create it back again, as intended. I do not understand why YANG needs a CLR preventing this sort of data model. What difference does it make what child nodes are defined within 'dhcp'. Because it is a presence container, it is allowed to be an empty container. > > /martin > > Andy From prvs=alexd=3613c98aa@redback.com Mon Apr 27 09:07:01 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5898C3A68B9 for ; Mon, 27 Apr 2009 09:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dn0+vALgZrrW for ; Mon, 27 Apr 2009 09:06:58 -0700 (PDT) Received: from mgate-2.redback.com (mgate-2.redback.com [209.82.119.199]) by core3.amsl.com (Postfix) with ESMTP id 462F13A69A4 for ; Mon, 27 Apr 2009 09:06:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,255,1239001200"; d="scan'208";a="16307" Received: from unknown (HELO mailhost.van.redback.com) ([155.53.172.64]) by mgate-2.redback.com with ESMTP; 27 Apr 2009 09:08:18 -0700 Received: from [127.0.0.1] (unknown [155.53.189.235]) by mailhost.van.redback.com (Postfix) with ESMTP id 69E1F8C09A for ; Mon, 27 Apr 2009 09:08:18 -0700 (PDT) Message-ID: <49F5D871.2070901@redback.com> Date: Mon, 27 Apr 2009 09:08:17 -0700 From: Alex Dickinson User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: netmod@ietf.org References: <49F23566.4020602@redback.com> <49F263D1.8000704@netconfcentral.com> In-Reply-To: <49F263D1.8000704@netconfcentral.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Leaf node ambiguity in container elements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 16:08:41 -0000 Andy Bierman wrote: > Alex Dickinson wrote: >> Hello, >> >> Suppose I define the following container: >> >> container aaa { >> >> leaf bar { >> description: "Some configuration parameter" >> mandatory: false; >> type: string; >> } >> >> leaf bar { >> description: >> "Some other configuration parameter, but distinct from >> the first" >> mandatory: false; >> type: int; >> } >> } >> > > This is invalid YANG. > > Section 6.2.1, bullet 7: > > > o All leafs, leaf-lists, lists, containers, choices, rpcs, and > notifications defined within a parent node or at the top-level of > the module or its submodules share the same identifier namespace. > This namespace is scoped to the parent node or module, unless the > parent node is a case node. In that case, the namespace is scoped > to the parent node of the case node's parent choice node. > > > Andy > Ahhh, I see. Too many years of XML is blinding me I guess. Am I correct in saying that the namespace of the identifiers bar nodes defined in the aaa container would be in a namespace that is unique to the aaa container, and not that of the defining module? Thanks, Alex >> >> Now given the following XML instance document: >> >> >> 123 >> >> >> It is ambiguous as to which bar leaf node definition that the >> element represents. >> >> Are there any constraints present in the YANG spec that prevents the >> initial container from being formed? >> >> Cheers, >> Alex Dickinson >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> > > > > From andy@netconfcentral.com Mon Apr 27 09:57:13 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EB793A68E7 for ; Mon, 27 Apr 2009 09:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chZ-XSxxz94S for ; Mon, 27 Apr 2009 09:57:13 -0700 (PDT) Received: from n24.bullet.mail.mud.yahoo.com (n24.bullet.mail.mud.yahoo.com [68.142.206.163]) by core3.amsl.com (Postfix) with SMTP id D24433A6863 for ; Mon, 27 Apr 2009 09:57:12 -0700 (PDT) Received: from [68.142.194.244] by n24.bullet.mail.mud.yahoo.com with NNFMP; 27 Apr 2009 16:58:33 -0000 Received: from [68.142.201.249] by t2.bullet.mud.yahoo.com with NNFMP; 27 Apr 2009 16:58:33 -0000 Received: from [127.0.0.1] by omp410.mail.mud.yahoo.com with NNFMP; 27 Apr 2009 16:58:33 -0000 X-Yahoo-Newman-Id: 717474.33565.bm@omp410.mail.mud.yahoo.com Received: (qmail 39056 invoked from network); 27 Apr 2009 16:58:33 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.97.151 with plain) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 27 Apr 2009 16:58:32 -0000 X-YMail-OSG: wYnyauAVM1lWc7RPsN9Jptsu01wE0tl6UMlyrwAnrUxSkamUTW9dG_uUGbRIzvjogO9RPPRRGzMTvuornWSj5QfDgVb38Pzlii2sYTN7iTEVzHauTfSX6A_IuuaER4UKZQhxWOr4WtnOZ.uFWI1D.x37zijrkEaR6UwR16KmuVOAfsCu62X50Q2RTpMgP2wq9DlopPZ2ElB9RXyeACNZmfHW4y81cRcbbjmSLS3k3B7tVLKXCQkRSprjHrggXjf2x4rl.yBONvE1xWw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49F5E437.9090800@netconfcentral.com> Date: Mon, 27 Apr 2009 09:58:31 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Alex Dickinson References: <49F23566.4020602@redback.com> <49F263D1.8000704@netconfcentral.com> <49F5D871.2070901@redback.com> In-Reply-To: <49F5D871.2070901@redback.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Leaf node ambiguity in container elements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 16:57:13 -0000 Alex Dickinson wrote: > Andy Bierman wrote: >> Alex Dickinson wrote: >>> Hello, >>> >>> Suppose I define the following container: >>> >>> container aaa { >>> >>> leaf bar { >>> description: "Some configuration parameter" >>> mandatory: false; >>> type: string; >>> } >>> >>> leaf bar { >>> description: >>> "Some other configuration parameter, but distinct from >>> the first" >>> mandatory: false; >>> type: int; >>> } >>> } >>> >> This is invalid YANG. >> >> Section 6.2.1, bullet 7: >> >> >> o All leafs, leaf-lists, lists, containers, choices, rpcs, and >> notifications defined within a parent node or at the top-level of >> the module or its submodules share the same identifier namespace. >> This namespace is scoped to the parent node or module, unless the >> parent node is a case node. In that case, the namespace is scoped >> to the parent node of the case node's parent choice node. >> >> >> Andy >> > > Ahhh, I see. Too many years of XML is blinding me I guess. Am I correct > in saying that the namespace of the identifiers bar nodes defined in the > aaa container would be in a namespace that is unique to the aaa > container, and not that of the defining module? > yes. I guess sentences 2 and 3 are confusing. The choice and case nodes are not present in the XML, so they do no not define a naming scope in the YANG module either. > Thanks, > Alex Andy From mbj@tail-f.com Mon Apr 27 10:18:35 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA9263A68E7 for ; Mon, 27 Apr 2009 10:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpYvLUYpmUl6 for ; Mon, 27 Apr 2009 10:18:35 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A11213A6901 for ; Mon, 27 Apr 2009 10:18:34 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 76450616005; Mon, 27 Apr 2009 19:19:54 +0200 (CEST) Date: Mon, 27 Apr 2009 19:19:54 +0200 (CEST) Message-Id: <20090427.191954.162259350.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49F5D3C5.3020904@netconfcentral.com> References: <49F19F93.7080608@netconfcentral.com> <20090427.165323.11937488.mbj@tail-f.com> <49F5D3C5.3020904@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 17:18:35 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >>> Andy Bierman wrote: > >>>> Martin Bjorklund wrote: > >>>>> I'm not sure I understand what you mean with "substituting defaults", > >>>>> but 7.9.3 says: > >>>>> The default case is only important when considering the default > >>>>> values of nodes under the cases. The default values for nodes under > >>>>> the default case are used if none of the nodes under any of the cases > >>>>> are present. > >>>>> This means that if no case is present in your configuration, nothing > >>>>> special happens, since there are no default values under the default > >>>>> case. Maybe our tools should give a warning about this... > >>>>> > >>>> I'm not sure I interpreted/implemented this correctly. > >>>> I probably create because it is a P container. > >>>> > >>>> Clearly, if 'foo' was an NP-container, it would not > >>>> be added as the default unless it had child nodes > >>>> that had defaults. > >>>> > >>>> Lists and leaf-lists do not get entries created by default. > >>>> That is also clear. > >>>> > >>>> But why not presence containers? > >>> We want this to work with all flavors of :with-defaults. In some > >>> systems defaults are actually not stored in the data store. If a leaf > >>> does not exist in the data store, its default value is used. If a P > >>> container doesn't exist, with your suggestion above, the application > >>> would treat it as if it existed. But this means that there is no > >>> difference to the application if it exists or not! Another way to > >>> understand > >>> this is that default values are not sent > >>> unless with-defaults is "true" in the request. So if a P container > >>> would exist by default, it would not be sent if with-defaults is > >>> false. How can you differentiate this with the case that the P > >>> container is explicitly removed? In both cases it is not there. > >>> > >> I don't agree with this logic at all. > >> > >> The data modeler can decide if the default case makes sense > >> or not. It makes no difference whether the default case > >> is a leaf or a P container. In my perfectly valid use case, > >> there are semantics associated with the agent-selected default > >> of 'plain DCHP'. If the node was a leaf of type 'empty' > >> then everything is fine. > > No, that not how choice defaults work. If I understand you correctly, > > you mean that with this model: > > list foo { > > key name; > > leaf name { type string; } > > choice bar { > > default "tcp"; > > case tcp { > > leaf tcp { type empty; } > > } > > case udp { > > leaf tcp { type empty; } > > } > > } > > } > > If I create: > > > > t1 > > > > Then /foo/tcp gets automatically created by the agent? > > And you suggest that the same happens if 'tcp' is a P container? > > But the same does not happen if 'tcp' is a leaf of type boolean? > > After my create in the example above, suppose I do: > > > > t1 > > > > > > Is 'tcp' deleted or not? > > > > no -- just the same as any other time you > try to delete the default case. Ok, and would a P container behave like this only when it is a child of a default case? The rule would be that if a default case has a P container or a leaf of type empty, then this node is automatically created by the agent if no nodes from the choice is present? A P container under a list would not behave like this? > choice dhcp-or-static { > default dhcp; > > container dhcp { > presence > "empty container means default DHCP parms are in effect."; > leaf getDnsFromDhcp { > description > "If true, then the agent will use the DHCP provided > DNS servers. Otherwise any pre-configured DNS servers > will be used instead."; > type boolean; > default true; > } > } > container static { > leaf address { type inet:ip-address; mandatory true; } > leaf subnetmask { type inet:ip-address; mandatory true; } > leaf gateway { type inet:ip-address; mandatory true; } > } > } > > This data model works fine wrt/ default case. > It does not make sense to simply delete /dhcp or its leaf. > The agent will create it back again, as intended. > > I do not understand why YANG needs a CLR preventing this > sort of data model. In this case, you will get what you are looking for by making dhcp a NP-container. /martin From andy@netconfcentral.com Mon Apr 27 10:33:21 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DCA33A6DC9 for ; Mon, 27 Apr 2009 10:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGrpiWNBg3C5 for ; Mon, 27 Apr 2009 10:33:20 -0700 (PDT) Received: from n20.bullet.mail.mud.yahoo.com (n20.bullet.mail.mud.yahoo.com [68.142.206.147]) by core3.amsl.com (Postfix) with SMTP id AC7CD3A6FFB for ; Mon, 27 Apr 2009 10:32:28 -0700 (PDT) Received: from [68.142.200.221] by n20.bullet.mail.mud.yahoo.com with NNFMP; 27 Apr 2009 17:33:49 -0000 Received: from [68.142.201.252] by t9.bullet.mud.yahoo.com with NNFMP; 27 Apr 2009 17:33:49 -0000 Received: from [127.0.0.1] by omp413.mail.mud.yahoo.com with NNFMP; 27 Apr 2009 17:33:49 -0000 X-Yahoo-Newman-Id: 564937.12172.bm@omp413.mail.mud.yahoo.com Received: (qmail 7494 invoked from network); 27 Apr 2009 17:33:49 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.97.151 with plain) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 27 Apr 2009 17:33:48 -0000 X-YMail-OSG: lCevfJcVM1l9P7_Y58l4rInk56b5L8MvF_y6wM.GyMzrRF5SFcWomfpKxa3ZSgPZWXstqiNjhWCQ.LQu6icTRya4CBicwObdgSwo0qRzxgm4OCUhAQDY4pJMgLrM_2A9sy7g94eXFgy8ORwHecAq.tpjvfLwIpKfp__W.Y99r1UnY3xpC5eJ37ErAS7fmqFmscdIAh4qMS1Rrd1Sggj_us.X9CF59iy2DpQ9GkRnQ4nhtRkIndj09RWvK4LuJc8tbPf1DDJH6ZxaUPTEoZjQiyl4oCkVI.dW0qZM9ASd3QHc9wq.xZJH494M8k8zc4t5Fn.9tLZk2Qdqa3D.6XojAlAIiKzx9oX.f25vLruFoNZ9zj_E X-Yahoo-Newman-Property: ymail-3 Message-ID: <49F5EC7B.9050702@netconfcentral.com> Date: Mon, 27 Apr 2009 10:33:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <49F19F93.7080608@netconfcentral.com> <20090427.165323.11937488.mbj@tail-f.com> <49F5D3C5.3020904@netconfcentral.com> <20090427.191954.162259350.mbj@tail-f.com> In-Reply-To: <20090427.191954.162259350.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 17:33:21 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Martin Bjorklund wrote: >>>>> Andy Bierman wrote: >>>>>> Martin Bjorklund wrote: >>>>>>> I'm not sure I understand what you mean with "substituting defaults", >>>>>>> but 7.9.3 says: >>>>>>> The default case is only important when considering the default >>>>>>> values of nodes under the cases. The default values for nodes under >>>>>>> the default case are used if none of the nodes under any of the cases >>>>>>> are present. >>>>>>> This means that if no case is present in your configuration, nothing >>>>>>> special happens, since there are no default values under the default >>>>>>> case. Maybe our tools should give a warning about this... >>>>>>> >>>>>> I'm not sure I interpreted/implemented this correctly. >>>>>> I probably create because it is a P container. >>>>>> >>>>>> Clearly, if 'foo' was an NP-container, it would not >>>>>> be added as the default unless it had child nodes >>>>>> that had defaults. >>>>>> >>>>>> Lists and leaf-lists do not get entries created by default. >>>>>> That is also clear. >>>>>> >>>>>> But why not presence containers? >>>>> We want this to work with all flavors of :with-defaults. In some >>>>> systems defaults are actually not stored in the data store. If a leaf >>>>> does not exist in the data store, its default value is used. If a P >>>>> container doesn't exist, with your suggestion above, the application >>>>> would treat it as if it existed. But this means that there is no >>>>> difference to the application if it exists or not! Another way to >>>>> understand >>>>> this is that default values are not sent >>>>> unless with-defaults is "true" in the request. So if a P container >>>>> would exist by default, it would not be sent if with-defaults is >>>>> false. How can you differentiate this with the case that the P >>>>> container is explicitly removed? In both cases it is not there. >>>>> >>>> I don't agree with this logic at all. >>>> >>>> The data modeler can decide if the default case makes sense >>>> or not. It makes no difference whether the default case >>>> is a leaf or a P container. In my perfectly valid use case, >>>> there are semantics associated with the agent-selected default >>>> of 'plain DCHP'. If the node was a leaf of type 'empty' >>>> then everything is fine. >>> No, that not how choice defaults work. If I understand you correctly, >>> you mean that with this model: >>> list foo { >>> key name; >>> leaf name { type string; } >>> choice bar { >>> default "tcp"; >>> case tcp { >>> leaf tcp { type empty; } >>> } >>> case udp { >>> leaf tcp { type empty; } >>> } >>> } >>> } >>> If I create: >>> >>> t1 >>> >>> Then /foo/tcp gets automatically created by the agent? >>> And you suggest that the same happens if 'tcp' is a P container? >>> But the same does not happen if 'tcp' is a leaf of type boolean? >>> After my create in the example above, suppose I do: >>> >>> t1 >>> >>> >>> Is 'tcp' deleted or not? >>> >> no -- just the same as any other time you >> try to delete the default case. > > Ok, and would a P container behave like this only when it is a child > of a default case? The rule would be that if a default case has a P > container or a leaf of type empty, then this node is automatically > created by the agent if no nodes from the choice is present? > > A P container under a list would not behave like this? > correct -- IMO this makes the default case consistent with the leaf default. It is the default-stmt causing the automatic creation, not the P container itself. > >> choice dhcp-or-static { >> default dhcp; >> >> container dhcp { >> presence >> "empty container means default DHCP parms are in effect."; >> leaf getDnsFromDhcp { >> description >> "If true, then the agent will use the DHCP provided >> DNS servers. Otherwise any pre-configured DNS servers >> will be used instead."; >> type boolean; >> default true; >> } >> } >> container static { >> leaf address { type inet:ip-address; mandatory true; } >> leaf subnetmask { type inet:ip-address; mandatory true; } >> leaf gateway { type inet:ip-address; mandatory true; } >> } >> } >> >> This data model works fine wrt/ default case. >> It does not make sense to simply delete /dhcp or its leaf. >> The agent will create it back again, as intended. >> >> I do not understand why YANG needs a CLR preventing this >> sort of data model. > > In this case, you will get what you are looking for by making dhcp a > NP-container. > true, but what about an empty P container that is defined just so it can be augmented? That might be rare, but maybe not. What if some WG cannot agree on any of the exact DHCP parameters to define, but they can agree on the concept of a flag to have some indication of which choice is made (dhcp-or-static)? An empty NP container should be deleted by the agent, so it is only an empty P container that would make sense for the default case. > > /martin > > Andy From dromasca@avaya.com Tue Apr 28 04:32:44 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E413A6FC1 for ; Tue, 28 Apr 2009 04:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poelnJXn2XFe for ; Tue, 28 Apr 2009 04:32:43 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id A94683A6B05 for ; Tue, 28 Apr 2009 04:32:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,260,1238990400"; d="scan'208";a="144293258" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 Apr 2009 07:34:02 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 28 Apr 2009 07:34:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Apr 2009 13:33:57 +0200 Message-ID: In-Reply-To: <200904271931.n3RJVNDZ074545@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Arch draft comments Thread-Index: AcnHck9GRwJmajoZQzqEajYCRrM5YwAfnE8w References: <200904271931.n3RJVNDZ074545@idle.juniper.net> From: "Romascanu, Dan (Dan)" To: "Phil Shafer" Cc: netmod@ietf.org Subject: Re: [netmod] Arch draft comments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 11:32:44 -0000 Here are my comments and questions. I apologize for the delay.=20 Regards, Dan 1. In the Abstract you say ' NETCONF and YANG are pieces of an ambitious plan to improve network management.'. Please keep your hidden agenda in the dark :-) Neither NETCONF nor YANG were chartered with such ambitious plans. I suggest to reformulate the phrasing keeping the scope to what was approved by consensus in the IETF (configuration management, notifications capabilities). You can certainly mention that the architecture is extensible and may cover more management functionality in the future, but better keep it less declarative at this phase. The title should also rather be 'A NETCONF and NETMOD based Architecture for Network Management'.=20 2. 'This document describes how NETCONF and YANG help build network management applications that meet the needs of network services providers.' I would rather say 'network operators' than 'network service providers'. There is nothing in NETCONF and YANG that prevents them being used in enterprise networks or home networks.=20 3. I prefer to refer to NETMOD rather than YANG in the general sections. The document is about how NETCONF and NETMOD architecture works, with NETMOD including YANG, but not only YANG. From this perspective naming YIN a 'related technology' is misguiding. YIN is an integral part of the NETMOD architecture.=20 4. Editorial nit - Make YANG / yang capitalization consistent 5. I had a hard time in understanding what section 6 tries to tell. A device that includes an unacceptable deviations behavior may behave as unexpectedly you can get, and I cannot see how an application can 'expect' and deal with such implementations. Also the usage of the term 'node' in this section is misguiding - do you mean routers? But then people may use some NETCONF and NETMOD for hosts, or servers, or other network devices.=20 6. Section 7 does not seem to say anything useful 7. I am not sure that the Security Considerations section should be null. We are defining an architecture and not only a data modeling language in this document. Is there nothing to say for example about access-rights on the different elements of the management domain and how they are being kept or mapped in the different translations?=20 8. Should we say nothing about basic types in YANG and their extensibility? 9. Should we say nothing about the backwards (lack of) compatibility to SMI and the translation tools?=20 > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net]=20 > Sent: Monday, April 27, 2009 10:31 PM > To: Romascanu, Dan (Dan) > Subject: Arch draft comments >=20 > Dan, > In SF, you said you had some comments on the arch draft. > Could I please get them from you asap? >=20 > Thanks, > Phil >=20 From ietfdbh@comcast.net Tue Apr 28 05:19:43 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75A8328C201 for ; Tue, 28 Apr 2009 05:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mktoe2ruu01V for ; Tue, 28 Apr 2009 05:19:42 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 8B5E328C1F2 for ; Tue, 28 Apr 2009 05:19:42 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA10.westchester.pa.mail.comcast.net with comcast id l00g1b00f17dt5G5A0M1SG; Tue, 28 Apr 2009 12:21:01 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA13.westchester.pa.mail.comcast.net with comcast id l0M11b00E0UQ6dC3Z0M1E5; Tue, 28 Apr 2009 12:21:01 +0000 From: "David Harrington" To: "'Romascanu, Dan \(Dan\)'" , , References: Date: Tue, 28 Apr 2009 08:21:00 -0400 Message-ID: <02bb01c9c7fb$cab184c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnGgva03edne+kIQ1WDbI5buW0BNwBeMakA X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Cc: ngo@ietf.org Subject: Re: [netmod] The NGO List - EOL? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 12:19:43 -0000 I do not see a good reason to keep it open. dbh > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > Sent: Sunday, April 26, 2009 11:24 AM > To: netconf@ietf.org; netmod@ietf.org > Cc: ngo@ietf.org > Subject: [netmod] The NGO List - EOL? > > Is there any reason to keep the NGO (NETCONF Goes On) list alive? No > useful traffic seems to have been sent to that list for the last > calendar year. > > Dan > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From lhotka@cesnet.cz Tue Apr 28 07:46:39 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 914683A685F for ; Tue, 28 Apr 2009 07:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.973 X-Spam-Level: X-Spam-Status: No, score=-0.973 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XVUJkNtY135 for ; Tue, 28 Apr 2009 07:46:38 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7DD023A6B21 for ; Tue, 28 Apr 2009 07:45:56 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 4A029D800CE; Tue, 28 Apr 2009 16:47:17 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49F5EC7B.9050702@netconfcentral.com> References: <49F19F93.7080608@netconfcentral.com> <20090427.165323.11937488.mbj@tail-f.com> <49F5D3C5.3020904@netconfcentral.com> <20090427.191954.162259350.mbj@tail-f.com> <49F5EC7B.9050702@netconfcentral.com> Content-Type: text/plain Organization: CESNET Date: Tue, 28 Apr 2009 16:47:17 +0200 Message-Id: <1240930037.6728.48.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 14:46:39 -0000 Hi, how about this choice: choice one-or-two { default "one"; container one { leaf leaf1 { type uint8; default "1"; } } container two { leaf leaf2 { type uint8; default "2"; } } } Now, if the with-defaults=true document contains 2 the corresponding with-defaults=false document should probably have just However, in this case this empty NP container must not be removed, contrary to what sec. 7.5.7 says. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Apr 28 07:53:10 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14513A70D1 for ; Tue, 28 Apr 2009 07:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QD5uHzcj6PF for ; Tue, 28 Apr 2009 07:53:10 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 311E33A709C for ; Tue, 28 Apr 2009 07:53:10 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A1EB3616005; Tue, 28 Apr 2009 16:54:30 +0200 (CEST) Date: Tue, 28 Apr 2009 16:54:30 +0200 (CEST) Message-Id: <20090428.165430.81300938.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1240930037.6728.48.camel@missotis> References: <20090427.191954.162259350.mbj@tail-f.com> <49F5EC7B.9050702@netconfcentral.com> <1240930037.6728.48.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 14:53:11 -0000 Ladislav Lhotka wrote: > Hi, > > how about this choice: > > choice one-or-two { > default "one"; > container one { > leaf leaf1 { > type uint8; > default "1"; > } > } > container two { > leaf leaf2 { > type uint8; > default "2"; > } > } > } > > Now, if the with-defaults=true document contains > > > 2 > > > the corresponding with-defaults=false document should probably have just > > two wasn't the default case, so it must have been explicity created, and thus with-defaults false would reply with the same as with-defaults=true. But if we change the model a bit: container x { presence "..."; } and is created, a get with with-defaults=true would return: 1 and get with with-defaults=false would return: /martin From andy@netconfcentral.com Tue Apr 28 07:57:23 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACB6F28C1F9 for ; Tue, 28 Apr 2009 07:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LR3VVt29VXKq for ; Tue, 28 Apr 2009 07:57:23 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 0367F3A70F0 for ; Tue, 28 Apr 2009 07:57:11 -0700 (PDT) Received: (qmail 95250 invoked from network); 28 Apr 2009 14:58:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.97.151 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 28 Apr 2009 14:58:32 -0000 X-YMail-OSG: jZk5aUQVM1mOkxMWdCAPlZlP2a6N_a0CHZVCuS2Lh9hHlgz9DK4FZYBf6ExKAG2uOuHULql7E97obzxZKXM9qJ.4RUfitwTJXHkVxIDtN6UHr.xkQnR5xSYyTFUD2MrRbq.EZSrd.2KXKVsrKigoLXfhm0T1TEvbSwxXH3xVudwbZ9fVUdpXra4HYj4aGPmgFVg4XO9vkYvvTHgHuHfqSqkpgiolZsbp5OtddKWOvEIzP_aPcoWy1t4SCtT2d5n_PMy4JJlWEyB7_uAOYg_S0RroWt4kVxU3qtmELE8o_LXuYygkcIg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49F71995.2050201@netconfcentral.com> Date: Tue, 28 Apr 2009 07:58:29 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ladislav Lhotka References: <49F19F93.7080608@netconfcentral.com> <20090427.165323.11937488.mbj@tail-f.com> <49F5D3C5.3020904@netconfcentral.com> <20090427.191954.162259350.mbj@tail-f.com> <49F5EC7B.9050702@netconfcentral.com> <1240930037.6728.48.camel@missotis> In-Reply-To: <1240930037.6728.48.camel@missotis> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 14:57:23 -0000 Ladislav Lhotka wrote: > Hi, > > how about this choice: > > choice one-or-two { > default "one"; > container one { > leaf leaf1 { > type uint8; > default "1"; > } > } > container two { > leaf leaf2 { > type uint8; > default "2"; > } > } > } > > Now, if the with-defaults=true document contains > > > 2 > > > the corresponding with-defaults=false document should probably have just > > > You are mixing up the for a get operation with the contents of a NETCONF configuration database. The filtered contents within an do not have anything to do with the requirements for a valid configuration database. > However, in this case this empty NP container must not be removed, > contrary to what sec. 7.5.7 says. > > Lada > Andy From lhotka@cesnet.cz Tue Apr 28 08:04:31 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 346B83A6C5A for ; Tue, 28 Apr 2009 08:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.047 X-Spam-Level: X-Spam-Status: No, score=-0.047 tagged_above=-999 required=5 tests=[AWL=-0.656, BAYES_20=-0.74, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCvNggKQ2jot for ; Tue, 28 Apr 2009 08:04:30 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 78DF328C270 for ; Tue, 28 Apr 2009 08:02:16 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 0F586D800CE; Tue, 28 Apr 2009 17:03:38 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49F71995.2050201@netconfcentral.com> References: <49F19F93.7080608@netconfcentral.com> <20090427.165323.11937488.mbj@tail-f.com> <49F5D3C5.3020904@netconfcentral.com> <20090427.191954.162259350.mbj@tail-f.com> <49F5EC7B.9050702@netconfcentral.com> <1240930037.6728.48.camel@missotis> <49F71995.2050201@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Tue, 28 Apr 2009 17:03:38 +0200 Message-Id: <1240931018.6728.52.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 15:04:31 -0000 Andy Bierman píše v Út 28. 04. 2009 v 07:58 -0700: > > > > Now, if the with-defaults=true document contains > > > > > > 2 > > > > > > the corresponding with-defaults=false document should probably have just > > > > > > > > > You are mixing up the for a get operation > with the contents of a NETCONF configuration database. > The filtered contents within an do not > have anything to do with the requirements for a > valid configuration database. I don't think so. Both fragments above may be contained in get-reply data, the first if with-defaults is true and the second if with-defaults is false. Lada > > > > However, in this case this empty NP container must not be removed, > > contrary to what sec. 7.5.7 says. > > > > Lada > > > > Andy > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Tue Apr 28 08:14:58 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22FD73A7102 for ; Tue, 28 Apr 2009 08:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[AWL=-0.949, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnViJbu2kn20 for ; Tue, 28 Apr 2009 08:14:57 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 76F663A6CDC for ; Tue, 28 Apr 2009 08:14:57 -0700 (PDT) Received: (qmail 43972 invoked from network); 28 Apr 2009 15:16:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.97.151 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 28 Apr 2009 15:16:18 -0000 X-YMail-OSG: N69FB9kVM1kEYAUOhwSTlf2JtQOt4gYkVOHwQ86hV32yvWWXuFYbTutILPKW383wj13yneIyedQr3iBDCp5wuC_2IgSlCIN0yZ2UmISCjB0b3PkMXXjZyRsZEM3ehz0PxAzXzKMfj_uItnfzDXs8CwB.fHKJC39NdSsGO5BEhpmF3sDSfl1m2QAtSeiZuGXyUUDyKu9zF1Iby2z2s2KY1PoHPILR7VfCdAkGvjPYiGgi80FaPJPYhrgw51YDkh0sds9ymkqKamcKoieO3Ob3krb8s0ZRqfEDl2ETQAe7fsBm2.iT7GE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49F71DC0.6080906@netconfcentral.com> Date: Tue, 28 Apr 2009 08:16:16 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ladislav Lhotka References: <49F19F93.7080608@netconfcentral.com> <20090427.165323.11937488.mbj@tail-f.com> <49F5D3C5.3020904@netconfcentral.com> <20090427.191954.162259350.mbj@tail-f.com> <49F5EC7B.9050702@netconfcentral.com> <1240930037.6728.48.camel@missotis> <49F71995.2050201@netconfcentral.com> <1240931018.6728.52.camel@missotis> In-Reply-To: <1240931018.6728.52.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 15:14:58 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Út 28. 04. 2009 v 07:58 -0700: > >>> Now, if the with-defaults=true document contains >>> >>> >>> 2 >>> >>> >>> the corresponding with-defaults=false document should probably have just >>> >>> >>> >> >> You are mixing up the for a get operation >> with the contents of a NETCONF configuration database. >> The filtered contents within an do not >> have anything to do with the requirements for a >> valid configuration database. > > I don't think so. Both fragments above may be contained in get-reply > data, the first if with-defaults is true and the second if with-defaults > is false. > I do not see any problem here. Paragraph 3 of 7.5.7 says a manager needs to be aware that an agent may return either form of . So what's the problem? > Lada Andy From lhotka@cesnet.cz Tue Apr 28 08:17:55 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6758D3A6A63 for ; Tue, 28 Apr 2009 08:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.223 X-Spam-Level: X-Spam-Status: No, score=-0.223 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_05=-1.11, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rKVa3h0mtpC for ; Tue, 28 Apr 2009 08:17:54 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 71EB53A6452 for ; Tue, 28 Apr 2009 08:17:54 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 284F7D800CE; Tue, 28 Apr 2009 17:19:15 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090428.165430.81300938.mbj@tail-f.com> References: <20090427.191954.162259350.mbj@tail-f.com> <49F5EC7B.9050702@netconfcentral.com> <1240930037.6728.48.camel@missotis> <20090428.165430.81300938.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Tue, 28 Apr 2009 17:19:15 +0200 Message-Id: <1240931955.6728.67.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 15:17:55 -0000 Martin Bjorklund píše v Út 28. 04. 2009 v 16:54 +0200: > two wasn't the default case, so it must have been explicity created, > and thus with-defaults false would reply with the same as > with-defaults=true. > Yes, but the client could have explicitly created just the empty container and not the inner leaf2. Sec. 7.5.7 says: A NETCONF server that replies to a or request MAY choose not to send a container element if the container node does not have the "presence" statement and no child nodes exist. This is wrong here because removing switches to the default case "one". The same problem could IMO also happen with full case "two" explicitly created like this: 2 If the server sends a get reply and applies the "trim" method for suppressing defaults, it can 1. Remove leaf2, as its value equals to the default. 2. Following sec. 7.5.7, remove the empty NP container . Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Tue Apr 28 08:21:41 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 737D13A6BEA for ; Tue, 28 Apr 2009 08:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.032 X-Spam-Level: X-Spam-Status: No, score=-0.032 tagged_above=-999 required=5 tests=[AWL=-0.641, BAYES_20=-0.74, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YESwGXy7pXAV for ; Tue, 28 Apr 2009 08:21:40 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 8F2453A6D18 for ; Tue, 28 Apr 2009 08:20:58 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id CF086D800CE; Tue, 28 Apr 2009 17:22:19 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49F71DC0.6080906@netconfcentral.com> References: <49F19F93.7080608@netconfcentral.com> <20090427.165323.11937488.mbj@tail-f.com> <49F5D3C5.3020904@netconfcentral.com> <20090427.191954.162259350.mbj@tail-f.com> <49F5EC7B.9050702@netconfcentral.com> <1240930037.6728.48.camel@missotis> <49F71995.2050201@netconfcentral.com> <1240931018.6728.52.camel@missotis> <49F71DC0.6080906@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Tue, 28 Apr 2009 17:22:20 +0200 Message-Id: <1240932140.6728.70.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 15:21:41 -0000 Andy Bierman píše v Út 28. 04. 2009 v 08:16 -0700: > > I do not see any problem here. > Paragraph 3 of 7.5.7 says a manager needs to be aware > that an agent may return either form of . > So what's the problem? The problem is that if the agent removes the empty container , which it MAY do according to 7.5.7, the manager will interpret it as if 1 was sent. Lada > > > Lada > > Andy > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Tue Apr 28 08:36:47 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A9CC3A6BA3 for ; Tue, 28 Apr 2009 08:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzjkoR+-7AH8 for ; Tue, 28 Apr 2009 08:36:43 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id 634E828C256 for ; Tue, 28 Apr 2009 08:36:21 -0700 (PDT) Received: (qmail 29931 invoked from network); 28 Apr 2009 15:37:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.97.151 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 28 Apr 2009 15:37:38 -0000 X-YMail-OSG: MPFSYzAVM1n7kg6thH1616mdKnq2QjFzRmL0Y7eYdlyxf9901yqQFCdSHUvC8Vj7gTFrgBuGkeSD.JNmmwo7OgUUQkTrS3s_UcRBp2UfLA0EKhm1J5xekUy6q.ajdGe4ae7wAPn5tjHOfxFXblOgtOCaVVNWuGIpb_IaeHA5OXzqQrJ_iB3MKdhtOTwqiIKMfGj5pzPUHv9Anii2XodEqRairXnev5tLS2WRV5dgaXUd_sR4xzfyn7KzHqzitsxn.WUxghh0Aq5Sew6QtJzA6KxBJx.1Cs9LgdhstiguuJxFWwaqNuE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49F722C0.6040900@netconfcentral.com> Date: Tue, 28 Apr 2009 08:37:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ladislav Lhotka References: <20090427.191954.162259350.mbj@tail-f.com> <49F5EC7B.9050702@netconfcentral.com> <1240930037.6728.48.camel@missotis> <20090428.165430.81300938.mbj@tail-f.com> <1240931955.6728.67.camel@missotis> In-Reply-To: <1240931955.6728.67.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 15:36:47 -0000 Ladislav Lhotka wrote: > Martin Bjorklund píše v Út 28. 04. 2009 v 16:54 +0200: > >> two wasn't the default case, so it must have been explicity created, >> and thus with-defaults false would reply with the same as >> with-defaults=true. >> > > Yes, but the client could have explicitly created just the empty > container and not the inner leaf2. Sec. 7.5.7 says: > > A NETCONF server that replies to a or request MAY > choose not to send a container element if the container node does not > have the "presence" statement and no child nodes exist. > > This is wrong here because removing switches to the default case "one". > What does or have to do with deleting nodes from the database? That requires an operation. > The same problem could IMO also happen with full case "two" explicitly created like this: > > 2 > > If the server sends a get reply and applies the "trim" method for > suppressing defaults, it can > > 1. Remove leaf2, as its value equals to the default. > 2. Following sec. 7.5.7, remove the empty NP container . > > Lada > Andy From andy@netconfcentral.com Tue Apr 28 08:41:39 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C76928C1DF for ; Tue, 28 Apr 2009 08:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYB4ENx1qq0O for ; Tue, 28 Apr 2009 08:41:38 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 5F39E3A6A21 for ; Tue, 28 Apr 2009 08:41:11 -0700 (PDT) Received: (qmail 51356 invoked from network); 28 Apr 2009 15:42:33 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.97.151 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 28 Apr 2009 15:42:32 -0000 X-YMail-OSG: pvn1TWkVM1l4G_W8be2QRqnnMI19UQdkjUatPDzFdDxGKSOBxmDDkDML4691qFADcxtBIEeiRBRMgZs9Bxdbo4sIgPtkGGg_FqtxczdlR5IOw5KimhD7UKlGfn1kR20awu2wVvw4a_g6nrfSQ0H70vn2oFJcdCLGm5knMCoM82EqeyMB.uU1RKp5TqUGbIuLgbY6B4sF95KL.6MWEysZrRq66oH1k.adMbdYAp3fHKqXkSCF4k90vZ30xajqfoZefaImTyz2I4UEVhLWKH4l3gdR.iSVMkPhoHk0TS_dmuGbdQXIp48- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49F723E6.4060700@netconfcentral.com> Date: Tue, 28 Apr 2009 08:42:30 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ladislav Lhotka References: <49F19F93.7080608@netconfcentral.com> <20090427.165323.11937488.mbj@tail-f.com> <49F5D3C5.3020904@netconfcentral.com> <20090427.191954.162259350.mbj@tail-f.com> <49F5EC7B.9050702@netconfcentral.com> <1240930037.6728.48.camel@missotis> <49F71995.2050201@netconfcentral.com> <1240931018.6728.52.camel@missotis> <49F71DC0.6080906@netconfcentral.com> <1240932140.6728.70.camel@missotis> In-Reply-To: <1240932140.6728.70.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 15:41:39 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Út 28. 04. 2009 v 08:16 -0700: > >> I do not see any problem here. >> Paragraph 3 of 7.5.7 says a manager needs to be aware >> that an agent may return either form of . >> So what's the problem? > > The problem is that if the agent removes the empty container , > which it MAY do according to 7.5.7, the manager will interpret it as if > 1 was sent. > The results of an arbitrary subtree or XPath filtered retrieval via or may need to be interpreted with some knowledge of the original filter. Arbitrary sub-trees may be missing, as requested by the filter. > Lada > >>> Lada >> Andy >> Andy From lhotka@cesnet.cz Tue Apr 28 09:54:40 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 435DE3A6CB7 for ; Tue, 28 Apr 2009 09:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.023 X-Spam-Level: X-Spam-Status: No, score=-0.023 tagged_above=-999 required=5 tests=[AWL=-0.632, BAYES_20=-0.74, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xB4WKyE4MtnO for ; Tue, 28 Apr 2009 09:54:39 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 5FCEC3A6A12 for ; Tue, 28 Apr 2009 09:54:39 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id C21BDD800C7 for ; Tue, 28 Apr 2009 18:56:00 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <49F729CF.7070402@netconfcentral.com> References: <20090427.191954.162259350.mbj@tail-f.com> <49F5EC7B.9050702@netconfcentral.com> <1240930037.6728.48.camel@missotis> <20090428.165430.81300938.mbj@tail-f.com> <1240931955.6728.67.camel@missotis> <49F722C0.6040900@netconfcentral.com> <1240934321.6728.75.camel@missotis> <49F729CF.7070402@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Tue, 28 Apr 2009 18:56:01 +0200 Message-Id: <1240937761.6728.84.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 16:54:40 -0000 Andy Bierman píše v Út 28. 04. 2009 v 09:07 -0700: > >>> > >>> This is wrong here because removing switches to the default case "one". > >>> > >> What does or have to do with deleting > >> nodes from the database? That requires an > >> operation. > > > > It's not about removing anything from the database but about a NETCONF > > server that replies to a or request and chooses not > > to send the empty element. > > > > then why do you say it switches the default case to . > It does not. A get operation does not change the database. > Because if the server doesn't send the empty container so that nothing is present from any of the choice's cases, the manager should use the default values for nodes under the default case - this is how I interpret third paragraph of sec. 7.9.3. Lada > > > Lada > > Andy > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Tue Apr 28 10:04:05 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5855C28C1E5 for ; Tue, 28 Apr 2009 10:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c06g-SitT6pa for ; Tue, 28 Apr 2009 10:04:00 -0700 (PDT) Received: from n22a.bullet.mail.mud.yahoo.com (n22a.bullet.mail.mud.yahoo.com [68.142.207.188]) by core3.amsl.com (Postfix) with SMTP id 597E428C0F6 for ; Tue, 28 Apr 2009 10:04:00 -0700 (PDT) Received: from [68.142.200.224] by n22.bullet.mail.mud.yahoo.com with NNFMP; 28 Apr 2009 17:05:21 -0000 Received: from [68.142.201.71] by t5.bullet.mud.yahoo.com with NNFMP; 28 Apr 2009 17:05:21 -0000 Received: from [127.0.0.1] by omp423.mail.mud.yahoo.com with NNFMP; 28 Apr 2009 17:05:21 -0000 X-Yahoo-Newman-Id: 845571.4113.bm@omp423.mail.mud.yahoo.com Received: (qmail 17896 invoked from network); 28 Apr 2009 17:05:21 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.97.151 with plain) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 28 Apr 2009 17:05:20 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49F7374E.6070307@netconfcentral.com> Date: Tue, 28 Apr 2009 10:05:18 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ladislav Lhotka References: <20090427.191954.162259350.mbj@tail-f.com> <49F5EC7B.9050702@netconfcentral.com> <1240930037.6728.48.camel@missotis> <20090428.165430.81300938.mbj@tail-f.com> <1240931955.6728.67.camel@missotis> <49F722C0.6040900@netconfcentral.com> <1240934321.6728.75.camel@missotis> <49F729CF.7070402@netconfcentral.com> <1240937761.6728.84.camel@missotis> In-Reply-To: <1240937761.6728.84.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 17:04:05 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Út 28. 04. 2009 v 09:07 -0700: > >>>>> This is wrong here because removing switches to the default case "one". >>>>> >>>> What does or have to do with deleting >>>> nodes from the database? That requires an >>>> operation. >>> It's not about removing anything from the database but about a NETCONF >>> server that replies to a or request and chooses not >>> to send the empty element. >>> >> then why do you say it switches the default case to . >> It does not. A get operation does not change the database. >> > > Because if the server doesn't send the empty container so that > nothing is present from any of the choice's cases, the manager should > use the default values for nodes under the default case - this is how I > interpret third paragraph of sec. 7.9.3. > It depends on the filter. The YANG draft does not consider the affects of filtering on the contents. Perhaps there needs to be a sentence that says filtering mechanisms such as those defined by , , and the extension may alter the reply contents. > Lada > Andy From lhotka@cesnet.cz Tue Apr 28 11:14:01 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D57973A6FBA for ; Tue, 28 Apr 2009 11:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.945 X-Spam-Level: X-Spam-Status: No, score=-0.945 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9K5rsnY0Prjp for ; Tue, 28 Apr 2009 11:14:01 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 122F93A6A8D for ; Tue, 28 Apr 2009 11:14:01 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 3CEDFD800CE; Tue, 28 Apr 2009 20:15:22 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49F7374E.6070307@netconfcentral.com> References: <20090427.191954.162259350.mbj@tail-f.com> <49F5EC7B.9050702@netconfcentral.com> <1240930037.6728.48.camel@missotis> <20090428.165430.81300938.mbj@tail-f.com> <1240931955.6728.67.camel@missotis> <49F722C0.6040900@netconfcentral.com> <1240934321.6728.75.camel@missotis> <49F729CF.7070402@netconfcentral.com> <1240937761.6728.84.camel@missotis> <49F7374E.6070307@netconfcentral.com> Content-Type: text/plain; charset=UTF-8 Organization: CESNET Date: Tue, 28 Apr 2009 20:15:22 +0200 Message-Id: <1240942522.32511.8.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 18:14:01 -0000 Andy Bierman píše v Út 28. 04. 2009 v 10:05 -0700: > Ladislav Lhotka wrote: > > Andy Bierman píše v Út 28. 04. 2009 v 09:07 -0700: > > > >>>>> This is wrong here because removing switches to the default case "one". > >>>>> > >>>> What does or have to do with deleting > >>>> nodes from the database? That requires an > >>>> operation. > >>> It's not about removing anything from the database but about a NETCONF > >>> server that replies to a or request and chooses not > >>> to send the empty element. > >>> > >> then why do you say it switches the default case to . > >> It does not. A get operation does not change the database. > >> > > > > Because if the server doesn't send the empty container so that > > nothing is present from any of the choice's cases, the manager should > > use the default values for nodes under the default case - this is how I > > interpret third paragraph of sec. 7.9.3. > > > > It depends on the filter. > The YANG draft does not consider the affects of > filtering on the contents. Perhaps there > needs to be a sentence that says filtering mechanisms > such as those defined by , , and > the extension may alter the reply contents. The behavior I am talking about may occur for replies to get/get-config without any filters. The problem is that a non-presence container inside a choice's case in fact does have a meaning even if it is empty - its presence selects the case it is in, so it cannot be omitted at server's discretion. Lada > > > > Lada > > > Andy > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Apr 28 12:22:01 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54FFF3A6981 for ; Tue, 28 Apr 2009 12:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2VHYiSzh4Me for ; Tue, 28 Apr 2009 12:22:00 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7A5763A67EA for ; Tue, 28 Apr 2009 12:22:00 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 94CFA616005; Tue, 28 Apr 2009 21:23:20 +0200 (CEST) Date: Tue, 28 Apr 2009 21:23:20 +0200 (CEST) Message-Id: <20090428.212320.20024580.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1240931955.6728.67.camel@missotis> References: <1240930037.6728.48.camel@missotis> <20090428.165430.81300938.mbj@tail-f.com> <1240931955.6728.67.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 19:22:01 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiDDmnQgMjguIDA0LiAyMDA5IHYgMTY6NTQgKzAyMDA6DQo+IA0KPiA+IHR3 byB3YXNuJ3QgdGhlIGRlZmF1bHQgY2FzZSwgc28gaXQgbXVzdCBoYXZlIGJlZW4gZXhwbGljaXR5 IGNyZWF0ZWQsDQo+ID4gYW5kIHRodXMgd2l0aC1kZWZhdWx0cyBmYWxzZSB3b3VsZCByZXBseSB3 aXRoIHRoZSBzYW1lIGFzDQo+ID4gd2l0aC1kZWZhdWx0cz10cnVlLg0KPiA+IA0KPiANCj4gWWVz LCBidXQgdGhlIGNsaWVudCBjb3VsZCBoYXZlIGV4cGxpY2l0bHkgY3JlYXRlZCBqdXN0IHRoZSBl bXB0eQ0KPiBjb250YWluZXIgPHR3by8+IGFuZCBub3QgdGhlIGlubmVyIGxlYWYyLiBTZWMuIDcu NS43IHNheXM6DQo+IA0KPiBBIE5FVENPTkYgc2VydmVyIHRoYXQgcmVwbGllcyB0byBhIDxnZXQ+ IG9yIDxnZXQtY29uZmlnPiByZXF1ZXN0IE1BWQ0KPiBjaG9vc2Ugbm90IHRvIHNlbmQgYSBjb250 YWluZXIgZWxlbWVudCBpZiB0aGUgY29udGFpbmVyIG5vZGUgZG9lcyBub3QNCj4gaGF2ZSB0aGUg InByZXNlbmNlIiBzdGF0ZW1lbnQgYW5kIG5vIGNoaWxkIG5vZGVzIGV4aXN0Lg0KPiANCj4gVGhp cyBpcyB3cm9uZyBoZXJlIGJlY2F1c2UgcmVtb3ZpbmcgPHR3by8+IHN3aXRjaGVzIHRvIHRoZSBk ZWZhdWx0IGNhc2UgIm9uZSIuDQoNClRoZSBwcm9ibGVtIGlzIGluIHRoZSBkYXRhIG1vZGVsLiAg QW4gTlAtY29udGFpbmVyIGhhcyBubyBzZW1hbnRpYw0KbWVhbmluZywgc28gdGhlIGV4YW1wbGUg Y2FuIGJlIHNpbXBsaWZpZWQgaW50bzoNCg0KICAgIGNob2ljZSBvbmUtb3ItdHdvIHsNCiAgICAg IGRlZmF1bHQgIm9uZSI7DQogICAgICBjb250YWluZXIgb25lIHsNCiAgICAgICAgbGVhZiBsZWFm MSB7DQogICAgICAgICAgdHlwZSB1aW50ODsNCiAgICAgICAgICBkZWZhdWx0ICIxIjsNCiAgICAg ICAgfQ0KICAgICAgfQ0KICAgICAgY2FzZSB0d28geyAgICAgLy8gbm8gY29udGFpbmVyIGhlcmUh DQogICAgICAgIGxlYWYgbGVhZjIgew0KICAgICAgICAgIHR5cGUgdWludDg7DQogICAgICAgICAg ZGVmYXVsdCAiMiI7DQogICAgICAgIH0NCiAgICAgIH0NCiAgICB9DQoNCkluIG9yZGVyIGZvciBh IG5vbi1kZWZhdWx0IGNhc2UgdG8gbWFrZSBzZW5zZSwgeW91IG5lZWQgdG8gaGF2ZSBzb21lDQpu b2RlcyBpbiB0aGUgY2FzZSB3aGVyZSB0aGVpciBwcmVzZW5jZSBtYWtlIHNlbnNlLCBpLmUuIGEg bGlzdCwNCmxlYWYtbGlzdCwgbGVhZiB3L28gZGVmYXVsdCB2YWx1ZSwgb3IgYSBQLWNvbnRhaW5l ci4gIFRoZSByZWFzb24gZm9yDQp0aGlzIGlzIHRoYXQgdGhlIHNlbGVjdGVkIGNhc2UgaXMgbm90 IGV4cGxpY2l0bHkgcHJlc2VudCBpbiB0aGUgWE1MLg0KDQoNCi9tYXJ0aW4NCg== From Washam.Fan@huaweisymantec.com Tue Apr 28 19:13:56 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE71C3A6C22 for ; Tue, 28 Apr 2009 19:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkTmdp8i3Dh6 for ; Tue, 28 Apr 2009 19:13:56 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id C15063A689C for ; Tue, 28 Apr 2009 19:13:55 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KIU00C6TBLC1G10@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Wed, 29 Apr 2009 10:15:14 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KIU00AAVBLASS20@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Wed, 29 Apr 2009 10:15:12 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 29 Apr 2009 10:15:10 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Wed, 29 Apr 2009 10:15:10 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090428.212320.20024580.mbj@tail-f.com> References: <1240930037.6728.48.camel@missotis> <20090428.165430.81300938.mbj@tail-f.com> <1240931955.6728.67.camel@missotis> <20090428.212320.20024580.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 02:13:56 -0000 > The problem is in the data model. An NP-container has no semantic > meaning, so the example can be simplified into: > > choice one-or-two { > default "one"; > container one { > leaf leaf1 { > type uint8; > default "1"; > } > } > case two { // no container here! > leaf leaf2 { > type uint8; > default "2"; > } > } > } Suppose case two has been chosen in the datastore, then I issue report-all 2 would be returned, right? But what if I issue trim nothing about the choice content would be returned, right? washam > In order for a non-default case to make sense, you need to have some > nodes in the case where their presence make sense, i.e. a list, > leaf-list, leaf w/o default value, or a P-container. The reason for > this is that the selected case is not explicitly present in the XML. > > > /martin From lhotka@cesnet.cz Tue Apr 28 22:09:13 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEA043A6CBF for ; Tue, 28 Apr 2009 22:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwryobVbM85K for ; Tue, 28 Apr 2009 22:09:11 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 202683A689C for ; Tue, 28 Apr 2009 22:09:10 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id F1CB7D800C8; Wed, 29 Apr 2009 07:10:31 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090428.212320.20024580.mbj@tail-f.com> References: <1240930037.6728.48.camel@missotis> <20090428.165430.81300938.mbj@tail-f.com> <1240931955.6728.67.camel@missotis> <20090428.212320.20024580.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 29 Apr 2009 07:10:31 +0200 Message-Id: <1240981831.6411.12.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 05:09:15 -0000 Martin Bjorklund píše v Út 28. 04. 2009 v 21:23 +0200: > Ladislav Lhotka wrote: > > Martin Bjorklund píše v Út 28. 04. 2009 v 16:54 +0200: > > > > > two wasn't the default case, so it must have been explicity created, > > > and thus with-defaults false would reply with the same as > > > with-defaults=true. > > > > > > > Yes, but the client could have explicitly created just the empty > > container and not the inner leaf2. Sec. 7.5.7 says: > > > > A NETCONF server that replies to a or request MAY > > choose not to send a container element if the container node does not > > have the "presence" statement and no child nodes exist. > > > > This is wrong here because removing switches to the default case "one". > > The problem is in the data model. An NP-container has no semantic > meaning, so the example can be simplified into: Well, there could be multiple leafs with default values in each container, so an NP container can be used exactly what it is intended for - organizing the data. > > choice one-or-two { > default "one"; > container one { > leaf leaf1 { > type uint8; > default "1"; > } > } > case two { // no container here! > leaf leaf2 { > type uint8; > default "2"; > } > } > } > > In order for a non-default case to make sense, you need to have some > nodes in the case where their presence make sense, i.e. a list, > leaf-list, leaf w/o default value, or a P-container. The reason for > this is that the selected case is not explicitly present in the XML. I think the empty container makes sense in my example - it selects the particular case and activates the default leaf values for that case. I agree that the container then behaves more like a P container but the example with NP containers is valid YANG, too, and can lead to interoperability problems. Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Tue Apr 28 22:14:46 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 950F03A6B08 for ; Tue, 28 Apr 2009 22:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.952 X-Spam-Level: X-Spam-Status: No, score=-0.952 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41OQP4wgwzKT for ; Tue, 28 Apr 2009 22:14:44 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C4EA83A67D8 for ; Tue, 28 Apr 2009 22:14:43 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 9F989D800C7; Wed, 29 Apr 2009 07:16:05 +0200 (CEST) From: Ladislav Lhotka To: WashamFan In-Reply-To: References: <1240930037.6728.48.camel@missotis> <20090428.165430.81300938.mbj@tail-f.com> <1240931955.6728.67.camel@missotis> <20090428.212320.20024580.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 29 Apr 2009 07:16:05 +0200 Message-Id: <1240982165.6411.18.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] choice's default case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 05:14:46 -0000 WashamFan píše v St 29. 04. 2009 v 10:15 +0800: > > Suppose case two has been chosen in the datastore, then I issue > > > report-all > > > 2 would be returned, right? > > But what if I issue > > > trim > > > nothing about the choice content would be returned, right? If this happens, the manager should again assume the default case to be present, so it leads to the same problem as in my example. Lada > > washam > > > In order for a non-default case to make sense, you need to have some > > nodes in the case where their presence make sense, i.e. a list, > > leaf-list, leaf w/o default value, or a P-container. The reason for > > this is that the selected case is not explicitly present in the XML. > > > > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From root@core3.amsl.com Wed Apr 29 07:15:01 2009 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B653528C24F; Wed, 29 Apr 2009 07:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090429141501.B653528C24F@core3.amsl.com> Date: Wed, 29 Apr 2009 07:15:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-dsdl-map-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 14:15:01 -0000 --NextPart 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 : Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content Author(s) : L. Lhotka, et al. Filename : draft-ietf-netmod-dsdl-map-02.txt Pages : 102 Date : 2009-04-29 This draft describes the mapping rules for translating YANG data models into XML schemas using Document Schema Definition Languages (DSDL) and outlines the procedure for validating various types of NETCONF protocol data units using these schemas. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-dsdl-map-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-dsdl-map-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-29071426.I-D@ietf.org> --NextPart-- From lhotka@cesnet.cz Wed Apr 29 07:22:08 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D04D3A67F3 for ; Wed, 29 Apr 2009 07:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.956 X-Spam-Level: X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5uqHdWeRxCI for ; Wed, 29 Apr 2009 07:22:07 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D6C9028C2B8 for ; Wed, 29 Apr 2009 07:21:58 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 1F152D800C8 for ; Wed, 29 Apr 2009 16:23:20 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain; charset=UTF-8 Organization: CESNET Date: Wed, 29 Apr 2009 16:23:19 +0200 Message-Id: <1241014999.7958.4.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: [netmod] [Fwd: New Version Notification for draft-ietf-netmod-dsdl-map-02] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 14:22:08 -0000 Hi, the main new thing in this version is sec. 9.4 about mapping defaults to DSRL. Any comments will be appreciated. Lada -------- Přeposlaná zpráva -------- Od: IETF I-D Submission Tool Komu: lhotka@cesnet.cz Kopie: rohan@ekabal.com, schishol@nortel.com Předmět: New Version Notification for draft-ietf-netmod-dsdl-map-02 Datum: Wed, 29 Apr 2009 07:14:27 -0700 (PDT) A new version of I-D, draft-ietf-netmod-dsdl-map-02.txt has been successfuly submitted by Ladislav Lhotka and posted to the IETF repository. Filename: draft-ietf-netmod-dsdl-map Revision: 02 Title: Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content Creation_date: 2009-04-29 WG ID: netmod Number_of_pages: 102 Abstract: This draft describes the mapping rules for translating YANG data models into XML schemas using Document Schema Definition Languages (DSDL) and outlines the procedure for validating various types of NETCONF protocol data units using these schemas. The IETF Secretariat. -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From david.partain@ericsson.com Thu Apr 30 00:04:08 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F48C3A6E3F for ; Thu, 30 Apr 2009 00:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.846 X-Spam-Level: X-Spam-Status: No, score=-5.846 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9t487TkiS-4j for ; Thu, 30 Apr 2009 00:04:07 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6225B3A6DEA for ; Thu, 30 Apr 2009 00:04:07 -0700 (PDT) X-AuditID: c1b4fb3c-b7b4bae000001105-98-49f94db4552e Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 7F.E8.04357.4BD49F94; Thu, 30 Apr 2009 09:05:24 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 09:04:22 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 09:04:22 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Thu, 30 Apr 2009 09:04:21 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904300904.21808.david.partain@ericsson.com> X-OriginalArrivalTime: 30 Apr 2009 07:04:22.0674 (UTC) FILETIME=[E3BF3720:01C9C961] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Working Group Last Call: draft-ietf-netmod-yang-05.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 07:04:08 -0000 Dear all, This is the working group last call on the current working group document: - YANG - A data modeling language for NETCONF: http://tools.ietf.org/html/draft-ietf-netmod-yang-05.txt The authors and the chairs think that this document is mature enough for WGLC. This WGLC will last until May 15, 2009. Please review and send comments to this list. Thanks. David^2 From wjhns1@hardakers.net Thu Apr 30 07:16:46 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B566D3A7175 for ; Thu, 30 Apr 2009 07:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_20=-0.74, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfqww-YqqmLG for ; Thu, 30 Apr 2009 07:16:46 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 6FE7D28C28A for ; Thu, 30 Apr 2009 07:16:31 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 7420539A0F4; Thu, 30 Apr 2009 07:17:54 -0700 (PDT) From: Wes Hardaker To: David Partain Organization: Sparta References: <200904300904.21808.david.partain@ericsson.com> Date: Thu, 30 Apr 2009 07:17:54 -0700 In-Reply-To: <200904300904.21808.david.partain@ericsson.com> (David Partain's message of "Thu, 30 Apr 2009 09:04:21 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] Working Group Last Call: draft-ietf-netmod-yang-05.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 14:16:46 -0000 >>>>> On Thu, 30 Apr 2009 09:04:21 +0200, David Partain said: DP> The authors and the chairs think that this document is mature enough DP> for WGLC. This WGLC will last until May 15, 2009. I've seen working groups have longer last calls for large documents before. Since this is a 174 page document, you might consider that. Or, if you're confident that only the standard few will be reading it (again) this time then it doesn't make sense to lengthen it. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett